Zum Hauptinhalt springen

RFC 2661 - Layer Two Tunneling Protocol (L2TP)

  • Status: Proposed Standard
  • Veröffentlicht: August 1999
  • Stream: IETF
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

Dieses Dokument beschreibt das Layer Two Tunneling Protocol (L2TP). STD 51, RFC 1661 definiert den Multiprotokoll-Zugang über PPP. L2TP erleichtert das Tunneling von PPP-Paketen über Zwischennetzwerke auf eine für Endbenutzer und Anwendungen so transparent wie mögliche Weise.

Inhaltsverzeichnis (Contents)​

  • 1. Introduction (Einführung)
    • 1.1 Specification of Requirements (Anforderungsspezifikation)
    • 1.2 Terminology (Terminologie)
  • 2. Topology (Topologie)
  • 3. Protocol Overview (Protokollübersicht)
    • 3.1 L2TP Header Format (L2TP-Header-Format)
    • 3.2 Control Message Types (Kontrollnachrichtentypen)
  • 4. Control Message Attribute Value Pairs (Kontrollnachrichten-Attribut-Wert-Paare)
    • 4.1 AVP Format (AVP-Format)
    • 4.2 Mandatory AVPs (Obligatorische AVPs)
    • 4.3 Hiding of AVP Attribute Values (Verbergen von AVP-Attributwerten)
    • 4.4 AVP Summary (AVP-Zusammenfassung)
      • 4.4.1 AVPs Applicable To All Control Messages (AVPs für alle Kontrollnachrichten)
      • 4.4.2 Result and Error Codes (Ergebnis- und Fehlercodes)
      • 4.4.3 Control Connection Management AVPs (Kontrollverbindungs-Management-AVPs)
      • 4.4.4 Call Management AVPs (Anrufmanagement-AVPs)
      • 4.4.5 Proxy LCP and Authentication AVPs (Proxy-LCP- und Authentifizierungs-AVPs)
      • 4.4.6 Call Status AVPs (Anrufstatus-AVPs)
  • 5. Protocol Operation (Protokollbetrieb)
    • 5.1 Control Connection Establishment (Kontrollverbindungsaufbau)
      • 5.1.1 Tunnel Authentication (Tunnel-Authentifizierung)
    • 5.2 Session Establishment (Sitzungsaufbau)
      • 5.2.1 Incoming Call Establishment (Eingehender Anrufaufbau)
      • 5.2.2 Outgoing Call Establishment (Ausgehender Anrufaufbau)
    • 5.3 Forwarding PPP Frames (Weiterleiten von PPP-Frames)
    • 5.4 Using Sequence Numbers on the Data Channel (Verwendung von Sequenznummern im Datenkanal)
    • 5.5 Keepalive (Hello) (Keepalive-Mechanismus)
    • 5.6 Session Teardown (Sitzungsabbau)
    • 5.7 Control Connection Teardown (Kontrollverbindungsabbau)
    • 5.8 Reliable Delivery of Control Messages (Zuverlässige Zustellung von Kontrollnachrichten)
  • 6. Control Connection Protocol Specification (Kontrollverbindungsprotokoll-Spezifikation)
    • 6.1 Start-Control-Connection-Request (SCCRQ)
    • 6.2 Start-Control-Connection-Reply (SCCRP)
    • 6.3 Start-Control-Connection-Connected (SCCCN)
    • 6.4 Stop-Control-Connection-Notification (StopCCN)
    • 6.5 Hello (HELLO)
    • 6.6 Incoming-Call-Request (ICRQ)
    • 6.7 Incoming-Call-Reply (ICRP)
    • 6.8 Incoming-Call-Connected (ICCN)
    • 6.9 Outgoing-Call-Request (OCRQ)
    • 6.10 Outgoing-Call-Reply (OCRP)
    • 6.11 Outgoing-Call-Connected (OCCN)
    • 6.12 Call-Disconnect-Notify (CDN)
    • 6.13 WAN-Error-Notify (WEN)
    • 6.14 Set-Link-Info (SLI)
  • 7. Control Connection State Machines (Kontrollverbindungs-Zustandsautomaten)
    • 7.1 Control Connection Protocol Operation (Kontrollverbindungsprotokoll-Betrieb)
    • 7.2 Control Connection States (Kontrollverbindungszustände)
      • 7.2.1 Control Connection Establishment (Kontrollverbindungsaufbau)
    • 7.3 Timing considerations (Zeitliche Überlegungen)
    • 7.4 Incoming calls (Eingehende Anrufe)
      • 7.4.1 LAC Incoming Call States (LAC-Eingehender-Anruf-Zustände)
      • 7.4.2 LNS Incoming Call States (LNS-Eingehender-Anruf-Zustände)
    • 7.5 Outgoing calls (Ausgehende Anrufe)
      • 7.5.1 LAC Outgoing Call States (LAC-Ausgehender-Anruf-Zustände)
      • 7.5.2 LNS Outgoing Call States (LNS-Ausgehender-Anruf-Zustände)
    • 7.6 Tunnel Disconnection (Tunnel-Trennung)
  • 8. L2TP Over Specific Media (L2TP über spezifische Medien)
    • 8.1 L2TP over UDP/IP
    • 8.2 IP
  • 9. Security Considerations (Sicherheitsüberlegungen)
    • 9.1 Tunnel Endpoint Security (Tunnel-Endpunkt-Sicherheit)
    • 9.2 Packet Level Security (Paket-Ebene-Sicherheit)
    • 9.3 End to End Security (Ende-zu-Ende-Sicherheit)
    • 9.4 L2TP and IPsec
    • 9.5 Proxy PPP Authentication (Proxy-PPP-Authentifizierung)
  • 10. IANA Considerations (IANA-Überlegungen)
    • 10.1 AVP Attributes
    • 10.2 Message Type AVP Values
    • 10.3 Result Code AVP Values
      • 10.3.1 Result Code Field Values
      • 10.3.2 Error Code Field Values
    • 10.4 Framing Capabilities & Bearer Capabilities
    • 10.5 Proxy Authen Type AVP Values
    • 10.6 AVP Header Bits
  • 11. References (Referenzen)
  • 12. Acknowledgments (Danksagungen)
  • 13. Authors' Addresses (Autorenads Adressen)

Anhänge (Appendices)​

Verwandte Ressourcen​

7. Control Connection State Machines (Steuerverbindungs-Zustandsmaschinen)​

Dieses Kapitel definiert die Zustandsmaschinen für den Aufbau, die Aufrechterhaltung und den Abbau von L2TP-Steuerverbindungen und -Sitzungen.

7.1 Control Connection Protocol Operation (Steuerverbindungs-Protokollbetrieb)​

Die Zustandsmaschine der Steuerverbindung beschreibt die Zustandsübergänge beim Aufbau und Abbau von Tunneln. Jeder Zustand definiert die zulässigen Ereignisse, die entsprechenden Aktionen und den Folgezustand.

Ein LAC (L2TP Access Concentrator, L2TP-Zugriffskonzentrator) oder LNS (L2TP Network Server, L2TP-Netzwerkserver) MUSS die hier beschriebenen Zustandsmaschinen implementieren, um die korrekte Interoperabilität sicherzustellen.

7.2 Control Connection States (Steuerverbindungszustände)​

Die Steuerverbindung durchläuft folgende Zustände:

  • idle: Ausgangszustand; es besteht keine aktive Verbindung.
  • wait-ctl-reply: Warten auf die Steuerverbindungsantwort des Gegenstellen-Peers.
  • wait-ctl-conn: Warten auf den Abschluss der Steuerverbindung.
  • established: Die Steuerverbindung ist vollständig aufgebaut.
  • closing: Die Steuerverbindung wird gerade abgebaut.

