--- 1/draft-ietf-cdni-logging-13.txt 2014-10-25 08:14:45.218952024 -0700 +++ 2/draft-ietf-cdni-logging-14.txt 2014-10-25 08:14:45.314954357 -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: January 25, 2015 I. Oprescu, Ed. +Expires: April 28, 2015 I. Oprescu, Ed. Orange R. Peterkofsky Skytide, Inc. - July 24, 2014 + October 25, 2014 CDNI Logging Interface - draft-ietf-cdni-logging-13 + draft-ietf-cdni-logging-14 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 January 25, 2015. + This Internet-Draft will expire on April 28, 2015. Copyright Notice Copyright (c) 2014 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 @@ -96,76 +96,76 @@ 6.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7.1. Authentication, Confidentiality, Integrity Protection . . 46 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 47 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 47 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.1. Normative References . . . . . . . . . . . . . . . . . . 48 9.2. Informative References . . . . . . . . . . . . . . . . . 49 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 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: - o CDNI problem statement [RFC6707] and framework - [I-D.ietf-cdni-framework] identify a Logging interface, + o CDNI problem statement [RFC6707] and framework [RFC7336] identify + a Logging interface, - o Section 8 of [I-D.ietf-cdni-requirements] specifies a set of - requirements for Logging, + o Section 8 of [RFC7337] specifies a set of requirements for + Logging, o [RFC6770] outlines real world use-cases for interconnecting CDNs. These use cases require the exchange of Logging information between the dCDN and the uCDN. As stated in [RFC6707], "the CDNI Logging interface enables details of logs or events to be exchanged between interconnected CDNs". The present document describes: o The CDNI Logging reference model (Section 2), o The CDNI Logging File format (Section 3), o The CDNI Logging File Exchange protocol (Section 4). 1.1. Terminology In this document, the first letter of each CDNI-specific term is capitalized. We adopt the terminology described in [RFC6707] and - [I-D.ietf-cdni-framework], and extend it with the additional terms - defined below. + [RFC7336], and extend it with the additional terms defined below. Intra-CDN Logging information: logging information generated and collected within a CDN. The format of the Intra-CDN Logging information may be different to the format of the CDNI Logging information. CDNI Logging information: logging information exchanged across CDNs using the CDNI Logging Interface. Logging information: logging information generated and collected within a CDN or obtained from another CDN using the CDNI Logging Interface. CDNI Logging Field: an atomic element of information that can be included in a CDNI Logging Record. The time an event/task started, the IP address of an End User to whom content was delivered, and the - URI of the content delivered are examples of CDNI Logging Fields. + Uniform Resource Identifier (URI) of the content delivered, are + examples of CDNI Logging Fields. CDNI Logging Record: an information record providing information about a specific event. This comprises a collection of CDNI Logging Fields. CDNI Logging File: a file containing CDNI Logging Records, as well as additional information facilitating the processing of the CDNI Logging Records. CDN Reporting: the process of providing the relevant information that @@ -359,21 +359,21 @@ | Filtering ^ | Collection ^ ^ | | | Generation | | uCDN - CDNI Logging ------------------------------------------------------- + CDNI Logging --------------------------------------------------- exchange dCDN ^ | Log Consuming Log Consuming | App App | ^ ^ | | | Rectification Rectification--------- ^ ^ | | Filtering @@ -1013,27 +1013,29 @@ = FIEVAL * ; where FIEVAL contains the CDNI Logging field value corresponding to the CDNI Logging field names (FIENAME) listed is the last Fields directive preceding the present CDNI Logging Record. 3.4.1. HTTP Request Logging Record This section defines the CDNI Logging Record of Record-Type "cdni_http_request_v1". It is applicable to content delivery - performed by the dCDN using HTTP/1.0([RFC1945]), HTTP/1.1([RFC2616]) - or HTTPS ([RFC2818]). We observe that, in the case of HTTPS - delivery, there may be value in logging additional 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 addressed in a - future document defining another CDNI Logging Record or another - version of the HTTP Request Logging Record. + performed by the dCDN using HTTP/1.0([RFC1945]), + HTTP/1.1([RFC7230],[RFC7231], [RFC7232], [RFC7233], [RFC7234], + + [RFC7235]) or HTTPS ([RFC2818], [RFC7230]). We observe that, in the + case of HTTPS delivery, there may be value in logging additional + 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 + addressed in a future document defining another CDNI Logging Record + or another version of the HTTP Request Logging Record. 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 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 semantics. We observe that, in the case of HTTP/2.0 delivery, there may be value in logging additional information specific to the additional functionality of HTTP/2.0 (e.g. information related to connection identification, to stream identification, to stream priority and to flow control). We note that such additional @@ -1148,56 +1149,56 @@ Surrogate. In the case of HTTP delivery, this is the HTTP method in the request. * occurrence: There MUST be one and only one instance of this field. o cs-uri: * format: NHTABSTRING - * field value: this is the complete URL of the request received - by the Surrogate. It is exactly in the format of a http_URL - specified in [RFC2616]) or, when the request was a HTTPS - request ([RFC2818]), it is in the format of a http_URL but with - the scheme part set to "https" instead of "http". + * field value: this is the "effective request URI" of the request + received by the Surrogate as specified in [RFC7230]. It + complies with the "http" URI scheme or the "https" URI scheme + as specified in [RFC7230]). * occurrence: there MUST be zero or exactly one instance of this field. o u-uri: * format: NHTABSTRING - * field value: this is a complete URL, derived from the complete - URI of the request received by the Surrogate (i.e., the cs-uri) - but transformed by the entity generating or transmitting the - CDNI Logging Record, in a way that is agreed upon between the - two ends of the CDNI Logging interface, so the transformed URI - is meaningful to the uCDN. For example, the two ends of the - CDNI Logging interface could agree that the u-uri is - constructed from the cs-uri by removing the part of the - hostname that exposes which individual Surrogate actually - performed the delivery. The details of modification performed - to generate the u-uri, as well as the mechanism to agree on - these modifications between the two sides of the CDNI Logging - interface are outside the scope of the present document. + * field value: this is a complete URI, derived from the + "effective request URI" ([RFC7230]) of the request received by + the Surrogate (i.e., the cs-uri) but transformed by the entity + generating or transmitting the CDNI Logging Record, in a way + that is agreed upon between the two ends of the CDNI Logging + interface, so the transformed URI is meaningful to the uCDN. + For example, the two ends of the CDNI Logging interface could + agree that the u-uri is constructed from the cs-uri by removing + the part of the hostname that exposes which individual + Surrogate actually performed the delivery. The details of + modification performed to generate the u-uri, as well as the + mechanism to agree on these modifications between the two sides + of the CDNI Logging interface are outside the scope of the + present document. * occurrence: there MUST be one and only one instance of this field. o protocol: * format: NHTABSTRING * field value: this is value of the HTTP-Version field as - specified in [RFC2616] of the Request-Line of the request + specified in [RFC7230] of the Request-Line of the request received by the Surrogate (e.g., "HTTP/1.1"). * occurrence: there MUST be one and only one instance of this field. o sc-status: * format: 3DIGIT * field value: this is the Status-Code in the response from the @@ -1798,58 +1798,59 @@ Figure 7: Example subscription document of a CDNI Logging Feed 4.2. CDNI Logging File 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 (in the subscription document or an archive document). To do so, the client-side: - o MUST implement HTTP/1.1 [RFC2616], MAY also support other HTTP + o MUST implement HTTP/1.1 ([RFC7230],[RFC7231], [RFC7232], + [RFC7233], [RFC7234], [RFC7235]), MAY also support other HTTP versions (e.g., HTTP/2.0 [I-D.ietf-httpbis-http2]) and MAY negotiate which HTTP version is actually used. This allows operators and implementers to choose to use later versions of HTTP to take advantage of new features, while still ensuring interoperability with systems that only support HTTP/1.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 MUST support exchange of CDNI Logging Files with "gzip" content - encoding (as defined in [RFC2616]) applied to the representation. + encoding (as defined in [RFC7230]) 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. 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 implement HTTP/1.1 to handle the client-side request and MAY also support other HTTP versions (e.g., HTTP/2.0); 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 MUST support exchange of CDNI Logging Files with "gzip" content - encoding (as defined in [RFC2616]) applied to the representation. + encoding (as defined in [RFC7231]) applied to the representation. - Content negotiation approaches defined in [RFC2616] (e.g., using + Content negotiation approaches defined in [RFC7231] (e.g., using Accept-Encoding request-header field or Content-Encoding entity- header field) MAY be used by the client-side and server-side implementations to establish the content-coding to be used for a 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 @@ -1930,26 +1931,26 @@ 6.2. CDNI Logging Record-Types Registry The IANA is requested to create a new registry, CDNI Logging Record- Types. The initial contents of the CDNI Logging Record-Types registry comprise the names of the CDNI Logging Record types specified in Section 3.4 of the present document, and are as follows: - +------------------------------+-----------+----------------------------------+ + +----------------------+-----------+----------------------------------+ | Record-Types | Reference | Description | - +------------------------------+-----------+----------------------------------+ + +----------------------+-----------+----------------------------------+ | cdni_http_request_v1 | RFC xxxx | CDNI Logging Record version 1 | | | | for content delivery using HTTP | - +------------------------------+-----------+----------------------------------+ + +----------------------+-----------+----------------------------------+ Figure 9 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry, Record-Types are to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. Record-Types are to be allocated by IANA with a format of NAMEFORMAT (see Section 3.1). Record-Types corresponding to @@ -1988,23 +1989,23 @@ are not strictly identical, or a format that is not strictly identical then this new Field is to be registered in the registry with a different Field name. When a Field from this registry is used by another CDNI Logging Record-Type, it can be used with different occurence rules. The initial contents of the CDNI Logging Fields Names registry comprise the names of the CDNI Logging fields specified in Section 3.4 of the present document, and are as follows: - +---------------------------------------------+-----------+ + +------------------------------------------+-----------+ | Field Name | Reference | - +---------------------------------------------+-----------+ + +------------------------------------------+-----------+ | date | RFC xxxx | | time | RFC xxxx | | time-taken | RFC xxxx | | c-ip | RFC xxxx | | c-ip-anonymizing | RFC xxxx | | c-port | RFC xxxx | | s-ip | RFC xxxx | | s-hostname | RFC xxxx | | s-port | RFC xxxx | | cs-method | RFC xxxx | @@ -2012,21 +2013,21 @@ | u-uri | RFC xxxx | | protocol | RFC xxxx | | sc-status | RFC xxxx | | sc-total-bytes | RFC xxxx | | sc-entity-bytes | RFC xxxx | | cs() | RFC xxxx | | sc() | RFC xxxx | | s-ccid | RFC xxxx | | s-sid | RFC xxxx | | s-cached | RFC xxxx | - +---------------------------------------------+-----------+ + +------------------------------------------+-----------+ Figure 10 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry, names are to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. Field names are to be allocated by IANA with a format of NHTABSTRING (see Section 3.1). @@ -2036,21 +2037,21 @@ The IANA is requested to allocate the "application/cdni.LoggingFile" MIME Media Type (whose use is specified in Section 4.1.1 of the present document) in the MIME Media Types registry. 7. Security Considerations 7.1. Authentication, Confidentiality, Integrity Protection An implementation of the CDNI Logging interface MUST support TLS transport of the CDNI Logging feed (Section 4.1) and of the CDNI - Logging File pull (Section 4.2) as per [RFC2818]. + Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230]. The use of TLS for transport of the CDNI Logging feed and CDNI Logging File pull allows: o the dCDN and uCDN to authenticate each other (to ensure they are transmitting/receiving CDNI Logging File from an authenticated CDN) o the CDNI Logging information to be transmitted with confidentiality @@ -2105,26 +2106,25 @@ downloads performed by End Users. The provision of this information to another CDN introduces potential End Users privacy protection concerns. The use of TLS for transport of the CDNI Logging feed and CDNI Logging pull as discussed in Section 7.1 protects the confidentiality of logged information by preventing any other party than the authorised uCDN to gain access to the logging information. 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 - URL of the request. + [RFC7336], 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 URL of the request. Nonetheless, if the dCDN and uCDN agree that anonymization is required to avoid making some detailed information available to the uCDN (such as how many bytes of the content have been watched by an End User and/or at what time) or is required to meet some legal obligations, then the uCDN and dCDN can agree to exchange anonymized End Users IP address in CDNI Logging Files and the c-ip-anonymization field can be used to convey the number of bits that have been anonymized so that the meaningful information can still be easily extracted from the anonymized addressses (e.g., for geolocation aware @@ -2163,24 +2163,20 @@ contributors of the EU FP7 OCEAN project for their input in the early versions of this document. 9. References 9.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 - Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005. @@ -2192,50 +2188,61 @@ IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008. + [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol + (HTTP/1.1): Message Syntax and Routing", RFC 7230, June + 2014. + + [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol + (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. + + [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol + (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. + + [RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext + Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, + June 2014. + + [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext + Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June + 2014. + + [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol + (HTTP/1.1): Authentication", RFC 7235, June 2014. + 9.2. Informative References [CHAR_SET] "IANA Character Sets registry", . [ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended Log File Format, W3C (work in progress), WD-logfile- 960323", . - [I-D.ietf-cdni-framework] - Peterson, L., Davie, B., and R. Brandenburg, "Framework - for CDN Interconnection", draft-ietf-cdni-framework-14 - (work in progress), June 2014. - [I-D.ietf-cdni-metadata] Niven-Jenkins, B., Murray, R., Caulfield, M., Leung, K., and K. Ma, "CDN Interconnection Metadata", draft-ietf- cdni-metadata-07 (work in progress), July 2014. - [I-D.ietf-cdni-requirements] - Leung, K. and Y. Lee, "Content Distribution Network - Interconnection (CDNI) Requirements", draft-ietf-cdni- - requirements-17 (work in progress), January 2014. - [I-D.ietf-httpbis-http2] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer - Protocol version 2", draft-ietf-httpbis-http2-13 (work in - progress), June 2014. + Protocol version 2", draft-ietf-httpbis-http2-14 (work in + progress), July 2014. [I-D.snell-atompub-link-extensions] Snell, J., "Atom Link Extensions", draft-snell-atompub- link-extensions-09 (work in progress), June 2012. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. @@ -2251,21 +2258,30 @@ [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 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. + [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, + "Framework for Content Distribution Network + Interconnection (CDNI)", RFC 7336, August 2014. + + [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network + Interconnection (CDNI) Requirements", RFC 7337, August + 2014. + Authors' Addresses + Francois Le Faucheur (editor) Cisco Systems E.Space Park - Batiment D 6254 Allee des Ormes - BP 1200 Mougins cedex 06254 FR Phone: +33 4 97 23 26 19 Email: flefauch@cisco.com