Loop Detection in Content Delivery Networks (CDNs)
Extracted elements (13)
Hostnames are preferred over pseudonyms for cdn-id values to help avoid accidental collisions. When pseudonyms are used, values should be a well-known CDN name or a high-entropy generated value (e.g., a UUID per RFC 4122) to reduce collision probability.
The existing Via header field (RFC 7230 Section 5.7.1) was considered for CDN loop detection but is not used in practice for this purpose. Some HTTP server implementations disable certain HTTP/1.1 features when Via is present, making Via unsuitable for general CDN loop signaling without unintended side effects.
The effectiveness of CDN-Loop depends on all intermediaries preserving the header field. Removing the header—whether deliberately or through customer configuration—prevents downstream CDNs from detecting loops. In general, unknown header fields are not removed by intermediaries, but implementations should ensure CDN-Loop is explicitly protected from removal.
CDNs cannot allow customers to modify or remove the CDN-Loop header field. There may be a need to add CDN-Loop to an implementation's list of header fields that are not to be removed under any circumstances.
Conforming Content Delivery Networks SHOULD add a cdn-info entry to the CDN-Loop header field in all requests they generate or forward, creating the header field if it does not already exist.
The CDN-Loop header field SHOULD NOT be used for purposes other than loop detection, to avoid misuse or unintended interactions.
The CDN-Loop request header field identifies when an incoming HTTP request has already passed through a given CDN's servers, enabling loop detection. It carries one or more cdn-info entries, each identifying a CDN by a hostname or pseudonym with optional semicolon-separated parameters.
RFC 8586 registers the 'CDN-Loop' header field in the IANA 'Permanent Message Header Field Names' registry, with protocol 'http' and status 'standard'.
A CDN's use of CDN-Loop may reveal the presence of that CDN or details about CDN chaining arrangements. For example, if CDN A forwards to CDN B, CDN B's presence can be inferred by observers who see CDN B react differently based on the CDN-Loop header.
Depending on how CDN-Loop is used, it can expose internal CDN configuration details such as the number of hops inside the CDN and the hostnames of internal nodes, which may aid attackers in mapping CDN topology.
The CDN-Loop header field can be generated by any client, so its contents cannot be trusted. CDNs that alter behavior based on its contents must ensure this does not create a Denial of Service attack vector.
The threat model addressed is a customer (intentionally or accidentally) configuring a forwarding loop that attacks a CDN service provider. CDNs must not permit customers to modify or remove the CDN-Loop header field; any CDN that does so remains an attack vector against both implementing and non-implementing CDNs.
CDN-Loop is defined as a comma-separated list of cdn-info values: `CDN-Loop = #cdn-info`, `cdn-info = cdn-id *( OWS ";" OWS parameter )`, `cdn-id = ( uri-host [ ":" port ] ) / pseudonym`, `pseudonym = token`. The pseudonym token syntax excludes whitespace, DQUOTE, and the characters `(),/:;<=>?@[]{}` per RFC 7230 Section 3.2.6.