I reported the problem in March 2022 but without good solution :/ https://www.ripe.net/ripe/mail/archives/ripe-atlas/2022-March/004961.html Filtering out all software probes is not a solution because many of them are good and useful. We should have filters to filter out probes which are useless and are deployed only for farming purposes and here we have totally such case. Regards, Grzegorz From: ripe-atlas <ripe-atlas-bounces@ripe.net> on behalf of Randy Bush <randy@psg.com> Date: Monday, 5 February 2024 at 18:54 To: Ben Cartwright-Cox via ripe-atlas <ripe-atlas@ripe.net> Subject: Re: [atlas] Possible software probe "farming" on AS47583 While doing some measurement work earlier this weekend I discovered that there are a large amount of probes on AS47583 that look like they are being set up to farm credits. seems silly, as all one has to do to get a jillion credits is asl on the mailing list randy -- ripe-atlas mailing list ripe-atlas@ripe.net<mailto:ripe-atlas@ripe.net> https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-atlas__;!!GjvTz_vk!SDCX1ok7Fg4dHevsKnAsP6jnOnJYpKBHkT3XgSzeFCzXDPyVlJ59NDSYifR_pu5mr7XL9NCQCA$<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atlas__;!!GjvTz_vk!SDCX1ok7Fg4dHevsKnAsP6jnOnJYpKBHkT3XgSzeFCzXDPyVlJ59NDSYifR_pu5mr7XL9NCQCA$>

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

The same farming is observed in other AS47583 locations: US, UK, France, Netherlands, Lithuania, India, Singapore, Indonesia. Regards, Grzegorz

Very weird, as mentioned one message to this mailing list and you can er millions of credit. Why would anyone do this? Could it have some other reason? Criminals trying to find IP addresses that respond to ICMP ping requests and then try to hack those addresses? I really think the owner of these probes should be contacted and if their response does not fit with the purpose of Atlas, the probes should be disabled. Regards, Ernst J. Oud

On 5 Feb 2024, at 18:54, Randy Bush <randy@psg.com> wrote:



...

While doing some measurement work earlier this weekend I discovered that there are a large amount of probes on AS47583 that look like they are being set up to farm credits.

seems silly, as all one has to do to get a jillion credits is asl on the mailing list

randy

-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas

Robert Kisteleki wrote on 20/02/2024 15:43:

Since the potential pool of software probes is almost infinite, in response to the highlighted case, we'd like to propose the following mid-term approach:

* No user/account should be allowed to run more than X SW probes from the same IP (X=3 ?)

* No user/account should be allowed to run more than Y SW probes from the same IPv4/24 IPv6/48 (Y=5 ?)

* Regardless of the user/account, no more than Z SW probes should be allowed from the same IPv4/24 IPv6/48 (Z=10 ?)

X, Y and Z are defaults, can be changed per account. This is done in order to facilitate corner cases and overstepping the limits, if this is warranted (given a good explanation). We are also reaching out to the current "peak users" to understand their use cases and motivations - the above limits can be enforced depending on the responses.

This looks reasonable. Particularly reaching out to try to understand why the individuals in question are doing this. It would be interesting to check for any unusual probe activity which used these credits. Nick

Those limits seem reasonable enough, My own intuition would suggest values of: X=2 Y=3 Z=5 But otherwise, I welcome such a change being implemented! On Tue, 20 Feb 2024 at 15:43, Robert Kisteleki <robert@ripe.net> wrote:

...

Is there an immediate way to report these probes other than this mailing list? I don't know of one and so I'm here :)

Dear Ben and others,

Each new, connected RIPE Atlas probe provides incremental value to the system and its users, but this value decreases with similarity to existing probes ("diminishing returns"). At the same time connecting a probe and processing results from it has some costs, so we'd like to be conscious of the cost/benefit ratio.

Since the potential pool of software probes is almost infinite, in response to the highlighted case, we'd like to propose the following mid-term approach:

* No user/account should be allowed to run more than X SW probes from the same IP (X=3 ?)

* No user/account should be allowed to run more than Y SW probes from the same IPv4/24 IPv6/48 (Y=5 ?)

* Regardless of the user/account, no more than Z SW probes should be allowed from the same IPv4/24 IPv6/48 (Z=10 ?)

X, Y and Z are defaults, can be changed per account. This is done in order to facilitate corner cases and overstepping the limits, if this is warranted (given a good explanation). We are also reaching out to the current "peak users" to understand their use cases and motivations - the above limits can be enforced depending on the responses.

In the longer term we believe a more flexible approach is to base this on what has been termed "probe similarity metrics": a new probe that is really similar to some existing one has less value to the system, therefore after reaching a low enough limit it can be refused, or alternatively, simply not gaining credits for its owner. This diincentivises creating "probe farms".

Regards,

Dear Ben, In short: yes. There were a couple of responses to the approach/limits proposed. We reached out to the users who are over those limits and have gotten some replies with justifications. The implementation of said rules is in in the plans now. Regards, Robert On Thu, May 2, 2024 at 1:44 PM Ben Cartwright-Cox <ripencc@benjojo.co.uk> wrote:

Did anything come of this? I just ran a measurement to spot check something and the same AS47583 probes make up a "hilarious" amount of results: https://atlas.ripe.net/measurements/70655999#probes

On Tue, 20 Feb 2024 at 23:16, Ben Cartwright-Cox <ripencc@benjojo.co.uk> wrote:

...

Those limits seem reasonable enough,

My own intuition would suggest values of:

X=2 Y=3 Z=5

But otherwise, I welcome such a change being implemented!

On Tue, 20 Feb 2024 at 15:43, Robert Kisteleki <robert@ripe.net> wrote:

...

...

Is there an immediate way to report these probes other than this mailing list? I don't know of one and so I'm here :)

Dear Ben and others,

Each new, connected RIPE Atlas probe provides incremental value to the system and its users, but this value decreases with similarity to existing probes ("diminishing returns"). At the same time connecting a probe and processing results from it has some costs, so we'd like to be conscious of the cost/benefit ratio.

Since the potential pool of software probes is almost infinite, in response to the highlighted case, we'd like to propose the following mid-term approach:

* No user/account should be allowed to run more than X SW probes from the same IP (X=3 ?)

* No user/account should be allowed to run more than Y SW probes from the same IPv4/24 IPv6/48 (Y=5 ?)

* Regardless of the user/account, no more than Z SW probes should be allowed from the same IPv4/24 IPv6/48 (Z=10 ?)

X, Y and Z are defaults, can be changed per account. This is done in order to facilitate corner cases and overstepping the limits, if this

...

...

warranted (given a good explanation). We are also reaching out to the current "peak users" to understand their use cases and motivations -

is the

...

...

above limits can be enforced depending on the responses.

In the longer term we believe a more flexible approach is to base this on what has been termed "probe similarity metrics": a new probe that is really similar to some existing one has less value to the system, therefore after reaching a low enough limit it can be refused, or alternatively, simply not gaining credits for its owner. This diincentivises creating "probe farms".

Regards,