Actually I do use that, or.. options::nohostcheck which basically means the same in this context. I need to, since I and the server I link to have both dynamic IPs. So not having "IP checks" isn't that uncommon.
Anyway, to summarize.. choose good passwords, and use SSL if you can. Don't rely on IPs for authentication.
I don't understand why people don't choose good passwords for link blocks anyway, you don't even have to remember the password.. you only have to store it on 2 sides and then you can forget about it ;).
Well, this is why I wanted to make a module for opers to do a challenge/response login. Challenge/response authentication is one method of authentication recommended by CERT.ORG, and is believed by many to be far more secure than any other method. I've started with a simple one that works for one oper, but for the module to work the way it should, I'd need to have a new conf item placed in the oper {} block.
1) The (public) key's filename is stored in the oper::password item as a string. A new authtype will also be needed to ensure people cannot do /oper name /path/to/keyfile.
2) I also need an item in the oper {} block that cannot be used, perhaps one that is hidden, which will store the contents of the key for each oper {} block. This would be like RSA *key.
I've put this feature request in the bug reports, but I guess it won't get added. I can alternatively have the keyfile loaded each time someone tries to challenge, but that would badly kill the CPU if flooded (even with a slow flood). It's best to load/reload the key when you /rehash, and when the server starts.
Corrected, thanks for the report. (I'm surprised that no-one noticed this earlier...)
I think I might also add information about backup links (the deny link block one) and circular topologies (which can't happen), which seems to have been asked a lot lately. Watch this space.