7.2.1 Control Connection Establishment (Steuerverbindungsaufbau)​

Der Aufbau der Steuerverbindung erfolgt mittels eines Drei-Wege-Handshakes unter Verwendung der Nachrichten SCCRQ (Start-Control-Connection-Request), SCCRP (Start-Control-Connection-Reply) und SCCCN (Start-Control-Connection-Connected).

Die Zustandsübergänge verlaufen wie folgt:

  1. idle → wait-ctl-reply: Der initiierende Peer sendet eine SCCRQ-Nachricht.
  2. wait-ctl-reply → wait-ctl-conn: Der initiierende Peer empfängt eine SCCRP-Nachricht vom Gegenstellen-Peer.
  3. wait-ctl-conn → established: Der initiierende Peer sendet eine SCCCN-Nachricht; der Gegenstellen-Peer wechselt nach Empfang von SCCCN ebenfalls in den Zustand established.

Empfängt ein Peer während des Aufbaus eine StopCCN-Nachricht oder tritt ein Fehler auf, MUSS die Verbindung in den Zustand idle zurückversetzt und alle zugehörigen Ressourcen freigegeben werden.

7.3 Timing Considerations (Zeitliche Überlegungen)​

Für den zuverlässigen Betrieb der Steuerverbindung sind folgende Zeitparameter relevant:

  • Retransmission Timer (Wiederholungssendetimer): Steuerverbindungsnachrichten MÜSSEN bei ausbleibender Bestätigung erneut gesendet werden. Der Timer SOLLTE mit einem exponentiellen Backoff-Verfahren implementiert werden.
  • Hello-Intervall: In regelmäßigen Abständen SOLLTEN Hello-Nachrichten gesendet werden, um die Verfügbarkeit des Tunnels zu überprüfen.
  • Timeout-Erkennung: Bleibt eine Antwort auf Hello-Nachrichten oder Steuerverbindungsnachrichten innerhalb einer definierten Zeitspanne aus, MUSS der Tunnel als ausgefallen betrachtet und abgebaut werden.

Die genauen Zeitwerte sind implementierungsabhängig; es SOLLTEN jedoch angemessene Standardwerte gewählt werden, um sowohl Reaktionsfähigkeit als auch Netzwerkstabilität zu gewährleisten.

7.4 Incoming Calls (Eingehende Anrufe)​

Der Aufbau eingehender Anrufe (Incoming Calls) erfordert koordinierte Zustandsübergänge sowohl auf der LAC- als auch auf der LNS-Seite. Der LAC erkennt einen eingehenden Anruf und benachrichtigt den LNS über die entsprechenden L2TP-Steuernachrichten.

7.4.1 LAC Incoming Call States (LAC-Zustände für eingehende Anrufe)​

Die Zustandsmaschine des LAC für eingehende Anrufe umfasst folgende Zustände:

  • idle: Kein aktiver Anruf vorhanden.
  • wait-reply: Der LAC hat eine ICRQ (Incoming-Call-Request)-Nachricht an den LNS gesendet und wartet auf eine ICRP (Incoming-Call-Reply)-Antwort.
  • wait-connect: Der LAC wartet auf den Verbindungsabschluss durch den LNS mittels ICCN (Incoming-Call-Connected).
  • established: Die Sitzung ist vollständig aufgebaut.

Zustandsübergänge:

  1. idle → wait-reply: LAC sendet ICRQ an den LNS.
  2. wait-reply → wait-connect: LAC empfängt ICRP vom LNS.
  3. wait-connect → established: LAC sendet ICCN; die Sitzung ist aufgebaut.

7.4.2 LNS Incoming Call States (LNS-Zustände für eingehende Anrufe)​

Die Zustandsmaschine des LNS für eingehende Anrufe umfasst folgende Zustände:

  • idle: Kein aktiver Anruf vorhanden.
  • wait-connect: Der LNS hat eine ICRP-Nachricht gesendet und wartet auf die ICCN-Nachricht des LAC.
  • established: Die Sitzung ist vollständig aufgebaut.

Zustandsübergänge:

  1. idle → wait-connect: LNS empfängt ICRQ und sendet ICRP.
  2. wait-connect → established: LNS empfängt ICCN vom LAC.

7.5 Outgoing Calls (Ausgehende Anrufe)​

Ausgehende Anrufe (Outgoing Calls) werden vom LNS initiiert; der LAC führt den eigentlichen Verbindungsaufbau zum Endgerät durch. Die verwendeten Steuernachrichten sind OCRQ (Outgoing-Call-Request), OCRP (Outgoing-Call-Reply) und OCCN (Outgoing-Call-Connected).

7.5.1 LAC Outgoing Call States (LAC-Zustände für ausgehende Anrufe)​

Die Zustandsmaschine des LAC für ausgehende Anrufe umfasst folgende Zustände:

  • idle: Kein aktiver Anruf vorhanden.
  • wait-reply: Der LAC hat eine OCRP-Nachricht gesendet und wartet auf weitere Anweisungen.
  • wait-cs-answer: Der LAC wartet auf die Antwort des angerufenen Endgeräts.
  • established: Die Sitzung ist vollständig aufgebaut.

Zustandsübergänge:

  1. idle → wait-reply: LAC empfängt OCRQ vom LNS und sendet OCRP.
  2. wait-reply → wait-cs-answer: LAC initiiert den Anruf zum Endgerät.
  3. wait-cs-answer → established: Das Endgerät antwortet; LAC sendet OCCN an den LNS.

7.5.2 LNS Outgoing Call States (LNS-Zustände für ausgehende Anrufe)​

Die Zustandsmaschine des LNS für ausgehende Anrufe umfasst folgende Zustände:

  • idle: Kein aktiver Anruf vorhanden.
  • wait-reply: Der LNS hat eine OCRQ-Nachricht gesendet und wartet auf die OCRP-Antwort des LAC.
  • wait-connect: Der LNS wartet auf die OCCN-Nachricht des LAC.
  • established: Die Sitzung ist vollständig aufgebaut.

Zustandsübergänge:

  1. idle → wait-reply: LNS sendet OCRQ an den LAC.
  2. wait-reply → wait-connect: LNS empfängt OCRP vom LAC.
  3. wait-connect → established: LNS empfängt OCCN vom LAC.

7.6 Tunnel Disconnection (Tunnelabbau)​

Der Tunnelabbau KANN von LAC oder LNS durch Senden einer StopCCN (Stop-Control-Connection-Notification)-Nachricht eingeleitet werden. Die StopCCN-Nachricht enthält einen Result Code (Ergebniscode), der den Grund für den Abbau angibt.

Nach Empfang einer StopCCN-Nachricht MUSS der empfangende Peer:

  1. Die StopCCN-Nachricht bestätigen (ZLB, Zero-Length Body).
  2. Alle aktiven Sitzungen innerhalb des Tunnels beenden.
  3. Alle zugehörigen Ressourcen freigeben.
  4. Den Zustand der Steuerverbindung auf idle zurücksetzen.

Ein Peer DARF NICHT versuchen, neue Sitzungen über einen Tunnel aufzubauen, für den eine StopCCN-Nachricht empfangen oder gesendet wurde. Nach dem Abbau KANN ein neuer Tunnel zwischen denselben Endpunkten aufgebaut werden, sofern dies erforderlich ist.

Hinweis: Vollständige Zustandsübergangstabellen und detaillierte Zustandsmaschinendiagramme sind im Originaltext von RFC 2661 enthalten. Dieses Kapitel bietet eine Übersicht der Zustandsmaschinen und der wesentlichen Zustandsübergänge.

