There’s interest in optional abuse mitigations - some similar to APRS IP gating password schemes or other simple shibboleths, others getting into full-blown key distribution issues.
There’s also a need to decide where this mitigation happens - at the network level only, or all the way down into RF.
What if we forced authentication for the repeaters?
I’m not sure exactly what you mean - requiring authentication from handheld radio to the repeater, or from the repeater to the network?
Whatever we do, I think requiring authentication as part of the spec is a bad idea. I think it may end up a barrier to entry that introduces an entire new class of very common problems that are worse than the problems it tries to solve.
As an option, it’s a tool - but even as an option I think it’s wise to be careful, because optional things can quickly become practical requirements.
Whatever authentication practice, here are the driving questions I’ve been working with:
I’d say the primary concern with spammers and impersonators is that the reflector or network level, primarily because of the audience represented and the lack of signal proximity.
In comparison, a spammer or impersonator locally can be found with direction finding techniques - and someone looking to be a pain can just jam the repeater, they don’t actually have to speak M17, so no M17 controls can be sufficient at the local RF level.
At the network side, we can have effective controls because otherwise we just drop the packets and nothing bad happens other than the bandwidth loss (which we cannot control).
This suggests to me that the auth should be at the IP level, which is also where we have more bandwidth available.
We can avoid IP spoofing while using UDP by requiring an application-level handshake of some sort.
Direct callsign calls will almost always have NAT traversal to take into account, which is effectively a handshake, so an IP or callsign blocklist can address any issues there.
Reflectors, and other permanent infrastructure don’t have that hole punching “handshake”, so we could require one to mitigate IP spoofing.
Once IP spoofing is taken care of, IP-level blocking is almost certainly sufficient for managing the kind of spammer we’re concerned with.
For actual crypto auth, the hard part is managing and distributing and updating keys. We could do something with a DHT for the key lookup and pubkey storage, and maybe do something with a PGP-style web of trust model to try and avoid centralization.
For anything less secure like APRS internet gating ‘passwords’, I’m convinced it is more of a barrier to real users than spammers, for little to no benefit and a lot of downside for the less technical users who will be frustrated by it.
I think that IP blocklists at the network side and mature traffic selective muting at the handheld, repeater, and reflector levels would be sufficient, no crypto involved (and much easier and intuitive to use). Certainly they are still required even with crypto auth setups, and the four questions I listed above are not any harder from having blocklists, unlike crypto or derivable passwords. Finally, blocking and squelching capabilities are decentralized and avoid a single root of control, which I think is critical for any ham radio networking and for the long term survivability of the project because of the lower operating costs.
At network side, we should allways require authentication.
At RF side, we should have authentication on hand. In DMR, we have faced lots of nasty things, some people puts someone elses id’s in their radios and kerchunked lot’s of tg’s before system gets them banned. They send remote disable, remote monitor commands. Inappropriate text messages happened somewhere in the world. Moreover, I have heard these things from my friends from other countries.
We have talked this in IRC long time ago, I am not sure were you there at that moment. Here what I thought.
We may have static pin code for repeater, and all users enter that code into their device and start to use repeater, most basic option. Motorola uses this system, named RAS.
As we have open source system, this code can spread very fast and became useless for amateur systems. So, we may implement more robust system.
Repeater have a password. We are going to sha this password with callsign and give the last few bytes of this hash to user. user should add this hash into their packet and send in packet’s hash. So, we may authorize people without connecting to repeater. Prevent people to use someone elses callsigns in their devices.
SD card fail, drag and drop your key file from backup. If it is totally lost, request from sysops to recalculate for you.
Multiple radios, If you are going to use same callsign, drag and drop key file. Otherwise, request keys for tarxvf-1, tarxvf-2, tarxvf-3, tarxvf-4 etc.
I don’t know whether loaning radio to another is acceptable, if yes, today most of the radios do not support id change on the go. Install new key file or use it as before.
Joining network, hardest part. Sysop may email key files. Distribute at local club. Sysop may send over the air at simplex freq’s. Repeater may send at first key-up (preferably encrypted/in specified time interval/ after texting to sysop etc.).
If repeater is included in a network. It may inherit this key from server and radios may roam with same authentication keys. Repeaters only stores their password. There is no need to setup authentication servers. White list/black list can be implemented seperately.
At some point, we’re going to make it so complicated we lose the benefit, and add so much friction it will not be usable except to PGP/GPG afficionados (who /still/ screw it up, and they’re the people with the best chance to do it right!)
Almost by definition, the security-convenience curve is such that you must create a system that’s PGP complicated, or it’s not enough to stop someone who wants to make trouble. If it’s accessible to a new ham, and we don’t demand identification, then an attacker can easily just say “hey, i’m <ham that hasn’t signed up yet>” and cause trouble in their name.
As for requiring proven identification, I can not and will not support it as a method of addressing the problem.
That’s too much friction, and there’s something off about requiring the same level of identification to use a radio network as to open a bank account.
We don’t need to create an exclusionary system where you must be explicitly allowed on - all we need is a way to deal with the most egregious offenders.
Better to have good audit facilities to figure out which repeater or network host the traffic was coming from, and ban them by IP address for set periods of time.
Abusers from the network itself can be blocked directly.
Abusers at an RF gateway can be DF’d. RF gateways can be banned temporarily as an intermediate measure.
We will need this moderation capability anyway, if the abuse is truly an issue.
No amount of encryption or signing or keys can solve the issue if new users have to be able to generate new keys. And if a user needs a verified signature from someone else to be on the network, that is again too limiting - not to mention so exclusionary as to drive people off. My local digital people can’t even keep their website updated, much less their codeplugs.
In conclusion, banning on the network is necessary - it’s also sufficient. Simplicity and low barrier to entry are absolutely critical.
Use all the keys and signing to be able to designate people authorized to moderate a reflector, and use them to maintain a public audit log.
This way you limit the higher technical requirements to the people best able to deal with it, that are known to each other and trusted, and keep the barrier to entry for new hams low while still addressing abuse.