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:
- 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. - 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! - 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
1 2 3 4 5 6 7 8 9 10 11 |
set security macsec connectivity-association CA-TEST security-mode static-cak set security macsec connectivity-association CA-TEST replay-protect replay-window-size 25 set security macsec connectivity-association CA-TEST offset 30 set security macsec connectivity-association CA-TEST pre-shared-key ckn [GEHEIM] set security macsec connectivity-association CA-TEST pre-shared-key cak [GEHEIM] set security macsec interfaces ge-0/0/7 connectivity-association CA-TEST set interfaces ge-0/0/0 unit 0 family ethernet-switching interface-mode access set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members VL0100_Test1 set interfaces ge-0/0/7 unit 0 family ethernet-switching interface-mode trunk set interfaces ge-0/0/7 unit 0 family ethernet-switching vlan members VL0100_Test1 set vlans VL0100_Test1 vlan-id 100 |
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.
1 2 |
100000 packets transmitted, 100000 received, 0% packet loss, time 15349ms rtt min/avg/max/mdev = 0.097/0.141/0.716/0.019 ms, ipg/ewma 0.153/0.141 ms |
Durchsatz (TCP):
Gemessen wurde mit einem „TCP-single stream“ iperf:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
------------------------------------------------------------ Client connecting to 192.168.1.101, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.100 port 60582 connected with 192.168.1.101 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 5.0 sec 551 MBytes 925 Mbits/sec [ 3] 5.0-10.0 sec 548 MBytes 920 Mbits/sec [ 3] 10.0-15.0 sec 550 MBytes 922 Mbits/sec [ 3] 15.0-20.0 sec 548 MBytes 919 Mbits/sec [ 3] 20.0-25.0 sec 549 MBytes 921 Mbits/sec [ 3] 25.0-30.0 sec 548 MBytes 920 Mbits/sec [ 3] 30.0-35.0 sec 548 MBytes 919 Mbits/sec [ 3] 35.0-40.0 sec 547 MBytes 918 Mbits/sec [ 3] 40.0-45.0 sec 550 MBytes 922 Mbits/sec [ 3] 45.0-50.0 sec 548 MBytes 919 Mbits/sec [ 3] 50.0-55.0 sec 549 MBytes 920 Mbits/sec [ 3] 55.0-60.0 sec 548 MBytes 920 Mbits/sec [ 3] 60.0-65.0 sec 548 MBytes 920 Mbits/sec [ 3] 65.0-70.0 sec 548 MBytes 920 Mbits/sec [ 3] 70.0-75.0 sec 549 MBytes 921 Mbits/sec [ 3] 75.0-80.0 sec 548 MBytes 920 Mbits/sec [ 3] 80.0-85.0 sec 548 MBytes 919 Mbits/sec [ 3] 85.0-90.0 sec 549 MBytes 921 Mbits/sec [ 3] 90.0-95.0 sec 548 MBytes 919 Mbits/sec [ 3] 95.0-100.0 sec 549 MBytes 922 Mbits/sec [ 3] 100.0-105.0 sec 548 MBytes 920 Mbits/sec [ 3] 105.0-110.0 sec 548 MBytes 920 Mbits/sec [ 3] 110.0-115.0 sec 547 MBytes 918 Mbits/sec [ 3] 115.0-120.0 sec 549 MBytes 922 Mbits/sec [ 3] 0.0-120.0 sec 12.9 GBytes 920 Mbits/sec |
Sonstiges
Während der laufenden Tests kam es zu keinerlei Auffälligkeiten bei PFE-Auslastung oder Taildrops:
1 2 3 4 5 6 7 8 |
# show chassis forwarding FWDD status: State Online Microkernel CPU utilization 16 percent Real-time threads CPU utilization 0 percent Heap utilization 22 percent Buffer utilization 1 percent Uptime: 1 hour, 53 minutes |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
# show interfaces queue ge-0/0/7 | match drop Tail-dropped packets : 0 0 pps RL-dropped packets : 0 0 pps RL-dropped bytes : 0 0 bps RED-dropped packets : 0 0 pps RED-dropped bytes : 0 0 bps Tail-dropped packets : 0 0 pps RL-dropped packets : 0 0 pps RL-dropped bytes : 0 0 bps RED-dropped packets : 0 0 pps RED-dropped bytes : 0 0 bps Tail-dropped packets : 0 0 pps RL-dropped packets : 0 0 pps RL-dropped bytes : 0 0 bps RED-dropped packets : 0 0 pps RED-dropped bytes : 0 0 bps Tail-dropped packets : 0 0 pps RL-dropped packets : 0 0 pps RL-dropped bytes : 0 0 bps RED-dropped packets : 0 0 pps RED-dropped bytes : 0 0 bps |
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.
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.