MACSec auf SRX300 – Ein kurzer und grobmotorischer Test

MACSec oder IEEE 802.1AE ist ein Protokoll, welches die verbindungslose Sicherstellung von Datenvertraulichkeit und Datenintegrität auf Media-Access-Control-(MAC) Ebene definiert bzw. standardisiert. Ebenso ist ein Wiederholungsschutz (replay-protection) und Schlüsseltauschprotokoll (perfect-forward-secrecy) mit definiert.

Seit JunOS 15.1X49-D100 ist MACSec offiziell auf den SRX3xx Branch Firewalls von Juniper unterstützt. Da inzwischen 15.1X49-D120 released wurde ist es an der Zeit mal einen halbwegs praxisnahen Test zu starten um zu sehen was die 300er SRX-Series denn mit MACSec so können, da einige Aspekte von MACSec im Vergleich zu IPSec oder anderen „secure tunnels“ allgemein oder speziell bei Juniper SRX interessant sind.

Hinweis: In diesem Artikel werden proprietäre Layer2- Verschlüsselungssysteme (z.B. Infoguard oder ATMedia) nicht behandelt, da diese wie bereits festgestellt in der Regel proprietär sind und sich nur für „spezialgelagerte Sonderfälle“ anbieten. Auch wird nicht auf Verschlüsselung auf Layer1 (z.B. DWDM Link Encryption) eingegangen.

I. Unsere Motivation – Warum überhaupt MACSec, es gibt doch IPSec, OpenVPN und noch mehr?

Bevor wir uns ins Config und Netwerkdiagrammgetümmel stürzen ist es immer gut zu wissen warum man sich überhaupt noch ein weiteres „VPN“-Protokoll antun will. Bisher hat man doch auch alles irgendwie hinbekommen. Gerade in Bezug auf MACsec ist das eine sehr verständliche und nachvollziehbare Argumentation und auch wir haben jetzt nicht zig MACSec Deployments im Feld. Darum möchte ich hier nochmal kurz zusammenfassen warum die Verwendung von MACSec durchaus in Betracht gezogen werden kann:

  1. Es agiert, wie der Name schon vermuten lässt auf der MAC bzw. Switching Ebene des Netzwerkstacks – das bedeutet eine Ebene tiefer als IPSec.
    Somit kann auch Non-IP-Traffic (ja sowas solls noch geben) transportiert werden. In der Theorie könnte man auch FCoE per MACSec absichern – hier haben wir jetzt keine konkreten Projekte/Betriebserfahrungen von denen wir berichten könnten. Sorry.
  2. MACSec kann von Switches und Routern gleichermaßen gesprochen werden
    Das bedeutet in der Praxis dass über einen einzigen MACSec gesicherten Link beispielsweise mehrere VLANs transportiert werden können (z.B. einfacher Datacenter Interconnect) oder aber auch die Kommunikation zwischen einzelnen Routern und Switches abgesichert werden kann. Wichtig: MACSec stellt keine Ende-zu-Ende Absicherung (z.B. Client-Server) bereit, sondern sichert nur einzelne Verbindungen (Links) zwischen Netzwerkgeräten ab. Auf Deutsch: MACSec schützt nicht zwangsläufig vor kompromittierten bzw. bösartigen Netzwerkgeräten!
  3. MACsec ist in der Regel direkt auf dem Forwarding-Chip (PFE) implementiert.
    Das bedeutet zum einen Geschwindigkeit (in der Regel Linerate des Interfaces) und zum anderen geringe Belastung der (Router bzw. Switch) CPU. Geringere Durchlauf-Latenzen sind hiermit natürlich auch selbstverständlich. Hier sehen wir im direkten Vergleich zu allen anderen Protokollen mit die größten Vorteile.

II. Der Laboraufbau

Hinreichend motiviert wurde folgender Laboraufbau ins Leben gerufen:

Zwischen zwei SRX300 (die kleinste SRX-Firewall die es von Juniper gerade zu kaufen gibt) ist ein 1GE X-Link mit VLAN-Tagging gesteckt und konfiguriert. Vor den SRXen hängen zwei Linux (VMs) welche dann entsprechende iPerf Messungen durchführen werden.

Relevante Konfigurationsschnipsel – den überflüssigen Ballast haben wir der Einfachheit mal weggelassen

Gemessen wurden neben dem Datendurchsatz auch die durchschnittliche Latenz. Bei der Verwendung der Ergebnisse muss man beachten, dass die beiden Testhosts „Tester-A und Tester-B“ VMs auf zwei unterschiedlichen ESX-Hosts waren.

III. Ergebnisse und deren Praxistauglichkeit

PacketLoss und Latenzen:

Gemessen wurde mit einem „adaptive ping“ zwischen den beiden Test-VMs.

Durchsatz (TCP):

Gemessen wurde mit einem „TCP-single stream“ iperf:

Sonstiges

Während der laufenden Tests kam es zu keinerlei Auffälligkeiten bei PFE-Auslastung oder Taildrops:

IV. Fazit

Der Einsatz von MACsec auf der SRX-Serie von Juniper ist durchaus wert in die Toolbox eines Netzwerkarchitekten bzw. Netzwerktechnikers aufgenommen zu werden. Dieser Quickie Test ist natürlich nicht vergleichbar mit irgendwelchen tollen IXIA-Mopeds, gibt aber schon mal keine negativen Indikationen die einem Praxiseinsatz im Wege stehen.

Richard Müller

Richard Müller ist Geschäftsführer der Proact Deutschland GmbH. Den "kreativen" Umgang mit Computern und Datennetzen lernte er schon im Schulalter. Bis heute hat Richard eine Begeisterung für technisch brilliante Konzepte und Lösungsansätze in den Bereichen IT-Infrastruktur - hier vor allem alles rund ums Netzwerk.

 
Kommentare

Wenn beide SRXen die gleiche key-server-priority haben, dann wird übrigens zumindest mit 15.1X49-D120.3 keine Session aufgebaut. Laut Doku sollte ja die niedrigere MAC Adresse dann zum Keyserver werden, das passiert aber nicht.

Hinterlassen Sie einen Kommentar