Cisco IOS: EIGRP-Authentifizierung mit Key-Rollover

Über die Qualität der Cisco Schulungsunterlagen habe ich mich schon ab und an mal ausgelassen.
Und während ich mich gerade auf eine neue Kursversion eines Security-Kurses vorbereite, fällt mir schon wieder eine Sache auf, die man besser nicht so macht, wie es im Kurs beschrieben ist. Beim Thema Routing-Protokoll-Authentifizierung findet sich dort eine Key-Chain mit den folgenden send- und accept-lifetimes:

key chain MYKEYS
 key 1
   key-string ThisIsKey1
   accept-lifetime 04:00:00 Jan 1 2010 04:00:00 Feb 1 2012
   send-lifetime 04:00:00 Jan 1 2010 04:00:00 Jan 1 2012
 key 2
   key-string ThisIsKey2
   accept-lifetime 04:00:00 Jan 1 2012 04:00:00 Feb 1 2014
   send-lifetime 04:00:00 Jan 1 2012 04:00:00 Jan 1 2014

Die accept-lifetime des zweiten Keys schließt sich hier genau an die sent-lifetime des ersten Keys an.
Was passieren kann, wenn man es genau so konfiguriert, habe ich in GNS3 nachgestellt (GNS3-Datei und Konfiguration):

R0#ping ipv6 R2-Loopback0 repeat 500
Type escape sequence to abort. Sending 500, 100-byte ICMP Echos to 2001:DB8:2222::12, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!...............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!

R1:
Jan 1 03:59:56.435: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 04:00:01.135: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:03.971: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:03.983: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C202:30FF:FE3F:0 (FastEthernet0/0) is down: Interface Goodbye received 
Jan 1 04:00:08.495: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:13.423: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:17.767: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:22.339: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:26.723: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:31.683: IPv6-EIGRP: received packet with MD5 authentication, key id = 2 
Jan 1 04:00:32.551: IPv6-EIGRP: received packet with MD5 authentication, key id =2

R2:
Jan 1 03:59:28.843: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 03:59:33.271: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live 
Jan 1 03:59:33.271: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 5 invalid authentication)
Jan 1 03:59:33.271: EIGRP: Dropping peer, invalid authentication 
Jan 1 03:59:33.275: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C201:30FF:FE3F:0 (FastEthernet0/0) is down: Auth failure 
Jan 1 03:59:37.823: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live 
Jan 1 03:59:37.823: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 5 (invalid authentication) ... 
Jan 1 03:59:57.347: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live 
Jan 1 03:59:57.347: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 1 (invalid authentication) 
Jan 1 04:00:01.851: IPv6-EIGRP: received packet with MD5 authentication, key id = 2 
Jan 1 04:00:01.851: EIGRP: Received HELLO on FastEthernet0/0 nbr FE80::C201:30FF:FE3F:0 
Jan 1 04:00:01.851: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 
Jan 1 04:00:01.851: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C201:30FF:FE3F:0 (FastEthernet0/0) is up: new adjacency

Was ist da passiert? Für dieses Beispiel habe ich die Uhren beider Router mit einer Differenz von 30 Sekunden konfiguriert. Solche und größere Zeitabweichnungen habe ich auch schon in Netzen mit NTP gesehen. Im Normalbetrieb sollte das zwar nicht auftreten, aber durch Konfigurations-Probleme kann ein NTP-Server halt auch mal nicht erreichbar sein. Und ein Grundsatz guten Netzwerk-Designs heißt halt mit Recht “Always Plan for Problems”.
Für 30 Sekunden (das ist die Zeitspanne am 1.1.2012 von 04:00:00 bis 04:00:30 auf Router1 bzw. von 03:59:30 bis 04:00:00 auf Router2) wird der Router1 den ersten Key nicht mehr verwenden, dieser würde aber von Router2 noch akzeptiert werden. Dafür verwendet Router1 den zweiten Key, dieser wird aber von Router2 noch nicht akzeptiert:

Der Verbindungsabbruch von ca. 30 Sekunden ergibt sich daher, das der Router2 bei einer fehlerhaften
Authentifizierung sofort die Nachbarschaftsbeziehung abbricht und erst wieder aufbaut, wenn beide Router den Key 2 benutzen können. Router1 hat in dieser Zeit keine fehlerhaften Authentifizierungen.
Das Problem lässt sich recht einfach vermeiden, indem man die accept-lifetime nicht nur länger laufen lässt als die sent-lifetime, sondern auch vor der sent-lifetime des nächsten Keys beginnen lässt:

Was passiert jetzt in diesen 30 Sekunden:

• Router1 sendet seine Pakete schon mit Key 2, der auch von Router 2 akzeptiert wird.
• Router2 sendet seine Pakete noch mit Key 1, der von Router 1 noch akzeptiert wird.

Die (relevante) Konfiguration von Router2 sieht dabei folgendermaßen aus. Wie lang man dabei die accept-lifetime überlappen lässt hängt natürlich von den persönlichen Vorlieben ab. Ich habe für dieses Beispiel einfach fünf Minuten genommen:

hostname R1
!
key chain MYKEYS
 key 1
   key-string ThisIsKey1
   accept-lifetime 04:00:00 Jan 1 2010 04:00:00 Feb 1 2012
   send-lifetime 04:00:00 Jan 1 2010 04:00:00 Jan 1 2012
 key 2
   key-string ThisIsKey2
   accept-lifetime 03:55:00 Jan 1 2012 04:00:00 Feb 1 2014
   send-lifetime 04:00:00 Jan 1 2012 04:00:00 Jan 1 2014
!
interface FastEthernet0/0
 ipv6 address 2001:DB8:2::11/64
 ipv6 eigrp 100
 ipv6 authentication mode eigrp 100 md5
 ipv6 authentication key-chain eigrp 100 MYKEYS
!
ipv6 router eigrp 100
 router-id 1.1.1.1
 no shutdown

Wer sich darüber wundert, das ich dieses Beispiel mit IPv6 aufgebaut habe, dem sei der Beitrag Blog Examples Going IPv6 Next Year von PacketLife.net zu empfehlen. Diese Idee werde ich aufgreifen und ab sofort meine Beispiele auch mit IPv6 implementieren, wo es möglich ist.