Network Working Group A. Siloniz Internet-Draft Telefonica Updates: 8006 (if approved) G. Goldstein Intended status: Standards Track Lumen Technologies Expires: 14 September 2023 13 March 2023 CDNI Edge Control Metadata draft-siloniz-cdni-edge-control-metadata-00 Abstract This specification defines MI configuration metadata objects to extend RFC 8006 related to controlling edge access to resources via CDNs and Open Caching systems. Configuring Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers is a key feature of typical configurations, as are the ability to define response body compression rules, client connection timeouts, and traffic type hints for optimized caching. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 https://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 14 September 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Siloniz & Goldstein Expires 14 September 2023 [Page 1] Internet-Draft CDNI Edge Control Metadata March 2023 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 3. MI.CrossoriginPolicy . . . . . . . . . . . . . . . . . . . . 3 3.1. MI.AccessControlAllowOrigin . . . . . . . . . . . . . . . 6 4. MI.AllowCompress . . . . . . . . . . . . . . . . . . . . . . 8 5. MI.ClientConnectionControl . . . . . . . . . . . . . . . . . 9 6. MI.TrafficType . . . . . . . . . . . . . . . . . . . . . . . 10 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction CDNs typically require a set of configuration metadata to inform processing of responses downstream (at the edge and in the user agent). This section specifies GenericMetadata objects to meet those requirements, defining edge processing rules such as CORS handling, response compressions, and client connection failures. 2. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Siloniz & Goldstein Expires 14 September 2023 [Page 2] Internet-Draft CDNI Edge Control Metadata March 2023 3. MI.CrossoriginPolicy Delegation of traffic between a CDN over an open caching node based on HTTP redirection does change the domain name in the client requests. This represents a cross-origin request that must be managed appropriately using Cross-Origin Resource Sharing (CORS) headers in the responses. The dynamic generation of CORS headers is typical in modern HTTP request processing and avoids CORS validation forwarded to the CDN origin servers, particularly with the preflight OPTIONS requests. The CDNI metadata model requires extensions to specify how a CDN or open caching node should generate and evaluate these headers. Required capabilities: Set a default value for CORS response headers independent of the origin request header value. 1. Set a default value for CORS response headers independent of the origin request header value. 2. Match the origin request header with a list of valid values, including PatternMatch, to return or not return the CORS response headers. 3. Set a list of custom headers that can be exposed to the client (expose headers). 4. Support for preflight requests using the OPTIONS method, including custom header validation, expose headers, and methods. 5. Support for credentials validation within CORS. Simple CORS requests are those where both HTTP method and headers in the request are included in the safe list defined by the World Wide Web Consortium [W3C]. The user agent (UA) request can include an origin header set to the URL domain of the webpage that the player runs. Depending on the metadata configuration, the logic to apply by the open caching node (OCN) is: Validation of the origin header - Metadata can include a list of valid domains to validate the request origin header. If it does not match, the CORS header must not be included in the response. 1. Validation of the origin header - Metadata can include a list of valid domains to validate the request origin header. If it does not match, the CORS header must not be included in the response. Siloniz & Goldstein Expires 14 September 2023 [Page 3] Internet-Draft CDNI Edge Control Metadata March 2023 2. WIldcard usage - Depending on the configuration, the resultant CORS header to include in the response will be the same as the request origin header, or a wildcard. 3. If no validation of request is included in the origin header, set a default value for CORS response headers independent of the origin request header value. When a UA makes a request that includes a method or headers that are not included in the safe-list, the client will make a CORS preflight request using the OPTIONS method to the resource including the origin header. If CORS is enabled and the requests passes the origin validation, the OCN SHOULD respond with the set of headers that indicate what is permitted for that resource, including one or more of the following: Allowed methods 1. Allowed methods 2. Allowed credentials 3. Allowed request headers 4. Max age that the OPTIONS request is valid 5. Headers that can be exposed to the client When an uCDN configures any of those advanced parameters it is requesting the dCDN to generate synthetic responses to OPTIONS requests. Thus, no conditional request is performed to the uCDN origin. uCDN should configure these values taking that into account. If some of the advanced parameters are empty, the dCDN would not send the corresponding header into the UA OPTIONS request. In case the uCDN only configures the MI.AccessControlAllowOrigin subobject, the dCDN will not generate synthetic responses to OPTIONS requests, thus it will validate we the uCDN every OPTIONS request to obtain the response. CrossoriginPolicy is a GenericMetadata object that allows for the specification of dynamically generated CORS headers. Property: allow-origin - Description: Validation of simple CORS requests. - Type: Object MI.AccessControlAllowOrigin Siloniz & Goldstein Expires 14 September 2023 [Page 4] Internet-Draft CDNI Edge Control Metadata March 2023 - Mandatory-to-Specify: Yes Property: expose-headers - Description: A list of values the OCN will include in the Access-Control-Expose-Headers response header to a preflight request. - Type: Array of strings - Mandatory-to-Specify: No Property: allow-methods - Description: A list of values the OCN will include in the Access-Control-Allow-Methods response header to a preflight request. - Type: Array of strings - Mandatory-to-Specify: No Property: allow-headers - Description: A list of values the OCN will include in the Access-Control-Allow-Headers response header to a preflight request. - Type: Array of strings - Mandatory-to-Specify: No Property: allow-credentials - Description: The value the OCN will include in the Access- Control-Allow-Credentials response header to a preflight request. - Type: Boolean - Mandatory-to-Specify: No Property: max-age - Description: The value the OCN will include in the Access- Control-Max-Age response header to a preflight request. - Type: Integer Siloniz & Goldstein Expires 14 September 2023 [Page 5] Internet-Draft CDNI Edge Control Metadata March 2023 - Mandatory-to-Specify: No Property: no-origin-response-headers - Description: In the case of a request that has no Origin field, return this set of headers with the response. - Type: Array of MI.HTTPHeader - Mandatory-to-Specify: No Property: apply-to-all-methods - Description: By default the CORS configuration refers to OPTIONS requests. Setting this flag to true applies the entire CORS configuration to the other methods as well - Type: Bollean - Default: false - Mandatory-to-Specify: No 3.1. MI.AccessControlAllowOrigin The MI.AccessControlAllowOrigin object has the following properties: Property: allow-list - Description: List of valid URLs that will be used to match the request origin header. The Origin header is a HTTP extension. Its value is a version of the Referer header in some specific requests, and used for Cross Origin requests. . Permitted values are schema://hostname[:port] - Type: Array of PatternMatch objects - Mandatory-to-Specify: Yes Property: wildcard-return - Description: If "True", the OCN will include a wildcard (*) in the Access-Control-Allow-Origin response header. If "False", the OCN will reflect the request origin header in the Access- Control-Allow-Origin response header. - Type: Boolean Siloniz & Goldstein Expires 14 September 2023 [Page 6] Internet-Draft CDNI Edge Control Metadata March 2023 - Mandatory-to-Specify: Yes The examples below demonstrate how to configure response headers dynamically for CORS validation. Example 1: A simple CORS validation configuration: { "generic-metadata-type": "MI.CrossoriginPolicy", "generic-metadata-value": { "allow-origin": { "allow-list": [ { "pattern": "*" } ], "wildcard-return": true } } } Example 2: Validation of a preflight request when some of the headers included in the subsequent object request are not included in the CORS specification safelist: { "generic-metadata-type": "MI.CrossoriginPolicy", "generic-metadata-value": { "allow-origin": { "allow-list": [ { "pattern": "*://sourcepage.example.com" }, "wildcard-return": false }, "allow-methods": [ "GET", "POST" ], "allow-credentials": true, "allow-headers": [ "X-PINGOTHER", "Content-Type" ], "expose-headers": [ "X-User", "Authorization" ], "max-age": 3600 } } } Siloniz & Goldstein Expires 14 September 2023 [Page 7] Internet-Draft CDNI Edge Control Metadata March 2023 4. MI.AllowCompress Downstream CDNs often have the ability to compress HTTP response bodies in cases where the client has declared that it can accept compressed responses (via an Accept-Encoding header), but the source/ origin has returned an uncompressed response. The specific compression algorithm used by the dCDN is negotiated by the client’s Accept-Encoding header according to [RFC9110] (including q= preferences) and the compression capabilities available on the dCDN. In addition, HeaderTransform allows the uCDN to normalize, or modify, the Accept-Encoding header to allow for fine-grain control over the selection of the compression algorithm (e.g., gzip, compress, deflate, br, etc.). AllowCompress is a new GenericMetadata object that allows the dCDN to compress content before sending to the client. Property: allow-compress - Description: If set to "True", then the dCDN will try to compress the response to the client based on the Accept- Encoding request header. - Type: Boolean - Values: True or False - Mandatory-to-Specify: No. The default is "False". The following examples illustrate the use of MI.AllowCompress in the context of the Processing Stages model that allowed for metadata to be applied conditionally based on evaluation of HTTP request headers. See the Processing Stages Metadata Specification and Metadata Model Expression Language (MEL) Specification. Example 1: An MI.AllowCompress that allows manifests (*.m3u8) to be compressed by the dCDN: Siloniz & Goldstein Expires 14 September 2023 [Page 8] Internet-Draft CDNI Edge Control Metadata March 2023 { "match": { "expression": "req.h.uri *= '*.m3u8'" }, "stage-metadata": { "generic-metadata": [ { "generic-metadata-type": "MI.AllowCompress", "generic-metadata-value": { "allow-compress": "true" } } ] } } Example 2: An MI.AllowCompress that allows manifests (*.m3u8) to be compressed by the dCDN but normalizing the client’s Accept-Encoding header: { "match": { "expression": "req.h.accept-encoding *= '*gzip*'" }, "stage-metadata": { "generic-metadata": [ { "generic-metadata-type": "MI.AllowCompress", "generic-metadata-value": { "allow-compress": "true" } } ] } } 5. MI.ClientConnectionControl Configuration metadata is required to define how connections against a client are maintained by a dCDN. Since the clients are typically owned/operated by a uCDN, giving this control to a uCDN allows it to accommodate device specific constraints and performance optimizations. A dCDN can also benefit from this configuration metadata to meet its security and resource consumption requirements. ClientConnectionControl is a new GenericMetadata object that specifies how a dCDN manages its connections to clients/players. Siloniz & Goldstein Expires 14 September 2023 [Page 9] Internet-Draft CDNI Edge Control Metadata March 2023 Property: connection-keep-alive-time-ms - Description: Specifies the time in milliseconds to keep an idle connection open. - Type: Integer - Mandatory-to-Specify: No. When not specified, a default value selected by the dCDN will be used. Following example shows how a connection setup and keep alive timeout can be set for client connections against a dCDN: { "generic-metadata-type": "MI.ClientConnectionControl", "generic-metadata-value": { "connection-keep-alive-time-ms": 3 } } 6. MI.TrafficType Content delivery networks often apply different infrastructure, network routes, and internal metadata for different types of traffic. Delivery of large static objects (such as software downloads), may, for example, use different edge servers and network routes than video stream delivery. In an HTTP adaptive bitrate video service, every video title corresponds to a set of video files and descriptors according to different video protocols, and this is independent of the type of service (Video-on-Demand, Live, Catch-up, etc.). The way the video service is consumed by the user agents can vary. For instance, a segment that belongs to a Video-on-Demand (VoD) title can be requested for every moment the content is available for the user agents to consume, while a segment of live content will be only requested as long as the time-shift duration is configured for that service. Knowing those differences, a CDN or OCN provider can implement specific strategies that will maximize performance and thereby provide more available capacity to the upstream provider. It should be noted that the dCDNs handling of the traffic types is implementation-specific and not prescribed here. MI.TrafficType metadata defines a set of descriptors that characterize either the type or usage of the traffic, enabling CDNs and OCNs to apply any internal configuration rules without exposing an unnecessary number of internal details. Note that the interpretation of these traffic types and application of rules such as rate limiting or delivery pacing are implementation specific. Siloniz & Goldstein Expires 14 September 2023 [Page 10] Internet-Draft CDNI Edge Control Metadata March 2023 Property: traffic-type - Description: A literal that defines the traffic type. uCDN will use the literal that is most representative of the traffic being delegated. - Type: Enumeration [vod, live, object-download] encoded as lowercase string - Mandatory-to-Specify: Yes Property: hints - Description: Other traffic characteristics that the uCDN can indicate to the dCDN as suggestions for service optimization. Accepts free-form unconstrained values. - Type: Array of strings - Mandatory-to-Specify: No A TrafficType definition example for HostMetadata: { "generic-metadata-type": "MI.TrafficType", "generic-metadata-value": { "traffic-type": "vod", "hints": [ "low-latency", "catch-up" ] } } 7. Conclusion The specification has extended the basic CDNI configuration metadata objects defined in [RFC8006], and can be extended in the future with additional Edge Control Metadata object definitions. 8. Security Considerations The FCI and MI objects defined in the present document are transferred via the interfaces defined in CDNI [RFC8006]. [RFC8006] describes how to secure these interfaces, protecting the integrity, confidentiality and ensuring the authenticity of the dCDN and uCDN. The security provide by [RFC8006] should therefore address the above security concerns. 9. IANA Considerations Siloniz & Goldstein Expires 14 September 2023 [Page 11] Internet-Draft CDNI Edge Control Metadata March 2023 9.1. CDNI Payload Types TBD. 10. Acknowledgements The authors would like to express their gratitude to the members of the Streaming Video Technology Alliance [SVTA] Open Caching Working Group for their guidance / contribution / reviews ...) Particulary the following people contribute in one or other way to the content of this draft: Guillaume Bichot - Broadpeak Christoph Neumann - Broadpeak Pankaj Chaudhari - Disney Streaming Services Rajeev RK - picoNETS Yoav Gressel - Qwilt Arnon Warshavsky - QWilt Shmuel Asafi . Qwilt Nir Sopher - Qwilt Arnon Warshavsky - Qwilt Ben Rosenblum - Vecima 11. References 11.1. Normative References [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, . Siloniz & Goldstein Expires 14 September 2023 [Page 12] Internet-Draft CDNI Edge Control Metadata March 2023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 11.2. Informative References [W3C] "Cross-Origin Resource Sharing", . [SVTA] "Streaming Video Technology Alliance Home Page", . Authors' Addresses Alfonso Siloniz Telefonica Spain Email: alfonsosiloniz@gmail.com Glenn Goldstein Lumen Technologies United States of America Email: glenng1215@gmail.com Siloniz & Goldstein Expires 14 September 2023 [Page 13]