- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 2 Jul 2018 18:35:31 +1000
- To: Thomas Peterson <hidinginthebbc@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, "Ludin, Stephen" <sludin@akamai.com>, Nick Sullivan <nick@cloudflare.com>
Yes :) > On 2 Jul 2018, at 6:35 pm, Thomas Peterson <hidinginthebbc@gmail.com> wrote: > > You mean Via and not Vary, right? > > Regardless, it makes sense. > > Thank you. > > -----Original Message----- > From: Mark Nottingham <mnot@mnot.net> > Date: Monday, 2 July 2018 at 09:19 > To: Thomas Peterson <hidinginthebbc@gmail.com> > Cc: HTTP Working Group <ietf-http-wg@w3.org>, "Ludin, Stephen" <sludin@akamai.com>, Nick Sullivan <nick@cloudflare.com> > Subject: Re: New Version Notification for draft-cdn-loop-prevention-00.txt > > Hi Thomas, > > That's a good question. The focus is on CDNs here because it's a problem and a solution that's pretty specific to them. > > In other words, it's easy to prevent loops when you control all of the layers (or can closely coordinate with them); you just define a loop prevention mechanism. AFAIK most CDNs do this internally already. > > The problem is when you a) have multiple uncoordinated layers (like CDNs), and b) they can be configured by a potential attacker, or misconfigured by a well-meaning customer who's using multiple CDNs. > > In that case, the CDNs need to agree on a mechanism that can prevent loops amongst them; once we settle on it, we can prevent customer configuration from modifying that header field, and prevent any attack / misconfiguration. > > In theory it could be used by others. However, given the misuse of Vary that the draft cites, I'm reluctant to make its use too broad; if sites start doing other things with it, we won't be able to use it in CDNs, and we'll have to create Yet Another Header. > > Does that make sense? > > Cheers, > > >> On 2 Jul 2018, at 6:10 pm, Thomas Peterson <hidinginthebbc@gmail.com> wrote: >> >> Thanks Mark. >> >> Should this specification be specifically named and emphasised on CDNs exclusively? I would think that many web services with more than 1 tier of load balancing/traffic routing have also shot themselves in the foot at least once with traffic looping. >> >> From: Mark Nottingham <mnot@mnot.net> >> Date: Monday, 2 July 2018 at 08:04 >> To: HTTP Working Group <ietf-http-wg@w3.org> >> Cc: "Ludin, Stephen" <sludin@akamai.com>, Nick Sullivan <nick@cloudflare.com> >> Subject: Fwd: New Version Notification for draft-cdn-loop-prevention-00.txt >> Resent-From: <ietf-http-wg@w3.org> >> Resent-Date: Mon, 02 Jul 2018 07:00:48 +0000 >> >> (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/ > > -- > Mark Nottingham https://www.mnot.net/ > > > > -- Mark Nottingham https://www.mnot.net/
Received on Monday, 2 July 2018 08:36:00 UTC