Let’s conclude the RIP week with an interesting observation made by Yuri Selivanov: when using MD5 authentication with RIP, Cisco routers send 532-byte UDP datagrams while Juniper routers send 512-byte UDP datagrams. The maximum number of route entries (RTE) in a RIP datagram and its size thus varies based on authentication mechanism and router software:
|Authentication type||Cisco IOS||JunOS|
Somehow people expect RIP datagrams to be at most 512 bytes long, which (as you can see from the table) is not always the case.
Obviously I've tried to figure out whether that’s another bug in Cisco IOS (as I’ve reported in the past, the developers sometimes tend to ignore the standards), but it turns out (in my opinion) that the problem lies in ambiguous RFC (RFC 2082 and RFC 4822).
RIP v2 standard (RFC 2453) states that a RIP packet contains at most 25 RTEs and that the authentication uses the first RTE, allowing up to 24 RTEs in the RIP update. RIPv2 cryptographic authentication standard (RFC 4822) uses the information in the first RTE (matching the specs of RFC 2453) and appends variable-length authentication data after the RIP packet.
For MD5 authentication the digest size happens to be 16 bytes; together with the 4-byte header the authentication trailer happens to be 20 bytes, which is equal to RTE size. Juniper developers thus decided to reduce the number of useful RTEs to 23, whereas Cisco developers read the standard more literally. Anyhow, if anyone would care to implement HMAC-SHA1 digest instead of MD5, the authentication data would be 20 byte long, resulting in an 24-byte authentication trailer.