de

Methoden für flexiblen und intelligenten Netzbetrieb

Integration von High-Performance Zones (HPZs) in Campus-Netze und ins BelWü-Netz

SDN-NeIF, Demo-SDN-NeIF

Science DMZ, SciPass oder CampusBypass beschreiben bereits einfache Möglichkeiten wie Hochgeschwindigkeitszonen oder -netze in den Campus integriert werden können. Im Rahmen des Projektes wurden High-Performance Zones (HPZs) in Campus-Netzen aufgebaut, die mit besonders leistungsfähigen Servern und mit besonders breitbandigen Netzen ausgestattet sind. Die HPZs von verschiedenen Standorten wurden einerseits durch das optische Hochleistungsnetz „Netzwerk für Innovation und Forschung“ (NeIF) miteinander verbunden und andererseits aber auch ins BelWü-Netz und in die Campus-Netze integriert. Es wurde ein OpenFlow-basiertes SDN-Konzept vorgeschlagen, dieses zuerst in Mininet implementiert, daraufhin in einem lokalen Testbed aufgebaut, und schließlich noch mit realer Hardware über das NeIF getestet. Im letzten Fall wurde kritische Infrastruktur emuliert, um den Wirkbetrieb nicht zu gefährden. Eine besondere Herausforderung stellen dabei die verschiedenen Hoheiten über die Komponenten dar. So betreibt die jeweilige Universität das lokale Campus- und HPZ-Netz. Das BelWü verwaltet die Weiterleitung zwischen Campus-Netzen im BelWü-Core und die Weiterleitung im NeIF zwischen den HPZs.

SDN-NeIF Architektur

Die entwickelte SDN-Architektur ist in der Grafik dargestellt. Jeder Universitätsstandort besteht aus einem Campus-Netz und einer HPZ. Das Campus-Netz ist über einen Campus-Router (CR) mit einem Border-Router (BR) und einem Border-Switch (BS) verbunden. Der BR stellt den Uplink zum BelWü-Kernnetz und zum Internet bereit. Der BS ist ein OpenFlow-Switch, der von einem zentralen SDN-Controller (BSC) im BelWü-Netz gesteuert wird und mehrere Universitätsstandorte über das NeIF verbindet. Er ist auch mit dem CR und dem BR verbunden, um die HPZ an den Campus und das Internet anzubinden.

Entlastung von Firewalls in Campus-Netzen durch Firewall-Bypass für vertrauenswürdigen Verkehr

Offwall, FWCongOff

Firewalls stellen bei der Kommunikation im Campus-Umfeld häufig ein Bottleneck dar, wenn ihre Kapazität niedriger ist als die Netzgeschwindigkeit. Ein einfacher Upgrade von Firewalls ist zwar eine technologisch mögliche aber sehr kostenintensive Lösung. Ein typischer Anwendungsfall im Campus-Umfeld ist in der Grafik dargestellt. Nicht jeder Verkehr, der eine Instituts-Firewall passiert, muss notwendigerweise von einer Firewall kontrolliert werden, weil es sich z.B. um Datenaustausch mit anderen Uni-internen Instituten oder dem Rechenzentrum handelt. Eine Umleitung von solchem Verkehr um die Firewall herum ist in einem solchen Umfeld eine kostengünstige Lösung zur Linderung der Engstelle.

Netzwerk-Topologie für den Firewall-Bypass

Es wurden mehrere Möglichkeiten zur Umleitung von vertrauenswürdigem Verkehr um eine Firewall betrachtet.

  • Mit Hilfe von Access Control Lists (ACLs) können auf einem Switch Umleitungsregeln definiert werden. Eine Marktrecherche hat jedoch gezeigt, dass Switches mit ACLs sehr teuer sind, so dass dieser Ansatz keine kostengünstige Firewall-Entlastung ermöglicht.

