Le 09/08/2021 à 13:44, Mario Lorenz a écrit :
In theory, and in normal networks, you would be right. The difference is however that in normal networks, you generally use firewalls to block access to ressources. The problem we have at hand is slightly different: We need to protect access to links.
Interesting answer, but the discussion may come al little bit off-topic here :-)
At least in some jurisdictions, we must not route certain traffic via an amateur radio link, so we face the dilemma of having a (possibly preferable) route via the radio that is not available to that certain traffic. Naturally, you'd block that traffic using a firewall route.
1/ Most of HAM rules about interconnecting HAM networks with public networks were written during the last century, when the technology and Internet were not what they are today. My personal opinion is that most of those rules may need to be refined or re-defined :-) As licenses HAM operators, we have the right to experiment new things. Then we (AMPR) could make proposals for new rules, adapted to the current State of the Art.
2/ IMHO, the validity of the traffic ("Is the operator a licensed ham radio operator ?") must be checked at the edge. Can we assume every 44net owner is a licensed ham (this implies strict controls by the people who deliver 44net addresses) ? Can we use certificates ? But most of all : once some traffic entered 44net network, should we consider it as "valid" HAM traffic ? Or do we have to make further tests later (the example you quoted : routing through radio links) ?
3/ As far as we manage the full network from end to end, would it be possible possible to use QoS everywhere ? An obvious advantage f/ex would be to prioritize VoIP. But another advantage would be tagging "valid HAM" packets with a specific DSCP tag. That would allow policy routing farther in the path (don't route non-ham packets over radio links, but route them on another link, if available)
A route announcement generally is a promise to carry traffic to that destination. Can you still honestly make this promise if your firewall blocks that traffic?
I would say YES : - My home network currently has routes to porn sites - My firewall content filter blocks those sites for everybody (but not for me, HI)
But in our case, your route announcement and subsequent packet dropping would be wrong (needlessly preventing communication) if another route were available that is not subject to the amateur radio link access restriction (maybe there is no amateur radio link, or maybe its via a different jurisdiction)
Nor an easy answer, because there's not one single problem to answer. In my situation, the problem is simpler, because I'm an island with only one gateway. Currently, I don't route traffic to other neighbors, so I don't have to bother with the question : "This traffic is not for me, should I check if it's valid HAM or not, and should I route it or not ?"
I would say : - For traffic that is not for me / my network / my region : route in best effort (without firewalling) - For traffic that is for me : apply firewall rules according to my local rules
Somewhere deep down in that case lies the problem that the TAC proposal was trying to solve, although that was not fully documented.
I fully agree with the TAC proposal of splitting 44net into two separate subnets with different policies. We are already experimenting it locally (with 44.168 and 44.190). This was suggested to me by Jann DG8NGN a while ago. Each site has two VLANs, dual addressing, and dual routing policy. Endpoint routers have Ethernet interfaces on both VLANs. We can choose to connect any equipment to Intranet (44.168) or Internet (44.190). The central firewall does the main filtering job. It works fine. It does the job of clearly separating what is "Intranet" and what is "Internet"
A related question, also burried deep down in that lane: Your firewall rule would typically be filtering on source/destination addresses.
Modern firewalls allow rules based on many parameters (not only source/dest). Can we imagine a DSCP tag designating "valid" ham radio traffic ?
It is, I think, not disputed that a part of the reason to get users onto the 44 Net is that it identifies communiation partners as duly licensed ham radio operators, hinting your firewall that amateur radio frequency access may be allowed.
My personal opinion is that identifying valid amateur radio operators should be done at the edge, when delivering 44net addresses (Who will do that and how is yet to be defined, but has been discussed already). Then, if a packet enters the network with a source IP in the 44net "Intranet" range, we can consider it as valid amateur data, and route it accordingly.
So, does initiation of a 44-to-44 communication also imply some form of agreement/representation that the content of that communication is suitable for the amateur radio air waves ?
We should distinguish between "Intranet" and "Internet" ranges : - If source IP is in the 44net "Intranet" range, then, the sender is a valid amateur radio operator, operating on a closed radioamateur network : current amateur traffic rules do apply. - If source IP is in the 44net "Internet" range, then, the sender is a valid amateur radio operator : - If the destination is public Internet : current rules for general Internet browsing do apply - If the destination is an amateur radio endpoint (ie, a D-Star or DMR repeater, linked through Internet because its sysop does not know how to use 44net, HI) : amateur traffic rules apply.
Suppose I'd want to tell a non-politically-correct joke to another OM. I can now choose if I wanted to take the VHF TRX to call him on the local repeater, or I could call him on the landline phone.
Obviously, you wouldn't use the local VHF repeater, but you would use phone :-)
How should this be handled ?
You wouldn't connect your terminal to the "Intranet" Ethernet interface (or WiFi network) of your 44net router, but instead, you would connect it to the "Internet" interface (or WiFi network)...
73 de TK1BI