[aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption

[Steve Dimse]

On Mar 29, 2014, at 11:13 AM, Andrew P. <andrewemt at hotmail.com> wrote:

> Hi, Steve.
> 
> I agree with some of your statements, but I have some questions about others.
> ...
> Actually, aren't there 3rd-party traffic rules, such that, for example, Internet traffic from certain countries can't be transmitted by a US ham (because the US doesn't have an agreement with that country to allow 3rd-party traffic)?
>  
Foreign third party rules apply to transmissions to destinations outside the US, not to the country of origination. As long as the destination of the third party message is inside the US this restriction does not apply.

> > Nor is there a violation if a non-ham husband uses messaging on findU that
> > results in a transmission to a ham wife "Buy milk on the way home".
> 
> Unless that non-ham is prohibited from being a third-party for whatever reason.

The only restriction which might come into play is the restriction on a third party participating in stating the message "The third party is not a prior amateur service licensee whose license was revoked or not renewed after hearing and re-licensing has not taken place; suspended for less than the balance of the license term and the suspension is still in effect; suspended for the balance of the license term and re- licensing has not taken place; or surrendered for cancellation following notice of revocation, suspension or monetary forfeiture proceedings. The third party may not be the subject of a cease and desist order which relates to amateur service operation and which is still in effect."

Rare, and very hard to detect! Does LOTW suspend certs for this reason? If so, this is indeed another example where an large amount of effort would prevent an unprecedented and extremely unlikely threat.
> 
> > We will notice an ongoing problem long before the FCC, and we can handle it
> > ourselves without generating any adverse consequences for the IGate operator.
> 
> Uh, how _can_ and _do_ we handle it at the present time? Do we have blacklisting
> ability in every I-gate to block an offender? That's asking a lot of the thousands of
> Tx-IGate operators, who probably aren't monitoring every single station gating to
> RF through them. The problem still exists (in a smaller scale) in the APRS-IS
> servers, because it only takes one party not enforcing the blockade to let
> offenders through.
> 
This is not an APRS IS level issue, it is an RF LAN issue. How _do_ we do it? We don't because it AFAIK has never been an issue.

We would handle it the old fashioned way, person to person. Say I'm an IGate transmitting the weather report for CWxxxx, which has "Eat at Joe's". If it is an issue it is only because someone notices it on RF, and they will get in touch with me and I'll remove the station from my blessed list. The FCC is not driving around the country looking for commercial traffic on 144.39!

There can never be a blacklist because any traffic can look like it originates from anywhere. 

Suppose a guy starts bootlegging my call, and send on the APRS IS messages to every other station saying "Eat at Joe's". Those destination stations which are on RF will cause the message to be IGated, and lots of IGate operators will be in violation of FCC rules. Blocking my call does not good even if you had a blacklist, he'll just switch to your call. We'll know it because everyone is getting the message. Dealing with this would be harder than if we had per-packet signing. But true authentication doesn't prevent attack on the APRS IS, it just changes the manner.

If someone is determined to ruin the APRS IS, they will do it. Even if you wave the magic wand and sign every packet and have a blacklist, the same guy can just rent a botnet and DoS the APRS IS servers. 

We aren't protecting a bank's assets. The APRS IS is not a target, guys with the skills to hack aim at the Targets of the world.

> Frankly, I don't think this whole thread would have gotten started if it weren't for the problem that we _don't_ have a way to handle it. APRS-IS doesn't have the central
> authority and resources to automatically and selectively censor traffic.

The APRS IS also does not have a way to slice bread. It doesn't need it. 

The thread started because people are reacting to an extremely unlikely, theoretical threat with effort intensive solutions that modify but don't prevent attack. The best way to be sure the APRS IS does not become a target is to remain useless to hackers. And we will!

Steve K4HG