There is a problem with RIP MD5 Authentication when connections are made between Juniper and Cisco routers
Customer
may experience RIP MD5 authentication issues when connected Cisco router reloads.
To identify the issue, enable traceoption with flag set to RIP authentication.
{MASTER}[edit]
lab@router# set protocols rip traceoptions flag auth detail
or
{MASTER}[edit]
lab@router# set routing-instances <instance_name> protocols rip traceoptions flag auth detail
Look for output provided here regarding the sequence number:
Nov 19 11:20:37.507021 Failed authentication on sequence number; received: 157, expected: 16328
Nov 19 11:20:37.507321 RPD_RIP_AUTH: Update with invalid authentication from x.x.x.x (ge-1/1/0.2909)
RIP MD5 authentication is failing as Juniper side is expecting MD5 authentication sequence number 16328 but instead received 157.
RFC 2082 RIP2 MD5 Authentication states the following:
3.1. RIP-2 PDU Format
(5) An unsigned 32 bit sequence number. The sequence number MUST be non-decreasing for all messages sent with the same Key ID.
3.2.2. Message Reception
When connectivity to the neighbor has been lost, the receiver SHOULD be ready to accept either:
- a message with a sequence number of zero
- a message with a higher sequence number than the last received sequence number.
A router that has forgotten its current sequence number but remembers
its key and Key-ID MUST send its first packet with a sequence number
of zero. This leaves a small opening for a replay attack. Router
vendors are encouraged to provide stable storage for keys, key
lifetimes, Key-IDs, and the related sequence numbers.
Hence when Juniper side receives the sequence number which is non-zero and lower sequence number (i.e. 157 in the example) than the one mostly recently received (i.e. 16328), it will reject this packet and hence fails MD5 authentication.
Workaround is to apply
ip rip initial-delay on the Cisco side to "ensure that the sequence number of the first MD5 packet that the router sends to the non-Cisco neighbor router is 0."