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

It's worth noting that it's possible that this header, at some point
in the future, could be used in situations where DNS isn't even
applicable. (Consider a hypothetical CDN whose edges are found via
some distributed mesh system. Or even some more esoteric and creative
situation.) As far as I can tell, there's no particularly compelling
reason to require a DNS registration for CDN-Loop to operate

In fact, if each host in a CDN simply picked a fairly long random
string at boot time, it would still prevent non-terminating loops. (I
wouldn't advise this generally, of course, since a request could still
"bounce" a little before terminating.)

CDNs aren't useful if they don't deliver content. Mark is exactly
right that the natural incentives will lead CDN operators to choose
values that are very unlikely to collide. I like the advice provided
that encourages the use of DNS names, since it's an easy way to pick a
non-colliding name and it works very well in today's Internet

Regarding the other point, most (all?) CDNs have the concept of
"Delivery Lanes" for groups of content managed by a single person or
group. Some CDNs may want to use different tokens for each Lane,
effectively treating each Lane as a unique CDN. This can be used to
mitigate the topology discovery attack Eric was discussing by making
the token used for a given lane difficult to determine without control
of the lane or its origin. (Consider: <random-string>.lane.cdn.example
.) Now, that doesn't directly conflict with the "identifies the CDN as
a whole" text, but the text does imply a different implementation.
Clarification on this sort of usage might be useful... or it might
obscure more than it clarifies.

On Tue, Jan 29, 2019 at 12:10 AM Martin J. Dürst <> wrote:
> On 2019/01/29 12:09, Eric Rescorla wrote:
> > On Mon, Jan 28, 2019 at 6:18 PM Mark Nottingham <> wrote:
> >
> >> Adam seemed to be OK with the current text in <
> >>>,
> >> so I think it's just you.
> >>
> >
> > 1. I'd like to hear Adam comment after reading my note below.
> > 2. I'm not sure how this changes the points I'm making.
> I think on the other side, it's not just Mark, but it's Mark, the WG,
> and, as Mark has described again recently (still included below),
> between 20 and 30 years of deployment experience with similar headers.
> Regards,   Martin.
> >
> > -Ekr
> >
> >
> >>
> >>> On 29 Jan 2019, at 11:13 am, Eric Rescorla <> wrote:
> >>>
> >>> I feel like we're talking past each other a bit.
> >>>
> >>> The original text just has some opaque string and then assumes there
> >> will be no collisions, but doesn't provide any mechanism for preventing
> >> them. Saying that people should use DNS-based names is a mechanism of
> >> preventing them, but if you also allow opaque strings then there's still no
> >> mechanism for preventing them from colliding. So, either we believe that
> >> arbitrarily chosen opaque names have a nontrivial chance of collision (in
> >> which case we need to provide a mechanism about how to not have that
> >> happen) or we believe they don't, in which case no text is needed. It seems
> >> to me that Adam and I think there is a nontrivial chance, and Mark doesn't,
> >> but that's the point to resolve.
> >>>
> >>> -Ekr
> >>>
> >>>
> >>> On Sun, Jan 27, 2019 at 4:51 PM Mark Nottingham <> wrote:
> >>> Some advisory text to guide using them?
> >>>
> >>>
> >>>> On 28 Jan 2019, at 9:45 am, Eric Rescorla <> wrote:
> >>>>
> >>>> Well, this argument has some force, but my point is that this isn't
> >> substantively different from the initial version of the draft in this
> >> respect.
> >>>>
> >>>> -Ekr
> >>>>
> >>>>
> >>>> On Sun, Jan 27, 2019 at 2:10 PM Mark Nottingham <> wrote:
> >>>> HTTP has used similar constructs for 20+ years and collisions have not
> >> been an issue:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 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.

Received on Thursday, 31 January 2019 23:21:55 UTC