Cisco supports a wide array of protocols that uses text or md5 based authentication.
e.g
GLBP
LDP
RIPv2
BGP
OSPF
EIGRP
IS-IS
All of the above support some types of authentication.
In best common practices, we want to use the same key-chain key ID for all authentications purporse, but some protocols allows for a slight degree of variance in the key-chain id for expirations. VRRP is a different beast.Take this snapshot;
And on the 1.1.1.1 router we have the following key configured;
Notice the BADAUTHs ? Why is this so? Both routers have the keystring of cisclob for their md5 key ?
Will here's the reason why; " with VRRP and authentication, it only supports key-id 0 & with any device using just a md5 key-string under it's interface.
If you use any other key-id and no matter if they all match, you will not acquire authentication between the VRRP members if one side uses the md5 key-string and the other side just a key-chain.
Once I configured the key ID to be 0 , or configured both routers vrrp auth type of "key-chain" , the BADAUTH will go away.
And when using key-chains only, if the key IDs do not match, you will have problems.
So in this above example, we have a key-chain named vrrp, but the IDs do not match. One side ( r1 ) uses a key id of 1 and the other side a key id of 5.
By updating the key ID on the router#1 to match router#2, VRRP authentication will be established.
So to recap
- VRRP authentication and use just a mix of a key-string for our vrrp interface and key-chain, requires the used of a key ID of 0
- If you decided to use key-chain for your vrrp interfaces, all key ID needs to match.
- The highest number key ID in key-chain will be the key ID used
- it probably best to not use md5 key-string option at all, under your vrrp interfaces ( imho )
- GLBP authentication doesn't exhibit these issues, you either use key-string only or key-chain only thru out your AVG ( no mix and match )
Ken Felix
Freelance Network/Security Engineer
kfelix ----at---- socpuppets ---d-o-t-- com
^ ^
=( * * )
o
/ \
Hi Ken,
ReplyDeleteNote sure if you have a method to, in case authentication on one router fails, the other router will not become "master" as well. Is this a very poor design, because any rogue device could be configured to join the vrrp group and will mess up the traffic.
Unknown,
ReplyDeleteYes this is a security risk but VRRPv3 has a md5 support for the password under ipv6 and by using "IPSEC-AH" , but how much success you would have would be ???s. ( I have never seen anybody successful execute this btw )
Since HSRPv2 support both ipv4/6, it would best be served to use HSRPv2 but this is a cisco solution. HSRP v1 or v2 has always had md5 support btw.
So to answer the question, if the authentication is NOT md5 , anybody could hijack the redundancy protocol operations and selection as primary YMMV on what method you use. I've always try to avoid VRRPv3 or deploy other layer2 security feature from switchport secure mac or arp inspections.