This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] Possible software probe "farming" on AS47583
- Previous message (by thread): [atlas] Possible software probe "farming" on AS47583
- Next message (by thread): [atlas] Possible software probe "farming" on AS47583
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Job Snijders
job at sobornost.net
Mon Feb 5 22:39:58 CET 2024
Dear all, With no hats ... On Mon, Feb 05, 2024 at 09:17:46PM +0000, Rodolfo García Peñas (kix) wrote: > if the goal is farm credits, remove the credits obtained by these > probes to prevent these situations from proliferating. While I agree with the sentiment, I am not sure we can be certain that the goal is farming of credits. It is possible there are innocuous explanations for what was observed: there could be a misunderstanding on how to productively participate in RIPE Atlas, and do so too enthusiasticly; there could be a deployment scenario that wasn't envisioned before (someone allocating a /32 and /128 from a contigious IP range albeit that each probe really is in a very different POP); or perhaps a provisioning script that went rampant, or perhaps someone is actively trying to understand a horrible elusive load-balancing issue (... raison d'etre of NLNOG RING) >From my experience with operating the NLNOG RING Looking Glass, as admins we'd sometimes politely refuse to set up additional BGP sessions because of a lack of perceived diversity, to avoid bearing a burden for no new information. On the one hand the RIPE NCC operational staff should probably have a free hand in refusing service in terms of RIPE Atlas data ingestion iff there is reasonable suspicion about 'gaming the system' (whatever motivates the gaming). On the other hand, there might be merit in implementating a 'similarity' metric (based on keys like origin AS, latency to anchors, hops to anchors, some other factors, but not necessarily on prefix); and the default being to skew the probe selection algorithm towards 'more diverse'. I posit it wouldn't be all that strange when a global ISP allocates a /26 IPv4 towards RIPE Atlas probes for their global distribution of sw-probes (perhaps to conserve on ACL TCAM space if holes need poking), but where things get a tad less useful is when 64 probes exist on the exact same place in the Internet topology. In short: perhaps there is a place for very similar probes, but it would be nice of all-too-similar probes don't end up being selected, but it could be nice to be able to select very similar probes! Kind regards, Job
- Previous message (by thread): [atlas] Possible software probe "farming" on AS47583
- Next message (by thread): [atlas] Possible software probe "farming" on AS47583
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]