Re: Eric Rescorla's Discuss on draft-ietf-httpbis-cdn-loop-01: (with DISCUSS and COMMENT)

HTTP has used similar constructs for 20+ years and collisions have not been an issue:

https://httpwg.org/specs/rfc7230.html#header.via
https://httpwg.org/specs/rfc7231.html#header.user-agent
https://httpwg.org/specs/rfc7231.html#header.server

All of them address the issue of pseudonym collision by recognising that implementers have an interest in distinguishing their implementations from others if they want to rely upon a field for debugging (as all of these are, effectively). None of them addresses the case of an active, *intentional* collision (as we see sometimes with User-Agent), because doing so would require far too much infrastructure, compared to any benefit seen.

Notably, doing something like rooting product tokens in the DNS name space would have done *nothing* to prevent the issues we're seeing with User-Agent. Doing so would have also brought about the usual questions around whether something needs to listen at that hostname, whether it needs to resolve, and what happens when a name changes hands.

The failure case of a collision is also pretty straightforward; if I run a CDN and another CDN usurps my value, they're only shooting themselves in the foot, because it'll look like they're in a loop if I'm configured to forward traffic to them, and they'll start refusing requests -- thereby screwing their customers. Their natural incentive is to avoid this situation.

So, the properties you're looking for are already naturally emergent from the documented protocol. While we could require a hostname, I think doing so is effectively cargo-cult protocol design; it won't actually improve collision avoidance in practice.



> On 28 Jan 2019, at 6:44 am, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Unless I am misreading this text, it seems to not provide any guidance at all about how the pseudonyms are constructed, so I don't really see how it addresses the issue of pseudonym collision
> 
> On Thu, Dec 20, 2018 at 9:04 PM Mark Nottingham <mnot@mnot.net> wrote:
> See:
>   https://github.com/httpwg/http-extensions/commit/59505dbd1883
> 
> 
> > On 21 Dec 2018, at 3:34 pm, Adam Roach <adam@nostrum.com> wrote:
> > 
> > On 12/20/18 7:19 PM, Mark Nottingham wrote:
> >> On 21 Dec 2018, at 11:40 am, Adam Roach <adam@nostrum.com> wrote:
> >>> I agree with EKR here. The more I think about the situation -- and Mark's responses in particular ("There are relatively few CDNs, and they're pretty aware of each other") -- the more I'm convinced that, while the proposed solution *probably* works in 2018, it may well fail in 2028, depending on how the CDN market evolves. If history is any guide, engineers are pretty terrible futurists. The best we can do is plan for scaling beyond that which we can presently imagine (cf. IPv4).
> >>> 
> >>> I think some means of collision avoidance here is required prior to document publication.
> >> I agree engineers are terrible futurists; however (and perhaps as a result), we're really really good at over-engineering things for anticipated problems that don't eventuate. My viewpoint here is informed by observing how many Web-related registries operate (or fail to).
> > 
> > 
> > No one here is asking for a registry.
> > 
> > 
> >> The current specification allows us to insert more stringent requirements in the future if necessary. Personally, I think that's sufficient.
> >> 
> >> However, if you insist, I think the lowest-impact way to address this is to adopt a structure similar to that used in Via, (hostname under control of the CDN or pseudonym) and encourage (but not require) use of a hostname.
> > 
> > 
> > It's probably enough to say that it has to end in a domain name under control of the CDN, but your proposal works as well.
> > 
> > 
> >> If we do that, we might want to revisit the example, since its use of 'host' might be confusing to readers.
> > 
> > 
> > I always assume that spec changes that impact examples imply changes in the corresponding examples, so yes. Thanks.
> > 
> > 
> > /a
> > 
> > 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 

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

Received on Sunday, 27 January 2019 22:10:51 UTC