8. L2TP Over Specific Media (L2TP über spezifische Medien)​

Dieses Kapitel beschreibt Implementierungsdetails von L2TP über spezifische Medientypen. L2TP ist für den Betrieb über verschiedene Pakettransportmedien konzipiert, einschließlich UDP/IP, Frame Relay, ATM usw.

8.1 L2TP over UDP/IP (L2TP über UDP/IP)​

L2TP verwendet den registrierten UDP-Port 1701 für die Kommunikation zwischen Tunnelendpunkten. UDP bietet Pakettransportdienste sowohl für L2TP-Kontrollnachrichten als auch für Datennachrichten.

Portzuweisung:

  • Quellport: Der Sender kann jeden verfügbaren UDP-Port als Quellport verwenden.
  • Zielport: Muss UDP-Port 1701 verwenden.

Paketkapselung:

Das Kapselungsformat für L2TP-Pakete über UDP/IP lautet wie folgt:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    IP-Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   UDP-Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   L2TP-Header                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              L2TP-Kontrollnachricht oder            |
|                  PPP-Nutzlast                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UDP-Prüfsumme:

Die UDP-Prüfsumme sollte berechnet und in allen L2TP-Paketen enthalten sein. Empfänger müssen die Prüfsumme überprüfen, falls vorhanden. Wenn die Prüfsummenüberprüfung fehlschlägt, muss das Paket verworfen werden.

MTU-Überlegungen:

Da L2TP zusätzliche Kapselungsschichten hinzufügt (L2TP-Header + UDP-Header + IP-Header), müssen Implementierungen die Pfad-MTU berücksichtigen. Typischer Kapselungs-Overhead:

  • IP-Header: 20 Bytes (IPv4) oder 40 Bytes (IPv6)
  • UDP-Header: 8 Bytes
  • L2TP-Header: Mindestens 6 Bytes (abhängig von Optionen möglicherweise mehr)

Fragmentierung:

L2TP-Implementierungen wird empfohlen, IP-Fragmentierung zu vermeiden. Dies kann erreicht werden durch:

  1. Pfad-MTU-Erkennung
  2. Aushandlung der MRU (Maximum Receive Unit) während der Tunneletablierung
  3. Durchführung der Fragmentierung auf PPP-Ebene statt auf IP-Ebene

8.2 IP (Internetprotokoll)​

L2TP-Pakete verwenden IP als Pakettransportprotokoll. IP bietet End-to-End-Pakettransportdienste für L2TP.

IP-Versionsunterstützung:

L2TP ist für den Betrieb über IPv4 [RFC791] und IPv6 [RFC2460] konzipiert. Implementierungen sollten mindestens eine IP-Version unterstützen und können optional beide unterstützen.

IPv4-spezifische Überlegungen:

  • Protokolltyp: Bei Verwendung von UDP-Kapselung wird das IP-Protokollfeld auf 17 (UDP) gesetzt.
  • Diensttyp (TOS): L2TP-Implementierungen können das IP-TOS-Feld setzen, um Anforderungen an die Dienstqualität anzuzeigen. Kontrollnachrichten können eine höhere Priorität als Datennachrichten erfordern.
  • Lebensdauer (TTL): Es sollte ein geeigneter TTL-Wert gesetzt werden, um zu verhindern, dass Pakete unbegrenzt im Netzwerk kreisen.

IPv6-spezifische Überlegungen:

  • Nächster Header: Bei Verwendung von UDP-Kapselung auf 17 (UDP) gesetzt.
  • Flussetikett: Das IPv6-Flussetikett kann verwendet werden, um Paketflüsse zu identifizieren, die zum selben Tunnel gehören, für die QoS-Verarbeitung.
  • Hop-Limit: Entspricht dem TTL von IPv4.

Adressauswahl:

LACs und LNSs müssen in der Lage sein, die IP-Adresse des Peers zu bestimmen. Dies kann erreicht werden durch:

  • Statische Konfiguration
  • DNS-Auflösung
  • Dynamische Erkennungsmechanismen

Multi-Homing-Überlegungen:

Wenn ein Tunnelendpunkt mehrere IP-Adressen hat (Multi-Homing), müssen Implementierungen sicherstellen, dass alle Pakete für einen Tunnel eine konsistente Quelladresse verwenden. Dies ist entscheidend für die Aufrechterhaltung des Tunnelzustands und zur Vermeidung von Verwirrung.

Sicherheit:

Wenn L2TP über IP betrieben wird, wird dringend empfohlen, IPsec [RFC2401] zum Schutz des Tunnelverkehrs zu verwenden. IPsec kann bieten:

  • Vertraulichkeit: Durch ESP-Verschlüsselung
  • Integrität: Durch AH- oder ESP-Authentifizierung
  • Endpunkt-Authentifizierung: Durch IKE

Detaillierte Sicherheitsüberlegungen werden in Kapitel 9 behandelt.

Implementierungshinweise:

  1. Port-Multiplexing: Mehrere Tunnel können zwischen demselben IP-Adresspaar eingerichtet werden, unterschieden durch Tunnel-ID.

  2. NAT-Durchquerung: Wenn L2TP NAT-Geräte durchqueren muss, können zusätzliche Mechanismen erforderlich sein (wie L2TP/IPsec NAT-T).

  3. Firewall-Überlegungen: Firewalls müssen bidirektionale Kommunikation über UDP-Port 1701 zulassen, um L2TP zu unterstützen.

  4. QoS-Zuordnung: Implementierungen können QoS-Anforderungen von der PPP-Ebene auf das DSCP- oder TOS-Feld der IP-Ebene abbilden.

9. Security Considerations (Sicherheitsüberlegungen)​

Das L2TP-Protokoll selbst bietet keine Verschlüsselung oder starke Authentifizierungsdienste. Dieses Kapitel behandelt Sicherheitsüberlegungen bei L2TP-Bereitstellungen und verfügbare Sicherheitsmechanismen.

9.1 Tunnel Endpoint Security (Sicherheit der Tunnelendpunkte)​

Die Vertrauensbeziehung zwischen Tunnelendpunkten ist grundlegend für die L2TP-Sicherheit.

Endpunkt-Authentifizierung:

LAC und LNS müssen in der Lage sein, die Identität des jeweils anderen zu überprüfen. L2TP bietet einen optionalen Tunnel-Authentifizierungsmechanismus:

  • Challenge AVP: Der Initiator sendet einen zufälligen Challenge-Wert im SCCRQ (Start-Control-Connection-Request).
  • Challenge Response AVP: Der Responder berechnet eine Antwort basierend auf einem gemeinsamen Geheimnis und gibt sie im SCCRP (Start-Control-Connection-Reply) zurück.
  • Antwortberechnung: Verwendet MD5-Hash-Funktion: MD5(Nachrichtentyp + gemeinsames_Geheimnis + Challenge + Sitzungs_ID)

Verwaltung gemeinsamer Geheimnisse:

  • Gemeinsame Geheimnisse sollten ausreichende Entropie haben (mindestens 128 Bit empfohlen).
  • Gemeinsame Geheimnisse sollten sicher gespeichert werden (verschlüsselte Speicherung).
  • Gemeinsame Geheimnisse sollten regelmäßig erneuert werden.
  • Verschiedene Tunnelpaare sollten verschiedene gemeinsame Geheimnisse verwenden.

Tunnel-Autorisierung:

Zusätzlich zur Authentifizierung sollten Autorisierungsmechanismen implementiert werden:

  • Überprüfen, ob der Peer berechtigt ist, einen Tunnel einzurichten.
  • Prüfen, ob der Peer die Berechtigung hat, auf bestimmte Ressourcen oder Dienste zuzugreifen.
  • Access Control Lists (ACLs) verwenden, um einzuschränken, welche Peers Tunnel einrichten können.

