Use a policy without trusting the input
04Any client can send CDN-Loop. A CDN must account for forged values when deciding what to do, so a spelling match alone cannot authenticate a visit. The RFC leaves detection policy and response status unspecified. The second state shows only a counting-policy illustration, not a secure implementation recipe.
A separate design could add signatures, in the field or another field. RFC8586 provides neither a signature format nor a requirement to sign, so this picture does not claim verified provenance.
Source for this drawing: RFC 8586 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Untrusted input
- Data whose claimed history cannot be accepted as established merely because it is present.
- Local policy
- An implementation or deployment choice, distinguished here from a normative RFC rule.
- Denial of service
- Preventing legitimate service, including through behavior triggered by attacker-supplied values.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Treat the field as untrusted input when designing loop handling.
- Section3 says the field can be generated by any client and its contents cannot be trusted.
- CDNs changing behavior based on the field should assure this does not become an attack vector, including denial of service. Do not turn that discussion into a claim that a simple counter is a complete defense.
- The example limit of two appearances is an arbitrary local-policy value; RFC8586 assigns no mandatory count or rejection code. Legitimate forwarding topology and forged input need consideration.
- Signing field contents is possible, but RFC8586 neither defines nor requires a signature format. The base field provides no built-in authentication.
A forged marker can influence a careless reject-on-match rule. This guide explains why that is a design risk; it does not deploy a detector or send test traffic through real CDNs.
Read the RFC section ↗