Zusammenfassung

  • RFC 3336 nutzte AAL2-Multiplexing, um kleine PPP-Nutzdaten effizienter zu übertragen, etwa Sprache nach der RTP-Headerkompression.
  • Die Vertrauensgrenze blieb enger als die gemeinsame ATM-Verbindung: Eine PPP-Sitzungsauthentifizierung schützte weder benachbarte Nicht-PPP-CIDs noch das ATM-Vermittlungsnetz.

Eine CID trennte Ströme, keine Identitäten

Das Problem lag im Maßstab. PPP über AAL5 eignete sich gut für den IP-Transport, doch RFC 3336 hielt fest, dass Padding und Rahmenbildung bei kleinen Nutzdaten Bandbreite verschwenden konnten – besonders bei Sprache mit bereits komprimierten RTP-Headern. AAL2 bot eine andere Anordnung: Seine Common Part Sublayer (CPS) konnte mehrere PPP-Nutzdaten in ATM-Zellen multiplexen, statt jedes kurze Paket mit den Kosten eines vollständigen Rahmens zu belasten.

Diese Effizienz machte aus einer ATM-Verbindung jedoch keine einzelne PPP-Leitung. RFC 3336 beschrieb den PPP/AAL2-Dienst als bidirektionale Punkt-zu-Punkt-Verbindung, die dauerhaft provisioniert oder bei Bedarf geschaltet werden konnte. Innerhalb dieser Verbindung kennzeichnete eine AAL2 Channel ID (CID) einen Teilstrom. Eine PPP-Sitzung durfte eine oder mehrere CIDs verwenden; beide Endpunkte mussten Anzahl, Zuordnung zu den dienstspezifischen Unterschichten und Werte vereinbaren. Bei einer dedizierten Verbindung konnte die Provisionierung diese Angaben liefern, bei einer geschalteten die Signalisierung.

Dieselbe virtuelle Verbindung konnte auch gewöhnlichen AAL2-Verkehr und unterschiedliche dienstspezifische Konvergenzfunktionen tragen. Eine CID trennte also Teilströme, war aber keine kryptografische Identität. RFC 3336 zog hier eine klare Grenze: Aus der Authentifizierung einer PPP-Sitzung und den zugehörigen Mechanismen durfte nicht geschlossen werden, dass auch Nicht-PPP-CIDs auf derselben Verbindung geschützt waren. Die PPP-Authentifizierung sicherte ebenso wenig das ATM-Vermittlungsnetz selbst. Bei einer Kompromittierung dieser Transportinfrastruktur blieb laut RFC ein Man-in-the-Middle-Angriff möglich.

Weitere Signale hoben diese Grenzen nicht auf. Der Verbindungsstatus „Up“ oder „Down“ konnte aus Typ-3-Fehlermanagementpaketen im betreffenden CID-Strom abgeleitet werden. Die Kapselung ergänzte außerdem eine 16-Bit-CRC zur Fehlererkennung. Weder eine Statusmeldung noch eine CRC belegte, wer eine benachbarte CID kontrollierte, oder verbarg deren Inhalte vor einem Angreifer. Für Schutz über die PPP-Sitzung hinaus verwies RFC 3336 auf Authentifizierung oder Verschlüsselung in höheren Schichten und/oder ATM-Sicherheitsdienste.

RFC 3337 aus derselben Zeit zeigt, warum mehrere Kanäle auch für Echtzeitanwendungen interessant waren: Eine PPP-Sitzung konnte mehrere CIDs umfassen, sodass Fragmente unterschiedlicher Klassen ineinander verschachtelt werden konnten. Das Begleitdokument überließ das CPS-Scheduling jedoch den Echtzeitanforderungen der Anwendung. Eine Klassenkennung garantierte für sich genommen keine bestimmte Latenz. Das Format ermöglichte eine differenzierte Behandlung; es belegte nicht, dass ein bestimmter Scheduler oder ein Netz sie tatsächlich lieferte.

Die Aussage muss auf den Dokumentenstand begrenzt bleiben. Der RFC Editor führt RFC 3336 als Proposed Standard; der Text spezifiziert einen Mechanismus. Keiner dieser Umstände belegt, welche Anbieter ihn implementierten, wie weit er verbreitet war oder ob ein Betreiber einen damit verbundenen Sicherheitsvorfall erlebte. Lu Hengs Note 65 bietet eine passende redaktionelle Leitlinie: Ein Standard ist ein Vorschlag für laufende Systeme, kein Nachweis ihrer Übernahme.

Die Lehre ist architektonischer Art. Eine gemeinsam genutzte Transportverbindung kann Kosten pro Paket senken und zugleich mehrere Kontroll- und Vertrauensbereiche enthalten. Wenn in einer Prüfung „PPP authentifiziert“ steht, muss klar sein, was genau authentifiziert wurde: die PPP-Gegenstellen und der Verkehr dieser Sitzung oder jede CID, Dienstfunktion und Vermittlungsstelle der virtuellen Verbindung? RFC 3336 macht deutlich, dass das Erste das Zweite nicht einschließt.

Quellen

RFC-Editor-Statusseite

Quellen: RFC 3336 · RFC 3337 · PPP über AAL5, RFC 2364 · PPP-Multiplexing, RFC 3153 · PPP, RFC 1661 · RTP-Headerkompression, RFC 2508 · Echtzeitdienste auf langsamen Verbindungen, RFC 2689 · ITU-T I.363.2 · ITU-T I.366.1 · Lu Heng, Note 65