10 Aug
2021
10 Aug
'21
2:58 p.m.
Le 09/08/2021 à 17:59, pete M via 44Net a écrit :
Firewaling is the responsibility of the end user and
not the routing service.
As already noticed several times on this list, there are as many
opinions as members of the list. And I think it's the main difficulty
for the TAC :-)
I don't think firewalling should be the responsibility of end users. We
are sysops and network administrators. We are dealing with complex rules
about connecting 44net networks to Internet. Even on this list, which
includes all major 44net administrators over the world, it's difficult
to agree with a common scheme. Then, it does not seem a clever idea to
let end users do what they want, HI :-)
Here, we are an island. We currently have only one gateway to "the rest
of the world", and in the definite setup, we plan to have two. It seems
obvious to do routing and firewalling at gateway level. At least, it's
what we did :-)
Routing is what AMPR should keep to and not firewaling.
We are saying the same thing :
1/ Routing may be redefined and standardized by AMPR in a way that
allows all possible configurations all over the world (whether local
regulations or policies allow it or not) with modern protocols and tools
2/ Firewalling is where local countries or user groups will define what
is permitted or not in their specific country/region/situation. We are
an island with one gateway, so it's an easy task at gateway level. On a
continent, where rules are different between different neighbor
countries, and where networks are meshed, of course, this is far from easy.
If you don't want to be directly exposed to the
internet there are multiple ways, a firewall on the machine directly, a "router"
that do NAT and won't forward any traffic except traffic initiated by one machine
behind the NAT first. And at the end not having any route that can connect to the rest of
the world and not be connected to any network at all. The first one is done easily, the
second one is a given. And the other are not really useful at anything.
One of the purposes is to allow mass adoption of 44net. Then, we have to
provide plug and play / easy to use setups that can do most of the job
for the user. Here, we are providing "TKBoxes" (OpenWRT routers with
pre-defined configuration made by us). At world-wide scale, we need to
define a common scheme that fits all possible user cases. The split of
44net space in two (one "pure Intranet" and one "Internet-connected")
is
one important step. We are already experimenting it here (44.168 HamNet,
and 44.190 Internet). This involves dual configuration, dual routing,
route exchanges and firewalling at network / gateway level. This can not
be done only at the edge.
Now, if you don't want to be accessible from the
internet BUT want to be accessible to HAM ONLY traffic, that is another story. In that
case, the only way to go is by route. As trying to firewall every thing BUT known HAM ONLY
traffic is a lost of time, and it will change almost daily.
We've been playing that story for a few years now :-) Maybe with a lot
of time lost, I agree :-) For a service that needs to be accessible from
HAMs but not from Internet, you have to put it on the "Intranet" IP
space, and it just works :-) Again, that's not a matter of route, but of
access policy / rule (ie, firewalling).
PS :
As an additional comment, it may be required at some point to mix
routing and firewalling. Nowaday's systems allow to define access rules
and routes based on a lot of parameters (not only source/destination
IP/ports). Some manufacturers call that "policy routing" : there may be
different routes for different kind of traffic based f/ex on a DSCP tag
designating HAM traffic.
What I meant is that the lack of a valid route is not a good way to
block some unwanted traffic. Because what is unwanted by you may be
wanted by me. Routing policy and IP placement must be designed in a WW
strategy, so that it can suit all possible user cases over the world.
Then, what is allowed/forbiden in a specific region may be defined
locally (by firewall rules, not by lack of routes).
73 de TK1BI