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

[Ballot comment]
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?

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D12072


This seems like can be easily fixed, but I do think it needs to be
fixed.

DETAIL
S 2.
>      header if necessary).
> 
>      The token identifies the CDN as a whole.  Chosen token values SHOULD
>      be unique enough that a collision with other CDNs is unlikely.
>      Optionally, the token can have semicolon-separated key/value
>      parameters, to accommodate additional information for the CDN's use.

I don't know how to understand "unique enough" as a conformance
requirement. I think you need to specify something specific here, like
"globally unique" or some other scope. I don't insist that you provide
a construction algorithm, though obviously that would be good.

[Ballot comment]
S 1.
>      in a "loop" accidentally; because routing is achieved through a
>      combination of DNS and forwarding rules, and site configurations are
>      sometimes complex and managed by several parties.
> 
>      When this happens, it is difficult to debug.  Additionally, it
>      sometimes isn't accidental; loops between multiple CDNs be used as an

can be used


S 2.
>      CDN-Loop = #cdn-id
>      cdn-id  = token *( OWS ";" OWS parameter )
> 
>      Conforming Content Delivery Networks SHOULD add a value to this
>      header field to all requests they generate or forward (creating the
>      header if necessary).

Can this header only go in a request?


S 3.
>      through configuration) and servers (including intermediaries) SHOULD
>      NOT use it for other purposes.
> 
>  3.  Security Considerations
> 
>      The threat model that the CDN-Loop header field addresses is a

As Alissa points out, this also potentially leaks the CDN you use,
even if that would otherwise be hidden. For instance, suppose that a
request goes A -> B -> C but B is hidden (doesn't add anything to the
headers). If you know B's token, then you can tell if this is the case
or not., by injecting it yourself and seeing if you get service. Seems
like you should document this.

[Ballot comment]
*** 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?

[Ballot comment]
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...

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-cdn-loop-01. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

a single, new registration is to be made as follows:

Header Field Name: CDN-Loop
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review registry (see RFC 8126), we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-12-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-cdn-loop@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, alexey.melnikov@isode.com, Tommy Pauly , tpauly@apple.com, Patrick McManus
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CDN Loop Prevention) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document: - 'CDN Loop Prevention'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-12-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


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




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cdn-loop/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cdn-loop/ballot/


No IPR declarations have been submitted directly on this I-D.

Technical Summary

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.

The document was co-authored by employees of three different large CDNs.

Working Group Summary

The group was largely in agreement that this was a sensible solution
and consensus was quickly reached. About 35 emails were exchanged on
the document. A majority of the comments dealt with the relationship
between CDN-Loop and the existing Via header field. Consensus was
reached that Via was essentially 'burned' at this point and not
operationally suitable for that purpose.

Document Quality

Participation in the document's review and development was sufficient
given the tight scope of the document. In addition to the 3
primary authors, 9 other individuals weighed in with comments and
reviews. This represented contributors from both clients, servers, and
intermediaries

The Working Group Last Call requested information on any plans to
implement. In addition to the author's CDNs one other CDN stepped
forward at that time with interest. There has been at least one
pre-release deployment already.

Personnel

Tommy Pauly is the document shepherd; Alexey Melnikov is the
responsible Area Director.
 

Technical Summary

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.

The document was co-authored by employees of three different large CDNs.

Working Group Summary

The group was largely in agreement that this was a sensible solution
and consensus was quickly reached. About 35 emails were exchanged on
the document. A majority of the comments dealt with the relationship
between CDN-Loop and the existing Via header field. Consensus was
reached that Via was essentially 'burned' at this point and not
operationally suitable for that purpose.

Document Quality

Participation in the document's review and development was sufficient
given the tight scope of the document. In addition to the 3
primary authors, 9 other individuals weighed in with comments and
reviews. This represented contributors from both clients, servers, and
intermediaries

The Working Group Last Call requested information on any plans to
implement. In addition to the author's CDNs one other CDN stepped
forward at that time with interest. There has been at least one
pre-release deployment already.

Personnel

Patrick McManus is the document shepherd; Alexey Melnikov is the
responsible Area Director.