[aprssig] Universal APRS messaging and authentication

[Pete Loveall AE5PL Lists]

> -----Original Message-----
> From: Robert Bruninga
> Sent: Wednesday, October 22, 2008 12:30 PM
> Subject: Re: [aprssig] Universal APRS messaging and authentication
> 
> Greg, this is great news.  I think it is very important to have
> that initial layer of authentication.  I have not used it yet,
> but here are some additional issues which maybe you have
> addressed:

I agree.  While Steve maintains that "since APRS-IS is not secure" makes it ok to make it easy to abuse, I disagree.  The weak level of security that exists on APRS-IS has served its purpose and will continue to as long as someone doesn't encourage abuse either directly or by "showing everyone how it can be done".  There are over 1000 servers of different flavors out there and thousands more APRS clients that depend on the weak security that was implemented in the early days of APRS-IS.  Most of those clients cannot be changed which makes any type of APRS-IS 2 incompatible with those clients and therefore with the majority of the amateur community.  Presenting some level of authentication like OpenAPRS does for web access helps preserve the relative calm we have had on APRS-IS to-date.

> 1) Messages should be transmitted using the original APRS decay
> algorithm to improve delivery reliability.  I'd suggest
> something like Now, then 15
> sec later, then 30, then 1 min, then 2, then 4 then 8 and then
> stop.

Unfortunately, this decay algorithm is incompatible with the dupe checking algorithm implemented out of necessity on APRS-IS.  The dupe checking algorithm is a sliding 30 second window based on station of origin, destination station (since Mic-E can use the destination as data), and the data portion of the packet (usually done by CRC).  Like the digipeater dupe check algorithm, this is purposefully oblivious to packet "types" as the dupe check algorithm is primarily in place to prevent (or reduce) loops.  The decay algorithm you propose would, at a minimum, miss the first and second retries (15 and 30 seconds).  Just food for thought...

> 4) Somewhere in the message packet, the source of the Message
> Engine should be identified.  There are two places.  One is for
> anything going into the APRS-IS could use some kind of ID syntax
> in the PATH like the Igates do now.  The other is in the
> LINE-NUMBER.  I suggest the last two bytes for a unique
> two-letter abreviation.  So the line number could be like this:
> ...{xxxID where "ID" is the engine sending the message.

APRS-IS shows TCPIP* in the path for locally attached systems.  A further indicator (since these messages would "originate" from the user, not from the message server) could be using the qAS construct with the message server's APRS-IS login shown after the qAS.  This is much better for diagnosis than a 2 character ID that would have to be coordinated (and verified that it doesn't break other software).

73,

Pete Loveall AE5PL
pete at ae5pl dot net