IETF: Gegenläufige Trends bei der Entwicklung von Netz-Transportprotokollen
Wie kann man die Privatsphäre wahren, ohne die Verwaltung des IP-Verkehrs zu behindern? Braucht man angesichts immer kürzerer Innovationszyklen die Standardisierung überhaupt noch? IETF-Area-Directorin Mirja Kühlewind nimmt Stellung.
- Monika Ermert
- Dusan Zivadinovic
Ein neuer Aufschlag soll Sicherheit und Authentifizierung zu einem integralen Bestandteil des guten alten Internet Transport Protokolls machen (TCP). Google treibt gleichzeitig die Arbeit am hauseigenen Quic voran und möchte es von der IETF, die sich derzeit zu ihrem 96. Meeting in Berlin versammelt hat, standardisieren lassen.
Spannende Zeiten in einem Bereich, in dem sich jahrzehntelang nur eine Handvoll von Experten tummelte. Als neuer Area Director (AD) wird künftig Mirja Kühlewind die Standardisierungsdebatten in diesem Bereich moderieren. Kühlewind ist Nachwuchswissenschaftlerin am Computer Engineering and Networks Laboratory der ETH Zurich. Sie gehört als Area Director der 20-köpfigen Internet Engineering Steering Group an, dem Peer-Gremium der IETF, als eine von fünf Frauen.
heise netze: Transport-Protokolle sind zurzeit offenbar ein Lieblingsthema von Wissenschaftlern. Was hat dich dazu bewogen, den Job zu übernehmen?
Kühlewind: Ich arbeite seit einigen Jahren aktiv bei der IETF mit und fand es immer sehr interessant. Ich leite aktuell selbst zwei Arbeitsgruppen, die an einer sicheren Variante für TCP arbeiten – TCPINC und RTP Media Congestion Avoidance Techniques.
heise netze: Auch das sind wiederum Transport-Protokollthemen...
Kühlewind: Ja. Die Entscheidung wurde dadurch beeinflusst, dass es zu meiner laufenden Forschungsarbeit passt. An der ETH arbeite ich am EU-Projekt Measurement and Architecture for a Middleboxed Internet mit (MAMI). Weil meine Arbeiten bei der IETF auch für das Projekt interessant sind, stehen mir Projektmittel zur Verfügung, beispielsweise für die Reisekosten.
heise netze: Sind Transportprotokolle so etwas wie Grundlagenforschung, verglichen zu den eher schnelllebigen Applikationen? Ist es deshalb eine Domäne der Akademiker?
Kühlewind: Es ist lustig, abgesehen davon, dass Wissenschaftler ganz gut vertreten sind, ist es auch eine deutsche Domäne. Seit 2006, von einer kurzen Phase abgesehen, war immer ein deutscher AD mit dabei.
heise netze: Und du bist erst die zweite Frau in 30 Jahren. Bemerkenswert ist aber auch, dass die Zahl der Unternehmensvertreter zuletzt abgenommen hat. Warum ist das so?
Kühlewind: Das hat vermutlich damit zu tun, dass es in diesem Bereich keine große Kundennachfrage gibt. Natürlich sollen Anwendungen standardkonform sein. Aber welche Protokolle für den Transport verwendet werden, ist aus Kundensicht nicht so wichtig.
Zwar gibt es im Transport-Bereich einige forschungsnahe Gruppen, die die Protokolle und Erweiterungen in den Gruppen erarbeiten. Aber Arbeit in der IETF ist normalerweise keine Forschung. Man will hier fertige Protokolle, die im Konsens mit anderen standardisiert werden können.
In der Standardisierung ist es aus meiner Sicht von zentraler Bedeutung, wieder mehr Flexibilität für die Anwender und Nutzer der Transportprotokolle zu schaffen.
heise netze: Es ist ja tatsächlich viel Bewegung in diesem Bereich. Wie kommt das?
Kühlewind: Die Zunahme an interaktiven Diensten, an Videodiensten und die vielen Cloud-Services erfordern eine stärkere Unterstützung durch Transportprotokolle. Neue Anwendungen bleiben oft auf dem Weg hängen. Manche Middleboxen filtern alles, was nicht TCP ist oder sogar HTTP über TCP. Natürlich können die Anwendungen ihren Verkehr komplett verschlüsseln. Dann wird es aber noch schwieriger.
Hinzu kommt, dass vor fünf oder sechs Jahren Google in der IETF auf den Plan getreten ist und mit seinen Anforderungen für neue Dynamik gesorgt hat. Das ist schon bemerkenswert, was der Strategiewechsel einer einzigen großen Firma in der Standardisierung ausgelöst hat.
heise netze: Haben Snowdens Enthüllungen nicht auch die Nachfrage nach einer besseren Absicherung mittels Verschlüsselung auf dem Transport-Layer verstärkt?
Wenn alles verschlüsselt ist, bekomme ich nicht mehr genügend Informationen, um zu wissen, wie ich den Verkehr behandeln muss.
Kühlewind: Doch. Das ist auch ein Trend. Anwendungsentwickler können nichts Neues machen ohne erhebliche Klimmzüge. Wenn sie verschlüsseln, funktioniert die Anwendung über Middleboxen hinweg nicht mehr. Je mehr Verschlüsselung, desto schwieriger wird es, den Verkehr zu managen. Denn wenn alles verschlüsselt ist, bekomme ich nicht mehr genügend Informationen, um zu wissen, welchen Datenstrom ich wie behandeln muss. Die Snowden-Debatte hat jedoch auf jeden Fall die Sensibilität für Sicherheitsthemen und Verschlüsselung verstärkt.
heise netze: Ein Beispiel für einen Snowden Fall-Out scheint TCPINC zu sein. Die Arbeitsgruppe will das gute alte TCP mit Verschlüsselung verheiraten. Wie ist da der Status?
Kühlewind: In den ersten beiden Jahren ist man nicht so recht vorangekommen. Als Working Group Chair habe ich befürwortet, dass man weiter an den technischen Fragen für die beiden Lösungen arbeitet. Weil TLS 1.3 nicht so schnell fertig wird wie erwartet, verfolgt die Arbeitsgruppe jetzt die Entwicklung von TCPCrypt.
heise netze: TCP mit TLS und TCPCrypt sind Alternativen – und daher nicht kompatibel.
Kühlewind: Für TCP mit TLS sollte einfach TLS fürs Aushandeln der Schlüssel beim Verbindungsaufbau genutzt werden. TCPINC geht zur Aushandlung der Schlüssel einen neuen Weg.
Mit einer Lösung basierend auf TLS würde man sich auf altbewährte, gut funktionierende Verfahren verlassen, während TCPcrypt einen neuen, eigenen Mechanismus vorschlägt. Das birgt natürlich die Gefahr von Implementierungsfehlern und damit neuen Sicherheitslücken. Anderseits heißt die Entscheidung für TCPCrypt aber, dass man einen weiteren Mechanismum unabhängig von TLS hat. Das wiederum kann aus Sicherheitsgründen gut sein.
heise netze: Gleichzeitig beklagt man die zunehmende Verschlüsselung und will in die verschlüsselten Pakete hineinsehen, etwa mit Konzepten wie Session Protocol Underneath Datagrams (SPUD). Die erste Vorstellung der SPUD-Idee stieß auf wenig Gegenliebe im Plenum. Kann man die Position der Kritiker nachvollziehen?
Kühlewind: Spud würde eine Art Zwischenschicht zwischen TCP und der Anwendungsschicht einziehen. Das ganze ist eine Reaktion auf Middlelboxen und resultiert aus einem Workshop des Internet Architecture Board. Middleboxen sind ein Problem. Mittlerweile ist es kaum noch möglich, neue Protokolle auszurollen. Manche Mittelboxen blockieren alles, was nicht TCP ist. Vorerst gibt es dazu noch keine Arbeitsgruppe. Allerdings arbeiten wir daran.
heise netze: Das hört sich nach gegenläufigen Trends an. Einerseits will man mehr Verschlüsselung zum Schutz gegen pervasive Monitoring oder auch einfach zum Tunneln durch die oft querstehenden Mittelboxen. Andererseits soll in Pakete aus QoS-Gründen oder ähnlichen Gründen doch wieder reingeschaut werden. Wird damit nicht die mühsam auf den Weg gebrachte Vertraulichkeit wieder zur Disposition gestellt?
Kühlewind: Ich kann die Bedenken gut nachvollziehen. Aber ich glaube nicht, dass die beiden Entwicklungen inkompatibel sind. Ich bin die erste, die ein Mehr an Zusatzinformation in Frage stellt, wenn sich darüber Nutzer identifizieren lassen und vertrauliche Metainformationen offengelegt werden. Hier geht aber darum, den Middleboxen nur die Informationen zur Verfügung zu stellen, die sie brauchen.
Dabei muss eine solche Box gar nicht wissen, um was für eine Anwendung es sich genau handelt. Angaben über Toleranz für Latency und Jitter reichen aus. Dann muss ich nicht noch mal sagen, 'ich bin Video Verkehr'. Wenn ich zu viel Information reinnehme, kann nämlich genau diese Anwendung ungewollt blockiert werden. Ich glaube aber, trotz der Bedenken, es ist wichtig, diese Fragen zu stellen. Und man sollte auch nicht sofort auf die Komplexität abheben, sondern überlegen, wie man wieder neue Protokolle ausrollen kann. Für SPUD haben wir die Vorstellung, es über UDP zu realisieren. Wie gesagt, die Arbeitsgruppe gibt es noch nicht.
heise netze: Gestartet sind aber die Arbeiten für TAPS, also Transport Services. Kannst du das kurz ins Verhältnis zum neuen Zwischen-Layer setzen?
Kühlewind: TAPS will Interfaces zwischen Anwendungen und der Transportschicht standardisieren. TAPS schafft dafür neue Mechanismen beim Transportprotokoll. Es wird praktisch nicht nur einfach signalisiert "ich brauche eine TCP Verbindung", sondern die Anwendungen teilen zusätzlich bestimmte Anforderungen mit, also Charakteristiken der gewünschten Verbindung. Die Infos bekommt die Transportschicht und kann dann zum Beispiel entscheiden, welches Protokoll das richtige ist und auch testen, ob dieses Protokoll auf der entsprechenden Netzplattform funktioniert.
Man kann es mit Skype vergleichen, das eine Menge Testing macht, um zu checken, welcher Port funktioniert. SPUD würde dagegen eine grundsätzliche Änderung im Stack bringen. Über den Zwischenlayer würden eine Reihe von Informationen zu den Datenpaketen fließen, die das Management erleichtern. Bei Spud fließen hingegen die Information in den Datenpaketen selbst zu den Middleboxen. Doch die Zielrichtung beider Ansätze ist die gleiche.
heise netze: Rollt Google in der Zwischenzeit das Feld mit seinem Quic-Protokoll auf?
Kühlewind: Es gibt Leute, die fragen, warum brauchen wir eigentlich ein neues Transport-Protokoll? Sie wollen lieber TCP weiter verbessern. Ich finde es aber gut, wenn IETF-Mitspieler auch mal ihr eigenes Problem dokumentieren und eine Lösung designen.
Google macht das ja nicht im stillen Kämmerchen, sondern hat das hier in der IETF vorgestellt, auch um die hier vorhandene Expertise zu nutzen. Ich meine, so funktioniert Standardisierung. Die Leute entwickeln ein Protokoll für ein Problem und bringen es dann zur IETF zur Standardisierung. Was nicht geht, ist, wenn die entsprechenden Gruppen von uns nur noch einen Stempel mit "IETF Standard" bekommen wollen. Wenn sie es in die Standardisierung geben, müssen sie bereit sein, das Design zur Diskussion zu stellen.
heise netze: Eine provokante Frage, die der Vorsitzende der IETF, Jari Arkko, in seinem akuellen Strategiepapier zu den Trends in der Standardisierung gestellt hat, lautet: Braucht man eigentlich angesichts immer kürzerer Innovationszyklen eigentlich noch die Standardisierung? Arkko empfiehlt, die IETF solle sich stärker mit der Open Source Community verbünden. Werden Standards und die Standardisierung also obsolet?
Kühlewind: Ich bin da einig mit der Mehrheit der Kollegen in der IESG. Wir denken, dass Standardisierung keineswegs obsolet wird. Zusammenarbeit ist auf jeden Fall gut, aber unsere Aufgabe ist die Standarsidierung. Natürlich ist Open Source attraktiv, weil es schnell geht: Man entwickelt etwas und implementiert es einfach ohne langen Prozess. Ich glaube daher, unser Job bei der IETF ist es, schneller zu werden.
Lesen Sie dazu auch:
• Middleboxen verkalken das Internet
(dz)