Schwachstellen und Gegenmaßnahmen:

  1. Man-in-the-Middle-Angriff:

    • Risiko: L2TP-Tunnel-Authentifizierung basierend auf gemeinsamen Geheimnissen ist anfällig für MITM-Angriffe.
    • Gegenmaßnahme: IPsec verwenden, um Ende-zu-Ende-Verschlüsselung und -Authentifizierung bereitzustellen.

  2. Replay-Angriff:

    • Risiko: Angreifer können erfasste Kontrollnachrichten wiedergeben.
    • Gegenmaßnahme: Sequenznummern und ZLB-ACK-Mechanismen verwenden, um Replay-Angriffe zu erkennen und zu verhindern.

  3. Denial-of-Service-Angriff:

    • Risiko: Angreifer können große Mengen von Tunnel-Einrichtungsanforderungen senden.
    • Gegenmaßnahme:
      • Anzahl gleichzeitiger Tunnel pro Quelladresse begrenzen.
      • Rate-Limiting implementieren.
      • Cookie-Mechanismen verwenden (ähnlich wie TCP SYN Cookies).

9.2 Packet Level Security (Sicherheit auf Paketebene)​

L2TP selbst bietet keine Paketverschlüsselung oder Integritätsschutz.

Risiken der Klartextübertragung:

  • Abhören: Angreifer können PPP-Paketinhalte abfangen und lesen, einschließlich Benutzeranmeldeinformationen und Anwendungsdaten.
  • Manipulation: Angreifer können Pakete während der Übertragung ändern.
  • Injektion: Angreifer können bösartige Pakete in den Tunnel injizieren.

AVP-Verbergungsmechanismus:

L2TP bietet einen AVP-Verbergungsmechanismus zum Schutz sensibler Kontrollinformationen:

  • Verbergungsprozess:

    1. MD5-Hash mit gemeinsamem Geheimnis und Random Vector generieren.
    2. Hash-Wert mit AVP-Wert XOR verknüpfen.
    3. Prozess wiederholen, wenn der AVP-Wert 16 Bytes überschreitet.

  • Einschränkungen:

    • AVP-Verbergung ist Verschleierung, keine echte Verschlüsselung.
    • Schützt nicht den Datenkanal, nur bestimmte AVPs im Kontrollkanal.
    • Anfällig für Wörterbuchangriffe (wenn das gemeinsame Geheimnis schwach ist).

Empfehlungen:

  • Nicht auf AVP-Verbergung als alleinigen Sicherheitsmechanismus verlassen.
  • IPsec oder andere Verschlüsselungstechnologien auf Tunnelebene verwenden.

9.3 End to End Security (Ende-zu-Ende-Sicherheit)​

Auch wenn der L2TP-Tunnel selbst geschützt ist, bleibt Ende-zu-Ende-Sicherheit wichtig.

PPP-Ebenen-Authentifizierung:

Unabhängige Authentifizierung sollte zwischen dem entfernten System und dem LNS stattfinden:

  • PAP (Password Authentication Protocol):

    • Einfache Klartext-Passwort-Authentifizierung.
    • Nicht empfohlen, da Passwörter im Klartext übertragen werden (sollte auch innerhalb verschlüsselter L2TP-Tunnel vermieden werden).

  • CHAP (Challenge Handshake Authentication Protocol):

    • Challenge-Response-Authentifizierungsmechanismus.
    • Passwörter werden nicht im Klartext übertragen.
    • Regelmäßige Neuauthentifizierung zur Verhinderung von Replay-Angriffen.

  • EAP (Extensible Authentication Protocol):

    • Unterstützt verschiedene Authentifizierungsmethoden (EAP-TLS, EAP-TTLS, PEAP usw.).
    • Kann gegenseitige Authentifizierung und Schlüsselverhandlung bereitstellen.
    • EAP-TLS wird empfohlen für die stärkste Sicherheit.

Ende-zu-Ende-Verschlüsselung:

Verschlüsselung auf Anwendungsebene bietet eine zusätzliche Sicherheitsschicht:

  • TLS/SSL: Wird zum Schutz von Anwendungsdaten verwendet (z. B. HTTPS).
  • VPN-Client-Software: Bietet zusätzliche Verschlüsselungsschicht über PPP.

Verteidigung in der Tiefe-Strategie:

Entferntes System <--PPP-Auth/Verschl.--> LNS
    |                                       |
    +--<L2TP-Tunnel>--LAC------------------+
              |
         <IPsec-Schutz>
  • Schicht 1: PPP-Ebenen-Authentifizierung (CHAP/EAP)
  • Schicht 2: L2TP-Tunnel-Authentifizierung
  • Schicht 3: IPsec-Verschlüsselung und -Authentifizierung
  • Schicht 4: Verschlüsselung auf Anwendungsebene (TLS/SSL)

9.4 L2TP and IPsec (L2TP und IPsec)​

Es wird dringend empfohlen, L2TP in Kombination mit IPsec zu verwenden, allgemein als L2TP/IPsec bezeichnet.

Von IPsec bereitgestellte Sicherheitsdienste:

  1. Vertraulichkeit:

    • Bereitgestellt durch ESP-Verschlüsselung (Encapsulating Security Payload).
    • Unterstützt mehrere Verschlüsselungsalgorithmen: AES, 3DES, ChaCha20 usw.

  2. Integrität:

    • Bereitgestellt durch AH (Authentication Header) oder ESP-Authentifizierung.
    • Verwendet HMAC (z. B. HMAC-SHA256) zur Überprüfung der Datenintegrität.

  3. Quellen-Authentifizierung:

    • Überprüft die Authentizität von Paketquellen.
    • Verhindert IP-Spoofing-Angriffe.

  4. Anti-Replay:

    • Verwendet Sequenznummern zur Verhinderung von Replay-Angriffen.

L2TP/IPsec-Architektur:

+-------------------+
|   PPP-Nutzlast    |
+-------------------+
|   L2TP-Header     |
+-------------------+
|   UDP-Header      |
+-------------------+
|   ESP-Header      | <-- IPsec-Verschlüsselung und -Authentifizierung
+-------------------+
|   IP-Header       |
+-------------------+

IPsec-Konfigurationsoptionen:

  • Transportmodus:

    • Verschlüsselt und authentifiziert nur die IP-Nutzlast.
    • Geeignet für Ende-zu-Ende-Kommunikation.
    • Empfohlen für L2TP/IPsec.

  • Tunnelmodus:

    • Verschlüsselt und authentifiziert das gesamte IP-Paket.
    • Fügt einen neuen äußeren IP-Header hinzu.
    • Geeignet für Gateway-zu-Gateway-Kommunikation.

Schlüsselverwaltung:

  • IKE (Internet Key Exchange):

    • IKEv1: Originalversion, zweiphasige Verhandlung.
    • IKEv2: Verbesserte Version, rationalisierter und effizienter.
    • IKEv2 wird empfohlen für Schlüsselverhandlung.

  • Vorab geteilte Schlüssel vs. Zertifikate:

    • Vorab geteilte Schlüssel (PSK): Einfach zu konfigurieren, aber schwierig, Schlüssel zu verteilen.
    • Zertifikate: Sicherer, unterstützt große Bereitstellungen, dringend empfohlen.

NAT-Durchquerung (NAT-T):

