| |
ZL3AI > APRDIG 30.10.03 19:23l 300 Lines 12472 Bytes #999 (0) @ WW
BID : 2237-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 28, 2/4
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<7M3TJZ<ZL2TZE<ZL3VML
Sent: 031030/1239Z @:ZL3VML.#80.NZL.OC #:11607 [Chch-NZ] FBB7.00i $:2237-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: The point is NOT use of BLN, it's RF User Education
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 28 Oct 2003 09:12:50 -0500 (EST)
X-Message-Number: 9
On Mon, 27 Oct 2003, Ev Tupis (W2EV) wrote:
>I've already suggested the use of a simple periodic MSG (even a status
>text would work) to deliver the "preferred UNPROTO" to RF users, but
>somehow you keep returning to the use of BLN and villifying the whole
>idea of using RF to help RF users. The point is RF-based user
>education, the rest is unimportant and quite negotiable.
Yes, you are completely right, that it was your BULLETIN concept I am
opposed to. And for over a year, my FIX144.39.HTML web page and my
postings here have actively encouraged policing software that
intelligently sends polite reminder messages (and a followup email) to
repeat offenders.
>To answer your question (something that I've done twice before, by the
>way) about dumb trackers... someone is watching them. While you may not
>reach the tracker itself, the "owner" will eventually see the RF
>messages and, being a good network neighbor, comply...because we are
>Amateur Radio operators. That's what we do.
Yes, my ONLY point was that we dont want unnecessary BULLETINS on the air
when we really want to get only to the offenders.
And so intelligent and polite POLICING software that communicates to these
individuals by Email was my preferred approach. Sending a once a day
over-the-air message I would not object to strongly, but it has always
been my belief that over-the-air criticism was not a good idea.
Putting recommended paths in position comments is also an excellent way to
get the data out, just not bulletins... Glad we are on the same page
now...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: 0 channel load APRS Steward (New concept)
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 28 Oct 2003 09:31:17 -0500 (EST)
X-Message-Number: 10
On Mon, 27 Oct 2003, Ev Tupis (W2EV) wrote:
>KC4ZGQ-2>APND0X,WIDE,qAo,KC4ZGQ-10:!3257.84ND08348.48W#Mob:R,W,W Base:W3-3
>ALL:TXD 100ms. Preferred Macon APRS UNPROTO LAN settings.
>
>+---------------+
> ## KC4ZGQ-2
> Mob:R,W,W
> Base:W3-3
>+---------------+
>
>It's more specific and informative. Would that work?
But doesnt everyone know that already? I think the users KNOW what the
recommendations are, but just CHOOSE to do differently. That is why I am
now focused on the new n-N paradigm to design the NETWORK to work
independent of user choices while still allowing the user to choose the
path he needs
But using this notification method is exactly what we need for putting out
the local information under the new n-N paradigm.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: 0 channel load APRS Steward (New concept)
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 28 Oct 2003 10:17:41 -0500 (EST)
X-Message-Number: 11
On Tue, 28 Oct 2003, Ev Tupis (W2EV) wrote:
>As for changing an APRSteward message format from BLN to status... this
>simply addresses a Kenwood personality-fault (some people's opinion)
>related to how it handles BLN's vs. how it handles status frames.
>Nothing else.
No, Ev, you still dont get it. It is NOT due to the "limitations" of the
kenwood that I oppose BULLETIN SPAM on APRS:
BULLETINS in APRS are IMPORTANT information of IMMEDIATE, DIRECT interest
of ALL HUMAN OPERATORS. It is identical to a BULK EMAIL that is FORCED on
every user INTO HIS IN BOX of stuff he is REQUIRED to read. The size of
the Kenwood mail box is immaterial to this aversion to SPAM on APRS that
EVERY user HAS TO READ..
BULLETINS as MESSAGES-TO-ALL is the fundamental DESIGN of BULLETINS in
APRS. (though some clients have screwed up the implementation of
bulletins so much as to dilute their effectiveness.)
What you are hearing from me is that I am opposed to using BULLETINS for
routine non-changing PUBLISHED information when there are MANY OTHER MEANS
to get that information to the end users. Examples of excellent ways that
I have ENCOURAGED for years are:
1) Directed messages (and follow up email) to offenders
2) Putting locally useful information in DIGI position comments.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: 0 channel load APRS Steward (New concept)
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 28 Oct 2003 10:36:48 -0500 (EST)
X-Message-Number: 12
On Tue, 28 Oct 2003, Tim Cunningham wrote:
>What we need is a minimum required specification for a digipeater decoding
>system. Most can handle a 300ms delay in decoding a signal. As you venture
>below this number, you start to push the limits.
Yes! Great idea.
I would like to suggest that the minimum acceptible delays in an APRS
digi should be less than XXX ms. Then people will know what the standard
is. AND then, any digi that cannot support XXX ms, should include what
its minimum TXD should be in its POSITION comment field. I am hoping that
150 ms might be that minimum?
Of course measuring TXD is subjective because it involves BOTH ends.
BUT... Since the Kenwood is the most consistent APRS radio in use, I would
suggest that it be used to help establish what this minimum is. This way,
everyone will be using the same device for the measurement and so no
matter what the results, at least everyone would have the resources to get
a consistent and reproducible answer that can be compared elsewhere.
So, grab your D7(g) and go out to see what the minimum TXD setting is that
works reliably with YOUR local digi and that then is the working parameter
(I think only the D7(g) model has front panel MENU item for changing
TXD)...
>Also, keep in mind that a digipeater has to allow for the worst case
>with its own TXD setting because there is a diverse set of equipment on
>the other end that may employ squelch operated radio's. In order for the
>system to be reliable a digipeater must take this into account for
>compatibility with equipment on the receiving end..
I completely agree. I am only suggesting the Kenwood as a means for
measuring the minimum TXD needed at a DIGI for a Kenwood. How we
extrapolate that to other radios is the next step...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: 0 channel load APRS Steward (New concept)
From: Wes Johnston <wes@johnston.net>
Date: Tue, 28 Oct 2003 11:07:59 -0500
X-Message-Number: 13
So we need to program our digined's and TWP's to respond to ?PATH? right?
Wes
----------------------------------------------------------------------
Subject: Re: APRS bulletins
From: "Richard Amirault" <ramirault@erols.com>
Date: Tue, 28 Oct 2003 11:10:25 -0500
X-Message-Number: 14
----- Original Message -----
From: "Bob Bruninga" <bruninga@usna.edu>
Subject: [aprssig] APRS bulletins
(lots of stuff snipped)
>There was no such thing as an OLD bulletin.
>When replaced, edited or updated, the old one didnt exist anymore...
(sniped again)
>He sees whate everyone else is supposed to see. A single virtual SCREEN
of the
>"currently active bulletins".
Well, almost .. just becuase they show on your screen does not make them
"currently active" ... they can be two days old (or a week or more for that
matter) I have often seen bulletins saying something about "today" with no
way of me telling *when* "today" was.
Richard Amirault N1JDU Boston,
MA, USA
ramirault@erols.com "Go Fly A Kite"
http:// www.erols.com/ramirault
----------------------------------------------------------------------
Subject: Re: APRS bulletins
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 28 Oct 2003 11:41:46 -0500 (EST)
X-Message-Number: 15
On Tue, 28 Oct 2003, Richard Amirault wrote:
>>There was no such thing as an OLD bulletin. When replaced, edited or
>>updated, the old one didnt exist anymore... He sees what everyone
>>else is supposed to see. A single virtual SCREEN of the "currently
>>active bulletins".
>
>Well, almost .. just becuase they show on your screen does not make them
>"currently active" ... they can be two days old (or a week or more for
>that matter) I have often seen bulletins saying something about "today"
>with no way of me telling *when* "today" was.
True. In APRSdos the normal procedure is to read and digest all active
bulletins on the BULLETIN screen and then hit alt-E to erase them. Those
that are still active will re-accumulate...
Bob
----------------------------------------------------------------------
Subject: Re: 0 channel load APRS Steward (New concept)
From: David VanHorn <dvanhorn@cedar.net>
Date: Tue, 28 Oct 2003 12:17:48 -0500
X-Message-Number: 16
At 11:07 AM 10/28/2003 -0500, Wes Johnston wrote:
>So we need to program our digined's and TWP's to respond to ?PATH? right?
TWP?
----------------------------------------------------------------------
Subject: Object security in APRS
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 28 Oct 2003 09:42:39 -0800
X-Message-Number: 17
I know there have been problems (or at least concerns) in the past with
duplicate objects, and unauthorized moving of objects. This is something
I'm trying to address in OpenTrac, and I think it could be improved in APRS
as well.
As I understand it, rules on object manipulation are enforced (perhaps
inconsistently) in the clients. The only authentication of an object
report's source is the originating callsign. For amateur purposes that
might be enough - spoofing a report couldn't be done accidentally, and at
least on RF would require an illegal 'false or deceptive' transmission. On
the Internet we don't have that legal protection, though.
The only 'strong' authentication I've been able to come up with is a public
key digital signature algorithm. The situation is simplified if we don't
care so much about positively determining someone's identity, and we just
want to verify that two object reports came from the same station, or
perhaps two different stations that share the private key. The best
candidate algorithm I've seen so far is ECDSA (or a variant) - the elliptic
curve algorithm gives much better key strength than traditional DSA. I
think the most that's ever been cracked so far has been a 109 bit key. 112
bits gives more than enough security for our purposes - that's 14 bytes of
data to be tacked on, since we don't have a separate key distribution
system. Plus the message hash itself - I'm not sure how big that would have
to be, but I think the whole thing could be done in 30 bytes or less.
Still, that's a fair amount of bandwidth at 1200 baud. I'd argue that it's
worth it when you need it. The bigger problem is implementing security in
smaller devices. It'd take a lot of code to do in a TinyTrak. On the other
hand, you're not making objects with a TT3. Desktop platforms can handle
the processing very easily, and I think that's where you need the security
most. You'll just have to remember that your anti-tracker isn't 'secure'.
In APRS, you've also got the possibility of two people creating the same
object in different places with different signatures (both initially valid),
and then meeting in the middle and only the first one heard being 'valid'.
Might be something to think about. In OpenTrac it's not a big deal, since
your object IDs are derived from your callsign, even though they may not be
displayed as such.
I'm also looking at a hash-based message authentication code for secret key
based authentication. I KNOW this can be done in embedded hardware, and
that's mostly what I want it for. In a future (RX capable) version of the
OpenTracker I plan to allow remote control of output lines over RF to drive
relays and such. Could be used for remote experiment control, or just
turning on your sprinklers. This requires that both ends have the same
secret key, of course, and anyone with that key can generate valid messages.
Any suggestions on how this should be done? If there's an easier way to
provide 'adequate' security, let me know. Keep in mind that neither of
these techniques is intended to 'obscure the meaning' of a message. The
message is still sent in the clear. Crypto's not really my thing, so I'm
open to suggestions...
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
