{"id":3569,"date":"2010-12-23T23:05:12","date_gmt":"2010-12-23T22:05:12","guid":{"rendered":"http:\/\/security-planet.de\/?p=3569"},"modified":"2010-12-23T23:05:12","modified_gmt":"2010-12-23T22:05:12","slug":"cisco-ios-eigrp-authentifizierung-mit-key-rollover","status":"publish","type":"post","link":"https:\/\/cyber-fi.net\/index.php\/2010\/12\/23\/cisco-ios-eigrp-authentifizierung-mit-key-rollover\/","title":{"rendered":"Cisco IOS: EIGRP-Authentifizierung mit Key-Rollover"},"content":{"rendered":"

\"\"\u00dcber die Qualit\u00e4t der Cisco Schulungsunterlagen habe ich<\/a> mich schon ab und<\/a> an mal ausgelassen<\/a>.
\nUnd w\u00e4hrend ich mich gerade auf eine neue Kursversion eines Security-Kurses vorbereite, f\u00e4llt 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:<\/p>\n

key chain MYKEYS\n key 1\n   key-string ThisIsKey1\n   accept-lifetime 04:00:00 Jan 1 2010 04:00:00 Feb 1 2012\n   send-lifetime 04:00:00 Jan 1 2010 04:00:00 Jan 1 2012\n key 2\n   key-string ThisIsKey2\n   accept-lifetime 04:00:00 Jan 1 2012 04:00:00 Feb 1 2014\n   send-lifetime 04:00:00 Jan 1 2012 04:00:00 Jan 1 2014\n<\/pre>\n
Die accept-lifetime des zweiten Keys schlie\u00dft sich hier genau an die sent-lifetime des ersten Keys an.
\nWas passieren kann, wenn man es genau so konfiguriert, habe ich in GNS3 nachgestellt (GNS3-Datei und Konfiguration)<\/a>:<\/p>\n
\n
\n
\"\"<\/dt>\n
EIGRP-Authentication zwischen Router1 und
\nRouter2<\/dd>\n<\/dl>\n<\/div>\n
R0#ping ipv6 R2-Loopback0 repeat 500\nType escape sequence to abort. Sending 500, 100-byte ICMP Echos to 2001:DB8:2222::12, timeout is 2 seconds:\n!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n!!!!!!!!!!!!!!!!!!...............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n!!!!!!!!!!<\/code><\/pre>\n
R1:\nJan 1 03:59:56.435: IPv6-EIGRP: received packet with MD5 authentication, key id = 1\nJan 1 04:00:01.135: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 \nJan 1 04:00:03.971: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 \nJan 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 \nJan 1 04:00:08.495: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 \nJan 1 04:00:13.423: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 \nJan 1 04:00:17.767: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 \nJan 1 04:00:22.339: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 \nJan 1 04:00:26.723: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 \nJan 1 04:00:31.683: IPv6-EIGRP: received packet with MD5 authentication, key id = 2 \nJan 1 04:00:32.551: IPv6-EIGRP: received packet with MD5 authentication, key id =2\n<\/code><\/pre>\n
R2:\nJan 1 03:59:28.843: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 \nJan 1 03:59:33.271: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live \nJan 1 03:59:33.271: EIGRP: FastEthernet0\/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 5 invalid authentication)\nJan 1 03:59:33.271: EIGRP: Dropping peer, invalid authentication \nJan 1 03:59:33.275: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C201:30FF:FE3F:0 (FastEthernet0\/0) is down: Auth failure \nJan 1 03:59:37.823: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live \nJan 1 03:59:37.823: EIGRP: FastEthernet0\/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 5 (invalid authentication) ... \nJan 1 03:59:57.347: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live \nJan 1 03:59:57.347: EIGRP: FastEthernet0\/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 1 (invalid authentication) \nJan 1 04:00:01.851: IPv6-EIGRP: received packet with MD5 authentication, key id = 2 \nJan 1 04:00:01.851: EIGRP: Received HELLO on FastEthernet0\/0 nbr FE80::C201:30FF:FE3F:0 \nJan 1 04:00:01.851: AS 100, Flags 0x0, Seq 0\/0 idbQ 0\/0 \nJan 1 04:00:01.851: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C201:30FF:FE3F:0 (FastEthernet0\/0) is up: new adjacency<\/code><\/pre>\n
Was ist da passiert? F\u00fcr dieses Beispiel habe ich die Uhren beider Router mit einer Differenz von 30 Sekunden konfiguriert. Solche und gr\u00f6\u00dfere 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\u00dft halt mit Recht “Always Plan for Problems”.
\nF\u00fcr 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\u00fcrde aber von Router2 noch akzeptiert werden. Daf\u00fcr verwendet Router1 den zweiten Key, dieser wird aber von Router2 noch nicht akzeptiert:<\/p>\n
\n
\n
\"\"<\/dt>\n
Die sent- und accept-lifetimes (nicht proportional gezeichnet)<\/dd>\n<\/dl>\n<\/div>\n
Der Verbindungsabbruch von ca. 30 Sekunden ergibt sich daher, das der Router2 bei einer fehlerhaften
\nAuthentifizierung sofort die Nachbarschaftsbeziehung abbricht und erst wieder aufbaut, wenn beide Router den Key 2 benutzen k\u00f6nnen. Router1 hat in dieser Zeit keine fehlerhaften Authentifizierungen.
\nDas Problem l\u00e4sst sich recht einfach vermeiden, indem man die accept-lifetime nicht nur l\u00e4nger laufen l\u00e4sst als die sent-lifetime, sondern auch vor der sent-lifetime des n\u00e4chsten Keys beginnen l\u00e4sst:<\/p>\n
\n
\n
\"\"<\/dt>\n
Die accept-lifetime beginnt jetzt vor der send-lifetime<\/dd>\n<\/dl>\n<\/div>\n
Was passiert jetzt in diesen 30 Sekunden:<\/p>\n