rfc-8804

Content Delivery Network Interconnection (CDNI) Request Routing Extensions

O. Finkelman, S. Mishra
date2020-09 streamIETF areawit wgcdni statusPROPOSED STANDARD pages17 canonicalhttps://www.rfc-editor.org/rfc/rfc8804 doi10.17487/RFC8804
Open Caching architecture is a use case of Content Delivery Network Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document defines extensions to the CDNI Metadata Interface (MI) and the Footprint & Capabilities Advertisement interface (FCI). These extensions are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general.

Extracted elements (22)

design-rationale §2

Per-footprint redirect targets are needed because a dCDN spread across multiple geographies cannot rely solely on Geo DNS: clients using third-party DNS resolvers make client location detection impossible for the redirector, and Geo DNS granularity may be too coarse for application requirements.

dns

design-rationale §2

The Redirect Target address is advertised via the FCI rather than during bootstrap because RT addresses can vary between footprints and change over time (e.g., due to network problems). A dynamic, footprint-oriented interface is more suitable than static bootstrap advertisement.

http, dns

design-rationale §3.3

The uCDN SHOULD use a different fallback target address for each uCDN host, enabling load balancing of fallback traffic using the same methods as for original hosts. This is important because extreme dCDN failures or DoS attacks could route large segments of dCDN traffic back to the uCDN simultaneously.

http, dns, security

interoperability-note §2.1

A DNS redirect target (DnsTarget) is used as a CNAME alias in uCDN DNS router responses. DNS routing decisions are based on either the DNS resolver's IP address or client IP subnet via EDNS0 ECS. The dCDN may advertise different redirect targets per footprint to cover both resolver-IP and client-subnet routing cases.

dns

interoperability-note §2.4

In DNS redirection, the DnsTarget 'host' SHOULD NOT include a port number; if present, the uCDN MUST ignore it. Similarly for the FallbackTarget 'host' in DNS delegation, the dCDN MUST ignore any port number present.

dns

normative-requirement §2.1 SHOULD

A uCDN implementation SHOULD prefer routing DNS requests based on client IP subnet when the EDNS0 Client Subnet (ECS) option is present. A dCDN using ECS MUST be aware of the privacy drawbacks in RFC 7871 Section 2 and SHOULD follow the guidelines in Section 11.1 of RFC 7871.

dns, privacy

normative-requirement §2 MUST

If the Redirect Target capability object contains no target or an empty target, the uCDN MUST interpret it as 'no target available for these uCDN hosts for the specified footprint'. If such a target was previously advertised, the uCDN MUST treat this as an update that deletes the prior redirect target.

http, dns

normative-requirement §3 MUST

The fallback target server's address at the uCDN MUST be different from the original uCDN address from which the client was redirected to the dCDN, to avoid redirect loops. The uCDN MUST avoid further redirection when receiving client requests at the fallback target.

http, dns

normative-requirement §2.5 MUST

The HttpTarget 'path-prefix' MUST end with a trailing slash. If absent or empty, the uCDN MUST NOT prepend a path-prefix; the original path MUST appear in the Location URI right after the authority component.

http

normative-requirement §2 MUST

When a dCDN attaches a redirect target to specific uCDN hosts, it MUST advertise those hosts within the Redirect Target capability object as 'redirecting-hosts'. The uCDN may only redirect to that dCDN address if the User Agent request was to one of those hosts.

http, dns

normative-requirement §2.5 MUST

When an HttpTarget 'scheme' property is present, the uCDN MUST use that scheme for HTTP redirection to the dCDN. If absent or empty, the uCDN request router MUST use the same scheme as in the original request.

http

normative-requirement §2.5 MUST

When 'include-redirecting-host' is true and a path-prefix is used, the uCDN redirecting host MUST be added as a separate path segment after the path-prefix and before the original URL path. If true with no path-prefix, the uCDN redirecting host MUST be prepended as the first path segment.

http

normative-requirement §3.1 MUST

When the MI.FallbackTarget 'scheme' property is present, the dCDN MUST use that scheme for HTTP redirection to the uCDN fallback address. If absent or empty, the dCDN MUST use the same scheme as in the request received by the dCDN.

http

normative-requirement §3 MUST

When using HTTP redirect to route a client back to the uCDN fallback, the dCDN is responsible for using the original URL path as the client used for the original uCDN request, stripping any dCDN path-prefix and/or uCDN hostname that may have been added.

http

protocol-element §2.4

The DnsTarget object specifies a 'host' property (mandatory) used as the CNAME alias in DNS redirect responses from the uCDN to the dCDN. The host SHOULD NOT include a port number; if a port is present the uCDN MUST ignore it.

dns

protocol-element §3

The Fallback Target metadata object (MI.FallbackTarget) is advertised by the uCDN via the Metadata Interface within the host-metadata of each host. It indicates the target address the dCDN should redirect clients to when it cannot serve a request, represented as an Endpoint object.

http, dns

protocol-element §2.5

The HttpTarget object specifies the target Location URI for HTTP redirection and consists of: 'host' (mandatory, hostname/IP with optional port), 'scheme' (optional, MUST be 'http' or 'https'), 'path-prefix' (optional, MUST end with trailing slash), and 'include-redirecting-host' (optional boolean, default false).

http

protocol-element §3.1

The MI.FallbackTarget generic metadata object has two properties: 'host' (mandatory, Endpoint object; SHOULD NOT include port for DNS delegation, dCDN MUST ignore port if present) and 'scheme' (optional, MUST be 'http' or 'https'; if absent in HTTP redirect, dCDN MUST use same scheme as received request).

http, dns

protocol-element §2.3

The Redirect Target capability object (FCI.RedirectTarget) is advertised by the dCDN via the Footprint & Capabilities Advertisement interface to indicate the target address the uCDN should use when redirecting clients to the dCDN. It contains optional 'redirecting-hosts', 'dns-target', and 'http-target' properties.

registry, http, dns

registry §4.1

RFC 8804 registers two CDNI Payload Types in the IANA 'CDNI Payload Types' registry (defined in RFC 7736): 'FCI.RedirectTarget' (for FCI advertisement objects for redirect target) and 'MI.FallbackTarget' (for FallbackTarget MI objects and associated capability advertisement).

registry

security-consideration §5.1 MUST

The Redirect Target capability object may reveal information about the internal structure of the dCDN network, and the Fallback Target object may reveal internal uCDN structure. Implementations of the FCI and MI MUST use strong authentication and encryption and strictly follow securing directions in RFC 8006 Section 8.3.

security

security-consideration §5

This specification's extensions are subject to the security and privacy considerations defined in RFC 8006 Section 8 (Metadata Interface) and RFC 8008 Section 7 (Footprint & Capabilities Advertisement interface). Third parties intercepting FCI transactions could use redirect target information to attack the dCDN.

security, privacy