MD5 in RIPv2

[ohassairi]

                   Hello experts

does anyone know if the MD5 function in RIPv2 is applied only to RIP message or to the hole IP packet (including IP header) ?

Thanks

[Peter Paluch]

Hello,

The MD5 is applied only to the RIPv2 message plus the authentication data, not including the UDP or IP header.

Best regards,

Peter

[ohassairi]

so in this case, one hacker can capture one RIPv2 packet (that contains the MD5 value) then send it on the network with its new IP address. so other routers will think that the advertised network comes from this new IP !!! so RIPv2 will not be secure?

[Peter Paluch]

Hello,

Very good observation! Indeed, I believe that would be possible. I have downloaded the source files of Quagga routing protocol suite and verified the code of RIPv2. I can confirm that only the RIP message is being fed into the MD5 digest, not the IP+UDP encapsulation.

If I have some time during the next few days, I will try to write a RIPv2 interceptor that steals authenticated RIPv2 messages and sends them out with its own IP address to see if I can fool the recipients.

Best regards,

Peter

[ohassairi]

that's why i think MD5 should be applied to the hole IP packet including IP header ;-)

[Peter Paluch · Accepted solution]

Hi,

Well, it should but according to RFC and Quagga's implementation (to say the least) it isn't And by judging the fact that Quagga talks nicely to Cisco router via RIPv2, I assume Cisco routers also don't implement it any differently.

Best regards,

Peter

[ohassairi]

is it possible to suggest to RFC people to change the RFC so that the hash function will be applied to the hole IP packet ? so it will be more secure ...

[Peter Paluch · Accepted solution]

Hi,

Such a comment to a "Request for Comment" is always possible, of course. However, the problem is that there is an immensely large installed base of devices that are using the current RFC. It is questionable how many vendors would update their code just because a newer RFC was issued, and also, there is the issue of the compatibility between older and newer implementations. You would need to somehow indicate whether you also authenticate the IP+UDP header or just the RIP message, so the changes to the protocol would need to be more extensive than just changes to the data fed into the MD5 hash. It could also be argued that the IPsec AH already covers the requested functionality, and also, it is not certain whether the effort would be of any significant effect... like, how many times has this attack vector been actually exploited in the wild?

Best regards,

Peter

[Karsten Iwen]

There could be a countermeasure by using the next-hop-option in RIPv2. But to my knowledge it's not quite common that this optional attribute is used and per RFC the receiver is also not forced to use the option.

One reason more not to use RIP ...

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[cadet alain]

Hi,

The authentication is working the same way for EIGRP and OSPFv2

Regards

Alain