Zusammenfassung
- Tunnelaufbau mit
MID=0und Client-Annahme mit einer Nichtnull-MID sind getrennte Übergänge; ein Tunnel-OPENbestätigt keinen Client. - CLID, MID, Challenge und Key wählen und schützen Protokollkontexte, sind aber kein Nachweis menschlicher Identität oder aktueller Berechtigung.
- L2F bietet für Datenverkehr keine zuverlässige Zustellung. Ein gesunder Kontrollpfad beweist weder jedes Frame noch ein nutzbares Anwendungsergebnis.
Zwei Türen, danach noch ein ganzer Flur
RFC 2341 beschreibt virtuelles Dial-up. Ein entfernter Nutzer wählt sich über PSTN oder ISDN beim Network Access Server eines Providers ein. Die physische Verbindung endet am NAS, die PPP- oder SLIP-Verbindung jedoch an einem entfernten Home Gateway. L2F kapselt die Link-Layer-Frames zwischen beiden Geräten.
Damit entstehen mehrere eigenständige Übergaben: der Anruf erreicht das NAS; PPP beginnt mit LCP; das NAS ermittelt eine scheinbare Identität und wählt ein Home Gateway; der L2F-Tunnel entsteht; das Gateway akzeptiert oder verwirft einen Client; weitere Authentisierung und NCP folgen; einzelne Frames überqueren den Transport; schließlich baut eine Anwendung ihre eigene Sitzung auf und liefert ein Ergebnis.
Die erste Tür ist der Tunnel. Auf MID=0 tauschen beide Seiten L2F_CONF und L2F_OPEN samt Name, Challenge und zugewiesener CLID aus. Danach ist der Tunnel für die Einrichtung von Clients verfügbar. Verfügbarkeit ist hier eine geschaffene Fähigkeit, nicht der Nachweis eines bereits angenommenen Clients.
Die zweite Tür gehört jeder Client-Verbindung. Sie verwendet eine Nichtnull-MID und ein weiteres L2F_OPEN. Das NAS kann Authentisierungstyp sowie Informationen aus CHAP, PAP oder LCP mitsenden. Erst die L2F_OPEN-Antwort des Home Gateway bedeutet, dass diese Client-Verbindung angenommen wurde. Anschließend beginnt die Weiterleitung von PPP- oder SLIP-Frames. Mehrere Clients im selben Tunnel haben somit getrennte OPEN/CLOSE-Lebenszyklen.
CLID und MID bezeichnen Tabellenzeilen
Die CLID demultiplext überlagerte Tunnel, wenn das darunterliegende Medium sie nicht zuverlässig unterscheiden kann. Die MID wählt einen Client innerhalb des Tunnels. Null ist dem Tunnelzustand vorbehalten, Nichtnullwerte dem Clientzustand. Eine nach dem Schließen wiederverwendete MID muss als neue Verbindung initialisiert werden.
Diese Kennungen beantworten, welcher Zustand verarbeitet werden soll. Sie beantworten nicht, welche Person das Endgerät bedient, welche organisatorische Berechtigung sie gerade besitzt oder unter welcher Identität eine Anwendung sie erkennt. Aus einem Multiplex-Schlüssel eine Identität zu machen, fügt dem Protokoll eine Aussage hinzu, die es nicht erzeugt.
Der RFC nennt die erste Information beim ISP ausdrücklich „apparent identity“. Sie reicht zur Auswahl des Home Gateway. Das Gateway entscheidet danach über Annahme oder Ablehnung. Selbst nach der Annahme kann eine dritte PPP- oder SLIP-Authentisierung außerhalb des L2F-Umfangs folgen. CHAP besitzt in RFC 1994 eine eigene Challenge-Response-Grenze. Name erfassen, Daten weitergeben, Geheimnis prüfen, Netzwerkzugang autorisieren und eine Anwendungssitzung akzeptieren bleiben verschiedene Belege.
Die Zuverlässigkeit endet vor dem Nutzdatenbeleg
L2F-Kontrollnachrichten müssen erneut übertragen werden. Für Datenverkehr stellt L2F dagegen weder Flusskontrolle noch zuverlässige Zustellung bereit; das gekapselte Protokoll muss Wiederholungen selbst regeln. Normale Datenpakete verwenden das L2F-Seq-Feld üblicherweise nicht.
Ein bestätigtes OPEN, eine ECHO-Antwort, ein gültiger Key oder ein steigender Tunnelzähler kann daher nicht den Weg jedes Frames belegen. Diese Signale zeigen eine Peer-Reaktion, einen vorhandenen Kontext oder eine Beobachtung an einer bestimmten Grenze. Eine Ende-zu-Ende-Kette entsteht daraus nicht.
Bei PPP transportiert L2F das Link-Layer-Frame, nachdem physisches Framing, Transparenz und FCS entfernt wurden. PPP Echo, NCP-Aushandlung und TERMREQ bleiben getunnelte HDLC-like Frames. L2F erkennt ein PPP-TERMREQ nicht selbst; das Ergebnis am PPP-Endpunkt muss den passenden L2F_CLOSE-Übergang auslösen. Eine Transportschicht versteht nicht automatisch die Wirkung ihres Inhalts.
PPP durchläuft zudem LCP-Einrichtung, optionale Authentisierung und die Netzwerkschicht-Konfiguration über NCP. Erst danach versucht eine Anwendung ihre Sitzung. Selbst eine lückenlose Folge bis zum Client-OPEN beweist daher kein Anwendungsergebnis.
Ein Key ist kein umfassendes Sicherheitsversprechen
Beim Tunnelaufbau verwenden die Enden ein gemeinsames Geheimnis und Challenge-Response. Spätere Pakete können einen 32-Bit-Key tragen, der aus der Authentisierungsantwort abgeleitet ist. Unbekannte CLIDs, falsche Keys und ungültige Pakete sind zu verwerfen. Das erschwert bestimmte Spoofing-Angriffe in der konfigurierten NAS–Home-Gateway-Beziehung.
Es beweist keine Vertraulichkeit der Nutzlast, keine Endnutzer-Autorisierung, keine Anwendungsidentität und kein Ergebnis. RFC 3193 trennte später für L2TP/IPsec Tunnel-Authentisierung, paketweise Integrität, Replay-Schutz, Vertraulichkeit und Ende-zu-Ende-Sicherheit. Diese Eigenschaften dürfen L2F nicht rückwirkend zugeschrieben werden. Die Trennung zeigt aber, warum eine bestätigte Tunnelgegenstelle nicht für die gesamte Dienstsicherheit sprechen kann.
Historic ist ein Dokumentstatus, kein Betriebsnachweis
RFC 2341 ist heute als Historic eingestuft. Sein Statusvermerk sagt, dass er keinen Internetstandard irgendeiner Art festlegt. Der IETF Datatracker führt ihn im Legacy stream, ohne IETF endorsement und ohne formalen Stand im Standardisierungsprozess. Das Dokument bleibt eine technische Quelle; es belegt jedoch weder Verbreitung noch Interoperabilität, aktuelle Nutzung oder Produktkonformität.
Die bleibende Methode ist eine Belegkette mit klaren Objekten: physischer Anruf, LCP, Gateway-Auswahl, Tunnel nach CLID, Client nach MID, spätere Authentisierung, Frames an beiden Enden, NCP, Anwendungssitzung und sichtbares Resultat. Zähler von NAS und Home Gateway gehören getrennt aufbewahrt. Ein Beleg darf nur für die Grenze sprechen, die ihn erzeugt hat.
Quellen
- https://www.rfc-editor.org/info/rfc2341/
- https://www.rfc-editor.org/rfc/rfc2341.html
- https://datatracker.ietf.org/doc/rfc2341/
- https://datatracker.ietf.org/doc/rfc2341/history/
- https://errata.rfc-editor.org/search/?rfc_number=2341
- https://www.rfc-editor.org/rfc/rfc1661.html
- https://www.rfc-editor.org/rfc/rfc1662.html
- https://www.rfc-editor.org/rfc/rfc1994.html
- https://www.rfc-editor.org/rfc/rfc2661.html
- https://www.rfc-editor.org/rfc/rfc2868.html
- https://www.rfc-editor.org/rfc/rfc3193.html
- https://www.rfc-editor.org/rfc/rfc3931.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/on-data-sovereignty-technical-vs-practical-realities/
- https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten

