Yes, there are some good points in what Jakub has written.

Password authentication mechanism in RIPv2 is meant to protect against accidental misconfigurations and is the only way of configuring ampr-ripd routing.

Correct, the only use at the moment is to actually validate the RIP data. But I don't think this could eliminate actual misconfigurations, unless there are more RIP informations form other sources involved.

As it is UDP based and relies on source of UDP packets, which is easy to spoof, current routing infrastructure is vulnerable to unrestricted injecting of 44/8 routes to it's gateways - anybody can send forged RIP updates to them.

Here I don't think the situation is that critical. The RIP updates are sent via tunnel, and should be accepted only from the ampr-gw tunnel interface. The attacker needs actually to block out original IPIP traffic and spoof the IPIP tunnel to get fake RIP data into the network. This is a little harder than just sending a bunch of UDP packets to a host. And even if this is done, what does the attacker achieve? A redirection of remote tunnels to a fake endpoint. To do what? To send data to a now isolated system? To browse its web page from a fake host? I really don't see the point of doing that. Crackers want benefits from their work: e-mail collecting, snmp access, spamming, not the glory of sending data to a compromised system to which they are the only ones having access. And creating a DOS attack like this on an APMPR host is nothing interesting. Even so, in such a case, regular firewalling like on a regular internet host would prevent any malicios activity.

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.

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.

So I would say: Let's see how this password thing turns out. We can always change the password from the current one if needed, and the tools provide a way to do it on the user side. Making things more complicate will not help anyone.

Marius, YO2LOJ