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