Wenn L2TP/IPsec NAT-Geräte durchqueren muss:

  • UDP-Kapselung von ESP verwenden (UDP-Port 4500).
  • Regelmäßig NAT-Keepalive-Pakete senden.
  • IKEv2 hat integrierte NAT-T-Unterstützung.

Leistungsüberlegungen:

  • IPsec-Verschlüsselung erhöht den CPU-Overhead.
  • Verwendung von Hardware-Beschleunigung in Betracht ziehen (AES-NI usw.).
  • MTU-Reduzierung muss berücksichtigt werden (ESP-Header + ESP-Trailer + Authentifizierungsdaten).

9.5 Proxy PPP Authentication (Proxy-PPP-Authentifizierung)​

L2TP ermöglicht es dem LAC, die anfängliche PPP-Authentifizierung im Namen des LNS durchzuführen.

Proxy-Authentifizierungsmechanismus:

Der LAC kann LCP verhandeln und eine Authentifizierung mit dem entfernten System durchführen, bevor er den Anruf an den LNS weiterleitet:

  1. LAC führt PPP-Authentifizierung durch:

    • LAC verhandelt LCP mit dem entfernten System.
    • LAC führt PAP- oder CHAP-Authentifizierung durch.
    • LAC sammelt Authentifizierungsinformationen (Benutzername, Passwort-Hash usw.).

  2. LAC leitet Authentifizierungsinformationen an LNS weiter:

    • Verwendet Proxy-AVPs zur Weitergabe von Authentifizierungsinformationen:
      • Proxy Authen Type AVP (29): Authentifizierungstyp (PAP, CHAP usw.)
      • Proxy Authen Name AVP (30): Benutzername
      • Proxy Authen Challenge AVP (31): CHAP-Challenge-Wert
      • Proxy Authen Response AVP (33): Authentifizierungsantwort

  3. LNS überprüft Authentifizierungsinformationen:

    • LNS überprüft den Benutzer basierend auf den vom LAC bereitgestellten Informationen.
    • LNS kann die Sitzung akzeptieren oder ablehnen.

Sicherheitsrisiken:

  1. LAC-Kompromittierung:

    • Wenn der LAC kompromittiert ist, können Angreifer Benutzeranmeldeinformationen erlangen.
    • Gegenmaßnahme: IPsec verwenden, um die Kommunikation zwischen LAC und LNS zu schützen.

  2. Klartext-Passwortübertragung:

    • PAP-Passwörter werden im Klartext vom LAC zum LNS übertragen (in AVPs).
    • Gegenmaßnahme: AVP-Verbergungsmechanismus oder IPsec-Verschlüsselung verwenden.

  3. Vertrauensgrenze:

    • LNS muss den vom LAC bereitgestellten Authentifizierungsinformationen vollständig vertrauen.
    • Ein böswilliger LAC kann Authentifizierungsinformationen fälschen.
    • Gegenmaßnahme:
      • Proxy-Authentifizierung nur zwischen vertrauenswürdigen Verwaltungsdomänen verwenden.
      • Ende-zu-Ende-Neuauthentifizierung in Betracht ziehen.

Best Practices:

  1. Proxy-PAP-Authentifizierung vermeiden:

    • PAP-Passwörter sind anfällig für Angriffe, auch wenn sie verborgen sind.
    • Wenn es verwendet werden muss, IPsec-Schutz sicherstellen.

  2. Ende-zu-Ende-Authentifizierung bevorzugen:

    • Das entfernte System direkt mit dem LNS authentifizieren lassen (ohne Proxy).
    • EAP-Methoden für stärkere Sicherheit verwenden.

  3. Verwendungsfälle für Proxy-Authentifizierung einschränken:

    • Nur bei Bedarf verwenden (z. B. schnelle Anrufeinrichtung).
    • In vertrauenswürdigen Netzwerkumgebungen verwenden.

  4. Mehrere Authentifizierungsmethoden kombinieren:

    • LAC führt vorläufige Authentifizierung durch (für schnelles Filtern).
    • LNS führt sekundäre Authentifizierung durch (Ende-zu-Ende-Verifizierung).

Proxy-Authentifizierung mit RADIUS-Integration:

Entferntes System <--PAP/CHAP--> LAC <--RADIUS--> RADIUS-Server
                                   |
                                   |
                                   v
                            (Auth-Info weiterleiten)
                                   |
                                   v
                                  LNS <--RADIUS--> RADIUS-Server
  • LAC kann RADIUS verwenden, um Benutzeranmeldeinformationen zu überprüfen.
  • LNS kann auch unabhängig mit RADIUS überprüfen.
  • Doppelte Überprüfung bietet eine zusätzliche Sicherheitsschicht.

Sicherheitskonfigurations-Checkliste:

  • IPsec zwischen LAC und LNS verwenden
  • Starke gemeinsame Geheimnisse oder Zertifikate für Tunnel-Authentifizierung verwenden
  • Eindeutige gemeinsame Geheimnisse für jedes Tunnelpaar verwenden
  • PPP-Ebenen-Authentifizierung aktivieren (CHAP oder EAP)
  • Verwendung von PAP-Authentifizierung vermeiden
  • Gemeinsame Geheimnisse regelmäßig wechseln
  • Zugriffskontrolllisten zur Einschränkung der Tunnel-Einrichtung implementieren
  • Protokollierung und Überwachung aktivieren
  • Intrusion Detection Systeme (IDS) einsetzen
  • Regelmäßige Sicherheitsaudits und Penetrationstests durchführen

10. IANA Considerations (IANA-Überlegungen)​

Dieses Kapitel definiert verschiedene Parameter, die von der IANA (Internet Assigned Numbers Authority) für das L2TP-Protokoll zugewiesen und verwaltet werden müssen.

10.1 AVP Attributes (AVP-Attribute)​

Die IANA ist für die Pflege des L2TP-AVP-Attributtyp-Registers verantwortlich. Der AVP-Attributtyp ist ein 16-Bit-Feld.

Registrierungsanforderungen:

  • Wertebereich 0-1023: Durch IETF-Konsens zugewiesen (erfordert Veröffentlichung einer RFC).
  • Wertebereich 1024-65535: Zugewiesen nach dem Prinzip "Wer zuerst kommt, mahlt zuerst".

Zugewiesene Standard-AVP-Attributtypen:

AttributtypAVP-NameReferenz
0NachrichtentypRFC 2661 Section 4.4.1
1ErgebniscodeRFC 2661 Section 4.4.2
2ProtokollversionRFC 2661 Section 4.4.3
3Framing-FähigkeitenRFC 2661 Section 4.4.3
4Bearer-FähigkeitenRFC 2661 Section 4.4.3
5Tie BreakerRFC 2661 Section 4.4.3
6Firmware-RevisionRFC 2661 Section 4.4.3
7HostnameRFC 2661 Section 4.4.3
8AnbieternameRFC 2661 Section 4.4.3
9Zugewiesene Tunnel-IDRFC 2661 Section 4.4.3
10EmpfangsfenstergrößeRFC 2661 Section 4.4.3
11ChallengeRFC 2661 Section 4.4.3
12Q.931-UrsachencodeRFC 2661 Section 4.4.4
13Challenge-AntwortRFC 2661 Section 4.4.3
14Zugewiesene Sitzungs-IDRFC 2661 Section 4.4.4
15AnrufseriennummerRFC 2661 Section 4.4.4
16Minimum-BPSRFC 2661 Section 4.4.4
17Maximum-BPSRFC 2661 Section 4.4.4
18Bearer-TypRFC 2661 Section 4.4.4
19Framing-TypRFC 2661 Section 4.4.4
20PaketverarbeitungsverzögerungRFC 2661 Section 4.4.6
21Angerufene NummerRFC 2661 Section 4.4.4
22Anrufende NummerRFC 2661 Section 4.4.4
23UnteradresseRFC 2661 Section 4.4.4
24SendeverbindungsgeschwindigkeitRFC 2661 Section 4.4.4
25Physische Kanal-IDRFC 2661 Section 4.4.4
26Initial empfangenes LCP CONFREQRFC 2661 Section 4.4.5
27Zuletzt gesendetes LCP CONFREQRFC 2661 Section 4.4.5
28Zuletzt empfangenes LCP CONFREQRFC 2661 Section 4.4.5
29Proxy-AuthentifizierungstypRFC 2661 Section 4.4.5
30Proxy-AuthentifizierungsnameRFC 2661 Section 4.4.5
31Proxy-Authentifizierungs-ChallengeRFC 2661 Section 4.4.5
32Proxy-Authentifizierungs-IDRFC 2661 Section 4.4.5
33Proxy-AuthentifizierungsantwortRFC 2661 Section 4.4.5
34AnruffehlerRFC 2661 Section 4.4.6
35ACCMRFC 2661 Section 4.4.6
36ZufallsvektorRFC 2661 Section 4.3
37Private Gruppen-IDRFC 2661 Section 4.4.4
38EmpfangsverbindungsgeschwindigkeitRFC 2661 Section 4.4.4
39Sequenzierung erforderlichRFC 2661 Section 4.4.4

