© vege - Fotolia.com

Cisco OSPF IPv6 Verschlüsselung/ Authentifizierung

Aktuell arbeite ich am Thema der Absicherung von OSPFv3, speziell im Rahmen von IPv6. Die Topologie die ich heute zur Demonstration verwenden werde ist recht einfach:

OSPFv3-Topologie

Eine größere Topologie ist zur Demonstration nicht notwendig, dass Beispiel lässt sich beliebig skalieren. Die Möglichkeiten der Absicherung von OSPF haben sich im Zuge von IPv6 verändert, OSPFv3 verwendet keine eigene Lösung mehr zur Absicherung, sondern übergibt die Aufgaben der Sicherstellung von Integrität, Vertraulichkeit und Authentizität an die übergeordnete Protokollschicht - IPv6.

Relevant sind hierbei die IPv6 Extension Header vom Typ 50 und 51: Der Authentication Header (AH) sowie der Encapsulating Security Payload (ESP) Header.

In diesem Beitrag werde ich sowohl die "klassische" Variante zum Schutz von OSPF über IPv6 nach RFC 4552 erläutern, als auch die alternative IPSec unabhängige Variante, mit dem OSPFv3 Authentication Trailer nach RFC 7166. Beginnen werde ich mit der erst genannten Variante.

Ausgangszustand unverschlüsselt

Die Router sind beide in der Ausgangskonfiguration, geändert im Rahmen von OSPF wurde folgendes:

R1

hostname R1
!
ipv6 unicast-routing
!
interface GigabitEthernet0/1
 no ip address
 ipv6 address FE80::1 link-local
 ipv6 address 2001::1:1/112
 ipv6 enable
 ipv6 ospf 1 area 0
!
ipv6 router ospf 1
 router-id 1.1.1.1
!

R2

hostname R2
!
ipv6 unicast-routing
!
interface GigabitEthernet0/1
 no ip address
 ipv6 address FE80::2 link-local
 ipv6 address 2001::1:2/112
 ipv6 enable
 ipv6 ospf 1 area 0
!
ipv6 router ospf 1
 router-id 2.2.2.2
!

Ein Blick auf die Kommunikation zwischen R1 und R2 mit Hilfe von Wireshark zeigt, dass die periodischen "Hello" Pakete sichtbar und unverschlüsselt versendet werden:

ospfv3 Unverschlüsselt

Die komplette Kommunikation findet im Klartext statt, die drei Anfangs genannten Schutzziele sind nicht realisiert.

Nutzung des Authentication Headers

Eine erste Schutzmöglichkeit bietet die Nutzung des IPv6 Authentication Headers. Auf einem Interface lässt sich die Nutzung des Authentication Headers mit folgendem Befehl aktivieren:

ipv6 ospf authentication ipsec spi <SPI> <authentication-algorithm> <key-encryption-type> <key>

Im Beispiel:

ipv6 ospf authentication ipsec spi 256 sha1 0 47774ac770a7242a770d33364dce704629beb1a8

Der Befehl setzt sich wie folgt zusammen:

  • Der SPI (Security Parameter Index) ist ein manuell gewählter 32bit Wert, der im Klartext übermittelt wird und dem Router hilft, zwischen verschiedenen verschlüsselten Streams zu unterscheiden. Es handelt es sich dabei um eine Zahl zwischen 256-4294967295.
  • Als Authentication-Algorithm kann entweder SHA1 oder MD5 verwendet werden.
  • Der Key-Encryption-Type kann 0 (Klartext) oder 7 (mit Sichtschutz) sein bzw. weggelassen (=0) werden. Es handelt sich hierbei um die Art der Speicherung des Keys in der Konfiguration.

Nachträglich kann ein 0-Key mit dem Befehl

service password-encryption

mit einem Sichtschutz versehen werden.

Der Key sollte nicht von Hand eingegeben werden, sondern Beispielsweise der SHA Hash einer mit /dev/random erzeugten Datenfolge sein.

In Wireshark sieht ein Paket nun wie folgt aus:

ospfv3 AH

Im Paket zu erkennen ist nun der AH-Extension Header. Das Ganze funktioniert natürlich nicht nur auf einem Interface direkt, sondern auch im Konfigurations-Submenü (router ospfv3) für eine komplette Area.

Bei dieser Variante besteht die Gefahr von Replay-Attacken.

Nutzung des Encapsulating Security Payload Headers

Zur Verschlüsselung der OSPFv3 Pakete kann folgender Befehl verwendet werden:

ipv6 ospf encryption ipsec spi <SPI> esp <(mehrere) Verschlüsselungs-Parameter> <(mehrere) Authentication-Parameter>

Im Beispiel:

ipv6 ospf encryption ipsec spi 256 esp aes-cbc 128 0 6746fa40fc4e0833c257b9bd7f0714e6 sha1 0 47774ac770a7242a770d33364dce704629beb1a8

Der Befehl setzt sich wie folgt zusammen:

  • Der Security Parameter Index (256 im Beispiel) hat hierbei die selbe Bedeutung wie im vorherigen Kapitel.
  • Der Verschlüsselung-Algorithmus ist AES im Modus CBC (aes-cbc). Alternativen wären 3DES und DES.
  • Die Keysize für AES beträgt im Beispiel 128. Alternativen im Rahmen von AES wären 128, 192 und 256.
  • Die Verwendung des Passworts geschieht nach dem gleichen Verfahren mit 0 und 7 wie im vorherigen Beispiel. Es handelt sich bei AES-128 beispielsweise um einen 32 bit HEX-Wert (da Hex = 0..15 = 4 bit, 32*4 bit = 128 bit = AES Keysize). Der Key sollte nicht von Hand eingegeben werden, sondern Beispielsweise unter Nutzung eines kryptographisch sicheren Zufallszahlengenerators generiert werden.

Aufgrund der Tatsache, dass OSPF Pakete häufig an Multicast (One-To-Many) Adressen gesendet werden, lassen sich Verfahren zur Schlüsselaushandlung wie Diffie Hellmann nicht verwenden. Moderne Möglichkeiten wie Perfect Forward Secrecy sind hierbei nicht realisierbar. Dies zwingt Administratoren leider zur Nutzung von statischen, auf den Geräten hinterlegten Keys.

Im Wireshark sieht ein Paket nun wie folgt aus:

ospfv3 ESP

Der Inhalt des Pakets ist nun nicht mehr lesbar, dass es sich mit hoher Wahrscheinlichkeit um ein OSPF Paket handelt, lässt sich aus der IPv6 Multicast Adresse ff02::5 bestimmen.

Nutzung des OSPFv3 Authentication Trailer

Eine alternative Variante zur Sicherstellung der Authentizität ist in RFC 7166 definiert. Die Variante versucht einige, auch sicherheitsrelevante, Probleme zu beseitigen, die Beispielsweise in RFC 6039 näher beschrieben werden.

Die Konfiguration dieser Variante sieht wie folgt aus:

!
router ospfv3 1
 authentication mode strict
 area 0 authentication key-chain ospf-1
 !
 address-family ipv6 unicast
  router-id 1.1.1.1
 exit-address-family
!
key chain ospf-1
 key 1
  key-string CNJBBCwPLYAHOqrGXiblAhg8dspcfujNF6cT2BHzy5iJVxHiFWveWgRIG2qOMKGel21Dq85OBoKiju1m
  cryptographic-algorithm hmac-sha-512
!

Im Beispiel wurde OSPv3 konfiguriert, zusätzlich wurde für die IPv6 Variante eine Router-ID 1.1.1.1 definiert. Der für die Aktivierung relevante Eintrag ist area 0 authentication key-chain ospf-1. "ospf-1" ist hierbei ein frei wählbarer Name.

Im Rahmen der Erstellung der Keychains lassen sich viele weitere interessante Details konfigurieren, beispielsweise Ablaufzeiten für Keys. In Wireshark sieht ein Paket nun wie folgt aus:

ospfv3 AH Trailer

Unabhängig der Sinnhaftigkeit lässt sich der Authentication Trailer gemeinsam mit dem Authentication Header konfigurieren, genauso wie die Verschlüsselung, also die Verwendung von ESP, gemeinsam mit dem Authentication Trailer.

Kurze Prüfung der Umsetzung

An dieser Stelle lohnt sich ein kurzer Blick in die verschlüsselten Pakete: Nach kurzer Konfiguration von Wireshark ist es möglich, die Pakete zwischen R1 und R2 wieder zu entschlüsseln und Eigenschaften wie die Authentisierung zu prüfen.

Am Beispiel von einem Hello Paket:

ospfv3 Entschlüsselt

Gut zu sehen: Der ESP SPI ist der von uns manuell ausgewählte Identifier, darunter die fortlaufende ESP Sequenz, ein 32bit Wert; ein zufällig generierter 128bit IV für das CBC Verfahren (32bit-Hex = 0..15 = 4 bit, 32*4 bit = 128 bit = AES Blocksize), das Padding, der Inhalt des IPv6 Header Felds "Next Header", sowie die erfolgreiche Prüfung der HMAC-SHA-1-96, also des von uns eingegebenen Authentication-Keys. Das IP Paket enthält den Authentication Trailer.

In Wireshark habe ich an dieser Stelle einen Bug bemerkt: Bei keinen Paketen außer den OSPF "Hello" Paketen wird an dieser Stelle der Authentication Trailer angezeigt, obwohl klar im Hex Editor unten, beginnend mit 00 01 00 50 00 00 zu sehen ist, dass dieser enthalten ist (und auch sein muss):

ospfv3 wireshark bug


Bildnachweise:

  • © vege - Fotolia.com

2 Gedanken zu „Cisco OSPF IPv6 Verschlüsselung/ Authentifizierung“

  1. Hi Martin. Guter Beitrag, vielen Dank.
    Ich habe die AH Variante in meinem Labor eingesetzt. Lief auch ohne Probleme.
    Die ESP Variante konnte ich konfigurieren (und habe auch entsprechende ESP Pakete in Wireshark gesehen), allerdings kam kein einziger Nachbar wieder hoch. Per „show crypto ipsec sa“ konnte ich sehen, dass es viele Decrypt Errors gab. Warum auch immer.
    Etwas Googlelei hat mich dann darauf gebracht, dass meine 2811er Router mit 15.1(4)M12a *eigentlich* gar keine Encryption für OSPFv3 unterstützen. Aha. Vielleicht liegt es daran? Warum auch immer man es trotzdem konfigurieren konnte…

    Cheers,
    Johannes

    1. Hi Johannes,

      danke! Den Beitrag hatte ich mit virtuellen Routern in Cisco Virl getestet. Zumindest damit gab es keine Probleme.

      Aber das Verhalten „ich kann etwas konfigurieren dass dann jedoch ohne Funktion bleibt“ habe ich schon häufiger auf Cisco Geräten erlebt… :-/ Auf den von Dir beschriebenen Fehler bin ich bisher jedoch noch nicht gestoßen.

      Viele Grüße
      Martin

      Btw: Schöner Blog von Dir 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert