/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