Internet DRAFT - draft-siloniz-cdni-edge-control-metadata
draft-siloniz-cdni-edge-control-metadata
Network Working Group A. Siloniz
Internet-Draft Telefonica
Intended status: Standards Track G. Goldstein
Expires: 11 January 2024 Lumen Technologies
10 July 2023
CDNI Edge Control Metadata
draft-siloniz-cdni-edge-control-metadata-01
Abstract
CDNs typically require a set of configuration metadata to provide
directives for the processing of responses downstream (at the edge
and in the user agent). This document specifies GenericMetadata
objects to meet those requirements, defining edge processing rules
such as CORS handling, response compressions, and client connection
failures.
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 11 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Siloniz & Goldstein Expires 11 January 2024 [Page 1]
Internet-Draft CDNI Edge Control Metadata July 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. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
CDNs typically require a set of configuration metadata to provide
directives for the processing of responses downstream (at the edge
and in the user agent). This document 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 11 January 2024 [Page 2]
Internet-Draft CDNI Edge Control Metadata July 2023
3. MI.CrossoriginPolicy
Delegation of traffic between CDNs over an Open Caching node (OCN)
based on Hypertext Transfer Protocol (HTTP) redirection changes the
domain name in the client requests. This represents a cross-origin
request that must be managed appropriately using (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 CDN Interconnection (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 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 preflight requests using the OPTIONS method, including
custom header validation, expose headers, and methods.
5. Support credentials validation within CORS.
Simple CORS requests are those where both HTTP method and headers in
the request don´t require a preflight request. 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 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 11 January 2024 [Page 3]
Internet-Draft CDNI Edge Control Metadata July 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
require a CORS preflight request, the UA will use the OPTIONS method
to the resource, including the origin header. If CORS is enabled and
the request 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. Maximum age that the OPTIONS request is valid
5. Headers that can be exposed to the client
When an upstream CDN (uCDN) configures any of those advanced
parameters, it is requesting the dCDN generate synthetic responses to
OPTIONS requests. Therefore, no conditional request is performed to
the uCDN origin. The 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 cases where the uCDN only configures the
MI.AccessControlAllowOrigin subobject, the dCDN will not generate
synthetic responses to OPTIONS requests. Instead, the dCDN will
validate with the uCDN every OPTIONS request to obtain the response.
MI.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 11 January 2024 [Page 4]
Internet-Draft CDNI Edge Control Metadata July 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 11 January 2024 [Page 5]
Internet-Draft CDNI Edge Control Metadata July 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: Boolean
- Mandatory-to-Specify: No. The default is "False".
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 an 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, defined in [RFC8006]
section 4.1.5
- 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 11 January 2024 [Page 6]
Internet-Draft CDNI Edge Control Metadata July 2023
- Mandatory-to-Specify: Yes
The examples below demonstrate how to configure response headers
dynamically for CORS validation.
The following is an example of a simple CORS validation
configuration:
{
"generic-metadata-type": "MI.CrossoriginPolicy",
"generic-metadata-value": {
"allow-origin": {
"allow-list": [
{
"pattern": "*"
}
],
"wildcard-return": true
}
}
}
The following is an example of 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 11 January 2024 [Page 7]
Internet-Draft CDNI Edge Control Metadata July 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.).
MI.AllowCompress is a new GenericMetadata object that allows the dCDN
to compress content before sending it to the client.
Property: allow-compress
- Description: If set to "True", the dCDN will try to compress
the response to the client based on the Accept-Encoding request
header.
- Type: Boolean. The values are "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 [SVTA2032] and
Metadata Model Expression Language (MEL) Specification [SVTA2031].
The following is an example of an MI.AllowCompress that allows
manifests (*.m3u8) to be compressed by the dCDN:
Siloniz & Goldstein Expires 11 January 2024 [Page 8]
Internet-Draft CDNI Edge Control Metadata July 2023
{
"match": {
"expression": "req.h.uri *= '*.m3u8'"
},
"stage-metadata": {
"generic-metadata": [
{
"generic-metadata-type": "MI.AllowCompress",
"generic-metadata-value": {
"allow-compress": true
}
}
]
}
}
The following is an example of an MI.AllowCompress that allows
manifests (*.m3u8) to be compressed by the dCDN but normalizes 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 optimization.
A dCDN can also benefit from this configuration metadata to meet its
security and resource consumption requirements.
MI.ClientConnectionControl is a new GenericMetadata object that
specifies how a dCDN manages its connections to clients/players.
Siloniz & Goldstein Expires 11 January 2024 [Page 9]
Internet-Draft CDNI Edge Control Metadata July 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.
The following example shows how a connection setup and a keep alive
timeout can be set for client connections to a dCDN:
{
"generic-metadata-type": "MI.ClientConnectionControl",
"generic-metadata-value": {
"connection-keep-alive-time-ms": 3
}
}
6. Conclusion
This specification has defined configuration metadata objects related
to controlling edge access to resources via CDNs and Open Caching
systems. It has added to the set of basic CDNI configuration
metadata objects defined in [RFC8006], and can be extended in the
future with additional Edge Control Metadata object definitions.
7. 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.
8. IANA Considerations
8.1. CDNI Payload Types
TBD.
Siloniz & Goldstein Expires 11 January 2024 [Page 10]
Internet-Draft CDNI Edge Control Metadata July 2023
9. 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
10. References
10.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>.
[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>.
Siloniz & Goldstein Expires 11 January 2024 [Page 11]
Internet-Draft CDNI Edge Control Metadata July 2023
10.2. Informative References
[SVTA] "Streaming Video Technology Alliance Home Page",
<https://www.svta.org>.
[SVTA2032] Goldstein, G., Ed., Chaudhari, P., Power, W., Gressel, Y.,
and A. Warshavsky, "Processing Stages Metadata
Specification", 2 July 2021,
<https://svta.org/documents/SVTA2032>.
[SVTA2031] Goldstein, G., Ed., Chaudhari, P., Power, W., Gressel, Y.,
and A. Warshavsky, "Metadata Model Expression Language
(MEL) Specification", 2 July 2021,
<https://svta.org/documents/SVTA2031>.
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 11 January 2024 [Page 12]
