We are saying almost the same thing. ARDC/AMPR need to supply easy way for ham to connect to 44 net and we should not be defining what they want to receive or send as traffic. BUT ARDC/AMPR need to also give access to specific use case like an intranet ham only traffic if asked for it. ( I am sure that a lot of user on the ipip tunnel net dont want to have russian/chinese hacker to come in their place. And that use case is easy to do if the routing from the pop to the rest of the world is not open at all to the internet and you either connect to it by a vpn or any other type of tunnel if connected to the internet, or if connected by radio, you just dont use a tunel and be free and secure to use that space without fear. That aint firewalling that is internal routing between the pop's and the user and the ipip network.
The other use case is to route everything and not firewall anything to another part of 44 net. Yes we could firewall some traffic. Like sanner for port 22/80/443/8080 name the port you want, from the internet to the user space. (44 net) but again. That is just a service on top of the real work that ARDC/AMPR need to do. Route the 44 net to the user it target, the ham community. This can be done by direct BGP ( ARD/AMPR cannot firewall anything here) or by the POP (an now ARDC/AMPR can firewall things , but again it would be just a service over the real service they need to provide, ways of connecting ham together. ARDC/AMPR could make some firewaling rules to adapt to specific country rules and take the hard work out of the local user. But can it be easily done, We need to see the case before saying it can be done.
I am sure that you ahve played with routing and programming some route into your setup. can you tell me, if you want to connect to many /24 that are not on aggregated on a /10 or even a /16 how many route will you have to keep in your router ? At max the same number of /24 you have and mayve if lucky you will have a few of those /24 that are aggregated into a /22 or better a /20 to limit the route number. That is not an easy thing to manage. The TAC Idea of reserving a /10 for a ham only net would had fix that kind of problem by a signle magical line that would had route 44.128.0.0/10 to a specific route and without firewall, without complicated routing and without large difficulty to enter the net a user would have fallen into the ham only network we all wish we had since the beginning of AMPR.
But this have been judged by the community as being bad if we read all the answer to the TAC proposal. I find that very disapointing.
Pierre VE2PF
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Toussaint OTTAVI via 44Net 44net@mailman.ampr.org Envoyé : 10 août 2021 03:58 À : 44net@mailman.ampr.org Cc : Toussaint OTTAVI Objet : Re: [44net] On Allocations, PoPs, and Proposals
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
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net