Brauchen wir ein neues Internet? Gemäss diversen Forscher und Professoren auf dem Internetgebiet, ja. Diese haben eine neue Netzwerkarchtitektur entwickelt: Scalability, Control, and Isolation on next-generation Networks (SCION), welche ich euch hier kurz vorstellen möchte. Ich war an einem Talk der ISSS (Internet Security Society Switzerland) und Adrian Perrig persönlich hat den Teilnehmern seine seit 2009 andauernde Arbeit vorgestellt.

Probleme mt der aktuellen Netzwerkarchitektur

Die heutige Architektur des Internets hat diverse Schwachstellen, welche schwierig zu beheben sind. Zum einen ist da die Verfügbarkeit, welche nach heutigen Messungen 99.9% (86 s pro Tag) für eine gut vernetze Entität ist.  Zum Vergleich: Ein Festnetzanschluss (Kabel, keine IP-Telefonie) hat 99.999% (0.86 s pro Tag) Verfügbarkeit.     Vielen sind sicherlich die kurzen Ausfälle im weltweiten Routing aufgefallen, welche durch Misskonfigurationen oder absichtlichen Attacken (prefix hijacking) durch BGP entstanden sind, oder die prominenten Beispiele im DDoS-Bereich, von welchen wir mittlerweile schon fast täglich betroffen sind.
Ein zweites Problem ist die Kontrolle über die Kommunikationspfade, denn diese können sehr einfach manipuliert werden und dadurch wird der ganze Traffic umgeleitet. Schon erstaunlich, dass ein ISP ein ganzes Land offline nehmen kann (z.B. Google und Japan). Auch das Militär hat starkes Interesse an sogenannten "Kill-Switches", welche auch aktiv bewirtschaftet werden. Einer der Gründe dass wir heute DDoS Attacken haben ist, dass es auch keine wirkliche Kontrolle über eingehenden Traffic gibt, und so nur derjenige mit den meisten Ressourcen diese abwehren kann.
Weitere Problemfelder gibt es bei der Transparenz der Routing-Pfade, denn der Sender kann heute nicht die Gewissheit haben, dass das Paket den Weg nimmt für welchen man es vorherbestimmt hat und wo es wirklich durchgeroutet wurde. All diese Probleme und noch weitere welche ich hier nicht aufgezählt habe, möchte SCION lösen.

SCION

Nun zu SCION selbst. Was bringt SCION für Benefits?

  • High Availability: end-to-end Verbindung, egal ob es Netzwerkstörungen gibt
  • Kontrolle über den Weg: ISP, Sender und Empfänger steuern zusammen die end-to-end Pfade.
  • Transparenz: Klar was mit Paketen passiert und wem vertraut werden soll
  • Sichere Authentifizierung von Netzwerktraffic

ISD Overview
Quelle "SCION: A Secure Internet Architecture (Open Access PDF)"

Das bestehende Konzept der Autonomous Systems (ASes) wird übernommen und diese werden neu gruppiert in sogenannte "isolation domains" (ISDs). Das ist eine grosse Änderung zur heutigen Architektur und einige Kritiker stossen sich daran, dass das Internet "aufgeteilt" wird. Wenn jedoch das ganze Konzept betrachtet wird, könnte das aufgehen. Die sogenannten "Core ASes" sind direkt mit anderen Core AS von anderen ISD verbunden, der Rest via Kunden zu Provider-, oder Peering-Links. Als Beispiel kann man sich eine ISD als Land vorstellen und Core-ASes sind z.B. die grösseren Provider.   Das Routing wird durch einen Prozess genannt "beaconing" sichergestellt. Jede ISD flutet sein Netzwerk mit sogenannten PCBs (path-segement construction beacons), welche dann authentifiziert jeden Pfad traversieren und so alle möglichen Routingpfade erfassen. Jede AS-Traversierung wird im Beacon vermerkt und so entsteht automatisch ein Protokoll, wo das Beacon überall durchgereicht wurde. Diese Beacons können dann in Pfad-Segmente umgewandelt werden und im Netzwerk registriert werden.

Um dies zu tun benötigt jedes AS einige Hauptkomponenten für SCION:

  • Beacon Servers: Für die Information- und Pfadsuche; durch generieren, empfangen und senden von PCBs
  • Pfad Server: Registierung und Suche der Pfadsegemente
  • Zertifikatsserver: Hilft bei der validierung von Pfadinformationen
  • Namensserver: Ähnlich wie DNS, aber für SCION Adressen (ganze Pfadsegmente)
  • Border-Router: Verbindet verschiedene ASes die SCION supporten. Unterscheiden zwischen Service Kommunikation und Daten-Pakete. Unterstütz die gängigen Protokolle (OSPF, SDN, MPLS)

Path Lookup
Qelle "SCION: Slides Architecture Overview"

Wenn nun mein Client einen Host kontaktieren möchte, wird ähnlich wie im DNS eine Abfrage an den lokalen Pfadserver gemacht, welche Pfade verfügbar sind. Falls diese nicht gecached sind, wird die Anfrage weitergeleitet an den Core-Pfadserver. Falls dieser wiederum keine Informationen darüber hat (z.B. der Host steht in einer anderen ISD), fragt dieser den Remote Pfadserver. Schlussendlich bekommt der Client als Antwort alle verfügbaren Pfade/Segmente.
Falls es ein Netzwerkunterbruch gibt, hat der Client schon Backup-Pfade bereit, oder der Pfad "verstopft" ist, kann sehr schnell und automatisch aufgrund der Bandbreiten- und Latenzinformationen, welche auch in der Pfadinfo vorhanden sind, eine andere Route genommen werden. Der ISP hat die Kontrolle, welche Pfade verfügbar gemacht werden, und doch hat der Client die Wahl, welchen Pfad er nehmen möchte. Dazu kommt, dass es transparent ist, wo das Paket durchgeroutet wird.  

Das ganze Konzept wurde mit "security in mind" entworfen, daher sind alle ISD-Konfigurationen mit einer eignen PKI Infrastruktur durch die Core-ASes gesichert und bewirtschaftet. Da ich mich selbst noch nicht tiefer damit befasst habe, kann ich nur wiedergeben, was aus den Aussagen und Fragen hervorging: Es wird mehr als ein Core-AS benötigt um grössere Änderungen durchzuführen und mehrere "böse" AS um das Netzwerk der ISD zu infiltrieren.
TRC Infrastructure
Qelle "SCION: A Secure Internet Architecture (Open Access PDF)"

Jede ISD hat eine sogenannte "trust root configuration" (TRC), welche die Kryptographischen Konfigurationen festlegt. Um Traffic mit anderen ISDs austauschen zu können, müssen die TRCs signiert werden. Durch diese Signaturen können dann die Clients die Pfade und diverse weitere Informationen verifizieren. Dies ist aber auch einer der Herausforderungen, denn falls etwas mit diesen Konfigurationen und Signaturen nicht stimmt, gibt es keine Verbindung mehr. Weitere Informationen dazu gibt es im SCION Buch.
Einer der spannenden Aspekte fand ich noch, dass Pakete mit einem MAC (Message Authentication Code) signiert sind, um die Pfade verifizieren zu können. Gleich darauf fragte jemand Adrian Perrig, ob die kryptographische Operationen das Netzwerk nicht verlangsamen würde. Stolz hat er erwiedert, dass mit 128 Bit-CBC Ciphers und AESni unterstützter Hardware (was nebenbei bemerkt fast jedes Gerät hat) nur ~30 CPU Zyklen benötigt werden. Als Vergleich: ein Lookup im Memory dauert ~200 Zyklen. "Dadurch wird auch Energie gespart!", war seine Aussage.
Das adressiert nun auch die Problematik mit dem eingehenden Traffic bei den Border-Gateways. Ist dieser nicht signiert oder unbekannt (sogenanntes default off), wird er einfach ignoriert.

In der anschliessenden Disskussionsrunde wurden diverse interessante Fragen gestellt, unteranderem wieviel das Deployment kosten würde und ob es nicht so wird wie bei IPv6. IPv6 hatte den Launch am 6. Juni 2012 und ist nur zu 23% (stand 09.11.2017) ausgerollt. Anders als bei IPv6 hätte SCION echte und viele Vorteile (multipath, auto-failover, transparenz, resillenz etc.). Die grosszügige Schätzung von Perrig beträgt 25 Millionen CHF für die ganze Schweiz (inkl. benötigte Hardware, Schulung von Personal etc).
Zum Vergleich: Ein Bau 400 Meter Autobahn kostet in der Schweiz 27 Millionen. Ich persönlich könnte auf 400 Meter Strasse verzichten um dafür ein sichereres Internet zu haben :).

Fazit

Insgesamt finde ich das Konzept sehr interessant und bin gespannt wie die noch offenen Challenges gelöst werden. Einen Proof-Of-Concept läuft aktuell schon, denn es gibt ein aktives SCION Netzwerk, wie die Karte auf der Website von SCION zeigt, und im Talk einige beteiligte Parteien der Schweiz vorgestellt wurden. Falls das Administrieren der Infrastruktur einfach möglich ist (z.B. die Signaturen austauschen etc.) könnte dieses Konzept sich echt durchsetzen.
Aktuell wird gerade noch an einem Draft für die IETF gearbeitet, aber sobald der verabschiedet wird, könnte dies das Internet wirklich auf den Kopf stellen. Dies könnte aber noch einige Zeit dauern.

Quellen / Code

Die Teilnahme am Netzwerk kann mit einer Virtuellen Maschine (Image) getestet werden, was ich nun als nächstes ausprobieren werde. Die ganze Entwicklung ist Open Source, der Code ist auf Github zu finden:

Weitere Links:

Next Post Previous Post

Kommentar hinzufügen