EIGRP Authentication Part II

So after thinking about how to implement key-chains around my network, I decided the best way would be to have a setup that has a new key every month, with a little overlap from when one key ends to the next key starts, to account for differences in NTP – realistically a few second difference would be too much, but I’ll allow for an hour just in case.

I’ve made a spreadsheet which generates random strings for use as keys, and using the times/dates entered, generates some config (EIGRP Key Chains Spreadsheet) I can then push this out to all my routers with Solarwinds NCM to make sure the same key-chain is everywhere. In theory you can use a different key chain for every router pair, but I felt the admin overhead on this was way too much, even on a relatively small network.

Read on for the config….

EIGRP Authentication

I imagine most networks use EIGRP Authentication on the interfaces that are enabled for EIGRP;

R01(config)#int fa0/1
R01(config-if)# ip authentication mode eigrp 1 md5
R01(config-if)# ip authentication key-chain eigrp 1 MYKEYS

Usually i only see people using the one key with the send/accept lifetimes set to infinite.

I am reviewing the security on our network, and am debating whether or not to implement keys with a set lifetime?

I have always been put off doing this in the past due to the issues with making sure the key lifetimes overlap, below is a sample I’ve been working on in my lab using 1 minute keys with 30 second overlap at either side of the key lifetime;

key chain MYKEYS
key 1
key-string 1111
accept-lifetime local 16:39:30 Mar 27 2011 duration 120
send-lifetime local 16:40:00 Mar 27 2011 duration 60
key 2
key-string 2222
accept-lifetime local 16:40:30 Mar 27 2011 duration 120
send-lifetime local 16:41:00 Mar 27 2011 duration 60
key 3
key-string 3333
accept-lifetime local 16:41:30 Mar 27 2011 duration 120
send-lifetime local 16:42:00 Mar 27 2011 duration 60
key 4
key-string 4444
accept-lifetime local 16:42:30 Mar 27 2011 duration 120
send-lifetime local 16:43:00 Mar 27 2011 duration 60

Obviously in a production environment, you wouldn’t use such short durations, i think maybe a month per key would be about right. With the last key send/accept lifetime set to infinite to prevent the key-chain from expiring if new ones are not added in time and causing an outage.

the “show key chain” is alway quite useful if this is something you are new too;

R02#show key chain
Key-chain MYKEYS:
key 1 -- text "1111"
accept lifetime (16:39:30 BST Mar 27 2011) - (120 seconds) [valid now]
send lifetime (16:40:00 BST Mar 27 2011) - (60 seconds)
key 2 -- text "2222"
accept lifetime (16:40:30 BST Mar 27 2011) - (120 seconds) [valid now]
send lifetime (16:41:00 BST Mar 27 2011) - (60 seconds) [valid now]
key 3 -- text "3333"
accept lifetime (16:41:30 BST Mar 27 2011) - (120 seconds)
send lifetime (16:42:00 BST Mar 27 2011) - (60 seconds)
key 4 -- text "4444"
accept lifetime (16:42:30 BST Mar 27 2011) - (120 seconds)
send lifetime (16:43:00 BST Mar 27 2011) - (60 seconds)

All in all I think this is something that would be quite acceptable and not to much of an admin overhead with a proper planning.

The final question – do we use the same key chain on all routers/interfaces, or use multiple key chains, but then I can see the administration getting excessive!