ospf, same md5 value but different key number

[sarahr202]

Hi everybody

Let say  we have two routers as shown below:

R1-----199.199.199.0--------R2

R1 config:

interface Serial0/0

ip address 199.199.199.1 255.255.255.0

ip ospf authentication message-digest

ip ospf message-digest-key 1 md5 zee

clock rate 2000000

outer ospf 1

router-id 1.1.1.1

log-adjacency-changes

network 199.199.199.0 0.0.0.255 area 0

============================================

R2 config

interface Serial0/0

ip address 199.199.199.2 255.255.255.0

ip ospf authentication message-digest

interface Serial0/0

ip address 199.199.199.2 255.255.255.0

ip ospf authentication message-digest

ip ospf message-digest-key 1 md5 zee

R1 and R2 are able to form neighbor relationship.

However, when I replaced the command " ip ospf message-digest-key 1 md5 zee" by "ip ospf message-digest-key 2 md5 zee",

neighbor relationship fails.

The question is why.  Because , when I used wireshark ,captured hellos sent by R2  only contain the md5 hash value  not the key number

That means only hashed value is transmitted with hellos.  Consequently, that hash value has to be matched once R1 receives the hello from R2.

But then what accounts for failed neighbor relationship between R1 and R2 ?

Thanks and have a great weekend

[Giuseppe Larosa · Accepted solution]

Hello Sarah,

I hope you are well.

the key must match this is thought to provide a way to change the MD5 password over time without impacting existing adjacencies that are already using the MD5 protection.

This is called key rollover and we tested it some years ago. The critical point is the first introduction of MD5 authentication that causes impact.

MD5 hash = F( md5_password)

in math terms.

debug ip ospf adjacency should should why the neighborship fails.

Edit:

the key should be sent in a separate field as explained by our colleague Kishore

this is confirmed in books like Routing TCP/IP vol I second edition by  Jeff Doyle and Jennifer Carroll.

5 points for Kishore from me ...:)

Edit2:

from our old tests:

Router#debug ip ospf packet

OSPF: rcv. v:2 t:1 l:48 rid:200.0.0.116

aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x0

aut:	OSPF                     authentication type. 0—No                          authentication 1—Simple password 2—MD5
auk:	OSPF                     authentication key.
keyid:	MD5 key ID.

Hope to help

Giuseppe

[Kishore Chennupati]

Thanks Guiseppe for the ratings :-) 5+ to you too.

[sarahr202]

Thanks Giuseppe. 

Long time no see.  How have you been ?

[Kishore Chennupati · Accepted solution]

Hi,

It does send the Key number as well. Key numbers are helpful when you wan tto change your md5 pwd without disrupting the session. so you create key 2 etc and then slowly migrate to the second key with a different md5 pwd.

I am attaching a screenshot of a wireshark capture that I have taken and it does have the Key ID.

HTH

Kishore

[Peter Paluch · Accepted solution]

Hello everyone,

Please allow me to add a couple of observations.

The key number with MD5 works exactly as Giuseppe and Kishore described - it is sent along with the authenticated OSPF packet so that the receiving party knows which key should be used to verify that the packet's authentication is correct. This allows for graceful key migration where a new key can be added without disrupting the adjacencies. OSPF does it in a simple way: to sign sent packets, it always uses the key that was added as the last one (regardless of the key number). To authenticate the received packet, it uses the key ID that is indicated in the packet. If a neighbor is detected on an interface that uses a different key number than this router, OSPF enters a key migration phase in which it sends all packets as many times as how many keys are configured on the interface, and each packet is signed with a different key.

For example, assume that my router was using key ID 10, and now I have added a new key ID 5 with a different passphrase, without removing the key 10. My router will initially start using the key 5 to sign all outgoing OSPF packets through that particular interface. However, when an OSPF packet arrives that is still signed with key 10, the router will authenticate it correctly using the key 10, and will enter a migration phase: each OSPF packet will be sent twice through this interface, one signed with key 5, the other signed with key 10. This phase will end after all neighbors on the interface are using the new key 5. After that, the key 10 can be safely removed.

Other routing protocols that use key chains use a different approach but I don't want to be confusing so I'll leave out the details.

Another point to consider is that if using plaintext authentication, there is no key ID used and there can not be multiple plaintext passphrases configured on a single interface. Why the designers chose not to implement key IDs with plaintext authentication is not entirely clear to me but it seems to be some tradition keeping in accordance with RIP that also does not use key numbers when using plaintext authentication. Hence, with plaintext authentication, graceful key migration is not possible.

Best regards,

Peter

[cadet alain]

Hi Peter,

Can you explain why the neighbour relationship is going down in this case, is this because we can't have 2 key ids with same password?

Regards.

Alain

[Peter Paluch · Accepted solution]

Hello Alain,

If you are asking about Sarah's experiment, I am missing some information about what exactly was done immediately preceeding the adjacency breakup. So far, it does not make much sense. Sarah indicated that she changed the key 1 to key 2, keeping the same passphrase. The question is - did she change this only on a single router, or on both routers? Was there no typo involved?

We can safely have two and more key IDs with the same password (e.g. key IDs 1, 2, 3 all set to the password of "abracadabra"). There is no problem with that. However, the same key ID that is used to sign a sent OSPF packet will be used to authenticate it upon arrival. Pairwise, therefore, the routers must use the same key ID and password.

Best regards,

Peter

[sarahr202]

Thanks  everyone

I apologize for not providing enough detail

The question is - did she change this only on a single router, or on both routers?

yes , I changed the key number  to 2  on only one router which explain why the neighbor relationship fails

Have a great weekend.