[aprssig] Precedence Bit and IP Encapsulation

[Nick VA3NNW]

Iain R. Learmonth wrote:
>> Why would you do it this way instead of simply using UDP datagrams? 
> You get to save a UDP header's worth of overhead, and it's an update to
> a protocol that already exists. AX.25 over UDP was, as far as I can
> tell, never standardized. It could well be that AX.25 over UDP gets
> incorporated into this standard if there is interest for that. Both the
> QoS and security considerations would equally apply to AX.25 over UDP.

Note also the big difference between AX25 over UDP vs APRS over UDP
(like the APRS-IS uses)

UDP seems more likely to work through consumer or even coffee-shop NAT
gateways. DTLS could answer some of the signing concerns.

That said, it looks like you're looking at this RFC revision MOSTLY as
an excuse to use AX25 over IPSEC over IP(v4/v6) so you can optionally
encrypt, but mostly so you can SIGN the packets as they traverse the
internet, to avoid risk of spoofing to inject non-ham packets onto the air.

... which seems like a perfectly noble goal, and with IKE, which is a
pretty hideous protocol but is still about as standard as you can expect
to get for VPNs... Standard VPNs that ARE also likely to work through
consumer / coffee-shop NAT.

I think you're probably overly concerned about the risk of replay
attacks, but I think the goal of getting AX25 packets from A to B over
IP is a fair one for a bunch of reasons. Getting APRS packets from A to
B over IP is already fairly well solved (APRS-IS), but AX25...

Would also be fun(*) to think about routing protocols - if I'm trying to
get a packet to VE3IC and can't see them over RF, can I look them up in
some routing database (and/or DNS?) and dynamically provision a tunnel
to someone closer to pass their traffic? and route to 2nd-best if the
first tunnel fails to establish or fails to get a response? Can that
dynamically-provisioned tunnel endpoint owner still (cryptographically?)
verify that this is coming from a legitimate super-igate-thingy, or at
least a Ham, not a non-ham trying to inject things onto RF? Perhaps some
of the IPSEC NULL-Auth stuff but with super-igate keys signed by some
central signing authority/authorities, or IPSEC pubkeys in designated
HAM DNS zones? Is there a good routing protocol to exchange "HEARD"
(/peered) calls/digipeaters/super-igates for overlay mesh networking /
mesh routing? Publish into the routing DB "I have heard VE3IC and if you
want to route packets to them, feel free to establish an AX25-IPSEC
tunnel to VA3NNW.something,ampr.org" or whatever domain, or conversely
"VE3IC has been heard by VA3NNW and VE3KSR, pick one based on [some
algorithm], or even LOAD-BALANCE"...

(*) Yes, fun, y'know I'm always amazed the number of people who DON'T do
recreational protocol analysis / design for fun!   ;-)

-- 
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer;    sig at noseynick.net
People don't form relationships, they take hostages.