Thursday
Hello community,
I'm working on ISIS md5 authentication and I struggle to reproduce the digest the switches display.
I've read RFC 5304 which mentions that the Authentication Value field of the ISIS Hello PDU must be set to 0 before computing the authentication digest. Pretty simple isn'it ?
However, I am unable to reconstruct the digest the switches are sending to each other.
Here is the ISIS Hello PDU sent between a 5320 and a 4420 running VOSS 9.3.0.0 with MD5 authentication.
01deadbeefbb13001b00c00301080749c0de15152025f00f00000000cae4fd8c3d0484000000ca8102c18f8f7800000466000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000060c0080c201fd3c0080c202fd4c0a1136de92776eb44ac356fd0fbd934efcf233The authentication value field is the last 16 bytes : de9277...
From my understanding I should only have to zeroed this field, and compute a HMAC-MD5 with the key ("totototototototo") and the ISIS PDU.
Note : The key has been configured to 16 bytes to exclude any kind of padding on the key as we can have with HMAC-SHA256.
This does not work.
As the RFC states "The HMAC-MD5 result for the IS-IS Hello PDUs SHALL be calculated after the packet is padded to the MTU size, if padding is not disabled", and the hello-padding is indeed enabled in the configuration.
Ok so let's pad to 1484 bytes (for a total frame size of 1513 bytes) with 0x00.
Why 1484 you would say ? Because that's the padding observed at the very beginning of the adjacency creation (which then disappear which suggests the padding is in loose mode)
It does not work
Let's pad with the same padding structure we observe in the capture : the padding tlv (08) + the padding length (max 254) + the padded zeros
It does not work.
Let's try all the possible padding length between 0 and 9600 (L3 MTU is different from L2 MTU but I'm kind of desperate here).
It does not work.
So I'm kind of lost here on why the digests do not match.
I've also tried to MD5 the key before applying the HMAC-MD5 but no luck. The only thing I can think of is that the key is somehow modified before the hmac computation, or another field of the PDU is zeroed.
Does someone know how this digest compute work and what I'm missing ?
Thank you,