I never said it was "strong authentication", I said it "should
suffice". I've been doing IT and security work for a long time so I chose my
words carefully.
For the actual threat posed to an amateur radio IPIP or GRE tunnel, the effort to deploy,
maintain and troubleshoot complex technologies like IPSEC - especially by those who are
not networking experts - is not justified by the actual threat posed to the connection.
Could an adversary work out a man-in-the-middle attack, misroute your traffic, and spoof
one end of your IPIP/GRE tunnel? Sure. Is it in any way likely to happen? Not in in the
least. If you've attracted the attention of a malicious actor who is capable and
willing to do that against your connection, then doing a 44Net connection to begin with is
probably the wrong strategy for whatever the workload is and you have bigger problems.
Increased security brings increased complexity. Yes, I can make a super-secure tunneled
connection with PKI authentication, ephemeral keying, and all sorts of other things. But
it's complex and largely unnecessary for the threat posed to some links used to cart
around some digital voice traffic.
Is an authenticated and private (encrypted) tunnel better? Sure. Is it necessary?
That's a harder question.
Jason
-----Original Message-----
From: 44Net <44net-bounces+jason=mfamily.org(a)mailman.ampr.org> On Behalf Of Iain R.
Learmonth via 44Net
Sent: Friday, December 4, 2020 4:11 PM
To: 44net(a)mailman.ampr.org
Cc: Iain R. Learmonth <irl(a)hambsd.org>
Subject: Re: [44net] GRE tunnels
Hi,
I would have thought that this community more than others would understand that BGP
(especially for AMPR resources) is not all that secure, and IP addresses are not strong
authentication.
It depends what you want to do though. If it's just for leisure and experimentation,
then fine, you do not need encryption. If there are issues of abuse later, you can sort
them out when they occur. For emergency communications, and also I guess because I come at
amateur radio from a computing science background and not from a radio background, I
prefer something a little more pro-active. I don't want to be finding that things have
been randomly attacked (you don't need to be targeted to be attacked, look at
ransomware it will just attack everything it can) mid-incident where you're trying to
respond to some emergency and then your "resilient" communications turn out to
be not so resilient.
There is no right or wrong answer, it depends on your threat model, but you should give it
some critical thought. There's a reason that most roles in large enterprises will have
training on IT security even if the role isn't even remotely IT related.
Thanks,
Iain.
On 04/12/2020 20:58, Jason McCormick via 44Net wrote:
A simple firewall rule to control the access into the
IPIP or GRE endpoint should suffice. You don't want a wide-open IPIP/GRE listener, but
narrowed down to the particular endpoint(s) you want to permit is very functional.
Jason
-----Original Message-----
From: 44Net <44net-bounces+jason=mfamily.org(a)mailman.ampr.org> On
Behalf Of Marius Petrescu via 44Net
Sent: Friday, December 4, 2020 3:56 PM
To: pete M via 44Net <44net(a)mailman.ampr.org>
Cc: Marius Petrescu <marius(a)yo2loj.ro>
Subject: Re: [44net] GRE tunnels
In this case, why not use pptp? It does transport data over gre and offers a decent
authentication using mschap2. If needed, one can also add mppe as encryption.
I know there are theoreticians that state that it may be mathematical vulnerable because
of "shortcut" implementations done by MS, but still no exploit is out in the
wild.
And the out-phasing of it in favor of strong cryptographic solutions actually lessens the
pressure on really creating an usable exploit.
On the other hand, ham radio networks are not an interesting target for potential
crackers.
On 04.12.2020 21:52, pete M via 44Net wrote:
We dont need to protect any special information
in that setup. All the communication are for repeaters or device that will be used to
monitor the site, remote control or such.
So a simple tunnel without encryption is ok.
But authentication is just plain obligatory.
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de
la part de Iain R. Learmonth via 44Net <44net(a)mailman.ampr.org>
Envoyé : 4 décembre 2020 14:43 À : 44net(a)mailman.ampr.org Cc : Iain
R. Learmonth Objet : Re: [44net] GRE tunnels
Hi,
On 04/12/2020 18:55, Bryan Fields via 44Net wrote:
I take the position that it's ham radio, I
don't mess with IPSEC,
just run GRE directly on the connection.
This is perfectly fine and I'm not
going to say you're wrong for
doing it this way, but if you were building out something that could
be used for emergency communication then it can pay to add
authentication. You might also end up cornered into carrying
potential personal information over your network (e.g. safety of life
exemptions), and it'd be nice if you limited the scope of the
interceptable traffic to only the RF portion of the network.
In HamBSD (and OpenBSD) configuring IPSec for a GRE tunnel requires:
1. copy the public keys from one host to the other
2. add one line to /etc/iked.conf with the IP addresses and the names
for the public keys you copied in step 1
3. enable/start/restart iked
It's not magic, it's not mystery, it's actually pretty simple. That
one line of config looks like:
ikev2 'mb7uar_rsa' passive esp from 44.190.21.233/32 to
44.190.21.234/32 local 44.190.21.1 srcid
hambsd.org dstid
mb7uar.hambsd.org rsa
This configures a tunnel that expects an inbound connection (MB7UAR
has redundant internet connections, and is behind a NAT on both, so
the other end is not fixed) with the first two IP addresses as the
"internal" tunnel IP addresses. The third IP address is where to
listen "outside" the tunnel. The srcid and dstid just match up the
public keys to make sure you're authenticated.
Thanks,
Iain.
--
https://hambsd.org/
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
--
https://hambsd.org/
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net