[atlas] Proposal: Measure well-known CDNs,[CDN-HTTP]

Hello,


On Tue, 20 Dec 2022 at 14:38, <ripe.net at toppas.net> wrote:

> But maybe there's another way, to select which one of those providers/CDNs to measure?
> Instead of manually selecting them, there could be some sort of "threshold" which a
> provider/CDN has to reach

One layer of indirection doesn't solve that. You are just selecting
CDN indirectly then, by picking an arbitrary "threshold" that works
well for group A and doesn't for group B.

I also really can't come up with a single publicly verifiable value
that would work well for this.


I doubt that the availability of favicon.ico on a certain CDN is a
useful health check; lots of things can go wrong at a CDN which do not
impair favicon.ico delivery.
I think the entire idea of CDN-HTTP is flawed and I would much rather
see RIPE invest their resources into improving ATLAS generally.

ATLAS is not downdetector.com or Cloudflare Radar and it isn't a tool
for end-users.

I don't see a lot of value in CDN-HTTP, but lots of problems. I'm
suggesting dropping CDN-HTTP altogether and focusing the effort on
GENERIC-HTTP instead which can be very useful for everyone.

However it needs some discussion:

- where have those security concerns been previously discussed? The
arguments sound a little hand-waving'y to me. Is this really that big
of a deal that we need an opt-in approach? Are you suggesting that
people deploy ATLAS probes in security sensitive inside parts of
corporate networks? And those security concerns affect only
GENERIC-HTTP not other currently available measurements like DNS?
NLNOG RING provides *root access* to Ubuntu VMs in a large number of
organizations across the globe, we are talking about small HTTP HEAD
and GET requests here. I agree that with an opt-in approach this
feature is likely useless, for questionable security concerns.

- I think HTTPS would be very useful, considering that we are already
talking about STARTTLS (which seems more complicated to me), is HTTPS
support for GENERIC-HTTP really that long down the road? I'm talking
about HTTP/1.1 over TLS.

- data retention policies can always be modified at any point in time
based on actual data, I don't think this is a big deal


--
cheers,
lukas