Zusammenfassung

  • RFC 3193 verlangte ESP für L2TP-Steuer- und Datenpakete; die SA schützte jedoch nur dann den richtigen Tunnel, wenn L2TP die während des Aufbaus gewählten Adressen und Ports in die IPsec-Filter einspeiste.
  • Die Paketprüfung bestätigte die von IKE authentisierte Identität. War das die Maschine, während PPP einen Benutzer anmeldete, musste das Endgerät dessen Verkehr zusätzlich isolieren.

Der erste SCCRQ durfte nicht ungeschützt vorauslaufen. Der Filter musste existieren, bevor diese Nachricht die L2TP-Steuerverbindung öffnete. Gab es noch keine passende Phase-2-SA, sollte der Versand IKE auslösen; scheiterte der Aufbau, musste das Paket fallen gelassen werden.

Diese zeitliche Regel zeigt das eigentliche Problem. L2TP durfte einen dynamischen Quellport verwenden. Der Responder konnte vor SCCRP einen anderen Port wählen, nach dem älteren Grundtext sogar eine andere IP-Adresse. IKE Quick Mode beschrieb den geschützten Verkehr aber bereits durch Adressen, Protokoll und Ports. Die Anwendung entschied noch, während die Sicherheitsrichtlinie schon präzise sein musste.

L2TP verfügte zwar über Tunnelauthentisierung und trug PPP mit dessen Authentisierung, Verschlüsselung und Kompression. Diese Anfangshandlungen lieferten jedoch keine Integritäts- und Replay-Prüfung für jedes spätere Steuer- und Datenpaket. PPP-Verschlüsselung schützte den L2TP-Steuerkanal nicht und bot keine skalierbare Schlüsselverwaltung.

Daher mussten konforme Implementierungen ESP für Steuerung und Daten, Transportmodus und IPsec-Replay-Schutz unterstützen. Tunnelmodus war optional. Auch Nullverschlüsselung gehörte zu den damaligen Pflichtfähigkeiten; welche Suite eingesetzt wurde, entschied der Betreiber. Implementierte Fähigkeit und tatsächlich ausgehandelter Schutz blieben verschiedene Tatsachen.

RFC 3193 ließ L2TP seine neuen Socket-Fakten in die IPsec-Filterdatenbank eintragen. Sobald der dynamische Initiatorport bekannt war, konnte die Regel enger werden. Nach Quick Mode verband IKE den konkreten Filter mit der SA. Breitere Übergangsregeln ermöglichten die Portwahl; nach dem Aufbau konnten restliche SAs und Filter verschwinden.

Ein Adresswechsel wurde nicht als stillschweigende Kontinuität behandelt. Der Responder sandte auf dem ursprünglichen geschützten Pfad ein StopCCN mit „Try Another“ und der neuen Adresse. Der Initiator prüfte das Format, installierte neue Richtlinien, baute Phase 1 und Phase 2 neu auf und sandte erst dann einen neuen SCCRQ. Gleiches Ziel bedeutete nicht gleiche kryptografische Beziehung.

Für den Portwechsel galt ein eigener Ablauf. Die Entscheidung fiel vor SCCRP; L2TP injizierte neue Filter, und der Responder begann eine neue Phase 2. Der endgültige Filter beschrieb den wirklich ausgehandelten Socket. UDP 1701 war Treffpunkt, nicht Identitätsnachweis.

Beim Empfang waren zwei Prüfungen zwingend. Zuerst musste L2TP feststellen, dass IPsec das Paket authentisiert oder entschlüsselt hatte und es nicht im Klartext eingetroffen war. Danach mussten IP-Adressen und UDP-Ports zum Socket dieses Tunnels passen. Ein vertrauenswürdiger Peer konnte ein gültig geschütztes Paket trotzdem in den falschen L2TP-Kontext schicken.

Auch der Abbau blieb verteilt. PPP besaß LCP-Abschluss, L2TP seine Kontrollverbindung und Hellos, IKE Phase 1 und Phase 2, die Richtlinie ihre Filter. Wurde der Tunnel gelöscht, sollten zugehörige SAs gelöscht werden. Erhielt IKE eine Delete-Nachricht, sollte es L2TP informieren. Erst nach passender Bestätigung konnten Tunnelzustand und Filter sicher entfernt werden.

Ein Feld „getrennt“ beweist diesen Ablauf nicht. Es kann ein Tunnel fehlen, während eine SA weiterlebt; eine SA kann fehlen, während L2TP den Tunnel noch für aktiv hält; ein provisorischer Any-Port-Filter kann zurückbleiben. Der RFC koppelte Lebenszyklen, ohne sie zu einem Objekt umzudeuten.

Die Header veränderten zudem die nutzbare Paketgröße. Von der bei PPP üblichen MRU von 1500 Byte mussten L2TP- und IPsec-Overhead abgezogen werden. Vor LCP sollte der kleinere Wert weitergegeben werden. Meldete IPsec später eine kleinere Path MTU, sollte die SA sie speichern und L2TP benachrichtigen. Beobachtung und Wirkung lagen in verschiedenen Schichten.

Zustandsbehaftete Kompression war ähnlich heikel. L2TP war verbindungsorientiert, garantierte über IP aber keine Reihenfolge. Ein Verlust konnte den gemeinsamen Zustand für viele Folgepakete zerstören. Zustandslose Methoden waren deshalb erwünscht. Die Tunnelmetapher machte aus dem Untergrund keinen zuverlässigen Strom.

Die wichtigste Trennung betraf die Identität. PPP konnte beim Sitzungsbeginn einen Benutzer prüfen. IKE konnte eine Maschine prüfen und Schlüssel ableiten, mit denen IPsec jedes Paket authentisierte, gegen Veränderung schützte und auf Replay kontrollierte. Die wiederholte Prüfung war stark, bezog sich aber auf die IKE-Identität.

Auf einem Mehrbenutzersystem konnte daher ein anderer lokaler Benutzer den geöffneten Tunnel verwenden. Das Paket blieb unter dem Maschinenschlüssel gültig, ohne vom PPP-authentisierten Menschen zu stammen. Kryptografische Integrität ersetzte keine lokale Verkehrstrennung.

Benutzerauthentisierung in IKE konnte die Lücke verkleinern. Der Client musste dann aber sicherstellen, dass nur Verkehr dieses Benutzers in den Tunnel gelangte. Zertifikat, IKE-Erfolg und lokale Durchsetzung waren weiterhin getrennte Belege.

Bei Zertifikaten verlagerte sich Autorität in die Ausstellung. Ein LNS konnte mehreren CAs vertrauen und Revocation unterschiedlich behandeln. Ein Maschinenzertifikat war nur so aussagekräftig wie sein Enrollment. Eine Smartcard schützte den Benutzerschlüssel, konnte aber einer Richtlinie widersprechen, die Zugriff an genehmigte Hardware band. Der Schlüsselträger definierte den Zweck nicht allein.

Gruppen-Pre-Shared-Keys verdichteten viele Identitäten zu einem Geheimnis. Bei dynamischen Remote-Adressen brauchte Main Mode den Schlüssel womöglich vor dem Identity Payload. Eine gemeinsame Taste löste die Auswahl, bewies aber nur Gruppenwissen. Jeder Inhaber konnte im beschriebenen Modell den LNS imitieren und anschließend ältere PPP-Passwörter angreifen. RFC 3193 riet von Gruppenschlüsseln zur LNS-Authentisierung ab.

Aggressive Mode lieferte die Identität früher, legte sie aber offen. Zertifikate skalierten besser, verlangten jedoch Ausstellung, Vertrauensanker und Widerruf. „Authentisiert“ war ohne Angabe des Verfahrens keine vollständige Beschreibung.

Beim compulsory tunnel wusste der Client womöglich nichts vom IPsec-Schutz zwischen LAC und LNS. Der LNS konnte die SA auswerten; der Client durfte daraus keinen Schutz seines Weges bis zum LAC ableiten. Beim voluntary tunnel kannte der Client die SA bis zum LNS und konnte PPP-Doppelung besser vermeiden, nicht aber den Weg hinter dem LNS.

Der RFC standardisierte ausdrücklich keine Ende-zu-Ende-Sicherheit. Seine Leistung lag darin, L2TP- und IPsec-Zustände präzise zu verbinden und dennoch die Grenzen jeder Identitäts- und Schutzbehauptung zu erhalten.