Benjamin Kaduk's No Objection on draft-ietf-httpbis-cdn-loop-01: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-httpbis-cdn-loop-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cdn-loop/



----------------------------------------------------------------------
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?

Received on Thursday, 20 December 2018 13:48:24 UTC