Using v4.11 on a small and, so far, rather simple network (2 RB1100s and 3 RB450Gs) we enabled OSPF with MD5 authentication. Everything seemed to operate normally for 4+ weeks. Yesterday, we started getting MD5 authentication errors on one of the links. The error was "wrong authentication type." Nothing seemed to correct the problem so we disabled MD5 authentication on both ends of that link.

Today we started getting errors on a second link. These errors are "invalid sequence number" - with sequence numbers that are offset by one. Rather than debug this one, we have disabled MD5 on this link as well.

Searching messages on the forum I notice two places where people raised MD5 questions and the first response asked whether the routers clocks were synchronized. Ours are not, but searching the web I can find no explanation of why MD5 authentication might require that the router clocks be synchronized.

1. Do router clocks have to by synchronized for MD5 authentication to work?
2. If so, why?

While investigating these problems we also tried exporting the configuration of one of the operational RB 450Gs and loading it onto another 450G in the lab. On our production network we had used 32 ASCII character MD5 authentication keys that we entered through Winbox. When we tried to enter this 32 character key onto the lab router via a script, we got a script error "Value of authentication key should not be longer than 16." I can't find this limitation in the MikroTik documentation.

3. What are the restrictions on MD5 authentication keys?

4. Is there anything else we might be doing wrong?

Thanks for any help here,
Brough

PS: Here's a diagram of our initial network.

From what I understand with MD5, your router just does a hash of the password. It then sends the hash along with the Key ID. The key ID is supposed to make migrating to new passwords easier.

MD5 should be independent of the system clock. The idea is that you can run a hash on a given password and get the same output consistently.

Perhaps you can try using a moderately sized password and use just letters and numbers. See if that repairs the issue.

Thanks Greg. That lines up with my (limited) understanding of MD5 authentication.
We'll redo everything with 16 character authentication keys over the weekend.
We've also deployed an NTP server and are putting NTP clients on each router.
Of course that means, if our problems go away, we won't be sure what fixed them.
More on Monday.

We have just completed a deployment using OSPF with MD5 authentication using Cisco 2821s and RB493G's. We found that upgrading to 4.13 helped with a lot of the OSPF issues, also I found that there would be a heap of sequence errors to start with but after a while they would stop. As we are using Ubiquiti wireless links between some of the routers it was necessary to configure OSPF to PTMP mode.

hope this helps.

1. Do router clocks have to by synchronized for MD5 authentication to work?
2. If so, why?

No, with the caveat, as I understand it, that the clock cannot go backward without dropping the neighbor associations on the other routers for security reasons.

When a router which does not have the clock synchronized via NTP reboots, the clock goes backward by a lot. When the reboot takes less than 40 seconds, the neighbors suddenly see attempts for MD5 authentication which look like a possible replay attack.

I have had several instances, before I realized this caveat, where the only way I could get an unsynchronized clock machine to rejoin the OSPF network was to disable OSPF on that box until the neighbor associations on the other boxes on that segment time out and go away. Then I could re-enable MD5 and the problem box would rejoin then network immediately. I was mostly seeing that on my Quagga boxes (StarOS) because their NTP was causing 10 minute steps every 24 hours, which also causes OSPF issues.