Seite 3: Standards und Komplexität durch mehr Sicherheit

Inhaltsverzeichnis

Wenn wir von BGP sprechen, wie kamst du zur Standardisierung?

Meine erste Spezifikation war Fidonet. Jon Postel und Bob Braden, die damals RFC-Editors waren, hatten mich noch gebeten, diese Spec als RFC zu schreiben. Aber ich war schon fertig und hatte bei der Formatierung 80 Spalten gewählt. Sie wollten aber (entsprechend den RFC-Dokumenten, d. Red) 72. Ich sagte, zum Teufel damit. Seit den frühen 90ern bewegte ich mich im Dunstkreis der IETF und wurde mit Robert Elz erst einmal in die Arbeit an den DNS-Standards reingezogen.

Deine ersten Beiträge betrafen nicht Routing, wie man denken würde, sondern das Domain Name System, zum Beispiel mit einem Update zu RFC 1034 bezüglich des SOA Resource Record….

Seriennummer-Arithmetik, genau. Also ich erinnere mich sehr gut an das IETF-Treffen in Houston 1993. Es war für mich die erste Lektion über die Schrecken der IETF. Ich war in der DNS-Arbeitsgruppe mit den üblichen Verdächtigen, aber auch Susan Thompson, eine Informatikerin, die ich von den Bell Labs kannte. Ziemlich am Anfang war ich etwas direkt in einer Kritik an Paul Vixie (Chef von BIND; Anm. d. Red.) und er sagte mir, ich solle doch etwas höflicher sein. Aber dann war er mit etwas nicht einverstanden, was Susan Thomson sagte, und er schrie sie an. Susan war eine echte Forscherin, sie ging und kam nicht zurück zur IETF. Für mich sagt das etwas aus über toxischen, machomäßigen Irrsinn.

Aber du bist ja viele Jahre geblieben und hast eine Menge beigetragen, etwa zur Absicherung des Routing Systems mit RPKI, oder?

Ich blieb viele Jahre eher am Rand. Ich denke, die Schwachpunkte der IETF sind Komplexität, Featuritis und das Second-System-Syndrom. Wenn wir nicht mehr forschen und experimentieren, werden unvernünftige Dinge zu Standards erhoben. Das Paradebeispiel für mich ist IPv6. In den frühen Entwürfen war es so designt, dass nur 12 Bits und damit die Zahl von 4000 Providern weltweit möglich gewesen wären. Das war im PROTOKOLLDESIGN. Ich glaube, Steve Deering, der das vorgeschlagen hatte, hasste Operators. Ich habe fünf Jahre in diesem Krieg zugebracht. Ich musste mir bei einem Abendessen von Bob Hindon anhören, dass Operator keine Ahnung von Logarithmen hätten. Es war unglaublich. Letztlich flog der Mist raus aus der Spezifikation. Aber Feature um Feature wurde versucht, irgendwie eine andere sozioökonomische Welt zu schaffen, indem man technische Dinge hineinzupressen versuchte – und das funktionierte einfach nicht.

IPv6-Bashing

Wenn die kritisierten Punkte herausgenommen wurden, hat der Standardisierungsprozess dann nicht letztlich seine Schuldigkeit getan?

Die Schwäche der IETF zeigt sich für mich darin, dass wir den Standard angenommen haben, und der Grund, warum wir ihn angenommen haben, beruhte auf einer bestimmten Wahrnehmung von einem IPv4/IPv6-'Problems'. Die Presse hatte Wind bekommen von der als Problem wahrgenommenen künftigen Knappheit von IP-Adressen, nach dem Motto, dass 'wir bald keine Internet-Adressen mehr haben'. Man hätte sich hinstellen können und sagen, hey, beruhigt euch, wir arbeiten dran und es gibt eine Reihe von Lösungsvorschlägen. Stattdessen wählte man eine politische Lösung. Wir haben das regelrecht hingeworfen. Innerhalb von zwei Monaten wurde es ruhig in der Presse und heute, 25 Jahre später, schlagen wir uns immer noch mit diesem Müll herum.

Du meinst, es ist nach wie vor nicht gut?

Nein, es ist furchtbar – Adressierung ohne Änderungen im Routing. Es ist inkompatibel mit dem, was überall draußen genutzt wird, und ein Transitionsmechanismus ist nicht vorgesehen. Wie arrogant und dumm! Das Gerede vom Übergang durch Dual Stack-Implementierung! Dual Stack (das parallele Betreiben von IPv4 und IPv6; Anm. d. Red.) funktioniert, wenn alle zugleich migrieren. Aber wenn sich das über Jahre hinzieht und man irgendwann kein IPv4 mehr hat, wird es schwierig. Denn Dual Stack erfordert ja genauso viel IPv4- wie IPv6-Adressen. Das konnte nicht recht funktionieren. Oder? Es war ein echtes Desaster.

Welche Alternativen gibt es denn?

