[aprssig] Precedence Bit and IP Encapsulation

[Iain R. Learmonth]

Hi,

On 20/05/2020 15:54, Nick VA3NNW wrote:
> 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.
UDP/DTLS encapsulation makes sense for userspace impelmentations. It's
true that Google has taken this approach with the new QUIC transport
protocol as did the WebRTC group, which both use UDP and DTLS encapsulation.
> 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.
The security considerations are a motivating factor in updating this draft.
> ... 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.
OpenIKED is actually really nice to work with. IKEv1 wasn't so great,
but IKEv2 is cool.
> 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...

So many attacks are possible when you allow replays, it's better to just
not allow them. For IKEv2 this is the default arrangement, you will
automatically rekey when rolling over your ESP sequence number.

Regarding APRS-IS, I'm not trying to replace that. It does a job and it
does it reasonably well. My solution for APRS-IS can be found at:

https://man.hambsd.org/aprsisd.8

Note that I push the use of TLS certificates over using raw TCP. I'm yet
to implement the null crypto option in there but that is one line of
code and a command line flag to enable it.

To avoid ARRL becoming a bottleneck on this, I've also started to put
together this: https://hambsd.org/pki.html

> 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! Even better, some of this is already possible. You can already
establish IPSec tunnels between amateurs with good certainty because
IPSec supports the use of X.509 certificate authorities. If you have a
LoTW certificate, that can be used for IPSec! (I didn't try this yet,
but based on the docs it should work.)

Other things I'd like to experiment with are: IP multicast APRS nets and
presence reports where you beacon your IP endpoint information to allow
for direct communication to be established for messaging. There might be
things to learn from Mobile IP. There might be things to play with for
IPv6 because you can encode an entire AX.25 address into an IPv6 /64.

I don't want to start too many things at once, so I'm focusing right now
on building up the AX.25 kernel support and APRS userspace tools
(digipeating, IGating, weather station, tracker), but if someone was to
be experimenting with this stuff I'd be excited to hear about it.

Thanks,
Iain MM0ROR.

-- 
https://hambsd.org/