Software-Defined Networking (SDN)
Flexibler im Campus
Die Vielzahl neuer Anwendungen überfordert viele Netzwerke, sodass diese bildlich gesprochen kurz vor dem Herzstillstand stehen. Dennoch müssen die Informationen - Video- und Audiodaten ebenso wie die riesigen Big-Data-Übertragungen - ungestört fließen. Gleichzeitig müssen sie kontrolliert und überwacht sein, um die Sicherheit und Integrität des Netzwerks zu gewährleisten.
Auf dem Markt gibt es schon seit Jahren zentralisierte Anwendungen zur Überwachung der ordnungsgemäßen Funktion von Netzwerken. Bei diesen Anwendungen werden verschiedene Mechanismen für die Steuerung von Netzwerkgeräten zusammengeführt. Für jeden Netzwerkanbieter benötigen diese Anwendungen mindestens ein spezielles Plug-in. Probleme treten meist dann auf, wenn Softwareaktualisierungen eines Anbieters andere Anwendungen zum Absturz bringen. Das Nachjustieren ist weit mehr als nur ein Ärgernis für den Administrator: Es entstehen zusätzliche Kosten und die Funktionalität des Netzwerks ist in dieser Zeit eingeschränkt.
Openflow: ein Standard für alle Fälle
Zwar versuchen auch herkömmliche Architekturen und Netzwerkprotokolle, den Forderungen nach Agilität und Flexibilität gerecht zu werden, doch befinden sie sich bereits jetzt an der Grenze der Belastbarkeit. Um den freien und sicheren Informationsfluss im Campus sicherzustellen, sind neue Architekturen und Protokolle erforderlich. Ein Lösungsansatz ist Software-Defined Networking (SDN). SDN lässt sich schrittweise in bestehenden IT-Infrastrukturen implementieren und kann somit auch auf der Kostenseite überzeugen. Bei SDN sind Schnittstellen zwischen dem zentralisierten Controller und den Netzwerkgeräten definiert. Diese Schnittstellen bleiben unabhängig von Softwareänderungen auf beiden Seiten transparent, solange die Updates genau der Schnittstellendefinition entsprechen. Erste standardisierte Kommunikationsschnittstelle zwischen der Kontroll- und der Weiterleitungsebene einer SDN-Architektur ist der von der Open Networking Foundation (ONF) verwaltete Openflow-Standard.
Mittels Openflow können Switches entweder den gesamten Datenverkehr auf einem bestimmten Link beeinflussen oder zusammen mit herkömmlichen Protokollen operieren. In diesem Fall manipuliert der SDN-Controller nur bestimmte Datenflüsse auf einem Link, gleichzeitig kann es anderen Datenflüssen gestattet sein, die übliche Paketverarbeitungs-Pipeline zu nutzen. Der Revisionsstand von Openflow (Version 1.3.00 vs. 1.0.00) definiert den vollständigen Satz an Fähigkeiten, den jede Komponente (Anwendung, Controller und Switch) theoretisch unterstützen kann. Die im Openflow integrierte automatische Discovery-Fähigkeit ermöglicht eine schrittweise Aufrüstung jeder einzelnen Komponente, ohne die Kompatibilität zu verletzen.
Souverän gelenkt per SDN
Dank SDN kann der Administrator den Datenverkehr im Netzwerk also maßgeschneidert lenken. Die SDN-Anwendung akzeptiert Input aus zahlreichen Quellen. Dazu gehören Login- und Logoff-Informationen der Anwender im Netzwerk, Statistiken zu physischen Netzwerkdaten, auf Basis vergangener Trends berechneter voraussichtlicher Datenverkehr, Analysen zu Sicherheitsbedrohungen sowie andere Quellen. Diese Informationen dienen als Entscheidungsbasis für die jeweiligen Reaktionen. Der SDN-Controller entscheidet basierend auf der von ihm erstellten Netzwerkkarte, wo Änderungen im Netzwerk vorzunehmen sind. Diese können sehr unterschiedlich ausfallen: Angefangen mit der Erhöhung der Priorität des Datenflusses einer bestimmten Anwendung bis hin zu einem kompletten Zugriffskontrollsystem für das Netzwerk inklusive rollenbasierter Ressourcenzuweisung. All diese Komponenten operieren unabhängig voneinander auf unterschiedlichen Netzwerkschichten mit einer festgelegten API zwischen den jeweiligen Layers und einem vordefinierten Messaging-Set. So ist der Funktionsumfang stabil und skalierbar, zudem verursacht er auch bei einem Update auf einem Layer keine Unterbrechung in der Funktionalität eines anderen.
Die folgenden Abschnitte beschreiben beispielhaft zwei Anwendungsfälle im Campus-Netzwerk, um die Chancen durch den SDN-Einsatz im Campus-Netzwerk zu verdeutlichen.
Als erstes Beispiel dient die anwendungsbasierte Ressourcenzuteilung: Eine Anwendung wird traditionell anhand der IP Port-Nummer im Header eines Datenpakets identifiziert. Diese Nummern ließen sich statisch konfigurieren; dabei konnte der Administrator dem Netzwerkverkehr einer ausgewählten Gruppe von Anwendungen wie beispielsweise der SIP-Verkehr von VoIP-Telefonie eine höhere Priorität einräumen.
Doch immer häufiger setzen Administratoren statt einer Reihe vernetzter Geräte nur noch ein einziges Gerät pro Schreibtisch ein: meist ein Laptop oder sogar nur ein Tablet-PC mit einem Softphone. Gleichzeitig bewegen sich immer mehr Anwendungen von dedizierten Apps hin zur Integration in HTML und nutzen somit HTTP als bevorzugtes Transportmittel. Damit ist das bisherige Verfahren mit statischen ACL-Einträgen (Access Control List) unbrauchbar. Die Information zum IP-Port eines Pakets ist für Datenverkehr mit niedriger und hoher Priorität identisch und im HTTP-Verkehr über Port 80 verborgen. Die MAC-Adressen der Quellen sind ebenfalls identisch, da es keine Möglichkeit gibt, das VoIP-Telefon vom Laptop zu unterscheiden. Lösen könnte man das, indem man dem ToS- (Type of Service) und DSCP-Wert (Differentiated Services Code Point) des Pakets vertraut. Allerdings könnte hierbei Malware das Netzwerk gezielt mit fingiertem hochprioritärem Datenverkehr überschwemmen. Um festzustellen, welche speziellen Datenflüsse mit hoher Priorität zu behandeln sind, ist ein neuer Mechanismus erforderlich, der alle anderen Datenflüsse standardmäßig auf niedrige Priorität setzt. Der Einsatz von SDN mit hybriden Ports kann dieses Problem lösen.
Wie sieht der Anwendungsfall für SDN konkret aus? Als Beispiel lässt sich hier ein Anruf über Microsoft Lync heranziehen. Vereinfacht sieht der Anrufprozess folgendermaßen aus: Ein Anwender startet Lync via Web-Interface und ruft aus seiner Kontaktliste einen Kollegen an. Der Controller des Lync-Anrufs wandelt diese Kontaktinformation in eine IP-Adresse um und sendet diese zum Lync-Client auf dem Laptop. Der Controller lässt sich aber auch so konfigurieren, dass er diese Information an eine SDN-Anwendung sendet. Diese kommuniziert mit dem SDN-Controller und priorisiert bestimmte IP-Paare - beispielsweise eine hohe Priorität für den Lync-Anruf. Die SDN-Anwendung teilt dem SDN-Controller zugleich mit, dass der Verkehr über nicht überlastete Links zu führen ist. Der SDN-Controller legt den optimalen Openflow-Pfad fest und gibt die Informationen zum angepassten Datenfluss zusammen mit den dafür notwendigen Aktionen an jeden der Openflow-fähigen Switches weiter ("Push"). Nach Beenden des Anrufs "veralten" die Openflow-Einträge wegen Inaktivität, und die Ressourcen werden wieder für andere Anrufe oder anderen hochprioritären Datenverkehr freigegeben.
Rollenbasierte Ressourcenzuteilung
Das zweite Beispiel betrifft die rollenbasierte Ressourcenzuteilung: In den meisten Netzwerken ist für Anwender je nach Rolle innerhalb einer Organisation festgelegt, welche Rechte sie innerhalb des Netzwerks haben. Ein Standard zur Authentifizierung im Netzwerk ist das IEEE-802.1X-Protokoll. Allerdings kommen bei der Kommunikation zwischen Switch und Authentifizierungsdienst wie beispielsweise einem Radius-Server (Remote Authentication Dial-In User Service) oft herstellerspezifische Attribute (VSA, Vendor-Specific Attribute) zum Einsatz. Wenn sich die Fähigkeiten des Access-Gerätes ändern, ist also auch der Zugang zum Radius-Server zu aktualisieren. Andernfalls kann es vorkommen, dass Endanwender nicht authentifiziert werden. Oder, was erheblich folgenschwerer ist: Anwender werden authentifiziert, ohne dass die NAC-Software (Network Access Control) die individuell gültigen Sicherheitseinschränkungen mitliefert.
SDN und Openflow bieten hier ein hardware- und softwareunabhängiges Abstraktionsmodell für den Zugriff auf Ressourcen und deren Manipulation. Dieses Verfahren umgeht die produktspezifischen Funktionen und verwendet lediglich die Yes/No-Funktionen der Authentifizierung zwischen dem Anwender und der NAC-Anwendung. Sobald der Authentifizierungsprozess abgeschlossen ist, erreicht eine Nachricht die für die rollenbasierte Ressourcenzuteilung zuständige SDN-Anwendung. Diese Nachricht enthält die MAC-Adresse des Anwenders, seinen Zugangs-Port zum Netzwerk und seine Rolle. Die Anwendung vergleicht anschließend diese Rolle mit der zuvor konfigurierten Fähigkeitenliste, zum Beispiel: Wie viel Bandbreite erhält der Anwender für seinen Datenverkehr, welche IP-Adressen sind gesperrt?
Diese Fähigkeiten werden in eine Network Resource Message umgewandelt und an den SDN-Controller gesendet. Der SDN-Controller wiederum identifiziert das entsprechende Netzwerkgerät, an das die Openflow-Tabelle mit den entsprechend zugewiesenen Ressourcen (also Prioritätseinstellung für den Datenverkehr, Bandbreite für Datenflüsse) zusammen mit den Limits bezüglich Datenflüssen zu eingeschränkten Adressen zu senden ist. Diese Einstellungen werden dann auf dem Port des Access-Switches gesetzt, sobald der NAC-Server die Authentifizierung des Anwenders auf diesem Port abschließt.
Mit diesem Verfahren kann der Administrator das Peripheriegerät optimieren, ohne die Backend-Systeme anzufassen. Wenn das Peripheriegerät die gleiche Openflow-Revision unterstützt wie der SDN-Controller, ist jedes Update für die rollenbasierte SDN-Anwendung und das Backend völlig transparent. Sobald dem Anwender die Ressourcen zugewiesen sind, sind die standardmäßigen Paketverarbeitungs-Pipelines für das Switching und das Routing der Pakete durch das Netzwerk verwendbar. Die Openflow-Tabelle ermöglicht es, Paketen den Zutritt zum Netzwerk zu erlauben oder zu verweigern und Pakete für spezielle Ressourcen zu markieren. Für ausgewählte Anwender lässt sich die normale Pipeline auch umgehen und der Datenverkehr über bestimmte Ports leiten.
Für SDN ist aber noch eine große Zahl weiterer Anwendungsfälle umsetzbar, sei es die Implementierung eines vollständigen NAC-Systems mit SDN oder auch die Ressourcenverwaltung für Arbeitsgruppen, die sich dezidierte Netzwerk-Ressourcen teilen müssen.
Lesen Sie mehr zum Thema
