[aprssig] Why Not "Gate in Vicinity"

[Steve Dimse]

On Dec 28, 2011, at 8:59 AM, Lynn W. Deffenbaugh (Mr) wrote:

> But my real point was that the APRS-IS is not something that can do anything by itself, certainly APRS-IS can't deliver posits to local RF environments but itself, no matter what we do to the packets that are being carried.  APRS-IS is designed to be, and is, a packet transporter, no more, and no less, with none of the contemporary implications of being called a "network" as relates to the computer field.
> 
Then neither can the Internet do anything "by itself". Doing stuff is a function of the software that exists on the end nodes of the network (and therefore is part of the network), and since IGate software is a part of the APRS-IS, I think semantically it is correct to say the APRS-IS can deliver packets to RF (undeniably to the TNC feeding a radio, maybe you can make a claim that the radio is not part of the APRS_IS and only a radio can deliver the packet to RF); it has been able to since 1997. 

Whether any specific class of traffic should be gated to RF is debatable, but I maintain that is a decision that should be made locally.

There exists a method for individuals to send a posit to local RF networks. If done incorrectly it can cause problems, but that is true of almost everything in APRS. The default is off, someone needs to do it intentionally. I could in 2 minutes write a script that sends a message to every digi on findU from K4HG-8, thereby putting my position on every RF network. Obviously that is a bad idea, but the ability to do that has been part of the APRS IS for 14 years.

I would be opposed to any system which sends all posits to RF automatically, but mostly because it takes the autonomy away from the individual IGate operators who are in a position to decide how much additional traffic, if any, their local network can handle. I am not opposed to a system that allows local IGate operators the choice to make that decision. 

In most IGate software there has long been a way to gate traffic of individual stations from the internet to RF, at the discretion of the IGate operator (aprsd config options gate2rf, msgdest2rf, and posit2rf for example). Many areas used this feature when Citizen Weather traffic was on the same feed as the APRS traffic, as a way of putting additional local weather data on RF, and it was very useful for following locals when they were on long trips. Expanding this function would not be difficult, though the default should most definitely be off.

My overall point is that there are more than enough ways to remotely mount a denial of service attack on any individual APRS RF network or the APRS IS. Fighting a potentially useful feature on the grounds it provides another DoS route denies the potential utility but does nothing to improve the resistance of the APRS network to (intentional or accidental) attack. There certainly should be care given to how new features are implemented and documented and in keeping defaults such that they will not unknowingly affect areas, but as I've always said the decision of what is on the local RF networks belongs to the local users, not to the keepers of the APRS IS.


Steve K4HG