Es wurden eine Reihe von Alternativen entwickelt, einschließlich einer von Nimrod und einer von O’Dell. Es ist eine Riesen-Diskussion – und du solltest nicht nur mit mir sprechen.

Wird das Internet irgendwann aber doch vollständig auf IPv6 umgestellt sein?

Vermutlich nicht, solange ich noch lebe. Es könnte aber irgendwann so sein, dass IPv6 Grundlage und IPv4 Auslaufprotokoll ist. Ich kann nicht wirklich sagen, ob es passieren wird. Die Frage ist auch der Kern einer Diskussion, die wir aktuelle in der IETF SIRDOPS-Gruppe (Secure Interdomain Routing Operations) führen. Dort vertreten einige den Standpunkt, dass IPv6 und IPv4 das Gleiche sind und daher Datenobjekte beides zugleich repräsentieren können. Man bräuchte also keine unterschiedlichen Objekte zur Repräsentation von IPv4- oder IPv6-Objekten im Internet. Aber die Topologie auf beiden Seiten ist doch sehr verschieden, also, wer Nachbar von wem im Netz ist. Das gilt besonders für Asien. Zugleich sind wir an einem Punkt angelangt, wo beide Protokolle sich einander vielleicht wirklich maximal angenähert haben. Als IPv6 standardisiert wurde, waren beide grundverschieden. Inzwischen haben sie viele Gemeinsamkeiten. Sobald IPv6 das Hauptprotokoll ist, könnte sich das wieder verändern. Da wird noch mächtig diskutiert.

Wenn du von Featuritis und Komplexität sprichst: Muss die Nachfrage nach mehr Sicherheit nicht berücksichtigt werden? Könnte man nicht argumentieren, dass 'Keep it simple and stupid' natürlich erstrebenswert ist, mehr Sicherheit aber eben Komplexität mit sich bringt?

Ich denke, Sicherheit hinterher dranzuklatschen, resultiert in Komplexität. Wenn man Sicherheit von Beginn an integriert, by design, wäre es nicht so komplex. Das Argument, dass Sicherheit in den ursprünglichen Protokollen Innovation verlangsamt oder gestoppt hätten, zieht meiner Meinung nach nicht. Schauen wir uns nacktes BGP an und was es an Security bietet. Das ist der MD5-Algorithmus. In frühen Tagen – nicht des Internets, sondern der Übeltäter im Netz – bestanden Angriffe darin, dass man einen Neustart einer BGP-Session erzwang und damit laufende Sessions verworfen wurden. Wir nahmen also einen einzelnen, schlechten Crypto-Hash, MD5, und verwandten ihn zur Authentifizierung, um einen Hash auf alle TCP-Sessions von BGP zu setzen. Die Crypto- und Security-Leute waren entsetzt, weil es ein schwacher Hash ist. Aber es verhindert die Neustarts und wir machen das seit 20 Jahren. All das modische Zeug wie TCP/AO hat MD5 nicht ersetzen können, einfach weil es funktioniert und brutal einfach ist.

Sicherheit und Komplexität

Aber anfangs hat man eben DNS gemacht, unverschlüsselt und unauthentifiziert. Man hatte kein DNSSEC. Man hatte IP und nicht IPSec. Sorgt die ganze Verschlüsselung nicht doch für mehr Komplexität?

Mir leuchtet der Zusammenhang zwischen Security und Komplexität nicht ein. Klar, da sind die physikalischen Gegebenheiten und ich widerspreche dem Punkt gar nicht vollständig. Aber nehmen wir DNSSEC. Seine Komplexität rührt nicht so sehr vom Grad der Sicherheit, den es bringt. Fast ein größeres Problem ist, glaube ich, dass es anfangs von Leuten mit null operativer Erfahrung entwickelt wurde. Man brauchte drei größere Neuanläufe, um es halbwegs nutzbar zu machen. Einige der ursprünglichen Probleme hat es dann doch geerbt. Ursprünglich hätte ein Wechsel der Schlüssel der Com-Zone es zum Beispiel notwendig gemacht, dass alle Inhaber von com-Adressen zugleich hätten umschlüsseln müssen, auf dem ganzen Globus. Das skaliert bestimmt wirklich gut (lacht).

Klingt anspruchsvoll!

Ja, das war komplex, und Komplexität sorgt für eine gewisse Fragilität. Ich denke, RPKI (Resource PKI, mit dem kryptographisch Routen abgesichert werden; Anm. d. Red.) ist weit davon entfernt, perfekt zu sein. Aber es wurde von Sicherheitsexperten, OPS-Leuten und Herstellern gemeinsam erst außerhalb der IETF diskutiert und dann gemeinsam eingebracht. Natürlich veranstalten wir immer noch ein Chaos und es gibt Leute, die wollen es sehr gerne komplizierter machen. Aber, es ist deutlich weiter verbreitet als DNSSEC.

Ist es verbreiteter, weil es einfacher zu implementieren ist, oder weil die Risiken von Attacken größer sind?

Es ist einfacher zu implementieren. Netzwerkoperatoren haben beim Design geholfen. Rob Austein und ich haben die Caches, die die RPKI-Daten sammeln, so gestaltet, dass sie leichtgewichtig sind und von jedem Router verarbeitet werden können. Es läuft auf existierender Hardware. Wir hatten für die Designphase eine Menge Erfahrung ins Haus geholt. Für mich ist das ein Beispiel für eine erfolgreiche Standardisierung. Wenn man rechte-operative Bedürfnisse erfüllt, ist das ein Garant für Erfolg, meine ich. Wir haben das Beispiel mit den Leitungen erwähnt, die zu fett für die Router waren. Wir haben versucht, ATM-Switches vor die Router zu setzen und stahlen dann etwas von Cascade und dann entwickelte sich das ganze MPLS-Zeug. Der ursprüngliche Zweck von MPLS war einfach, Verkehr aufzuspalten. Aber das wurde sofort für das Management von Verkehr entdeckt. Und da floss so richtig viel Geld rein und der Bedarf war groß. Als Gegenbeispiel nenne ich mal das Debakel von Multicast. Obwohl wir viel ins Design gesteckt haben – ich erinnere mich an Verhandlungen an einem Picknicktisch in München –, hat die hochskalierte Hardware am Ende Unicast zum Gewinner gemacht. Jeder setzt heute Caches an die Netzenden. Wer will ein komplexes Kernnetz? Der Netflix-Cache in deinem Netz schlägt die Komplexität und die Politik zwischen den Providern. Schau dir einfach an, was funktioniert und was nicht.

Bottom-up ist eine Fantasiegespinst

Du hast in so vielen Internetgremien mitgearbeitet, IETF, den IP-Adressverwaltungen (RIRs), ICANN. Welches ist denn nun das Beste in Bezug auf einen partizipativen Prozess, das viel beschworene Bottom-up-Multistakehoder-Prinzip?

Bottom-up ist ein Buzzword und Fantasiegespinst. Keine der Organisationen ist bottom-up. "Die Community sagt" ist eine Ablenkung und wir verwenden das, wenn wir es brauchen. Das funktioniert so lange, bis die Revolution ausbricht. RIPE erscheint uns als egalitärste unserer Subkulturen. Aber schau dir das Chaos um die Vorschläge für die Mitgliedsbeiträge an! Wir stimmen ab, ohne dass wir eine gute Lösung für die Zukunft vor uns haben. Die RIRs tun ihr bestes und die IETF sicher auch, und ICANN lässt sie sicher gut aussehen, weil es von Anwälten kontrolliert wird und eine wirklich erstaunliche Geschichte hat, Widersprüche zu unterdrücken. Aber auch die IETF ist nicht wirklich bottom-up. Auch wir haben unsere Royals und Kontrollspielchen.

Ist denn bottom-up die beste Art und Weise der Zusammenarbeit, oder ist eine gewisse Meritokratie besser, die Leuten auch sagt, diese Spezifikation nehmen wir nicht an, die hat wenig Aussicht auf Erfolg?

Ich habe ein Paper gelesen, in dem dargelegt wird, dass anarchistische und lose informelle Organisationen nicht skalieren. Schon in einer Gruppe von sechs Leuten, die ebenbürtig sind, entwickelt sich eine Hierarchie, meist unbemerkt und ganz ohne formale Schritte. Es gibt keinen Präsidenten, und trotzdem kristallisieren sich Anführer heraus. Manche sind gut und haben gute Absichten, andere weniger, und auch die mit den besten Absichten sind nicht perfekt.

Warst du Mitglied im Internet Architecture Board (IAB, zuständig für Architekturfragen im IETF-Prozess) oder dem Internet Engineering Steering Committee (IESG, macht die Peer-Review für die IETF)?

Im IAB war ich nie, aber in der IESG fünfeinhalb Jahre und dann bin ich aufgestanden und gegangen.

Warum?

Der IETF-Vorsitzende und ich hatten unterschiedliche Vorstellungen, was meine Aufgabe war. Er fand, ich hätte eine soziale und politische Aufgabe. Ich habe versucht, bei den vielen Standardisierungsentwürfe auf dem Laufenden zu bleiben. Susan Hares hat eine interessante Studie gemacht und gemessen, wie viele RFCs bei der IETF in verschiedenen Jahren gemacht wurden, wie breit sie zum Einsatz kamen und wie effektiv die Entscheidungsprozesse waren. Wer sich Stärken und Schwächen der IETF-Führung über die Jahre anschauen will, dem empfehle ich einen Blick in diese Studie. Im Endeffekt bin ich aber nicht der Richtige, um die Frage zu beantworten, wer bottom-up am besten praktiziert. Es ist eine gesellschaftlich-politische Frage, und ich bin bloß ein Geek.