Anbieterspezifische AVPs:

Anbieterspezifische AVPs verwenden das Vendor-ID-Feld (basierend auf SMI-Netzwerkverwaltungs-Private-Enterprise-Codes), um Erweiterungen verschiedener Anbieter zu unterscheiden.

10.2 Message Type AVP Values (Nachrichtentyp-AVP-Werte)​

Der Wert des Nachrichtentyp-AVP (Attributtyp 0) wird verwendet, um den Typ der L2TP-Kontrollnachricht zu identifizieren.

Zugewiesene Nachrichtentypwerte:

WertNachrichtentypAbkürzungReferenz
0(Reserviert)
1Kontrollverbindungs-Start-AnfrageSCCRQRFC 2661 Section 6.1
2Kontrollverbindungs-Start-AntwortSCCRPRFC 2661 Section 6.2
3Kontrollverbindungs-Start-VerbundenSCCCNRFC 2661 Section 6.3
4Kontrollverbindungs-Stopp-BenachrichtigungStopCCNRFC 2661 Section 6.4
5(Reserviert)
6HelloHELLORFC 2661 Section 6.5
7Ausgehende-Anruf-AnfrageOCRQRFC 2661 Section 6.9
8Ausgehende-Anruf-AntwortOCRPRFC 2661 Section 6.10
9Ausgehender-Anruf-VerbundenOCCNRFC 2661 Section 6.11
10Eingehende-Anruf-AnfrageICRQRFC 2661 Section 6.6
11Eingehende-Anruf-AntwortICRPRFC 2661 Section 6.7
12Eingehender-Anruf-VerbundenICCNRFC 2661 Section 6.8
13(Reserviert)
14Anruf-Trennung-BenachrichtigungCDNRFC 2661 Section 6.12
15WAN-Fehler-BenachrichtigungWENRFC 2661 Section 6.13
16Link-Info-SetzenSLIRFC 2661 Section 6.14

Registrierungsrichtlinie:

Die Zuweisung neuer Nachrichtentypwerte erfordert die Veröffentlichung einer IETF-Standards-Track-RFC oder einer vom IESG genehmigten Informations-RFC.

10.3 Result Code AVP Values (Ergebniscode-AVP-Werte)​

Das Ergebniscode-AVP (Attributtyp 1) wird verwendet, um den Grund für die Beendigung der Kontrollverbindung oder Sitzung anzugeben.

10.3.1 Result Code Field Values (Ergebniscodefeldwerte)​

Allgemeine Ergebniscodes:

WertBedeutungGeltungsbereich
0Reserviert
1Allgemeine Anfrage zum Löschen der KontrollverbindungStopCCN
2Allgemeiner FehlerStopCCN, CDN
3Kontrollkanal existiert bereitsStopCCN
4Anforderer ist nicht autorisiertStopCCN
5Protokollversion nicht unterstütztStopCCN
6Anforderer wird heruntergefahrenStopCCN
7Endlicher-Automat-FehlerStopCCN

Anruftrennung-Ergebniscodes:

WertBedeutungGeltungsbereich
1Träger verlorenCDN
2Allgemeiner FehlerCDN
3Administrativer GrundCDN
4Vorübergehender Mangel an geeigneten EinrichtungenCDN
5Dauerhafter Mangel an geeigneten EinrichtungenCDN
6Ungültiges ZielCDN
7Kein Träger erkanntCDN
8BesetztzeichenCDN
9Kein WähltonCDN
10Timeout beim Warten auf TrägerCDN
11Keine Rahmung erkanntCDN

10.3.2 Error Code Field Values (Fehlercodefeldwerte)​

Das Fehlercodefeld liefert zusätzliche Details über den Fehler.

WertFehlermeldung
0Kein allgemeiner Fehler
1Für dieses Paar existiert noch keine Kontrollverbindung
2Länge ist falsch
3Einer der Feldwerte lag außerhalb des gültigen Bereichs
4Unzureichende Ressourcen zur Behandlung dieser Operation jetzt
5Ungültige Sitzungs-ID
6Ein allgemeiner anbieterspezifischer Fehler ist aufgetreten
7Versuchen Sie einen anderen (LNS/LAC)
8Sitzung oder Tunnel wurde aufgrund des Empfangs eines unbekannten AVP mit gesetztem M-Bit heruntergefahren

Registrierungsrichtlinie:

Die Zuweisung neuer Ergebniscode- und Fehlercodewerte erfordert IETF-Konsens (erfordert Veröffentlichung einer RFC).

10.4 Framing Capabilities & Bearer Capabilities (Framing-Fähigkeiten und Bearer-Fähigkeiten)​

Das Framing-Capabilities-AVP (Attributtyp 3) und das Bearer-Capabilities-AVP (Attributtyp 4) verwenden Bitmasken, um unterstützte Fähigkeiten anzuzeigen.

Framing-Capabilities-Bitdefinitionen:

BitBedeutung
0Asynchrones Framing unterstützt
1Synchrones Framing unterstützt
2-31Reserviert

Bearer-Capabilities-Bitdefinitionen:

BitBedeutung
0Analoger Zugang unterstützt
1Digitaler Zugang unterstützt
2-31Reserviert

Registrierungsrichtlinie:

Die Zuweisung neuer Fähigkeitsbits erfordert IETF-Konsens (erfordert Veröffentlichung einer RFC).

10.5 Proxy Authen Type AVP Values (Proxy-Authentifizierungstyp-AVP-Werte)​

Das Proxy-Authen-Type-AVP (Attributtyp 29) wird verwendet, um den vom LAC verwendeten Authentifizierungstyp anzuzeigen.

Zugewiesene Authentifizierungstypwerte:

WertAuthentifizierungstypReferenz
0Reserviert
1Textlicher Benutzername/Passwort-AustauschRFC 1334 (PAP)
2PPP CHAPRFC 1994
3PPP PAPRFC 1334
4Keine Authentifizierung
5Microsoft CHAP Version 1RFC 2433
6Reserviert
7Microsoft CHAP Version 2RFC 2759

Registrierungsrichtlinie:

Die Zuweisung neuer Authentifizierungstypwerte verwendet die Richtlinie "Wer zuerst kommt, mahlt zuerst".

10.6 AVP Header Bits (AVP-Header-Bits)​