Mit Hilfe eines OpenFlow-fähigen Switches können über einen Controller ebenfalls Regeln eingerichtet werden, die Verkehr entweder zur Firewall leiten oder um sie herumleiten. Es wurden ein dynamischer und ein statischer Firewall-Bypss definiert und untersucht.

  • Beim dynamischen Firewall-Bypass werden neue Flüsse grundsätzlich über die Firewall geleitet. Mit Hilfe von sFlow werden Proben am Ausgang der Firewall genommen und für diese Flüsse automatisch über den Controller Umleitungen auf dem OpenFlow Switch geschaltet. Experimentelle Untersuchungen auf Basis eines Prototyps sowie theoretische Hochrechnungen haben jedoch gezeigt, dass verfügbare OpenFlow-Switches nicht hinreichend viele Regeln unterstützen können, um diesen Ansatz in der Praxis realisieren zu können.
  • Beim statischen Firewall-Bypass wird eine Whitelist in einer Datenbank über eine Web-Applikation gepflegt. Der SDN-Controller kommuniziert mit der Datenbank und übersetzt die Whitelist in OpenFlow-Regeln, die er auf dem Switch installiert, wodurch definierter Verkehr um die Firewall herumgeleitet wird. Das Konzept wurde in einem lokalen Prototyp getestet und dann an die technischen Herausforderungen des Anwendungsfalls angepasst. Die entwickelte Lösung wurde für den Fachbereich Informatik der Uni Tübingen an den Standorten Sand und im TTR2-Gebäude auf der Oberen Viehweide in den Wirkbetrieb übernommen. Weitere Einsätze dieser Lösung zeichnen sich ab.

Flexibilisierter und erweiterter Einsatz der Sicherheitsprotokolle 802.1X, MACsec und IPsec im Campus-Umfeld mit Hilfe von SDN Die Protokolle 802.1X, MACsec und IPsec können im Campus-Umfeld zur Netzabsicherung eingesetzt werden. 802.1X wird zur Authentisierung und Autorisierung von Nutzern verwendet: Nur wer seine Identität nachweisen kann, bekommt Zugriff auf das Netz. Mit Hilfe von MACsec kann der gesamte Verkehr auf einer Übertragungsleitung zwischen zwei Switches verschlüsselt werden. Wenn dies für alle Leitungen eines Netzes angewendet wird, ist es für einen Angreifer sehr schwer Daten abzugreifen oder falsche Daten einzuspielen. Auf Basis von VPN-Lösungen und mit Hilfe von IPsec kann dagegen eine verschlüsselte virtuelle Verbindung von einem Rechner im Internet zu einem VPN-Konzentrator innerhalb eines Netzes aufgebaut werden. Die Forschungsarbeiten haben das Ziel den Einsatz dieser weit verbreiteten Protokolle im Licht von SDN neu zu denken und im Vergleich zur aktuellen Situation zu vereinfachen und zu verbessern.

IEEE 802.1X basierte Authentifizierung und Autorisierung mit SDN

AAM, xRAC

Der Standard IEEE 802.1X beschreibt Protokolle und Mechanismen, wie eine LAN-Infrastruktur mit Hilfe von Authentifizierung und Autorisierung abgesichert werden kann. Das Grundprinzip ist in der Grafik verdeutlicht. Ein Client kann zu Beginn nur über EAP mit seinem Zugangsknoten kommunizieren. Er wird von einem Authenticator auf dem Zugangsknoten mit Hilfe der Protokolle EAP und RADIUS authentifiziert. Mit RADIUS werden vom Authenticator entfernte Authentifizierungsserver miteingebunden. Nach erfolgreicher Authentifizierung erfolgt die Autorisierung, d.h. der Switch erlaubt dem Client den Zugang zum Netz. Eventuell wird der Client auch einem speziellen VLAN zugewiesen.

VLAN-Zuweisung basierend auf 802.1X und SDN

802.1X ist ein weit verbreitetes Konzept und wird auch in eduroam angewendet. Es hat aber einige Schwachstellen. 802.1X erfordert manuelle Konfiguration des Authenticators auf dem Switch. Die Autorisierung ist zustandslos, d.h. einem Client kann nach Autorisierung der Zugang zum Netz nicht mehr entzogen werden, auch wenn sich seine Berechtigung zwischenzeitlich ändert. Als Authentifizierungsserver müssen relativ aufwändig zu pflegende RADIUS oder DIAMETER Server eingesetzt werden, während kleine Datenbanken für lokale Zwecke ausreichend wären. Es wurde ein neues Konzept für SDN-basierte IEEE 802.1X Integration entwickelt. Der Authenticator ist als Controller-Applikation realisiert, die wahlweise mit RADIUS oder anderen Backends kommunizieren kann. Dadurch entfällt die Notwendigkeit für die manuelle Konfiguration des Zugangsknotens, wodurch das Deployment vereinfacht wird. Clients kommunizieren nach wie vor über EAP mit dem Switch, so dass Clients existierende 802.1X Software weiterhin verwenden können. EAP Nachrichten werden allerdings nicht mehr lokal auf dem Switch verarbeitet, sondern via OpenFlow an seinen Controller weiterreicht, von dem er nach erfolgreicher Autorisierung konfiguriert wird. Ein Prototyp wurde entwickelt mit Software- und Hardware-Switches.

Die Arbeit wurde erweitert, dass nicht nur Benutzer sondern auch einzelne Anwendungen authentifiziert und autorisiert werden können. Dazu müssen die Anwendungen als Restricted Application Containers (RACs) gekapselt werden. Ein Prototyp wurde auf Basis von Docker-Containern realisiert. Die RACs werden nach erfolgreicher Authentifizierung des RAC-Images und des Benutzers autorisiert. Daraufhin erst können sie auf ihrem Server ausgeführt werden. Zudem kann ihr Zugriff auf das Netz feingranular limitiert und überwacht werden.

MACsec basierte Absicherung von Campusnetzen mit Hilfe von P4

P4-MACsec

MACsec kann auf Interfaces geeigneter Switches manuell konfiguriert werden, um den gesamten Verkehr über eine Übertragungsleitung zu verschlüsseln. Die manuelle Konfiguration ist aufwändig und stellt eine Fehlerquelle dar. Eine Automatisierung mit Topologie-Erkennung durch LLDP und per Software gesteuerter Schlüsselverteilung liegt nahe. Allerdings wird Topologie-Erkennung mit LLDP heutzutage ohne Verschlüsselung durchgeführt, wodurch es angreifbar und das Ergebnis nicht vertrauenswürdig ist. Wir betrachten ein Netz, welches aus programmierbaren P4-Switches besteht. Auf diesen werden lokale Controllers konfiguriert, welche mit Hilfe eines angepassten LLDP lokale und verschlüsselte Topologie-Erkennung durchführen. Empfangene LLDP-Pakete werden an einen zentralen Controller geleitet, der eine Sicht auf die Gesamttopologie hat, Schlüssel generiert und MACsec unter Einbeziehung der lokalen Controller auf allen Übertragungsleitungen konfiguriert. Automatisches Rekeying kann ebenfalls automatisiert werden. Dieses Konzept wurde als Prototyp auf P4-Hardware implementiert. P4-MACsec verwendet lokale Controllers, welches in einer Vorarbeit für OpenFlow Switches im Rahmen des Projektes erarbeitet und implementiert wurde [LoCoSDN https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth18f.pdf]

IPsec-basierter Remotezugriff auf Campusnetze mit Hilfe von P4

P4-IPsec

Mit Hilfe eines VPNs kann sich ein sogenannter Roadwarrior, z.B. der Rechner eines Telearbeiters, von extern in ein Zielnetz einwählen. Der Nutzer konfiguriert dazu einen verschlüsselten IPsec-Tunnel zwischen dem VPN-Client auf dem Roadwarrier und einem VPN-Konzentrator im Zielnetz. Der Roadwarrier bekommt eine IP-Adresses aus dem Zielnetz und danach stehen ihm dessen Dienste zur Verfügung. Beim VPN-Konzentrator handelt es sich um teure Spezialhardware. Wir schlagen vor diesen durch mehrere P4-basierte VPN Gateways im Netz zu ersetzen. Ein geeignetes Signalisierungsverfahren unterstützt durch das DNS und einen zentralen Controller baut bei der Anfrage eines entsprechenden Dienstes automatisch ohne Mitwirkung des Nutzers einen verschlüsselten IPsec Tunnel zu dem VPN-Gateway auf, das sich am nächsten beim Zielserver befindet. Durch die Ersetzung des VPN-Konzentrators durch mehrere VPN Gateways erhöht sich die die Skalierbarkeit des VPNs. Zudem wird der Verkehr im Zielnetz so lange wie möglich verschlüsselt transportiert, wodurch auch die Sicherheit verbessert wird. Die Usability profitiert von der Automatisierung.

de/networks.txt · Last modified: 2019/10/09 14:34 by Mark Schmidt