/Furthermore, portal.ampr.org allows anybody with valid email address to />>/route any 44/8 subnet through any IP address, not only subnets assigned to />>/account in use. There're no restrictions to do so and it will stay there />>/and get broadcasted until somebody notice. />This is not true. By registering a gateway, you can use your assigned
subnet through your registered gateway. But if that subnet is already assigned to a gateway, you can not assign it to your own gateway without deassigning it from the old gateway first.So this is a non-issue unless there are unassigned subnets floating around in the portal for people to grab. But these are mostly the result of misconfiguration and lack of knowledge, not the work of an attacker. And it will disrupt only that specific subnet.
Well, this issue is really there! Recently I found that two users from the Netherlands had setup completely bogus gateway entries, both stealing subnets belonging to others and routing them to the 44.137.x.x address I have them as "the gateway external address".
Those were probably not malicious, they just did not understand the portal and fiddled around a bit, and left it as it is once they did not understand anymore what is happening.
I think the portal should not allow to route other people's subnets through your own gateway without some consent from the subnet's owner, I think for some time it was impossible to setup such entries, and people complained that they needed this to route for others, and the check was removed again.
So here we may need some improvement tot to allow e.g. assignements of national or regional subnets assigned to administrators to regular users, which are the most likely to float since they are not bound to any gateway.
Administering national and regional subnets is a real pain, as it is impossible to manipulate the subnet structure without deleting it first, and ownership of an entry cannot be transferred. We all know how hard it is to get anything improved in the portal. For now, I advise users to not register their subnets unless they want to do IPIP tunneling.
W.r.t. the processing of RIP and IPIP traffic, you can do a lot with a properly designed firewall. On my systems I accept only IPIP traffic from gateways that I received before via RIP, and I accept RIP only from 44.0.0.1 on the IPIP interface. Maybe it would be possible to also check if the traffic came from UCSD, I'll have to see how to check that in iptables. (probably can be done with marking packets when they come in from UCSD, then check the mark when they arrive on tunl0)
Rob
On 9/22/16 6:18 PM, Rob Janssen wrote:
We all know how hard it is to get anything improved in the portal.
And we all know the only reason for this is the closed source nature of the portal. The current coder wants nothing but control over this and sees it as some kind of power trip.
Put it on github under a free software license and see how fast it gets fixed. But, no we continue to stroke this persons ego and encourage his selfish behavior.
This is how it must be fixed, and is the only acceptable solution.
It’s so nice to know your unpaid voluntary contribution is so appreciated. It’s such a shame that folks with such vocal energy seem unable to channel that energy into something more useful and constructive instead of being rude and obnoxious to someone who actually got off their arse and did some work.
Chris
On 22 Sep 2016, at 23:34, Bryan Fields Bryan@bryanfields.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 9/22/16 6:18 PM, Rob Janssen wrote:
We all know how hard it is to get anything improved in the portal.
And we all know the only reason for this is the closed source nature of the portal. The current coder wants nothing but control over this and sees it as some kind of power trip.
Put it on github under a free software license and see how fast it gets fixed. But, no we continue to stroke this persons ego and encourage his selfish behavior.
This is how it must be fixed, and is the only acceptable solution.
Bryan Fields
727-409-1194 - Voice http://bryanfields.net _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 9/23/16 2:54 AM, G1FEF via 44Net wrote:
It’s so nice to know your unpaid voluntary contribution is so appreciated.
Your contribution is not that, it's something to dangle over our heads. You have done a disservice to all of 44net by your sanctimonious attitude and proprietary license. It's a portal, quit milking it like it's something special.
It’s such a shame that folks with such vocal energy seem unable to channel that energy into something more useful and constructive instead of being rude and obnoxious to someone who actually got off their arse and did some work.
https://yourlogicalfallacyis.com/tu-quoque
Your code is useless for extending and you have 44net by the balls if you decide to revoke the license to it. Open source it and you will have patches in a week. Tom has said this multiple times, and I'll say it again.
Put up or shut up.
Le 23/09/2016 à 00:34, Bryan Fields a écrit :
Put it on github under a free software license and see how fast it gets fixed.
+1000 ;-)
<friday_mode>
All Ham radio software and protocols should be Open source. Open source "spirit" has many things in common with "ham spirit". It's quite natural for us to use Open Source.
Ham radio sysops / administrators should avoid deploying systems that rely on non-open source parts. This should be taken into consideration by all of us. At least for new deployments. Closed-source software and protocols really deserve our activity in the long term, and we have lots of examples available. When possible, we should use only Open Source components on our core infrastructures.
And, most important, we should encourage Open Source developers and maintainers. Because the future of digital ham radio is there, and nowhere else ;-)
</friday_mode>
PS : In French mailing-lists, Friday usually is "the day of the troll" :-) And these are smileys ;-)
On Fri, Sep 23, 2016 at 12:18:16AM +0200, Rob Janssen wrote:
I think the portal should not allow to route other people's subnets through your own gateway without some consent from the subnet's owner, I think for some time it was impossible to setup such entries, and people complained that they needed this to route for others, and the check was removed again.
I believe Chris has reinstated this check.
For now, I advise users to not register their subnets unless they want to do IPIP tunneling.
That's fine for YOUR users because you keep a separate database of what is allocated and what is not in your country's subnet, but I and many of the other coordinators use the subnet allocations in the portal as the authority for what is allocated and what is available. It is essential that all subnets be registered in the portal in order for me to do my job. - Brian
-
Brian Kantor -
Bryan Fields -
G1FEF -
Rob Janssen -
Toussaint OTTAVI