Trying to hide the client IP address is “security by obscurity”. That is avoidable compared to “security by design”. Any decent customer grade router is blocking all inbound traffic by default, so knowing the client IP address does not help the attacker.
If the collection of the client IP addresses is for statistical reason, it is even a good thing, then.
It’s really not that difficult a feature to build, but I do have doubts that it’s worth the effort, for reasons we have discussed multiple times in this topic.
Involving an extra third party is just over-complicating things IMHO. It’s introducing someone else that needs to be trusted. If you (as operator of a service like the NTP pool) were going to do this, you would do it yourself.
It’s easy to get a VPS with a /48 IPv6 assignment. So that’;s 48 bits of entropy you have at your disposal. If you bring up a random IP inside that /48 and use it for only an NTP query, you are not going to see any other traffic on that IP (outside your local network doing Neighbor Discovery Protocol etc) from anywhere else except the NTP server you talked to.
So, for each volunteer NTP server you want to test:
- Bring up random IP.
- Query the NTP server you’re testing.
- See if you get any other traffic to that random IP in the next few days. It doesn’t matter where the traffic comes from, all that matters is if it looks like port scanning.
- If you did, test it again with another random IP and see if the same happens again.
- Appropriate punitive action against the NTP server you tested.
You can do large numbers of tests in parallel.
Again, I’m not advocating that anyone builds this. I’m just saying that it’s not at all as difficult as you’re making out. Aside from my doubts about whether the effort is justified, the obvious next step for the scanners would be to wait longer before doing their scans, in an effort to add doubt to the causal link between NTP query and incoming scans. After all, they are only going to be interested in long-lived server IPs, so why not wait a week, or a month?
And then the miscreant just signs up with another email address and server IP.
Building the detector is not the hard part here.
Also, the researchers being more intelligent and methodical than I am took into account the possibility of on path listeners, checked out what some of the back scanning operated and other good stuff which you can see if you read the dang paper.
TLDR: it’s just another monitoring system this time for bad actors. The pool neither needs, wants, or can even get the raw packet captures from the study. You should read the paper.
@Bas, I should probably apologize for thinking you are a stupid troll, but I will not. We should work on not coming across as such.
Yes of course the researchers have built it to show that people are doing this with the NTP pool and other services.
What I mean is that by pointing out that it’s not a massive technical challenge for the pool project to reproduce the work — which I think would be necessary rather than taking in reports from a third party — I am not advocating that the pool project or any similar entity actually does it.
It’s just that the technical aspects of detection are not hard; what to do about it is hard, and unclear to me if the effort is justified.
I see the research paper as actually promoting the importance of careful use of IPv6 privacy addresses on clients, rather than something that justifies changes on the server end.
Understood.
Hmm, maybe it is a bit naive, and I don’t claim that I fully understand the ramifications, but wouldn’t excluding the offending servers from the pool be sufficient? I think the challenge is if this is not a quasi-static list, but changes often. An if this would indeed trigger a cat-and-mouse game, the other is to keep up-to-date.
But if those are easy enough to do, I personally think it would be worthwhile. Also because I suspect (but admittedly don’t have any data) that a large number of devices potentially affected are servers in the widest sense, so might not be able to usefully use IPv6 privacy, both from a technical as well as operational point of view.
Anyway, the authors write in the paper:
The NTP Pool
administrators have provided positive feedback for this suggestion
and we are actively working on integrating a production version
of our prototype from this paper into the NTP Pool scoring system
at the time of writing.
So possibly, the decision has already been taken, and implementation is already underway.
IPv6 privacy is the default, so the address that a client uses is ephemeral, so its value in databases is nil.
Even before its lifetime is over, scanning it will likely be blocked by the firewall.
So the failure to consider IPv6 privacy by the OP makes me question the attributes magnitude of the issue, at least with regards to IPv6.
As for IPv4, it can’t be helped.
Well exactly, what is the pool project going to do? Blocklist a /64? Bad actor gets a new one in a few seconds with a customer service ticket, meanwhile pool project maintains an ever-growing list of bad /64s that may end up being used by other customers of the hosting company. So pool project has to expire them after some time.
Fair enough, I don’t think it;s a terrible thing to spend time on, and people’s time si their own. 
I did wonder about the comments regarding affecting the score - if that is intended instead of removing/disabling the problem servers then it does sound a bit like a sort of soft ban where the server might still be shown as enabled but is scored low and people are left to wonder why. So again, different challenges.
I keep saying, why is this a pool problem? Meaning, why should the pool detect bad people?
All the pool does is serving time, and check if timeservers are correct. That is it’s purpose, nothing more. And it does a very good job at it.
I mean Microsoft Windows is the cause of 99.9% of the hacking worldwide, Microsoft doesn’t do anything about it.
Difference between the pool and Microsoft is: The pool isn’t hackable…Windows IS…meaning, why fix something that isn’t the cause of the problem.
Typical Linux/Unix servers are not easy to hack unless run by a dumb moron sysop.
Again, secure your Windows servers or shut up, proper *nix servers don’t give a shit about a portscan. No we don’t!
@Jamesb192, you really need to bring your crap to Microsoft, they need to fix the crap OS they put in the market. People like me that run Linux do not care about a port-scan, no we don’t.
We have things like fail2ban to keep hackers out 
@Jamesb192 I recently learned that if you visit someone’s profile, under the “Message” button, there’s a dropdown where you can select “Ignore” which filters out their replies. Do with this information what you may, but I have found it can make a more pleasant reading experience.
Fair enough, some lean devices skip the full list of features of IPv6 and have no firewall. Their problem then is much larger than the pool.
Indeed, using public services on the Internet is always a vulnerability. Take Google’s public DNS, which is a bait for them to profile you. Google is a known bad actor to avoid.
In the case of the pool, there are unknown bad actors and therefore should likewise be avoided.