/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