Die ersten 6 Bits des AVP-Headers werden als Bitmaske verwendet, um das AVP-Verhalten zu steuern.

Definierte AVP-Header-Bits:

BitNameBedeutungReferenz
0M (Mandatory)Dieses AVP muss verstanden werdenRFC 2661 Section 4.1
1H (Hidden)AVP-Wert ist verborgenRFC 2661 Section 4.3
2-5ReserviertReserviert, muss auf 0 gesetzt werdenRFC 2661 Section 4.1

Registrierungsrichtlinie:

Die Zuweisung reservierter Bits erfordert Standards-Aktion - d.h. Veröffentlichung einer IETF-Standards-Track-RFC.

10.7 L2TP UDP Port (L2TP-UDP-Port)​

Zugewiesener Port:

  • Portnummer: 1701
  • Protokoll: UDP
  • Zweck: L2TP
  • Referenz: RFC 2661

Die IANA hat UDP-Port 1701 für L2TP sowohl für Kontrollverbindungen als auch für Datensitzungen zugewiesen.

10.8 L2TP Protocol Number (L2TP-Protokollnummer)​

Obwohl die aktuelle Spezifikation L2TP über UDP definiert, kann L2TP auch direkt über andere Pakettransportprotokolle betrieben werden.

IP-Protokollnummer:

  • L2TP-Protokollnummer: 115
  • Name: L2TP
  • Referenz: RFC 3931 (L2TPv3, direkt über IP)

IANA-Registerpflege:

Die IANA pflegt die folgenden L2TP-bezogenen Register:

  1. L2TP-AVP-Attributregister

  2. L2TP-Nachrichtentypregister

    • Enthält alle Kontrollnachrichtentypen

  3. L2TP-Ergebniscoderegister

    • Enthält Ergebniscodes und Fehlercodes

  4. L2TP-Proxy-Authentifizierungstypregister

    • Enthält Authentifizierungstypwerte

  5. L2TP-Ports und Protokollnummern

    • UDP-Port- und IP-Protokollnummernzuweisungen

Aktualisierungen und Erweiterungen:

Nachfolgende RFCs können neue AVPs, Nachrichtentypen oder andere Parameter definieren. Alle neuen Zuweisungen müssen den in diesem Abschnitt definierten Registrierungsrichtlinien folgen.

Wichtige Erweiterungen umfassen:

  • RFC 3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3)
  • RFC 4591: Frame Relay over L2TP
  • RFC 5515: Layer Two Tunneling Protocol (L2TP) Access Concentrator Configuration

11. References (Referenzen)​

Dieser Abschnitt listet alle normativen und informativen Referenzen auf, die in RFC 2661 zitiert werden.

11.1 Normative References (Normative Referenzen)​

Normative Referenzen sind Dokumente, die für die Implementierung des L2TP-Protokolls erforderlich sind.

