Re: New Version Notification for draft-cdn-loop-prevention-00.txt

Hi Patrick,

On 3 Jul 2018, at 2:29 am, Patrick McManus <mcmanus@ducksong.com> wrote:
> 
> Hi, thanks for the draft! Some comments as an individual ...
> 
> * I agree with the comment that, as proposed, this isn't really a CDN specific solution. Its a more opaque version of via.. so it makes sense to me to construct it independent of CDNs and instead focus it on any element that wants to participate in loop prevention. CDNs serve as the primary illustrator.

If it were made it into a generic loop-detection mechanism among all kinds of intermediaries, I'd be concerned that it becomes less robust for its intended purpose. Right now its primary use case is to avoid looping  in intermediaries that are uncoordinated in action but able to be directed to each other by a single party (either a potential attacker or a genuine mistake by a user). 

That's a fairly unique situation. People who want to avoid loops within their own infrastructure can already do so by inserting a new header field -- just as CDNs currently do. Or they can use Via, provided that they don't run into the same origin problems that I mentioned. It's only when the intermediaries are uncoordinated *but* able to be controlled by a potential attacker when you need to nominate a header that can't be modified by the user of the intermediary.

Another header like Forwarded could be used -- but since it's useful for other purposes, there will be some level of demand to remove / modify / etc. that header field, for various purposes. CDNs are very obliging like that. Likewise, if the header we choose were available for other purposes / parties, I'm concerned that there would be pressure from customers to allow it to be changed, precisely *because* other components are acting upon it; people tend to use their CDNs to do all sorts of fixups, routing, etc.

I know we try to make mechanisms as general as possible here, and that's a virtue. In this case, however, making it general makes it an attractive nuisance. 

> * I would be interested in more text on why Via failed and therefore this should succeed.. you mention that via is used in practice as a control signal incompatibly enumerating intermediaries.. I agree, but I also think via in practice reveals information people don't want revealed.. is CDN-loop perhaps more robust to this because the token is opaque (and perhaps not consistent between exchanges)?

I think it's more robust because it's specifically designed as a single-purpose mechanism with a very limited scope of applicability (CDNs); that's why I'm pushing back on broadening it.

> * the draft focuses on creation of the cdn-loop request header but has nothing to say on who/how/when that is policed.

Yes, I think some advisory text would help here.

> * "the token defines the CDN as a whole." feels like it needs more guidance.. is it even the right advice? Is it more about the scope of the token?

Since the primary use case is avoiding loops *between* CDNs, it seemed to be the right granularity. I'm open to changes here because at the end I think CDNs will put what they want into it; the only intended audience is themselves.

> are there use cases where cascading cdns make sense that might involve CDN repeats without forming a loop?

Could you give a concrete example of what you're thinking about here?

> * it would really help the wg to understand the scope of the problem a little more.. "not unknown for CDNs to be configured in a loop" makes me wonder if the authors believe this is a serious problem (though I suspect they just didn't want to over-assert).. but given that the document basically wants to restandardize something that has been standardized (Via), a little discussion of the operational imperative makes sense. (this is not necessarily something that would have to be in the doc)

I don't think this is considered to be a *severe* problem, but it's one where most people (without speaking for the entire industry!) would like to see a coordinated solution for. 

Personally, I also want to see CDNs work together more; they're a large part of the Internet now, and more standards for how they behave is IMO a good thing for everyone. This seemed like a small, easy (hah) problem to start on.

Cheers,

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

Received on Tuesday, 3 July 2018 02:33:12 UTC