Mehr Raum für die Wissenschaft - Mitteilungen - DFN-Verein
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Deutsches Forschungsnetz | DFN Mitteilungen Ausgabe 91 | Mai 2017
www.dfn.de
Mitteilungen
Mehr Raum für die Wissenschaft
Die Initiative Eduroam off Campus
Das Domain Name System im X-WiN 10 Jahre DFN-AAI
Beständigkeit im Wandel Ein Universalschlüssel zum Erfolg
2 | DFN Mitteilungen Ausgabe 90 | November 2016 Impressum Herausgeber: Verein zur Förderung eines Deutschen Forschungsnetzes e. V. DFN-Verein Alexanderplatz 1, 10178 Berlin Tel.: 030 - 88 42 99 - 0 Fax: 030 - 88 42 99 - 370 Mail: dfn-verein@dfn.de Web: www.dfn.de ISSN 0177-6894 Redaktion: Nina Bark Gestaltung: Labor3 | www.labor3.com Druck: Druckerei Rüss, Potsdam © DFN-Verein 05/2017 Fotonachweis: Titel © studo58 / iStockphoto Seite 6/7 © SEASTOCK / iStockphoto Seite 40/41 © sephoto / photocase.de
DFN Mitteilungen Ausgabe 91 | 3
Dipl. Phys. Johann A. Ruppert
Bibliotheksdirektor i. R.
Ein Blick zurück und ein Wort des Dankes – der Anfang der DFN-AAI.
Anfang der 90er-Jahre hatten wir in der UB Freiburg ein Problem: Der Betrieb der Regionalen Daten-
bankinformation ReDI erforderte einen sicher authentifizierten Zugang um die lizenzpflichtigen
Inhalte der Verlage nur denen anzubieten, die auch Lizenzen zur Nutzung hatten. IP-Adresskont-
rolle war nicht sicher und Verlage und die teilnehmenden Einrichtungen in Baden-Württemberg
hatten alle unterschiedliche Zugangssysteme. Nur mit einem einheitlichen, möglichst internatio-
nal eingeführten System war dies lösbar. Unser Blick fiel auf Shibboleth, das zum damaligen Zeit-
punkt schon in einigen Ländern weltweit, u. a. auch in der Schweiz, etabliert war. Ein Förderantrag
beim BMBW wurde im Jahr 2005 bewilligt. Was lag näher, als ein Besuch in Zürich bei SWITCH, dort
lief das System schon seit einiger Zeit. Bei diesem Besuch wurde uns klar, dass wir eine lokale Ein-
führung des Systems für einzelne Systeme wohl kaum realisieren könnten: Eine nationale Föde-
ration als Grundlage des Authentifizierungsdienstes benötigte auch einen nationalen Mitspieler.
Nach dem Vorbild der Schweiz fragten wir beim DFN-Verein an und fanden ein offenes Ohr. Ein ge-
meinsames Projekt wurde Mitte des Jahres 2005 definiert. Die UB übernahm den technischen Teil
der Implementierung, der DFN-Verein die vertraglichen Arbeiten zum Aufbau der Föderation. Mar-
keting und Schulungen wurden gemeinsam angegangen. Fortan reisten Ulrich Kähler und ich zu
Universitäten und Forschungseinrichtungen und trommelten für die Föderation und Shibboleth.
Im Kielwasser kam Bernd Oberknapp mit seinem Team Hannah Born, Franck Borel und Jochen
Lienhard und bot Schulungen zur Implementierung des Systems an. Als größtes Hemmnis erwies
sich an vielen Orten ein unzureichendes Identity Management System.
Parallel dazu wurde vom Einkaufskonsortium der Bibliotheken Baden-Württembergs mit den Ver-
lagen verhandelt und die Einführung von Shibboleth zunächst empfohlen und später vertraglich
festgeschrieben. Damit stieg die Motivation bei allen Teilnehmern, bei der DFN-AAI mitzumachen.
Schon 2 Jahre nach dem gemeinsamen Projektstart, als die DFN-AAI im Herbst 2007 den Produktiv-
betrieb aufnahm, waren 14 Einrichtungen und 4 internationale Verlage aktiv dabei.
Rückblickend war dieses gemeinsame Projekt mit dem DFN-Verein für mich das spannendste,
schönste und erfolgreichste Projekt meiner Dienstzeit. Ich möchte allen Beteiligten – auch den
hier nicht genannten – ganz herzlich für die Zusammenarbeit in dieser Aufbauphase danken. Zehn
Jahre nach dem Start ist die DFN-AAI heute eine nicht mehr wegzudenkende Institution und ich
wünsche allen weiterhin viel Erfolg.
Ato Ruppert
4 | DFN Mitteilungen Ausgabe 91 | Mai 2017
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
Unsere Autoren dieser Ausgabe im Überblick
1 Henry Kluge, DFN-Verein (kluge@dfn.de); 2 Dr. Stefan Piger, DFN-Verein (piger@
dfn.de); 3 Christian Meyer, DFN-Verein (cmeyer@dfn.de); 4 Torsten Kersting, DFN-
Verein (kersting@dfn.de); 5 Prof. Dr. Helmut Reiser, Leibniz-Rechenzentrum-LRZ
(helmut.reiser@lrz.de); 6 Rolf Borgeest, Landesamt für Digitalisierung, Breitband
und Vermessung (rolf.borgeest@ldbv.bayern.de); 7 Dr. Leonie Schäfer, DFN-Verein
(schaefer@dfn.de); 8 Helga Spitaler (GÉANT), helga.spitaler@geant.org; 9 Audrey
Gerber (Inter-University Computation Center); 10 Dr. Jakob Tendel, DFN-Verein
(tendel@dfn.de) 11 Wolfgang Pempe, DFN-Verein (pempe@dfn.de); 12 Detlef
Krummel, Georg-Eckert-Institut (krummel@gei.de); 13 Susanne Weinmann,
Max-Planck-Gesellschaft (susanne.weinmann@gv.mpg.de); 14 Jens Syckor, TU
Dresden (jens.syckor@tu-dresden.de); 15 Florian Klein, Forschungsstelle Recht
im DFN (recht@dfn.de); 16 Lennart Sydow, Forschungsstelle Recht im DFN
(recht@dfn.de)
DFN Mitteilungen Ausgabe 91 | 5
Inhalt
Wissenschaftsnetz Sicherheit
Beständigkeit im Wandel – das Domain Name 10 Jahre DFN-AAI – ein Universalschlüssel
System im X-WiN zum Erfolg
von Henry Kluge ............................................................................... 8 von Wolfgang Pempe ................................................................... 42
Der Erneuerung letzter Akt: Sicherheit durch Clientmanagementsysteme
Eine neue Aggregations-Plattform für das X-WiN am von Beispiel OPSI & Communityprojekt
von Stefan Piger ............................................................................. 14 ‚opsi4institutes‘ (o4i)
von Detlef Krummel ..................................................................... 48
DFNFernsprechen: Die Zukunft ist IP
von Christian Meyer ..................................................................... 20 Windows 10 – wie man die Datenkrake bändigt
von Susanne Weinmann, Jens Syckor .................................... 54
Einfach sicher Abstimmen:
DFN-Terminplaner jetzt auch mit DFN-AAI Sicherheit aktuell .......................................................................... 57
von Torsten Kersting .................................................................... 24
Eduroam off Campus und BayernWLAN – eine Recht
Win-win-Kooperation
von Helmut Reiser, Rolf Borgeest ............................................ 26 Wo ein Wille ist, darf auch ein Link sein
. von Florian Klein ............................................................................ 58
International Meldung machen!
von Lennart Sydow ....................................................................... 61
GÉANT weiterhin auf Erfolgskurs
von Leonie Schäfer......................................................................... 32
DFN-Verein
Breakneck Network speed to deliver new
energy paradigms Übersicht über die Mitgliedseinrichtungen
von Helga Spitaler, Audrey Gerber .......................................... 34 und Organe des DFN-Vereins .................................................... 64
Kurzmeldungen ............................................................................. 36
Forschung
GeRDI - Generic Research Data Infrastructure:
Forschungsdaten übergreifend vernetzen
von Jakob Tendel ............................................................................ 38
6 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | WISSENSCHAFTSNETZ
WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 91 | 7 Wissenschaftsnetz Beständigkeit im Wandel – das Domain Name System im X-WiN von Henry Kluge Der Erneuerung letzter Akt: Eine neue Aggregations-Plattform für das X-WiN von Stefan Piger DFNFernsprechen: Die Zukunft ist IP von Christian Meyer Einfach sicher Abstimmen: DFN-Terminplaner jetzt auch mit DFN-AAI von Torsten Kersting Eduroam off Campus und BayernWLAN – eine Win-win-Kooperation von Helmut Reiser, Rolf Borgeest
8 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | WISSENSCHAFTSNETZ Beständigkeit im Wandel – das Domain Name System im X-WiN Das Domain Name System (DNS) ist wohl unbestreitbar einer der wichtigsten Dienste in IP-basierten Netzwerken. Nicht nur für die Übersetzung der Domainnamen in IP-Ad- ressen beim Aufruf von Webseiten oder bei der E-Mail-Kommunikation, sondern eben- falls für die Vermittlung von VoIP-Anrufen und für Verzeichnisdienste wie Microsofts Active Directory ist die Funktionsfähigkeit des DNS eine zwingende Voraussetzung. Diese Abhängigkeit von der DNS-Infrastruktur ist den wenigsten Anwendern und auch nicht allen IT-Verantwortlichen so deutlich bewusst, da der Umgang mit den vom DNS bereitgestellten „human-readable“ Namen als selbstverständlich angesehen wird. Text: Henry Kluge (DFN-Verein) Foto © cinoby / iStockphoto
WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 91 | 9
Motivation – warum?
Im aktuellen X-WiN und den Vorgängerge-
nerationen des Wissenschaftsnetzes spiel-
te das Domain Name System schon immer
eine große Rolle, auch wenn es anders als
andere Dienste nie im direkten Rampen-
licht stand. Neben der Anmeldung und Ver-
waltung von Domains im Rahmen des DFN-
Internet-Dienstes betreibt der DFN-Verein
schon seit vielen Jahren eine DNS-Serverin-
frastruktur. Mittels dieser Server wird An-
wendern die Möglichkeit gegeben, die von
ihnen auf den eigenen primären Systemen
verwalteten DNS-Domains bzw. Zonen über
sogenannte Secondary Name Server hoch-
verfügbar abzusichern. Als weitere Dienst-
Secondary NS
leistung werden im X-WiN Recursive Na-
meserver angeboten.
Recursive NS
2015 war für den DFN-
Abbildung 1: DNS-Infrastruktur im X-WiN im Jahr 2015
Verein der Zeitpunkt
gekommen, sich mit der Leistung grundsätzlich noch ausreichend die vollständige Unterstützung von IPv6
DNS-Infrastruktur neu waren, so ist doch trotz vorhandener War- und DNSSEC sowie die komplette Trennung
auseinanderzusetzen. tungsverträge ein Ende der Lebenszeit die- der autoritativen und rekursiven Funktio-
ser soliden und bewährten Systeme abseh- nen. Der letzte Punkt ist insbesondere bei
bar. Viel stärker machte sich jedoch ein der standardkonformen Implementierung
Diese, auch als DNS Cache Server oder Re- Nachteil der ursprünglich sehr sinnvollen von DNSSEC wichtig, da sonst „lokal“ ge-
solver bekannten Systeme, ermöglichen Verteilung von insgesamt 14 DNS-Servern in haltene Zonen nicht durch den Recursor
eine direkte Abfrage von DNS-Informati- der Fläche bemerkbar (siehe Abbildung 1). validiert werden können.
onen. Auch wenn die DNS-Grundstruktur
über die letzten Jahrzehnte sehr stabil war, Zielarchitektur – wohin?
Eine Konsolidierung der
ist es wie bei anderen Diensten notwen-
dig und sinnvoll, die aktuelle Implementie- DNS-Infrastruktur sollte Nach einer umfassenden Analyse der Aus-
rung in einem sich verändernden Umfeld angegangen werden. gangslage wurde eine Architektur entwi-
zu prüfen und auf neue Anforderungen zu ckelt, die sowohl die bekannten Anforde-
reagieren. Im Jahr 2015 war für den DFN- Bei hochvolumigen Amplification-Angriffen rungen berücksichtigt als auch auf zukünf-
Verein der Zeitpunkt gekommen, sich mit auf DNS-Server in der äußeren Peripherie tige Ansprüche vorbereitet ist.
dieser Fragestellung auseinanderzusetzen. kam es zu spürbaren Beeinträchtigungen
von Anwendern, deren Datenverkehr über Zur Sicherstellung der im folgenden auf-
Ausgangslage – woher? die gleiche Router-Kette geführt wurde, geführten Ziele wurden Eckpunkte für ei-
da auf dieser durch den Angriffsverkehr ne Umsetzung definiert:
Konkrete Auslöser für die Beschäftigung nicht mehr die volle Netzwerkbandbreite 1. Vereinfachung von Betrieb und
mit diesem Thema waren zum einen die zur Verfügung stand. Darüber hinaus sind Administration durch Reduktion
in die Jahre gekommene Server-Hardware in der derzeit genutzten Server-Hardware der Serverinstanzen.
der DNS-Server und zum anderen die deut- nur Netzwerkschnittstellen mit 1 Gbit/s
liche Zunahme an DoS-Vorfällen, auch auf einsetzbar. Weitere Themen, die mit ei- Nur noch 3 Secondary
DNS-Infrastrukturen. Auch wenn die vor- ner Konsolidierung der DNS-Infrastruk- Server und 3 Recursive
rangig genutzten SUN T1000 Server von der tur angegangen werden sollten, waren Name Server.
10 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | WISSENSCHAFTSNETZ
trieb bewiesene Stabilität und Robustheit
des Gesamtsystems zu erhalten. Gerade
beim Einsatz einer Virtualisierung im DNS-
Umfeld gab es im DFN-Verein noch keine
praktischen Erfahrungen und somit einen
notwendigen Klärungsbedarf zur techni-
schen Umsetzbarkeit. Aus diesem Grund
war es besonders wichtig der Umsetzungs-
phase einen angemessenen Vorbereitungs-
und Testzeitraum voranzustellen.
Vorbereitung – wie?
Neben den rein technischen Fragestellun-
gen, wie z. B. welche Hard- und Software-
Plattform notwendig und sinnvoll einsetz-
bar ist, wurden ebenfalls die betrieblichen
Secondary NS Abläufe und eingesetzten Tools auf den
Prüfstand gestellt. Hier war es unter ande-
Recursive NS rem das Ziel, durch den Einsatz von Konfi-
gurationswerkzeugen wie „Ansible“, eine
Abbildung 2: Zielarchitektur DNS-Infrastruktur im X-WiN
standardisierte und flexibel anpassbare
Dienstumgebung für die DNS-Infrastruk-
tur bereitzustellen. Auch ein zentrales Re-
2. Sicherstellung eines langfristigen ner Infrastruktur präsent zu sein. Bei der pository für alle verwalteten Secondary-
Supports durch einheitliche HW- und Auswahl der DFN-Serverstandorte konn- Zonen, zurzeit mehr als 18.000 Zone Files,
SW-Plattform. te dieser Kernnetzknoten allerdings nicht sollte in diesem Zuge eingeführt werden.
berücksichtigt werden, da ein wirtschaftli-
Betrieb als Virtual Machines (VM)
cher Serverbetrieb von eigener Hardware Die Rahmenparameter zur konkreten Um-
auf der Server-Infrastruktur des
in kommerziellen Collocations, wie in die- setzung auf der HW-Ebene wurden durch
DFN-Vereins an dafür ausge-
sem Fall bei der Firma interxion, für den die eingesetzte DELL-Blade-Server Umge-
wiesenen Serverstandorten.
DFN-Verein nicht darstellbar war. bung grundsätzlich definiert. Pro Server
3. Erhöhung der Stabilität und Sicher- standort wurden exklusiv für die Nutzung
heit durch Trennung von Funktionen. Grundsätzlich ist es bei Bedarf jedoch re- durch DNS-Dienste initial jeweils zwei DELL
lativ einfach möglich, durch die Nutzung M630-Blade-Module (2 x Intel Xeon E5-2620,
Separierung von Authoritative
der Virtualisierung, sowohl an den defi- 24 GB RAM) und 10 Gbit/s Interfaces vor-
Name Server und Recursive
nierten Serverstandorten als auch an an- gesehen und beschafft. Für die Virtuali-
Name Server.
deren SuperCore-Standorten, die Anzahl sierung wird die auch für andere Diens-
4. Besserer Schutz vor DoS-Vorfällen der Instanzen zu erhöhen. In diesem Zu- te im DFN-Verein standardmäßig verwen-
durch optimale Platzierung im X-WiN. sammenhang wird vom DFN-Verein auch dete Kernel-Based Virtual Machine (KVM)
die Weiterentwicklung der „klassischen“ Architektur auf einem Linux-Hostsystem
Anbindung per 10 Gbit/s an den Router zu Systemen mit erweiterten netz- eingesetzt.
Standorten Erlangen, Hannover nahen Funktionen im Auge behalten. Bes-
und Berlin in direkter Nähe zur tes Beispiel für die erfolgreiche Nutzung Bei der Auswahl der eigentlichen DNS-Ser-
DoS-Mitigations-Infrastruktur. solcher Konzepte sind die Virtual Service ver Software wurden alternative Lösungen
Module (VSM) in den SuperCore-Routern für die Implementierung der DNS-Funkti-
Aus reiner DNS-Perspektive wäre es mit für die Realisierung des DoS-Schutzes im onen wie z. B. PowerDNS, unbound und
dem besonderen Fokus auf die Verbindun- Wissenschaftsnetz. Knot geprüft, allerdings zugunsten des ISC
gen in die „Außenwelt“ natürlich beson- BIND verworfen. Hauptgründe hierfür wa-
ders wünschenswert auch an dem „Pee- Als wichtigste Anforderung an die neue Um- ren die guten jahrelangen Erfahrungen mit
ring-Standort“ Frankfurt/M. (FRA) mit ei- gebung galt es jedoch, die im täglichen Be- ISC BIND im DFN-Verein und der erwarte-WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 91 | 11
te Mehraufwand für die Einführung eines Mit der Definition der Systemumgebung 2. Migration aller weiteren DNS-Ser-
neuen Produkts inklusive des damit ver- und dem Nachweis der Leistungsfähigkeit ver Virtual Machines auf die neue
bundenen potenziellen Stabilitätsrisikos. waren die Grundlagen für die Planung und Serverinfrastruktur.
Weiterhin bestand aufgrund der bekann- Umsetzung der einzelnen Phasen einer 3. Konsolidierung aller Secondary-
ten und prognostizierten Performancean- Konsolidierung der DNS-Infrastruktur im Zonen auf die DNS-Server DNS-1,
forderungen keine Notwendigkeit spezi- X-WiN gegeben. DNS-2 und DNS-3.
alisierte und auf einzelne Funktionen op-
timierte Softwarelösungen einzusetzen. Umsetzungsphase – Phase 1 – Etablierung der ersten DNS-
Durch die strikte Funktionstrennung ist a long run ... Server als virtuelle Instanzen
der Austausch einzelner Server bei zukünf- Oberstes Ziel dieser ersten Phase war es,
tigen und unter Umständen höheren An- Die nächste große Herausforderung inner- die während der Tests gesammelten Er-
forderungen problemlos möglich. halb des Gesamtprojekts war nun die Auf- fahrungen unter Produktionsbedingungen
stellung eines Migrationsplans, der die Um- zu bestätigen und eventuell notwendigen
Neben der bereits oben erwähnten Robust- setzung der angestrebten Ziele in kurzer Änderungsbedarf zu identifizieren. Hier-
heit des Gesamtsystems gegenüber DoS- Zeit ermöglichte, ohne aber für die Nutzer für wurde als Pilot die DNS-Recursor Funk-
Vorfällen stand der Einsatz der im Folgen- der DNS-Dienste spürbare negative Aus- tionalität des Servers DNS-3 in eine sepa-
den aufgeführten spezifischen Sicherheits- wirkung zu haben. rate VM als RES-3 unter Beibehaltung der
funktionen im Fokus: IP-Konfiguration am Standort Erlangen
Dieser Gesamtplan wurde zunächst in 3 migriert. Trotz einiger kleiner Fehler, die
• Minimal-Installation und Härtung Hauptphasen unterteilt: schnell behoben werden konnten, verlief
des Betriebssystems, die Migration weitestgehend reibungslos
• Separierung von Produktions – und 1. Migration der Funktionalitäten der und wie erwartet.
Management-Interfaces, vorhandenen DNS-Server DNS-1,
• Einsatz von Host-ACL auf jedem DNS-2 und DNS-3 in Virtual Machines Als nächster Schritt stand die VM-Migration
System, der neuen Serverinfrastruktur. des autoritativen Teils (Secondary Zones)
• Einsatz eines separaten Build-
Systems zur Erstellung der
BIND-SW-Pakete,
• Einsatz spezifischer BIND Funktio-
nen wie z. B. Response Rate Limiting
[BIND RRL].
Zum Abschluss der Vorbereitungsphase
wurden in einer Testumgebung unter
Nutzung der vorgesehenen Hardware
umfangreiche betriebliche und funktio-
nale Tests durchgeführt. Auch ein finaler
Performancetest mit der frei verfügba-
ren Testsoftware DNSPerf der Firma No-
minum [DNSPerf] zeigte die volle Einsatz-
fähigkeit innerhalb einer Virtual Machine-
Umgebung. Selbst die in der Testumgebung
generierten Anfrageraten von mehreren
hunderttausend DNS-Requests pro Sekun-
de führten zu keinerlei Einschränkungen Secondary NS
bei der mittleren Antwortzeit oder der
Stabilität der Systeme. Diese Ergebnisse
Recursive NS
liegen um den Faktor 100 über der maxi-
mal erwarteten Belastung unter norma-
len Produktionsbedingungen.
Abbildung 3: Umsetzung DNS-Konsolidierung Phase 112 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | WISSENSCHAFTSNETZ
des DNS-3 an. Auch hier wurde die Funk-
STANDARDABLAUF DER MIGRATION VON DOMAINS/ tionsfähigkeit des Systems in der neuen
Umgebung innerhalb des geplanten War-
ZONES AUF SECONDARY NAME SERVER tungsfensters vollständig hergestellt. Nach
der Einbindung in die Monitoring-Umge-
ʃʃ Information zur Migration durch DFN-Verein per E-Mail an
bung wurden die beiden Systeme inten-
zuständigen Zonen-Admin beim Anwender:
siv auf eventuelle Auffälligkeiten und
• Listung der betroffenen Domains und der zukünftigen Abweichungen zur vorherigen Betriebs
Secondary Name Server umgebung geprüft.
ʃʃ Freischaltung des Zonentransfers für die neuen DNS-Server auf
Nachdem sichergestellt war, dass alle DNS-
dem Primary Server:
Funktionen auf den Servern DNS-3 und RES-
• Info an hostmaster@dfn.de 3 ohne Einschränkung verfügbar waren,
wurden die verbleibenden Umzüge der
ʃʃ Konfigurieren des neuen Secondary Servers:
Authoritativen Server DNS-1 und DNS-2
• Info an Anwender sowie der DNS-Recursor RES-1 und RES-
2 durchgeführt. Die erwartete Stabilität
ʃʃ Anpassung des Zonenfiles auf dem Primary Server:
und Performance konnte auch für diese
• alte NS-Records entfernen Server von Beginn an vollständig erbracht
• neue NS-Records (DNS-1, DNS-2 oder DNS-3) einfügen werden und somit die erste Phase erfolg-
reich abgeschlossen werden (siehe Abbil-
ʃʃ Anpassung der Delegierung (NS-Records) in den übergeordneten
dung 3, S. 11).
Zonen durch den DFN-Verein.
ʃʃ Abschließende Prüfung der Funktionalität (Zonentransfer, Phase 2 – vollständiger Umzug in die
erfolgreiche Auflösung etc.). Virtual Machine Umgebung
Inhalt der zweiten Phase ist die Migration
ʃʃ Weiterbetrieb der Zone auf den alten DNS-Servern für noch der restlichen 10 DNS-Server in die VM-Um-
mindestens eine TTL wegen Ausaltern der Cachings auf externen gebung (siehe Abbildung 4). Hier ist neben
Recursor/Cache-Servern. der Außerbetriebnahme der SUN-Server die
Vorbereitung zur Übernahme der Seconda-
Die Detailinformationen (IP-Adressen, Hostname, Standorte) zu den für
ry Zonen auf die DNS-Server DNS-1, DNS-2
Anwender des DFNInternet-Dienstes nutzbaren Secondary Name Servern
und DNS-3 das Hauptziel. Die Verteilung
und Recursor/Cache-Servern können über die E-Mail-Adresse hostmaster@
der VM-Umgebung auf nur 3 Serverstand-
dfn.de oder per Telefon unter +49 30 884299 9910 angefragt werden.
orte stellt hier eine zusätzliche Herausfor-
derung dar. In der bisherigen Konstellati-
on wurden viele Domains auf geografisch
verteilten DNS-Servern abgestützt. Für die-
EINSTELLUNG VON FUNKTIONEN UND SERVICES se musste sichergestellt werden, dass sie
auf unterschiedliche VM migriert werden,
Die folgend aufgeführten Funktionen und Services werden aufgrund
dann aber nicht im selben Serverstandort
der Konsolidierung zum aufgeführten Zeitpunkt eingestellt:
betrieben werden. Zusätzlich erzeugte die
ʃʃ Backup-MX-Funktionalität zum Spooling von E-Mails hohe Anzahl von Domains durch diese Rah-
menbedingung einen nicht zu vernachläs-
• Einstellung mit der Außerbetriebnahme der DNS-Server sigenden Aufwand.
ab 30.06.2017 bis spätestens 30.06.2018
ʃʃ Smarthost bzw. SMTP-Relay-Server zur Weiterleitung von E-Mails Da diese DNS-Server zum überwiegenden
Teil mit hostspezifischen Parametern kon-
• Einstellung zum 30.06.2018 figuriert sind und nur eine kurze weitere
• es erfolgt eine separate Kontaktierung der Nutzer zur Abstimmung „Lebenszeit“ haben werden, wird dessen
eines Zeitplans bezüglich der Umstellung Konfiguration weitestgehend 1 : 1 auf der
VM abgebildet. Hier kommt aus Migrations-WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 91 | 13
Secondary NS
Recursive NS
Abbildung 4: Umsetzung DNS-Konsolidierung Phase 2
sicht erschwerend hinzu, dass auch noch Standardablauf die genutzten Secondary- form zusammenhängt (siehe auch Artikel
weitere nicht DNS-spezifische Funktionen Server umzustellen (siehe blauer Kasten). S. 14), soll diese Phase bis zum 30.06.2017
und Services auf den Systemen laufen. Die- abgeschlossen sein.
se nicht vertraglich definierten Dienste Da diese Umstellungen unabhängig von
werden im Rahmen der Migration einge- der VM-Migration der DNS-Server durchge- Aus Sicht der Anwender ist die dritte Phase
stellt (siehe oranger Kasten). führt werden können, wurde damit bereits besonders relevant, da sie direkt davon be-
im Oktober 2016 begonnen. Hier konnten troffen sind. Für die vollständige Migration
Phase 3 – Migration aller Secondary dank der aktiven Mitarbeit der Anwender aller Secondary-Zones auf die verbleiben-
Zones zum Sollzustand mehrere tausend Zonen in die neue Um- den DNS-Server DNS-1, DNS-2 und DNS-3 ist
In der abschließenden dritten Phase er- gebung umgezogen werden. der 30.06.2018 als Zieldatum festgesetzt.
folgt der Umzug aller auf den in der zwei- Deshalb an dieser Stelle der Aufruf zur
ten Phase migrierten DNS-Servern konfigu- Status, Zeitplanung Kenntnisnahme dieser „Deadline“ und der
rierten Secondary Zones auf die DNS-Ser- und (vorläufiges) Fazit – damit verbundenen Bitte zur Unterstüt-
ver DNS-1, DNS-2 und DNS-3 und damit die wie lange noch? zung der Migration, um auch in Zukunft
Herstellung des Zielzustands. Dieser Teil dem DFN-Verein die effiziente und quali-
der Migration ist aus operativer Sicht wei- Mit dem Erscheinen dieser Ausgabe der tativ hochwertige Erbringung von DNS-
testgehend unkritisch, jedoch administra- DFN-Mitteilungen befindet sich die Konso- Diensten im Sinne einer „Beständigkeit
tiv und zeitlich mit dem größten Aufwand lidierung der DNS-Infrastruktur im X-WiN im Wandel“ zu ermöglichen. M
verbunden. Als Standardverfahren ist vor- mitten in der zweiten Phase, also der Virtu-
gesehen, die zuständigen Verwalter der alisierung der SUN-Systeme. Nach aktueller
betroffenen Domains einzeln und gezielt Zeitplanung, die auch direkt mit dem Pro-
per E-Mail zu kontaktieren und nach einem jekt zur Migration der Aggregationsplatt-
Links & Quellen
[BIND RRL] ISC Knowledge Base - https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html
[DNSPerf] Nominum DNSPerf - http://www.nominum.com/measurement-tools/14 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | WISSENSCHAFTSNETZ Der Erneuerung letzter Akt: Eine neue Aggregations- Plattform für das X-WiN Die Runderneuerung des X-WiN geht in die letzte Phase. Nach der Modernisierung der DWDM-Technik für die Optische-Plattform und der Router des IP-SuperCore werden nun als vorerst letzter Schritt die Router der IP-Aggregations-Plattform ausgetauscht. Text: Stefan Piger (DFN-Verein) Foto © nesharm / iStockphoto
WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 91 | 15
Die Aggregations-Router stellen für die große Mehr- Um unkontrollierte Speicherüberläufe und damit den
heit der Teilnehmer am DFNInternet-Dienst die Schnitt- Verlust von Routen zu vermeiden, wurden durch das
stelle zwischen ihrer Teilnehmeranbindung und dem DFN-NOC ab diesem Zeitpunkt die Zahl der Routen
Kernnetz des X-WiN dar. Wie der Name „Aggregations- auf den Aggregations-Routern reduziert. Hierfür wur-
Plattform“ bereits suggeriert, nehmen diese Router als den nur noch die vollständigen Routing-Informatio-
wesentliche Aufgabe die Bündelung der Teilnehmer- nen des X-WiN und seiner Teilnehmer sowie die der
Verkehre in Richtung des X-WiN Kernnetz wahr. Dane- globalen NREN-Community vorgehalten, um für die-
ben stellen sie Layer-2- und Layer-3-VPN-Infrastruktu- se Ziele weiterhin ein optimales Routing zu ermögli-
ren bereit und dienen als lokale Ethernet-Switches. chen. Alle weiteren spezifischen Routen über die IP-
Upstreams wurden nur noch auf den Systemen des
Die derzeitige Aggregations-Plattform wurde in den SuperCore vorgehalten und den Aggregations-Syste-
Jahren 2005 – 2008 mit mehr als 50 Geräten vom Typ Cis- men per Default-Route annonciert. Für einzelne An-
co 7609 und 7609-S ausgestattet und seitdem nur wenig wender, die eine volle Routing-Tabelle benötigten, war
verändert betrieben. Da der Hersteller für diese Sys- es möglich, mit dem punktuellen Einsatz von Aggre-
teme absehbar keine technische Unterstützung oder gations-Systemen mit neueren Route-Prozessoren
Aktualisierungen der Betriebssoftware mehr gewähr- (RSP720), diese Anforderung zu erfüllen.
leistet, müssen die Geräte nun ausgetauscht werden.
Ein weitaus gravierenderes Problem entstand durch
Der Auslöser für die Modernisierung zum jetzigen Zeit- das vermehrte Aufkommen volumetrischer Distributed-
punkt ist somit in erster Linie die Aufrechterhaltung Denial-of-Service (DoS) Vorfälle, die Zielsysteme durch
der betrieblichen Sicherheit des X-WiN. Darüber hin- Überfluten mit großen Mengen von IP-Verkehr für le-
aus bietet sich aber auch die Chance, die Leistungsfä- gitime Nutzer unerreichbar machen.
higkeit der Aggregations-Plattform sowohl funktio
nal als auch in Bezug auf die Übertragungskapazität In der aktuellen Architektur des X-WiN IP-Backbone
signifikant zu erhöhen und damit das X-WiN für neue werden diese Angriffe ohne Beschränkungen in der
Herausforderungen zu rüsten. genutzten Datenrate bis zum Übergang von der Aggre
gations-Plattform zur Teilnehmeranbindung weiterge-
Neue Architektur der IP-Plattform leitet. Dort wird schließlich der Verkehr auf die Band-
des X-WiN breite entsprechend der gewählten DFNInternet-
Die Notwendigkeit, die Aggregations-Plattform zu mo-
dernisieren, bot auch die Gelegenheit, die Architektur
der derzeitigen IP-Plattform des X-WiN zu überdenken
und sie an die aktuellen Erfordernisse anzupassen.
DUI HAN
So wurde mit der Einführung des X-WiN dessen IP-
Backbone mit voller Internet Routing Tabelle an je-
dem Kernnetzknoten betrieben. Dadurch konnten
lokal auf jedem System der Aggregations-Plattform
DFNInternet-Dienste und zudem auf Wunsch des Teil-
nehmers immer auch die komplette globale Internet
Routing Tabelle bereitgestellt werden. DUI
Dieses Konzept musste bereits im Laufe des Jahres
2013 an vielen Standorten aufgeweicht werden, da die
KR BON BIR
Internet Routing Tabelle absehbar auf über 512.000 FRA
IPv4-Routen anwachsen würde und diese nicht mehr
vollständig in den eingesetzten Systemen vom Typ Kernnetz (100 Gbit/s) Teilnehmeranbindung (physisch)
Cisco 7609 abbildbar sein würde. Kernnetz (20 Gbit/s)
Abbildung 1: Architektur von DFNInternet-Teilnehmeranbindungen im X-WiN – heute16 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | WISSENSCHAFTSNETZ
Kategorie beschränkt. Dies kann bei entsprechendem Volumen
des Angriffs die Ketten der Aggregations-Plattform überlasten
und damit auch weitere, nicht direkt angegriffene Anwender
stark beeinträchtigen. Im X-WiN wurden bereits DoS-Vorfälle mit DUI HAN
Datenraten beobachtet, die die typische Dimensionierung der
Anbindungen von Aggregations-Systemen in den X-WiN Ketten
von 10 – 20 Gbit/s weit überschritten.
Zur Verdeutlichung des Problems soll hier ein Ausschnitt aus
dem X-WiN IP-Backbone mit einem exemplarischen Teilnehmer
herangezogen werden (vgl. Abbildung 1).
DUI
Dargestellt ist ein Teilnehmer, der an den X-WiN Kernnetzkno-
ten an der Universität Duisburg-Essen (DUI) und an der Univer-
sität Bonn (BON) angebunden ist. An diesen Kernnetzknoten KR BON BIR FRA
wird auch der DFNInternet-Dienst bereitgestellt. Die Router der
Aggregations-Plattform in den Kernnetzknoten DUI und BON Kernnetz (100 Gbit/s) Teilnehmeranbindung (physisch)
wiederum sind in einer Kette mit einer Kapazität von 20 Gbit/s Kernnetz (20 Gbit/s) Teilnehmeranbindung (logisch)
mit dem Router am Kernnetzknoten BIR angebunden. Die Ket-
te terminiert am IP-SuperCore an den Kernnetzknoten DUI und Abbildung 2: Architektur von DFNInternet-Teilnehmeranbindungen im
FRA. Im SuperCore stehen Bandbreiten von 100 – 200 Gbit/s je X-WiN – künftig
Spange zur Verfügung.
Durch die Verlagerung der IP-Übergabeschnittstelle auf die leis-
Wird nun auf den dargestellten Teilnehmer ein DoS-Angriff ausge- tungsfähigen SuperCore Router können alle Teilnehmer am DFN-
führt, der über den Knoten FRA aus dem SuperCore in die Aggre- Internet-Dienst künftig die volle Internet Routing Tabelle erhalten.
gations-Plattform geleitet wird, so traversiert dieser Angriffsver-
kehr erst den Kernnetzknoten BIR bevor er am Kernnetzknoten Auch werden in Richtung Teilnehmer fließende Verkehre künf-
BON auf die Teilnehmeranbindung geleitet wird. Hat der Angriffs- tig am Übergang vom SuperCore in die Ketten der Aggregations-
verkehr eine Datenrate größer als die aktuell freie Übertragungs- Plattform auf die Datenrate der durch den Teilnehmer gewähl-
kapazität auf der Strecke FRA-BIR-BON, so beeinträchtigt er die ten DFNInternet-Kategorie beschränkt. Dadurch wird eine Über-
Qualität aller DFNInternet-Dienste, die an diesen Kernnetzkno- lastung der jeweiligen Kette durch DoS-Vorfälle auf einen Teil-
ten terminieren. Diese Einschränkung bleibt bestehen, bis das nehmer effektiv verhindert.
DFN-NOC geeignete Gegenmaßnahmen einleiten kann oder der
Angriff beendet wird. Die neue Architektur erzeugt gegenüber dem aktuellen Modell
allerdings auch Mehraufwände insbesondere bei der initialen
Die zukünftige Architektur der IP-Plattform des X-WiN muss nun Konfiguration von DFNInternet-Diensten und beim Fehlerma-
die dargestellten Probleme adressieren, ohne für die Teilneh- nagement. Diese Mehraufwände konnten jedoch durch eine ver-
mer am DFNInternet-Dienst signifikante Einschränkungen nach stärkte Automatisierung von Konfigurationsvorgängen auf ein
sich zu ziehen. beherrschbares Maß beschränkt werden.
Die grundlegende Änderung betrifft den Ort, an dem DFNInter- Weiterhin erzeugt die neue Architektur geringfügige zusätzliche
net-Dienste realisiert werden. Künftig werden diese nicht mehr Latenzen bei Kommunikationsbeziehungen zwischen Anwendern
lokal auf dem Aggregations-Router konfiguriert, sondern direkt in der gleichen Aggregations-Kette. Verursacht wird dies durch den
auf den Router-Systemen des SuperCore. Dazu wird der Verkehr zusätzlichen Weg, den jedes IP-Paket zum nächsten SuperCore-
des jeweiligen DFNInternet-Dienstes zwischen dem die Teilneh- Router und wieder zurücknehmen muss. Die Auswirkungen dieses
meranbindung terminierenden Aggregations-Router und dem Effekts werden allerdings durch den in 2015 erfolgten Ausbau des
den jeweiligen DFNInternet-Dienst erbringenden SuperCore- SuperCore von vier auf acht Router-Systeme und der damit einherge-
Router in einem Tunnel (IP/MPLS Pseudowire) geführt. Auf dem henden Verkürzung der Aggregations-Ketten deutlich abgemildert.
SuperCore-Router wird er dann auf einer logischen Schnittstel- Um diese Verbesserung optimal nutzen zu können, sollten
le (sog. Pseudowire Headend) terminiert und nachfolgend glo- alle doppelt angebundenen Teilnehmer die beiden Verbindun-
bal geroutet (Abbildung 2). gen ihrer Teilnehmeranbindung in einer aktiv/aktiv KonfiguraWISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 91 | 17
Foto © alexey_ds / iStockphoto
tion nutzen. Beratungen und Dokumentationen zu Unverändert sollten die neuen Systeme Funktionen
evtl. erforderlichen Umstellungen bietet das DFN- und Technologien bereitstellen, mit denen die für die
NOC an. zukünftige Architektur von Teilnehmeranbindungen
notwendigen Layer-2-Kanäle als auch VPN-Infrastruk-
Insgesamt erwartet der DFN-Verein, dass die neue turen auf Layer-2 und Layer-3 für die Teilnehmer am
Architektur den IP-Backbone des X-WiN und insbe- X-WiN abgebildet werden können.
sondere den DFNInternet-Dienst erheblich robuster
gegenüber neuen Herausforderungen machen wird Zusätzlich zu den bisher angebotenen Punkt-zu-
und dies bei Erhalt der gewohnten Leistungsfähigkeit Punkt-Verbindungen auf Layer-2 sollten nun auch
und Verfügbarkeit. Multi-Punkt-Verbindungen auf Layer-2 unterstützt
werden. Auch das transparente Tunneln von VLAN-
Auswahlkriterien für eine neue Trunks der Teilnehmer durch das X-WiN stand auf der
Aggregations-Plattform im X-WiN Anforderungsliste, um Kopplungen von RZ-Infrastruk-
turen künftig besser unterstützen zu können.
Nachdem die Architektur des künftigen IP-Backbone
feststand, konnten die Anforderungen an die hierfür Durch die erheblich gestiegene Zahl von Teilnehmer-
erforderlichen Systeme spezifiziert werden. Gesucht diensten, aber insbesondere durch das permanent
wurde eine Plattform, die mit den an das X-WiN ge- steigende übertragene Datenvolumen im X-WiN (in
stellten Anforderungen wachsen kann und durch den 2016 25 % Steigerung zum Vorjahr), waren auch An-
Hersteller über einen ähnlich langen Zeitraum unter- forderungen an eine deutliche Steigerung der aggre-
stützt und weiterentwickelt wird, wie es bei den Gerä- gierten Systemkapazität überaus wichtig.
ten der aktuellen Aggregations-Plattform der Fall ist.
Aus diesen Gründen war nicht nur wie aktuell auch
Wie bisher wird eine grundlegende Anforderung die die Unterstützung einer großen Anzahl von Fast-Ether-
Fähigkeit zum Routing von IPv4 und IPv6 sowie die net und Gigabit-Ethernet-Schnittstellen notwendig,
Unterstützung der im X-WiN verwendeten Routing- sondern auch die Option, die Zahl der nutzbaren
Protokolle sein. Durch die neue Architektur des IP- 10-Gigabit-Schnittstellen erheblich zu erhöhen.
Backbone entfällt aber die Notwendigkeit, die volle
Internet Routing Tabelle halten zu können.18 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | WISSENSCHAFTSNETZ
Schließlich mussten die Systeme auch eine begrenzte Anzahl von Halbjahr 2016 veröffentlicht werden. Das Ergebnis der Ausschrei-
100-Gigabit-Ethernet-Schnittstellen unterstützen, um eine pers- bung war für den DFN-Verein unter technischen und wirtschaft-
pektivische Aufrüstung der Aggregations-Ketten zu ermöglichen. lichen Gesichtspunkten sehr positiv. Der Zuschlag erfolgte kurz
vor Weihnachten 2016.
Ein weiterer essenzieller Aspekt bei der Auswahl der Aggrega-
tions-Plattform, war die Unterstützung eines effizienten Mana– Das erfolgreiche Angebot beinhaltet Router-Systeme des Typs
gements und Monitorings der eingesetzten Systeme sowie die Cisco ASR907. Die Geräte erfüllen alle geforderten Eigenschaf-
möglichst nahtlose Integration in die bestehenden Prozesse der ten und sind nach ersten Tests im Labor des DFN-NOC gut für
DFN-Geschäftsstelle. den geplanten Einsatzzweck geeignet.
Ein weiteres Kriterium war die erhebliche Reduktion der Leistungs Ein wesentliches Kriterium bei der Beschaffung der neuen Aggre-
aufnahme gegenüber den heute eingesetzten Systemen. Auch gations-Plattform war, dass die neue technische Plattform eine
sollte der, durch diese benötigte Einbauraum in den Datenschrän- ähnlich lange Betriebsdauer erreichen wird wie deren Vorgän-
ken der Kernnetzknoten, deutlich geringer sein als heute. gerplattform. Bei den nun beschafften Systemen handelt es sich
um ein noch sehr junges Produkt, dessen Markteinführung erst
Die neue Aggregations-Plattform Ende 2015 erfolgte. Damit ist die technische Weiterentwicklung
sowohl in Bezug auf die Funktionalität als auch auf die techni-
Nachdem die Auswahlkriterien feststanden, konnte die Aus- sche Leistungsfähigkeit für einen längeren Zeitraum abschätz-
schreibung für die neue Plattform vorbereitet und im zweiten bar und durch entsprechende Herstelleraussagen bestätigt.
7
KIE
BRE ROS
HAM
HAM DES
GRE
EWE 13
TUB
FFO
6
8 MUE BIE HAN DRE CHE
HAN TUB
BRA MAG POT ZIB CHE
11
12
GOE HUB LEI
KAS
ADH
BOC DOR
DUI
MAR 4 LAP
BAY
GIE
5
ERL LAP
DUI FRB
9
FRA
10
AAC BON BIR ILM JEN
FRA ERL
WUE
0
REG 10 GE
2 GSI HEI
2 x 10 GE
1
SAA KAI FZK STU AUG GAR FHM 3 5 x 10 GE
GAR
100 GE
Abbildung 3: Phasen der Migration auf die neue Aggregations-PlattformWISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 91 | 19
Planung für die Migration auf die neue Aus Effizienzgründen für die Logistik und um den Paral
Aggregations-Plattform lelbetrieb von neuen und Bestandssystemen in der
gleichen Aggregations-Kette kurz zu halten, werden
Als Vorbereitung für den Einsatz der neuen Aggrega- alle Standorte in einer Aggregations-Kette in einem
tions-Plattform wurden bereits seit Anfang 2016 um- zusammenhängenden Zeitraum abgearbeitet. Insge-
fangreiche Vorarbeiten geleistet. Erheblichen Anteil samt wurden 14 dieser Zeiträume definiert, die in Ab-
an diesen hatten Maßnahmen an den Kernnetzkno- bildung 3 mit den Ziffern 0 – 13 dargestellt sind. Da-
ten, um die neuen Systeme parallel zu den Bestands- bei wurden die Standorte für die ersten Migrationen
systemen einbauen und in Betrieb nehmen zu kön- so ausgewählt, dass der gewählte Ansatz verifiziert
nen. Ziel dieser Arbeiten war es, die Unterbrechungs- werden und mit den ersten Erfahrungen für die nach-
zeiten bei der Migration der Teilnehmeranbindungen folgenden Arbeiten optimiert werden kann.
so gering wie möglich zu halten.
Mit den Arbeiten wurde zu Beginn des zweiten Quar-
Weitere Maßnahmen betrafen die seit den Anfangs- tals 2017 begonnen.
tagen des X-WiN an den Kernnetzknoten betriebenen
Server-Systeme, die nicht für lokale Betriebsaufgaben Fazit
wie dem Netzmanagement und der Qualitätssicherung
der Netzperformance benötigt werden. So wurden Eine Ära geht zu Ende: Nach mehr als 10 Jahren im
etwa Systeme für den VC- und Eduroam-Dienst sowie Einsatz wird die letzte noch aus den Anfängen des
DNS-Server (siehe Artikel S. 8) an Kernnetzknoten au- X-WiN stammende Plattform ersetzt. Bis Ende des
ßerhalb des SuperCore betrieben. In der neuen Archi- Jahres sind damit alle Plattformen des X-WiN erneu-
tektur der IP-Plattform können diese Server-Dienste ert und entsprechen dem aktuellen Stand der Technik.
nicht mehr an der Aggregations-Plattform betrieben
werden, sodass sie an die zentralen Server-Standorte Die neue Aggregations-Plattform eröffnet dem DFN-
des X-WiN migriert werden mussten. Diese Server- Verein neue Anwendungsszenarien speziell bei der
Standorte befinden sich an den SuperCore-Standor- Kooperation zwischen den Teilnehmereinrichtungen.
ten in Erlangen, Hannover und Berlin. Zudem bietet sie erhebliche Kapazitätsreserven, die
ihren langjährigen Einsatz realistisch erscheinen
Die Migration auf die neuen Aggregations-Systeme lassen.
wird grundsätzlich an jedem Kernnetzknoten in drei
Arbeitsschritten erfolgen: Die neue Architektur des IP-Backbone bringt den glei-
chen Leistungsumfang für alle DFNInternet-Diens-
1. Im ersten Schritt wird das betreffende System te und erhöht gleichzeitig die Robustheit des X-WiN
in einer Laborumgebung komplett zusammen- gegen DoS-Vorfälle.
gebaut, getestet und vom DFN-NOC mit einer
initialen Konfiguration versehen. Nachfolgend Mit dem geplanten Abschluss der Migrationsarbeiten
wird das System verpackt und an den vorgese- bis Ende 2017 steht die neue Aggregations-Plattform
henen Kernnetzknoten verschickt. rechtzeitig für die ab Mitte 2018 geplante Leistungs-
steigerung von DFNInternet bereit. M
2. Im zweiten Schritt wird das System am Kern-
netzknoten eingebaut, in Betrieb genommen
sowie in den IP-Backbone und die Monitoring-
systeme des X-WiN integriert.
3. Im dritten Schritt werden alle Teilnehmeran-
bindungen vom Bestandssystem auf den neu-
en Aggregations-Router migriert. Nachfolgend
wird das Bestandssystem abgebaut und vom
Kernnetzknoten abtransportiert.20 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | WISSENSCHAFTSNETZ DFNFernsprechen: Die Zukunft ist IP Mit dem Umstieg von ISDN auf rein IP-basierte Telekommunikation kommt der DFN-Verein seiner Vision der Konvergenz der Netze einen großen Schritt näher. Dabei bilden die für Wissenschaft und Forschung konzipierten VoIP-Anschlussarten die Grundlage für den Umstieg auf die nächste Kommunikationstechnologie. Text: Christian Meyer (DFN-Verein) Foto © ozgurdonmaz / iStockphoto
WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 91 | 21
Hintergrund tokoll für die Telekommunikation einen mandantenfähigen Anlage erfolgt zentral
stark wachsenden Stellenwert ein, um da- im Wissenschaftsnetz. Teilnehmer benöti-
Der Dienst DFNFernsprechen bietet den mit die bisherige ISDN-Technologie abzu- gen hierfür lediglich entsprechende VoIP-
Teilnehmern seit seinem Beginn im Jahre lösen. Alle Netzbetreiber haben diesbezüg- Endgeräte im lokalen Netz. Diese werden
1998 die Möglichkeit der Telekommunika- lich Pläne angekündigt oder sind in der Um- bei Inbetriebnahme automatisch provisi-
tion über unterschiedliche Anschlussar- setzung entsprechender Maßnahmen. Im oniert und sind dann sofort einsatzbereit.
ten. Dabei bedient sich das Dienstange- Privatkundenbereich hat die Deutsche Te- Jede aktive Nebenstelle wird in einem mo-
bot stets der Möglichkeiten der aktuellen lekom 2012 begonnen, IP-basierte Produkte natlichen Überlassungsentgelt abgerech-
Marktlage, um ein für Forschung und Wis- einzuführen und bestehende Anschlüsse net. Dieses Überlassungsentgelt beinhal-
senschaft zugeschnittenes Portfolio be- damit zu ersetzen. 2015 folgte dann auch tet sowohl die Bereitstellung des Dienstes
reitzustellen. Innerhalb dieser fast 20 Jah- im Geschäftskundenbereich die Ankündi- und seiner Leistungsmerkmale als auch
re war eine der technischen Grundlagen gung, bis Ende 2018 alle bestehenden ISDN- Wartung und Support des Anschlusses so-
des Dienstes immer die leitungsvermittel- Anschlüsse in IP-basierte Anschlüsse um- wie alle zukünftigen Softwareversionen
te Festnetztechnik sowohl in analoger als zuwandeln und ISDN abzuschalten. Dabei für Anlage und Endgeräte. Weitere Über-
auch in digitaler Ausführung. Als analoge betrifft die Abkehr von ISDN nicht nur die lassungs- oder Bereitstellungsentgelte fal-
Anschlüsse kommen dabei sogenannte N1- Betreiber der Netze, sondern auch die Her- len nicht an. Kompatible Endgeräte kön-
Anschlüsse mit einem Nutzkanal zum Ein- steller von Telefonanlagen der klassischen nen über eine Rahmenvereinbarung be-
satz, bei den digitalen ISDN-Anschlüssen Vermittlungstechnik: Neugeräte werden schafft werden.
finden N2-Basisanschlüsse (in den Betriebs- nicht mehr vertrieben, die Kosten für War-
arten Mehrgeräte- und Anlagenanschlüs- tung und Support bestehender Installati- Die zentrale Telefonanlage arbeitet höchst-
se) mit zwei Nutzkanälen und N30-Primär- onen steigen. Außerdem ist in der Ersatz- verfügbar, sie ist an zwei verschiedenen
multiplexanschlüsse (kurz PMX-Anschluss, teilversorgung mit Ausfällen zu rechnen. Standorten mit dem Wissenschaftsnetz ge-
auch S2M-Anschluss) mit 30 Nutzkanälen koppelt. Die Verbindungen der Endgeräte
Verwendung. Für den Dienst DFNFernsprechen hat der mit der Telefonanlage erfolgen standard-
DFN-Verein die Grundlagen geschaffen, um mäßig verschlüsselt, wobei die Signalisie-
Die Entwicklung der DFN-Dienste wird von den teilnehmenden Einrichtungen einen rung einer Verbindung zertifikatbasiert per
der Vision einer Konvergenz bisher unter- reibungslosen Übergang der Kommunika- Transport Layer Security (TLS) und der ei-
schiedlicher Kommunikationssysteme und tionsinfrastruktur von klassischer zu IP-ba- gentliche Medienstrom mit dem Secure
-netze bestimmt (Datennetze, Fernsprech- sierter Technologie zu ermöglichen. Durch Real-Time Transport Protocol (SRTP) ver-
netze, Mobilfunknetze usw.). Ein wichti- die letzte Ausschreibung des Dienstes schlüsselt werden.
ger Integrationsfaktor ist dabei das Inter- DFNFernsprechen wurden VoIP-basierte
netprotokoll, weil es global verbreitet ist Anschlussarten etabliert, die als Nachfol- Auch in der Qualität der Audioübertra-
und – zumindest prinzipiell – in allen Net- ger der bisherigen ISDN-Anschlüsse zum gung wurde eine Verbesserung im Ver-
zen und für nahezu alle Dienste und An- Einsatz kommen. Dabei handelt es sich um gleich zur klassischen Telefonie erreicht.
wendungen genutzt werden kann. Als ein Anschlüsse, die auf das Wissenschaftsnetz So kommt neben dem Sprach-Codec G.711,
Schritt in Richtung Konvergenz bietet der X-WiN aufsetzen. Das bedeutet, dass die der bei ISDN angewendet wurde, nun auch
DFN-Verein deswegen seit 2005 neben der für die Telekommunikation erforderliche der breitbandige Sprach-Codec G.722 zum
klassischen Telefonie auch die Möglichkeit Datenübertragung dieser Anschlüsse über Einsatz.
der IP-basierten Telefonie (Voice-over-IP, das Wissenschaftsnetz erfolgt. Es werden
kurz VoIP) sowie entsprechende Übergän- folglich keine zusätzlichen Anschlusslei- Die VoIP-Centrex-Telefonanlage ist über ein
ge zwischen den Technologien an. tungen bei den Teilnehmern benötigt. sogenanntes SIP-Trunking-Verfahren ver-
schlüsselt mit einer zentralen VoIP-Platt-
Neugeräte werden nicht VoIP-Centrex-Anschluss form verbunden. Diese Plattform dient der
Vermittlung der IP-basierten Kommuni-
mehr vertrieben, die Kosten
Die bisher eingesetzten Basis- oder Primär- kation innerhalb der teilnehmenden Ein-
für Wartung und Support multiplexanschlüsse können auf einen so- richtungen als auch in alle öffentlichen
bestehender Installationen genannten VoIP-Centrex-Anschluss umge- Telefonnetze. Entsprechend den Sicher-
steigen. stellt werden. Diese Anschlussart bietet die heitsanforderungen der über den DFN-
Möglichkeit, alle Funktionen einer Telefon- Verein organisierten Einrichtungen wird
Auch im globalen Umfeld der kommerziel- anlage zu nutzen, ohne selbst eine Anlage auch für die VoIP-Plattform ein optimier-
len Netzbetreiber nimmt das Internetpro- dafür betreiben zu müssen. Der Betrieb der tes Redundanzkonzept eingesetzt: sie ist22 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | WISSENSCHAFTSNETZ
Abbildung 1: VoIP-Centrex-Anschluss (oben) und
VoIP-Anschluss (unten). Bei beiden Anschlussar-
teilnehmende
Einrichtung VoIP-Centrex ten erfolgt die Datenübertragung über das Wis-
senschaftsnetz X-WiN. Im Gegensatz zum VoIP-
Anschluss benötigt ein VoIP-Centrex-Anschluss
IP
keine lokale Telefonanlage. Diese wird zentral im
Wissenschaftsnetz bereitgestellt.
IP
IP
X-WiN SIP Trunk
teilnehmende
Einrichtung Breakout
IP Öffentliche
Telefonnetze
SIP Trunk
IP VoIP-TK- Breakin
Anlage
VoIP-Plattform
IP
an zwei Standorten mit jeweils zwei tras- der Installation, die sowohl die zentral be- notwendig, weshalb die klassischen ana-
sendisjunkten redundanten Zugangslei- nötigten Komponenten als auch die End- logen Anschlüsse über eine Fernspeisung
tungen in das Wissenschaftsnetz einge- geräte in seiner Gesamtheit umfasst. Vie- spannungsversorgt sind. Um die Konnekti-
bunden und wird an jedem Standort re le der Leistungsmerkmale, die bisher im vität auch in diesen Sonderinstallationen
dundant betrieben. ISDN-Netz bereitgestellt wurden, werden zu gewährleisten, bieten die Telekommuni-
bei VoIP-Anschlüssen von der eingesetz- kationsprovider entsprechende Ersatzpro-
VoIP-Anschluss ten Telefonanlage umgesetzt. Auch hier dukte an. Diese Anschlüsse werden über
muss vor Neubeschaffung einer IP-Anla- eine eigene Anschlussleitung versorgt.
Für Einrichtungen, die auf den Betrieb einer ge eine entsprechende Prüfung erfolgen.
eigenen Telekommunikationsinfrastruktur Ist für den VoIP-Anschluss eine Verschlüs- Besonderes Augenmerk –
(kurz TK-Anlage) nicht verzichten wollen, selung geplant, muss die Einrichtung zu- Strategien zur Migration
besteht die Möglichkeit, selbst zwischen sätzliche Mittel zur Beschaffung entspre-
dieser TK-Anlage und der VoIP-Plattform chenden Equipments (sogenannter Border Die Grundlage zur Nutzung der IP-basier-
das SIP-Trunking-Verfahren einzusetzen, elemente bzw. Session Border Controller) ten Telekommunikationsanschlüsse von
um die Konnektivität in das öffentliche Te- einplanen. Auch hierbei werden die Proto- DFNFernsprechen ist der Zugang zum Wis-
lefonnetz herzustellen. Diese als VoIP-An- kolle TLS und SRTP eingesetzt. Für die Ver- senschaftsnetz X-WiN. Vor dem Beginn ei-
schluss bezeichnete Verbindungsart setzt schlüsselung der Signalisierung über TLS ner Anschlussmigration müssen Teilneh-
voraus, dass die eingesetzte TK-Anlage IP- werden Zertifikate der DFN-PKI eingesetzt. mer deswegen prüfen, inwieweit dieser Zu-
fähig ist, über die Kompatibilität zum SIP- gang aktiv ist und ob die Kapazitäten da-
Trunking verfügt und die entsprechende Auch vormals als Analoganschluss reali- für zur Verfügung stehen. Aus Gründen der
Schnittstellenbeschreibung erfüllt. Ist das sierte Installationen können auf die bei- Ausfallsicherheit ist ein redundanter Zu-
nicht der Fall, steht die Einrichtung vor den oben beschriebenen IP-basierten An- gang zum Wissenschaftsnetz empfehlens-
der Aufgabe, die eigene Infrastruktur da- schlussarten umgestellt werden, sofern wert. Gerade für verteilte Einrichtungen
für zu befähigen. Je nach örtlichen Gege- darüber eine Kommunikation ohne Son- ist es wichtig zu prüfen, ob alle Standorte
benheiten bzw. Anforderungen reicht das deranwendungen erfolgt. Viele analoge über Netzkonnektivität verfügen und das
Spektrum dabei von der Beschaffung zu- Geräte (z. B. Fax, Türklingelanlagen, etc.) interne LAN für VoIP vorbereitet ist. Beide
sätzlicher Software bzw. Softwarelizen- können mit sogenannten Digital-Analog- VoIP-Anschlussarten sind in der Lage, mit
zen über die Beschaffung von Gateways Wandlern (kurz D/A-Wandler) auf IP-Um- einem Anschluss die gesamte Einrichtung
oder Routern bis zur Neubeschaffung der gebungen umgesetzt werden. Für analoge zu versorgen. Es ist mit einem Anschluss
gesamten Systemumgebung. Damit ein- Sonderanwendungen speziell im Notrufbe- sogar möglich, den Betrieb einer eigenen
her geht eine vollständige Bedarfsanalyse reich ist immer eine Spannungsversorgung TK-Anlage in redundanter Ausführung überWISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 91 | 23
verschiedene Standorte aufzuspannen, um wird und demzufolge auch den geltenden
die Verfügbarkeit zu erhöhen. Für Standor- IT-Sicherheitskriterien unterliegt. So stel- ABSICHERUNG IT-BASIERTER
te ohne Möglichkeit der X-WiN-Konnekti- len vor allem lokal betriebene Telefonan- TELEKOMMUNIKATIONS-
vität müssen Einrichtungen zukünftig auf lagen, welche nicht mit adäquaten Maß-
Standardprodukte der Telekommunikati- nahmen abgesichert werden, ein großes Si-
ANLAGEN
onsprovider zurückgreifen. cherheitsrisiko dar. Mit der Bereitstellung Grundlegende Schutzmaßnahmen
eines VoIP-Anschlusses für eine lokale Te- sind z. B.
lefonanlage ist diese zur Herstellung welt-
Für die technische Umstel- ʃʃ der Einsatz von Firewall-
weiter Kommunikationsverbindungen be-
Absicherungen oder
lung eines bestehenden fähigt. Sind nun die grundlegenden Schrit-
Zugriffsbeschränkungen,
ISDN-Anschlusses zu einem te zur Absicherung nicht erfolgt, ist die An-
ʃʃ regelmäßige Pflege der TK-Soft-
lage potenziell gefährdet für IT-Angriffe,
VoIP-basierten Anschluss ware und Installation aktueller
mit dem Ziel des Gebührenmissbrauchs.
Betriebssoftware,
wurden Migrationsprozesse Dabei werden hochpreisige Verbindungen
ʃʃ Änderung der Standardpass-
etabliert. zu meist internationalen Mehrwertdiens-
wörter des Systems, Passwort-
ten hergestellt, die zu Lasten des betrof-
sicherung oder Deaktivierung
Für Teilnehmer von DFNFernsprechen, die fenen Teilnehmers gehen.
der Voice-Boxen,
bisher noch keine der VoIP-basierten An-
ʃʃ Absicherung durchwahlfähiger
schlussarten nutzen, ist die formale Rege- Für den sicheren Betrieb einer lokalen
Nebenstellen.
lung über eine neue Dienstvereinbarung Telefonanlage muss eine fachkundige Be-
notwendig. Für die technische Umstellung treuung sichergestellt werden. Planung,
eines bestehenden ISDN-Anschlusses zu Installation, Administration und Instand-
einem VoIP-basierten Anschluss wurden haltung von TK-Systemen erfordern für die Wechsel auf die gewünschte Anschlussart
Migrationsprozesse etabliert. Diese ge- jeweilige Aufgabe spezifische Kompeten- durchzuführen.
währleisten einen sanften Produktwech- zen. Potenziell sicherheitsrelevante Arbei-
sel und ermöglichen eine Portierung der ten sollten nur durch Fachkräfte bzw. ge- Da die für die Kommunikationsübertra-
bestehenden Rufnummer. Für einen An- schultes Personal erbracht werden. Bei Be- gung erforderliche Netzinfrastruktur glo-
schlusswechsel können der zu migrieren- darf sollten teilnehmende Einrichtungen bal verfügbar und nicht mehr von spezi-
de klassische Anschluss und der gewählte deswegen auf entsprechende Dienstleis- ellen Leitungsnetzen abhängig ist, kann
VoIP-basierte Anschluss parallel betrieben ter zugehen. für die IP-basierte Telekommunikation ei-
werden, ausgehende Verbindungen sind ne entfernungsunabhängige Abrechnung
dabei über beide Anschlüsse möglich. Da- Bei VoIP-Centrex-Anschlüssen ist die Ab- vorgenommen werden. Gemäß der Aussa-
mit ist gewährleistet, dass die Einrichtung sicherung der Anlage herstellerseitig um- ge „Die Welt ist ein Dorf“ können beispiels-
alle notwendigen Maßnahmen durchfüh- gesetzt, da der Betrieb und die Betreuung weise auch internationale Verbindungen
ren kann, bevor die Migration abgeschlos- der Systemumgebung zentral erfolgen. Teil- als Ortsverbindung abgerechnet werden.
sen ist. Sie ist dann abgeschlossen, wenn nehmer müssen nur noch die Telefone im Damit ergibt sich für die Teilnehmer ein
die Rufnummer des ISDN-Anschlusses zum eigenen Netz platzieren. reales Einsparpotenzial bei dem Umstieg
neuen Anschluss portiert und der ISDN-An- auf einen IP-basierten Anschluss. M
schluss gekündigt wurde. Für Einrichtun- Fazit
gen, die eine neue Rufnummer benötigen,
entfällt der Schritt der Rufnummernportie- Mit dem Umstieg auf rein IP-basierte Te-
rung. Die Migration ist in diesem Fall mit lekommunikation kommt der DFN-Verein
Kündigung des ISDN-Anschlusses beendet. seiner Vision der Konvergenz der Netze ei-
nen großen Schritt näher. Die beiden für
IT-Sicherheit in der Wissenschaft und Forschung konzipierten
Telekommunikation Anschlussarten „VoIP-Centrex-Anschluss“
und „VoIP-Anschluss“ bilden die Grundlage
Bei der Umstellung auf IP-basierte Telekom- für den Umstieg von ISDN auf die nächste
munikation ist zu beachten, dass die beim Kommunikationstechnologie. Dabei sol-
Teilnehmer eingesetzte Infrastruktur im lo- len optimierte Migrationsprozesse den
kalen Netzwerk der Einrichtung betrieben Teilnehmern helfen, einen reibungslosenSie können auch lesen
