Subject: Ben Campbell's No Objection on draft-ietf-httpbis-cdn-loop-01: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Dec 2018 15:58:39 -0800

Ben Campbell 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:
----------------------------------------------------------------------

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Dec 2018 12:56:35 +1100

Hi Ben,

> On 20 Dec 2018, at 10:58 am, Ben Campbell <[email-masked]> wrote:
> 

I think these are all addressed now.

> "prevent" them.

Good point. I've changed "prevent" to "detect" throughout -- including in the document title.

> -- last paragraph: "To be effective, intermediaries - including

That's a good question. If this is an issue, I think we could address it by either updating RFC7231, or removing the requirement and making this prose.

Do people have a preference there?

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

That depends on what capabilities that they offer to their customers; if they allow customers to configure a header modification, they'll need to make an exception for this header field name. Doing so is common; e.g., most CDNs don't allow you to modify headers like Connection or Content-Length, because doing so would break HTTP.

> attack vector" Missing word(s) around "CDNs be"?

Fixed, thanks.

> -- last paragraph: The last sentence os convoluted. Can it be broken into

I've rewritten to:

"""
This specification defines the CDN-Loop HTTP request header field to help prevent such attacks and accidents among implementing forwarding CDNs, by disallowing its modification by their customers.
"""

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Dec 2018 21:22:27 -0600

Hi Mark,

Thanks for the quick response. Response-responses are inline. I removed sections that seem resolved.

Thanks!

Ben

> On Dec 19, 2018, at 7:56 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Ben,
> 

[...]

> Do people have a preference there?

I’m okay either way. The latter is probably easier :-)

> That depends on what capabilities that they offer to their customers; if they allow customers to configure a header modification, they'll need to make an exception for this header field name. Doing…

Ah, maybe my confusion who the “customer” is and what it means for them to modify headers. If we are talking about customers configuring CDN settings, then it’s pretty obvious. If, OTOH, the “customers” modify headers in a client or intermediary, then things are different. From your response, I gather the former was the intent.

>> ** Editorial Comments ***

[...]

> “""

WFM.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Dec 2018 15:09:24 +1100

> On 20 Dec 2018, at 2:22 pm, Ben Campbell <[email-masked]> wrote:
>> 

OK. I've taken the easy way out and changed "MUST NOT" to "must not".

> Ah, maybe my confusion who the “customer” is and what it means for them to modify headers. If we are talking about customers configuring CDN settings, then it’s pretty obvious. If, OTOH, the “custo…

I've changed to "For it to function, CDNs cannot allow customers to modify or remove it in their configuration" to try to clarify this.

Thanks!