- From: Patrick McManus <mcmanus@ducksong.com>
- Date: Mon, 02 Jul 2018 16:29:24 +0000 (UTC)
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, "Ludin, Stephen" <sludin@akamai.com>, Nick Sullivan <nick@cloudflare.com>
- Message-ID: <CAOdDvNoAS6=ggE=47hUDG9QL8uB4aeZqG4MMkSzKaDQR9vuq=A@mail.gmail.com>
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. * 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)? * the draft focuses on creation of the cdn-loop request header but has nothing to say on who/how/when that is policed. * "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? are there use cases where cascading cdns make sense that might involve CDN repeats without forming a loop? * 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) -P On Mon, Jul 2, 2018 at 3:00 AM, Mark Nottingham <mnot@mnot.net> wrote: > (Co-author hat on) > > For interest / discussion. This is a proposal for a minimal mechanism to > avoid loop attacks and misconfigurations against CDNs. Feedback appreciated. > > Cheers, > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for draft-cdn-loop-prevention-00.txt* > *Date: *27 June 2018 at 2:12:46 pm AEST > *To: *"Stephen Ludin" <sludin@akamai.com>, "Mark Nottingham" < > mnot@fastly.com>, "Nick Sullivan" <nick@cloudflare.com> > > > A new version of I-D, draft-cdn-loop-prevention-00.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. > > Name: draft-cdn-loop-prevention > Revision: 00 > Title: CDN Loop Prevention > Document date: 2018-06-27 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet-drafts/draft-cdn- > loop-prevention-00.txt > Status: https://datatracker.ietf.org/doc/draft-cdn-loop- > prevention/ > Htmlized: https://tools.ietf.org/html/draft-cdn-loop-prevention-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-cdn- > loop-prevention > > > Abstract: > This specification defines the CDN-Loop request header field for > HTTP. > > > -- > Mark Nottingham https://www.mnot.net/ > >
Received on Monday, 2 July 2018 16:29:51 UTC