Loop Detection in Content Delivery Networks (CDNs)
draft-ietf-httpbis-cdn-loop-02

I have only a small nit: 
"The threat model that the CDN-Loop header field addresses is a customer who is attempting to attack a service provider by configuring a forwarding loop by accident or malice. "

The "attempting to attack ... by accident" reads oddly to me. It feel to me that "attempting" implies intent, and I don't see how you can accidentally intend to attack.
Perhaps "The threat model that the CDN-Loop header field addresses is a customer who is attacking a service provider by configuring a forwarding loop by accident or malice. " (or "causing an attack" or "negative impact").

Anyway, this is just a minor point, perhaps try address it if you are editing anyway...

Thanks to everyone who worked on this document. In general it looks good,
although I have a handful of suggestions that the authors may wish to
consider.

---------------------------------------------------------------------------

General:

SIP has a similar (albeit more rigorously-defined) loop detection model, which
carefully distinguishes between unwanted loops and what SIP terms "spirals,"
which are requests that (for valid operational reasons) traverse the same
entity more than once. Is it possible that CDNs might have similarly
intentional configurations that cause a request to traverse their network more
than once? If so, it's probably worth discussing this somewhere in this
document, so as to increase the chances that implementations have the
functionality needed by CDN operators.

---------------------------------------------------------------------------

General:

This mechanism implies a means for detecting loops, but gives no guidance for a
uniform way of indicating that such a loop has occurred. I would have expected
the document to either point to an existing 400- or 500-class response code, or
define a new 400- or 500-class response code to indicate a loop-induced failure.
(Compare with SIP's 482 response code).

Consider adding such guidance and/or a new code.

---------------------------------------------------------------------------

Abstract:

>  This specification defines the CDN-Loop request header field for
>  HTTP.

This description is too sparse to be a useful abstract. The technical summary
from the document shepherd write-up would seem to be a reasonable bit of text
to replace it with:

>   This simple document defines a new request header field for HTTP:
>   CDN-Loop. CDN-Loop addresses an operational need that occurs when an
>   HTTP request is intentionally forwarded between CDNs but then is
>   accidentally re-routed back into the original CDN causing a non
>   terminating loop. The new header field is used to identify the error
>   and terminate the loop.

---------------------------------------------------------------------------

§2:

>  header field to all requests they generate or forward (creating the
>  header if necessary).

Nit: "...creating the header field..."

>  As with all HTTP headers defined using the "#" rule, the CDN-Loop
>  header can be added to by comma-separating values, or by creating a

Nit: "...HTTP header fields..."

Nit: " ...CDN-Loop header field..."

---------------------------------------------------------------------------

§2:

>  CDN-Loop: FooCDN, barcdn; host="foo123.bar.cdn"

While the "cdn" TLD is not yet allocated by ICANN, it remains available for a
registry to apply for an be granted. Please use a hostname from a TLD or
second-level domain allocated by RFC 2606.

Is it possible that a chain of these headers might reveal something proprietary (or otherwise non-public) that an involved CDN or site might not want to have revealed to any entity with access to the request? Also, it seems possible for these headers to exacerbate fingerprinting of clients, say if something distinguishing two requests ends up being the chain of CDN-loop headers, or if the cdn-id is made more granular than it needs to be for the specified purpose. It might be good to discuss each of these issues a bit in Section 3.

Please respond to the Gen-ART review.

*** Substantive Comments ***

I agree with Alissa's comments, and Adam's comments about configurations that intentionally cross a CDN more than once.

- abstract: The abstract could use some more meat. What does the new header accomplish?

§2:
-- first paragraph: Seems like this header helps "detect" loops, rather than "prevent" them.
-- last paragraph: "To be effective, intermediaries - including Content Delivery Networks
- MUST NOT remove this header field,"

Does that put normative requirements on things that do not implement the spec?

§3, first paragraph: How can CDNs stop their customer from modifying the header?

** Editorial Comments ***

§1, 
-- 4th paragraph: "loops between multiple CDNs be used as an
attack vector" Missing word(s) around "CDNs be"?
-- last paragraph: The last sentence os convoluted. Can it be broken into simpler sentences?

I support Ekr's Discuss (and note that "unlikely" is not really a
quantifiable criterion).

Section 1

   This specification defines the CDN-Loop request header field for HTTP
   to enable secure interoperability of forwarding CDNs.  Having a
   header that is guaranteed not to be modified by other CDNs that are
   used by a shared customer helps give each CDN additional confidence
   that any purpose (debugging, data gathering, enforcement) that they
   use this header for is free from tampering due to how that customer
   configured the other CDNs.

Per some of the other discussions on this document, I don't think that
"guaranteed" is the best description here; the property that we are hoping
to get is more that we have a well-known place to store loop-prevention
state, and it is documented as being a header field that should not be
removed by cooperating implementations.  There is no "guarantee" so long as
implementations that do not support CDN-Loop are in play, but the field of
play should improve over time as CDN-Loop support increases.

(Ben's comment about the "MUST NOT remove this header field" apparently
applying to even intermediaries that do not implement this spec is also
relevant.)

I see that this Section 2 text is already slated for edits, but I might
make a bigger change than just s/MUST NOT/must not/, maybe something like:

The effectiveness of this mechanism relies on all intermediaries preserving
the header field, since removing (or allowing it to be removed, e.g., by
customer configuration) would prevent downstream CDNs from using it to
detect looping.  In general, unknown header fields are not removed by
intermediaries, but there may be need to add CDN-Loop to an
implementation's list of header fields that are not to be removed under any
circumstances.

Section 3

If we're going to talk about the potential for signing the header field's
contents (nit: the new text just talks about "the header" with no "field"),
do we need to say how the signature validation would be affected by another
intermediary adding to the CDN-Loop header field's value?

Mark provided new text and I'll trust the AD to follow up with getting it in the doc.