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:
- What happens when a user’s SD card fails?
- What happens when one user has multiple radios?
- What happens when a radio is loaned to another person?
- How does a user first get on the network?
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.