--- 1/draft-ietf-cdni-logging-07.txt 2013-10-18 02:14:27.716769467 -0700 +++ 2/draft-ietf-cdni-logging-08.txt 2013-10-18 02:14:27.808771736 -0700 @@ -1,22 +1,22 @@ Internet Engineering Task Force F. Le Faucheur, Ed. Internet-Draft Cisco Systems Intended status: Standards Track G. Bertrand, Ed. -Expires: April 13, 2014 I. Oprescu, Ed. +Expires: April 21, 2014 I. Oprescu, Ed. Orange R. Peterkofsky Skytide, Inc. - October 10, 2013 + October 18, 2013 CDNI Logging Interface - draft-ietf-cdni-logging-07 + draft-ietf-cdni-logging-08 Abstract This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 13, 2014. + This Internet-Draft will expire on April 21, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -79,35 +79,35 @@ 3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 21 3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 22 3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 29 4. CDNI Logging File Exchange Protocol . . . . . . . . . . . . . 30 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 30 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 31 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 31 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 32 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 32 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 33 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 - 5.1. CDNI Logging Directive Names Registry . . . . . . . . . . 34 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 + 5.1. CDNI Logging Directive Names Registry . . . . . . . . . . 35 5.2. CDNI Logging Record-Types Registry . . . . . . . . . . . 35 - 5.3. CDNI Logging Field Names Registry . . . . . . . . . . . . 35 - 5.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 36 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 - 6.1. Authentication, Confidentiality, Integrity Protection . . 36 - 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 37 - + 5.3. CDNI Logging Field Names Registry . . . . . . . . . . . . 36 + 5.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 37 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 + 6.1. Authentication, Confidentiality, Integrity Protection . . 37 + 6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 38 + 6.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 38 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 38 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 39 8.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. Compliance with CDNI Requirements . . . . . . . . . 40 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction This memo specifies the CDNI Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN). First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. The reader should be familiar with the following documents: @@ -1348,43 +1349,42 @@ 3.5. CDNI Logging File Example #Version:CDNI/1.0 #UUID:"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" #Claimed-Origin:cdni-logging-entity.dcdn.example.com #Record-Type:cdni_http_request_v1 - #Fields:datetimetime-takenc-ipcs- + #Fields:datetimetime-takenc-ipcs- methodu-uriprotocolsc-statussc-total- bytescs(User-Agent)cs(Referer)s-cached 2013-05-1700:38:06.8259.05810.5.7.1GETh ttp://cdni-ucdn.dcdn.example.com/video/movie100.mp4HTTP/ 1.12006729891"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4""host1.example.com"1 2013-05-1700:39:09.14515.3210.5.10.5GET http://cdni-ucdn.dcdn.example.com/video/movie118.mp4HTTP/ 1.120015799210"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4""host1.example.com"1 2013-05-1700:42:53.43752.87910.5.10.5GEThttp://cdni-ucdn.dcdn.example.com/video/picture11.mp4HTTP/ 1.020097234724"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari /533.4""host5.example.com"0 - #Integrity-Hash: 9e107d9d372bb6826bd81d3542a419d6 [Editor's Note: - include the correct MD5-hash value for the actual example] + #Integrity-Hash:fe113dfce8fec91323a4fc02261af26e 4. CDNI Logging File Exchange Protocol This document specifies a protocol for the exchange of CDNI Logging Files as specified in Section 3. This protocol comprises: o a CDNI Logging feed, allowing the dCDN to notify the uCDN about the CDNI Logging files that can be retrieved by that uCDN from the @@ -1452,126 +1452,130 @@ The atom:updated in the atom:entry MUST indicate the time at which the CDNI Logging file was last updated. 4.1.2. Updates to Log Files and the Feed CDNI Logging files MUST NOT be modified by the dCDN once published in the CDNI Logging feed. The frequency with which the subscription feed is updated, the period of time covered by each CDNI Logging file or each archive document, - and timeliness of publishing of CDNI Logging files is outside the - scope of the present document and is expected to be agreed upon by + and timeliness of publishing of CDNI Logging files are outside the + scope of the present document and are expected to be agreed upon by uCDN and dCDN via other means (e.g. human agreement). - The server-side implementation MUST retain, and be ready to serve, - any CDNI Logging File currently published by the server-side in the - subscription document of the CDNI Logging Feed. - The server-side implementation SHOULD use HTTP cache control headers on the subscription feed to indicate the frequency at which the client-side is to poll for updates. + The potential retention limits (e.g. sliding time window) within + which the dCDN is to retain and be ready to serve an archive document + is outside the scope of the present document and is expected to be + agreed upon by uCDN and dCDN via other means (e.g. human agreement). + The server-side implementation MUST retain, and be ready to serve, + any archive document within the agreed retention limits. Outside + these agreed limits, the server-side implementation MAY be unable to + serve (e.g., with HTTP status code 404) an archive document or MAY + refuse to serve it (e.g., with HTTP status code 403 or 410). + 4.1.3. Redundant Feeds The server-side implementation MAY present more than one CDNI Logging feed and for redundancy, CDNI Logging files MAY be published in more than one feed. A client-side implementation MAY support such redundant CDNI Logging feeds. If it supports redundant CDNI Logging feed, the client-side SHOULD use the UUID of the CDNI Logging file, presented in the - atom:id element of the Atom feed, to avoid uncessarily pulling and + atom:id element of the Atom feed, to avoid unnecessarily pulling and storing each CDNI Logging file more than once. 4.1.4. Example CDNI Logging Feed Figure 4 illustrates an example of the subscription document of a CDNI Logging feed. > CDNI Logging Feed - 2013-03-23T16:21:11Z + 2013-03-23T14:46:11Z urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce CDNI Log Feed Generator dcdn.example CDNI Logging File for uCDN at - 2013-03-23 14:55:00 + 2013-03-23 14:15:00 urn:uuid:12345678-1234-abcd-00aa-01234567abcd - 2013-03-23T14:55:00Z + 2013-03-23T14:15:00Z - CDNI Logging File for uCDN at - 2013-03-23 14:55:00 + 2013-03-23 14:15:00 CDNI Logging File for uCDN at - 2013-03-23 15:55:00 + 2013-03-23 14:30:00 urn:uuid:87654321-4321-dcba-aa00-dcba7654321 - 2013-03-23T15:55:00Z + 2013-03-23T14:30:00Z CDNI Logging File for uCDN at - 2013-03-23 15:55:00 + 2013-03-23 15:30:00 ... ... Figure 4: Example subscription document of a CDNI Logging Feed 4.2. CDNI Logging File Pull - A client-side implementation of the CDNI Logging interface MUST pull, + A client-side implementation of the CDNI Logging interface MAY pull, at its convenience, a CDNI Logging File that is published by the - server-side in the CDNI Logging Feed. To do so, the client-side: + server-side in the CDNI Logging Feed (in the subscription document or + an archive document). To do so, the client-side: o MUST use HTTP v1.1 ( [RFC2616]); o SHOULD use TLS (i.e. use what is loosely referred to as "HTTPS") as per [RFC2818] whenever protection of the CDNI Logging information is required (see Section 6.1); o MUST use the URI that was associated to the CDNI Logging File (within the "src" attribute of the corresponding atom:content element) in the CDNI Logging Feed o MUST support exchange of CDNI Logging Files with no content encoding applied to the representation; o SHOULD support exchange of CDNI Logging Files with "gzip" content encoding (as defined in [RFC2616]) applied to the representation. Note that a client-side implementation of the CDNI Logging interface - MAY pull a CDNI Logging File that it has already pulled, as long as - the file is still published by the server-side in the subscription - document of CDNI Logging Feed. + MAY pull a CDNI Logging File that it has already pulled. - The server-side implementation MUST respond to any valid pull request - by a client-side implementation for a CDNI Logging File published by - the server-side in the subscription document of the CDNI Logging - Feed. The server-side implementation: + The server-side implementation MUST respond to valid pull request by + a client-side implementation for a CDNI Logging File published by the + server-side in the CDNI Logging Feed (in the subscription document or + an archive document). The server-side implementation: o MUST handle the client-side request as per HTTP v1.1; o MUST include the CDNI Logging File identified by the request URI inside the body of the HTTP response; o MUST support exchange of CDNI Logging Files with no content encoding applied to the representation; o SHOULD support exchange of CDNI Logging Files with "gzip" content @@ -1584,20 +1588,32 @@ particular exchange of a CDNI Logging File. Applying compression content encoding (such as "gzip") is expected to mitigate the impact of exchanging the large volumes of logging information expected across CDNs. This is expected to be particularly useful in the presence of HTTP Adaptive Streaming (HAS) which, as per the present version of the document, will result in a separate CDNI Log Record for each HAS segment delivery in the CDNI Logging File. + The potential retention limits (e.g. sliding time window, maximum + aggregate file storage quotas) within which the dCDN is to retain and + be ready to serve a CDNI Logging File previously advertised in the + CDNI Logging Feed is outside the scope of the present document and is + expected to be agreed upon by uCDN and dCDN via other means (e.g. + human agreement). The server-side implementation MUST retain, and be + ready to serve, any CDNI Logging File within the agreed retention + limits. Outside these agreed limits, the server-side implementation + MAY be unable to serve (e.g., with HTTP status code 404) a CDNI + Logging File or MAY refuse to serve it (e.g., with HTTP status code + 403 or 410). + 5. IANA Considerations 5.1. CDNI Logging Directive Names Registry The IANA is requested to create a new registry, CDNI Logging Directive Names. The initial contents of the CDNI Logging File Directives registry comprise the names of the directives specified in Section 3.3 of the present document, and are as follows: @@ -1721,21 +1737,33 @@ The Integrity-Hash directive inside the CDNI Logging File provides additional integrity protection, this time targeting potential corruption of the CDNI logging information during the CDNI Logging File generation. This mechanism does not allow restoration of the corrupted CDNI Logging information, but it allows detection of such corruption and therefore triggering of appropraite correcting actions (e.g. discard of corrupted information, attempt to re-obtain the CDNI Logging information). -6.2. Privacy +6.2. Denial of Service + + This document does not define specific mechanism to protect against + Denial of Service (DoS) attacks on the Logging Interface. However, + the CDNI Logging feed and CDNI Logging pull endpoints can be + protected against DoS attacks through the use of TLS transport and/or + via mechanisms outside the scope of the CDNI Logging interface such + as firewalling or use of Virtual Private Networks (VPNs). + + Protection of dCDN Surrogates against spoofed delivery requests is + outside the scope of the CDNI Logging interface. + +6.3. Privacy CDNs have the opportunity to collect detailed information about the downloads performed by End-Users. The provision of this information to another CDN introduces potential End-Users privacy protection concerns. We observe that when CDNI interconnection is realised as per [I-D.ietf-cdni-framework], the uCDN handles the initial End-User requests (before it is redirected to the dCDN) so, regardless of which information is, or is not, communicated to the uCDN through the CDNI Logging interface, the uCDN has visibility on significant information such as the IP address of the End-User request and the @@ -1749,27 +1777,28 @@ have been anonymized so that the meaningful information can still be easily extracted from the anonymized addressses (e.g. for geolocation aware analytics). 7. Acknowledgments This document borrows from the W3C Extended Log Format [ELF]. Rob Murray significantly contributed into the text of Section 4.1 . - The authors would like to thank Sebastien Cubaud, Pawel Grochocki, - Christian Jacquenet, Yannick Le Louedec, Anne Marrec and Emile - Stephan for their contributions on early versions of this document. - The authors would like also to thank Fabio Costa, Sara Oueslati, Yvan - Massot, Renaud Edel, and Joel Favier for their input and comments. - Finally, they thank the contributors of the EU FP7 OCEAN project for - valuable inputs. + The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg and + Ray van Brandenburg for their ongoing input. + + Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian + Jacquenet, Yannick Le Louedec, Anne Marrec , Emile Stephan, Fabio + Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier and the + contributors of the EU FP7 OCEAN project for their input in the early + versions of this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext @@ -1838,27 +1867,33 @@ K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, November 2012. [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)", RFC 6983, July 2013. Appendix A. Compliance with CDNI Requirements - [Editor's Note: this section may need a small update if ietf-cdni- + [Editor's Note: This appendix is intended to help the WG understand + compliance of the CDNI Logging interface against the requirements + defined in the CDNI requirements document, in oder to establish + readiness for of the document publication. This appendix is expected + to be removed for bepublication]. + + [Editor's Note: this appendix may need a small update if ietf-cdni- requirements introduces an additional requirement for Privacy/ Anonimization as recently discussed on the list, and if LI14 & LI-15 are modified] The three tables below review compliance against, respectively, the - Generic CDNI requirements, the CDNI Logging interafce requirements + Generic CDNI requirements, the CDNI Logging interface requirements and the CDNI security requirements of [I-D.ietf-cdni-requirements]. The first two columns of the tables indicate the requirement number, and the requirement priority as defined in [I-D.ietf-cdni-requirements]. The third column of the table indicates the level of compliance of the CDNI Logging interface specified in the present document against the given requirement, and the fourth column provides additional comment and explanation on how or why the compliance is achieved or not achieved. +-------+-------+-----------+---------------------------------------+ @@ -1885,21 +1920,21 @@ | | | Compliant | delivery, but easily extensible to | | | | | add support for other delivery protos | +-------+-------+-----------+---------------------------------------+ | GEN-8 | LOW | N/A | | +-------+-------+-----------+---------------------------------------+ | GEN-9 | MED | Full | Supports logging across cascaded CDNs | +-------+-------+-----------+---------------------------------------+ | GEN-10| MED | Full | Supports any toplogy of interconnected| | | | | CDNs | +-------+-------+-----------+---------------------------------------+ - | GEN-11| HIGH | Parial | No explicit mechanism for loop | + | GEN-11| HIGH | Partial | No explicit mechanism for loop | | | | | avoidance is defined; the exchange of | | | | | logs is usually done in a point to | | | | | point manner between two well identi- | | | | | fied entities situated in the uCDN and| | | | | dCDN. Loop avoidance is expected to be| | | | | handled by implementations based on | | | | | inferring the CDN path from the URI | | | | | structure in the HTTP redirection case| | | | | and/or administrative information | | | | | (topology restrictions in case of DNS | @@ -1997,21 +2032,21 @@ | LI-11 | MED | Not | Future versions might define such a | | | | compliant | mechanism for logging data about | | | | | resources consumed by the dCDN | +-------+-------+-----------+---------------------------------------+ | LI-12 | MED | Not | Future versions might define such a | | | | compliant | mechanism for logging data about | | | | | resources consumed by cascaded CDNs | +-------+-------+-----------+---------------------------------------+ | LI-13 | HIGH | Not | Not supported by CDNI Logging | | | | compliant | interface. However, it is expected | - | | | | that teh CDNI Control interface will | + | | | | that the CDNI Control interface will | | | | | allow tracing of delete request | | | | | results (e.g. success, failure). | +-------+-------+-----------+---------------------------------------+ | LI-14 | HIGH | Full | Details about extensibility mechanisms| | | | | in Section 6. | +-------+-------+-----------+---------------------------------------+ | LI-15 | HIGH | Full | Details about proprietary fields in | | | | | Section 6. | +-------+-------+-----------+---------------------------------------+ | LI-16 | HIGH | Full | The CDNI Logging feed indicates which | @@ -2028,27 +2063,27 @@ | Re- | Prior-| Compli- | Comment | | quire-| ity | ance | | | ment | | | | +-------+-------+-----------+---------------------------------------+ | SEC-1 | HIGH | Full | TLS can be used for transport of any | | | | | CDNI logging related information which| | | | | provides authentication, confidentia- | | | | | lity, integrity protection as well as | | | | | protection agasint spoofing and replay| +-------+-------+-----------+---------------------------------------+ - | SEC-2 | HIGH | Full | No specific mechanism against Denial | + | SEC-2 | HIGH | Partial | No specific mechanism against Denial | | | | | of Service attacks is defined on the | | | | | Logging Interface. Spoofed requests | | | | | can be avoided by using TLS. | | | | | Protection against spoofed delivery | | | | | requests are outside the scope of CDNI| - | | | | Logging | + | | | | Logging. | +-------+-------+-----------+---------------------------------------+ | SEC-3 | MED | N/A | Establishing CDN path with non- | | | | | repudiation is outside the scope of | | | | | CDNI Logging. Does not prevent use of | | | | | such mechanism (e.g. including info | | | | | in content URI). | +-------+-------+-----------+---------------------------------------+ | SEC-4 | MED | Not | A non-repudiation mechanism for CDNI | | | | compliant | logging might be defined in a separate| | | | | document |