CDNI Edge Control Metadata
draft-siloniz-cdni-edge-control-metadata-00

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,
              <https://www.rfc-editor.org/info/rfc9110>.

   [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,
              <https://www.rfc-editor.org/info/rfc8006>.

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,
              <https://www.rfc-editor.org/info/rfc2119>.

11.2.  Informative References

   [W3C]      "Cross-Origin Resource Sharing",
              <https://www.w3.org/TR/2020/SPSD-cors-20200602/>.

   [SVTA]     "Streaming Video Technology Alliance Home Page",
              <https://www.svta.org>.

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]