[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

  • Titel: Point-to-Point Protocol (PPP)
  • Beschreibung: Definiert das grundlegende Format und den Aushandlungsprozess der PPP-Rahmen, die von L2TP durch Tunnel übertragen werden.

[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.

  • Titel: PPP in HDLC-ähnlicher Rahmenstruktur
  • Beschreibung: Definiert die Kapselungsmethode für PPP-Rahmen auf HDLC-ähnlichen Leitungen.

[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.

  • Titel: Zugewiesene Nummern
  • Beschreibung: Referenz für IANA-Nummernzuweisungen (durch die Online-IANA-Registry ersetzt).

[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

  • Titel: PPP Multilink Protocol (MP)
  • Beschreibung: Definiert den Mechanismus zum Bündeln mehrerer physischer Leitungen zu einer einzigen logischen Leitung.

[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

  • Titel: PPP Challenge Handshake Authentication Protocol (CHAP)
  • Beschreibung: Das im L2TP-Proxy-Authentifizierungsverfahren verwendete Authentifizierungsprotokoll.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • Titel: Schlüsselwörter zur Angabe von Anforderungsstufen in RFCs
  • Beschreibung: Definiert die Bedeutung von Schlüsselwörtern wie "MUST", "SHOULD", "MAY".

[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) 'L2F'", RFC 2341, May 1998.

  • Titel: Cisco Layer Two Forwarding (Protocol) (L2F)
  • Beschreibung: Vorgängerprotokoll von L2TP, wird für die Versionserkennung verwendet.

11.2 Informative References (Informative Referenzen)​

Informative Referenzen bieten Hintergrundinformationen und Erläuterungen zu verwandten Protokollen.

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

  • Titel: Internet Protocol (IPv4)
  • Beschreibung: Definiert das IPv4-Protokoll, auf dem L2TP betrieben werden kann.

[RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.

  • Titel: PPP-Authentifizierungsprotokolle
  • Beschreibung: Definiert PAP (Password Authentication Protocol).

[RFC2138] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.

  • Titel: Remote Authentication Dial In User Service (RADIUS)
  • Beschreibung: Protokoll für zentralisierte Authentifizierung, Autorisierung und Abrechnung.

[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.

  • Titel: IETF-Richtlinie zu Zeichensätzen und Sprachen
  • Beschreibung: Leitlinien zur Behandlung internationalisierter Texte.

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

  • Titel: Sicherheitsarchitektur für das Internet Protocol
  • Beschreibung: Definiert die IPsec-Architektur, die in Kombination mit L2TP empfohlen wird.

[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.

  • Titel: Microsoft PPP CHAP Extensions
  • Beschreibung: Definition des MS-CHAPv1-Protokolls.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

  • Titel: Internet Protocol, Version 6 (IPv6) Specification
  • Beschreibung: Definiert das IPv6-Protokoll, auf dem L2TP betrieben werden kann.

[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.

  • Titel: Microsoft PPP CHAP Extensions, Version 2
  • Beschreibung: Definition des MS-CHAPv2-Protokolls.

[KPS] Kaufman, C., Perlman, R., and M. Speciner, "Network Security: Private Communication in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1.

  • Titel: Network Security: Private Communication in a Public World
  • Beschreibung: Kryptographische Grundlagenreferenz für den AVP-Verbergungsmechanismus.

Folgende, mit L2TP verwandte, aber nicht direkt zitierte wichtige Standards:

L2TP-Evolutionsversionen:

  • RFC 3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3)
    • Die dritte Version von L2TP, die das Tunneln von Nicht-PPP-Datenrahmen unterstützt.
  • RFC 5515: Layer Two Tunneling Protocol (L2TP) Access Concentrator Configuration
    • Konfigurationsprotokoll für L2TP-Zugangskonzentratoren.

IPsec-bezogen:

  • RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP
  • RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)
  • RFC 2409: The Internet Key Exchange (IKE)
  • RFC 4306: Internet Key Exchange (IKEv2) Protocol
  • RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)

PPP-Erweiterungen:

  • RFC 2637: Point-to-Point Tunneling Protocol (PPTP)
  • RFC 3748: Extensible Authentication Protocol (EAP)
  • RFC 5281: Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)

QoS und Verkehrsmanagement:

  • RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
  • RFC 2475: An Architecture for Differentiated Services

11.4 Standards Organizations (Standardisierungsorganisationen)​

IETF (Internet Engineering Task Force)

IANA (Internet Assigned Numbers Authority)

IEEE (Institute of Electrical and Electronics Engineers)

  • Standards im Bereich der Layer-2-Technologien

ITU-T (International Telecommunication Union - Telecommunication Standardization Sector)

  • Q.931: ISDN-Signalisierung (referenziert im Q.931 Cause Code AVP)

11.5 Historical Context (Historischer Hintergrund)​

Das L2TP-Protokoll ist eine Verschmelzung der folgenden beiden Protokolle:

  1. L2F (Layer 2 Forwarding Protocol) - entwickelt von Cisco Systems

    • RFC 2341

  2. PPTP (Point-to-Point Tunneling Protocol) - entwickelt von Microsoft und anderen

    • RFC 2637

L2TP kombiniert die Stärken dieser beiden Protokolle und wurde zum IETF-Standards-Track-Protokoll.

11.6 Further Reading (Weiterführende Literatur)​

Fachbücher:

  • "VPN and NAT Traversal" von Gurdeep Singh Pall und Glen Zorn
  • "Understanding Virtual Private Networks" von Rod Rhoton
  • "Virtual Private Networks: Technologies and Solutions" von Ruixi Yuan und W. Timothy Strayer

Online-Ressourcen:

Hinweise zum Zitierformat (Citation Format Notes):

In diesem Dokument werden RFCs im Format [RFCXXXX] zitiert, wobei XXXX die RFC-Nummer ist. Andere Dokumente werden mit einem kurzen Bezeichner in eckigen Klammern referenziert (z. B. [KPS]).

Vollständige RFC-Dokumente sind über folgende Quellen erhältlich:

12. Acknowledgments (Danksagungen)​

Die Autoren von RFC 2661 danken allen Mitgliedern der IETF L2TP Working Group für ihre Beiträge zur Entwicklung dieser Spezifikation.

Major Contributors (Hauptbeitragende)​

Die Entwicklung dieses Protokolls profitierte von den technischen Beiträgen vieler Einzelpersonen und Organisationen. Besonderer Dank gilt folgenden Beitragenden:

  • Dem Engineering-Team von Cisco Systems, insbesondere den ursprünglichen Entwicklern des L2F-Protokolls
  • Dem Engineering-Team von Microsoft Corporation, insbesondere den Beitragenden zum PPTP-Protokoll
  • Den technischen Experten von Ascend Communications und Redback Networks

Working Group Members (Arbeitsgruppenmitglieder)​

Die Diskussionen und technischen Überprüfungen der L2TP Working Group waren entscheidend für die Qualität dieser Spezifikation. Besonderer Dank gilt allen Mitgliedern, die an den Mailinglisten-Diskussionen teilgenommen, Implementierungsfeedback gegeben und Interoperabilitätstests durchgeführt haben.

Technical Review (Technische Überprüfung)​

Dank an die folgenden Personen für die detaillierte technische Überprüfung des Entwurfs und die konstruktiven Anmerkungen:

  • Sicherheitsexperten für die Überprüfung des Sicherheitskapitels
  • PPP- und Tunnelprotokoll-Experten für Vorschläge zum Protokolldesign
  • IANA-Vertreter für die Anleitung zum Kapitel über Parameterzuweisungen

Editorial Support (Redaktionelle Unterstützung)​

Dank an das RFC-Editor-Team für die professionelle Unterstützung bei Dokumentformatierung, Terminologiekonsistenz und Klarheit der technischen Darstellung.

Anmerkung: Die vollständige Liste der Beitragenden und Organisationen findet sich im Danksagungskapitel des ursprünglichen RFC-2661-Dokuments.

13. Authors' Addresses (Adressen der Autoren)​

Dieser Abschnitt listet die Hauptautoren von RFC 2661 und ihre Kontaktinformationen (Stand der Veröffentlichung).

W. Mark Townsley​

Cisco Systems

Email: [email protected]
Website: https://www.townsley.net/

Beitrag: Chefredakteur und technische Koordination

Allan Valencia​

Cisco Systems

Email: [email protected]

Beitrag: Protokolldesign und L2F-Integration

Vertreter von Ascend Communications​

Andrew Rubens

Email: [email protected]

Beitrag: Control-Protokoll- und AVP-Design

Vertreter von Microsoft Corporation​

Gurdeep Singh Pall

Email: [email protected]

Beitrag: PPTP-Protokollintegration und Sicherheitsmechanismen

Vertreter von Microsoft Corporation​

Glen Zorn

Email: [email protected]

Beitrag: Authentifizierungsprotokolle und Sicherheitsdesign

Vertreter von Redback Networks​

Bernard Palter

Email: [email protected]

Beitrag: Protokollimplementierung und Interoperabilitätstests

Hinweise (Notes):

  1. Die oben genannten Kontaktinformationen entsprechen dem Stand der Veröffentlichung (August 1999).
  2. Einige E-Mail-Adressen sind möglicherweise nicht mehr gültig.
  3. Aktuelle Fragen und Diskussionen zum L2TP-Protokoll richten Sie bitte an die IETF L2TP Working Group Mailingliste.
  4. Die laufende Pflege und Erweiterung des L2TP-Standards erfolgt weiterhin durch die IETF.

Kontaktinformationen aktualisieren:

Für aktuelle Informationen zum L2TP-Protokoll oder zur Meldung von Problemen besuchen Sie:

Appendix A: Control Channel Slow Start and Congestion Avoidance​

A.1 Übersicht (Overview)​

Der L2TP-Kontrollkanal verwendet einen zuverlässigen Nachrichtenübertragungsmechanismus. Um Netzwerküberlastung zu verhindern, wird die Implementierung von TCP-ähnlichen Slow-Start- und Congestion-Avoidance-Algorithmen empfohlen.

A.2 Slow-Start-Algorithmus (Slow Start Algorithm)​

Anfangsparameter:

  • Anfängliches Congestion-Fenster (cwnd): 1 Nachricht
  • Slow-Start-Schwellenwert (ssthresh): Größe des Empfangsfensters

Algorithmusschritte:

  1. Mit jedem empfangenen ACK erhöht sich cwnd um 1
  2. Wenn cwnd >= ssthresh, wird in die Congestion-Avoidance-Phase übergegangen
  3. Die Anzahl der unbestätigten, gesendeten Nachrichten überschreitet nicht min(cwnd, Empfangsfenster)

A.3 Congestion Avoidance (Stauvermeidung)​

Backoff-Strategie:

  • Bei Erkennung eines Timeouts: ssthresh = max(cwnd/2, 2)
  • cwnd zurücksetzen auf 1 und Slow Start neu starten

RTT-Schätzung (RTT Estimation):

  • Verwendung des Jacobson/Karels-Algorithmus zur Berechnung des Retransmission-Timeouts (RTO)
  • Geglättetes RTT = (1-α) × geglättetes RTT + α × gemessenes RTT
  • RTO = geglättetes RTT + 4 × RTT-Abweichung

Appendix C: Intellectual Property Notice​

C.1 IP-Erklärung (IP Statement)​

Die IETF nimmt keine Stellung zur Gültigkeit oder zum Umfang irgendwelcher geistigen Eigentumsrechte oder anderer Rechte an den in diesem Dokument beschriebenen Technologien, ebenso wenig dazu, in welchem Umfang Lizenzen unter solchen Rechten verfügbar sein können oder nicht; sie erklärt auch nicht, dass sie sich bemüht habe, solche Rechte zu identifizieren.

C.2 Patentoffenlegung (Patent Disclosure)​

Gemäß den Anforderungen von RFC 2026 Abschnitt 10.4 können die im Zusammenhang mit dieser Spezifikation offengelegten Informationen zu geistigem Eigentum auf der IETF-Website eingesehen werden.

C.3 Lizenzinformationen (Licensing Information)​

Implementierer sollten beachten, dass einige L2TP-Funktionen durch Patente geschützt sein können. Die IETF ist nicht dafür verantwortlich, solche Patente zu identifizieren oder die Gültigkeit oder den Umfang von Patentansprüchen zu bewerten.

Verwandte Links: