Zum Hauptinhalt springen

8-13. L2TP über Medien, Sicherheit, IANA und Referenzen

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

Dieses Kapitel beschreibt die Verwendung von L2TP über verschiedene Netzwerkmedien und Transportprotokolle.

8.1 L2TP over UDP/IP​

L2TP verwendet UDP-Port 1701 sowohl für Steuerverbindungen als auch für Datensitzungen. UDP (User Datagram Protocol) stellt die Transportschicht für L2TP-Steuernachrichten und Datenpakete bereit.

L2TP-Implementierungen MÜSSEN UDP-Port 1701 als Standardport verwenden. Der Quellport KANN ebenfalls 1701 sein oder ein vom Betriebssystem zugewiesener ephemerer Port. Empfänger MÜSSEN Pakete akzeptieren, die an Port 1701 adressiert sind, unabhängig vom Quellport des Senders.

Das UDP-Prüfsummenfeld SOLLTE für L2TP-Pakete berechnet und überprüft werden, um die Datenintegrität sicherzustellen. Da L2TP einen eigenen Sequenznummernmechanismus für Steuernachrichten implementiert, ist die Reihenfolgegarantie von TCP nicht erforderlich.

8.2 IP​

L2TP KANN direkt über IP (Internet Protocol) ohne zwischengeschaltetes UDP transportiert werden, sofern beide Endpunkte diese Betriebsart unterstützen. In diesem Fall wird IP-Protokollnummer 115 verwendet.

Bei der Verwendung von L2TP über IP MÜSSEN die Implementierungen sicherstellen, dass die Fragmentierung und Reassemblierung von IP-Paketen korrekt gehandhabt wird. Die MTU (Maximum Transmission Unit, maximale Übertragungseinheit) des Tunnels MUSS so konfiguriert werden, dass eine übermäßige Fragmentierung vermieden wird.

9. Security Considerations (Sicherheitsüberlegungen)​

L2TP selbst bietet keine inhärenten Sicherheitsmechanismen für die Verschlüsselung oder starke Authentifizierung von Tunneldaten. Dieser Abschnitt beschreibt die Sicherheitsaspekte und empfohlene Maßnahmen zum Schutz von L2TP-Verbindungen.

9.1 Tunnel Endpoint Security (Sicherheit der Tunnelendpunkte)​

LAC und LNS SOLLTEN geeignete Authentifizierungsmechanismen implementieren, um sicherzustellen, dass nur autorisierte Gegenstellen einen Tunnel aufbauen können.

L2TP unterstützt einen optionalen Tunnel-Authentifizierungsmechanismus, der auf einem gemeinsamen Geheimnis (Shared Secret) basiert. Dieser Mechanismus verwendet einen CHAP-ähnlichen (Challenge Handshake Authentication Protocol) Austausch während des Steuerverbindungsaufbaus. Implementierungen, die Tunnel-Authentifizierung unterstützen, MÜSSEN den in RFC 2661 definierten Mechanismus korrekt implementieren.

Es ist zu beachten, dass der L2TP-eigene Authentifizierungsmechanismus keinen Schutz gegen Replay-Angriffe (Wiederholungsangriffe) bietet. Für eine robuste Sicherheit SOLLTE IPsec verwendet werden (siehe Abschnitt 9.4).

9.2 Packet Level Security (Sicherheit auf Paketebene)​

L2TP bietet selbst keine Verschlüsselung auf Paketebene. Um den Inhalt der übertragenen Pakete zu schützen, SOLLTE IPsec oder ein anderer Verschlüsselungsmechanismus in Verbindung mit L2TP eingesetzt werden.

Ohne zusätzliche Sicherheitsmaßnahmen sind L2TP-Pakete anfällig für:

  • Abhören (Eavesdropping): Unbefugte Dritte können den Datenverkehr mitlesen.
  • Manipulation (Tampering): Pakete können ohne Erkennung verändert werden.
  • Einschleusung (Injection): Gefälschte Pakete können in den Tunnel eingeschleust werden.

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

PPP-Schichtprotokolle wie EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) können Ende-zu-Ende-Sicherheit unabhängig von der L2TP-Tunnelsicherheit bereitstellen. Diese Protokolle schützen die Kommunikation zwischen dem Endbenutzer und dem LNS, ohne auf die Sicherheit des L2TP-Tunnels angewiesen zu sein.

Implementierungen SOLLTEN die Verwendung starker PPP-Authentifizierungsprotokolle unterstützen und fördern, um die Sicherheit der Endbenutzerkommunikation zu gewährleisten.

9.4 L2TP and IPsec​

Die empfohlene Methode zur Absicherung von L2TP-Verbindungen ist die Verwendung von IPsec (Internet Protocol Security). IPsec KANN folgende Sicherheitsdienste bereitstellen:

  • Vertraulichkeit (Confidentiality): Verschlüsselung der Paketinhalte durch ESP (Encapsulating Security Payload).
  • Integrität (Integrity): Überprüfung der Paketunversehrtheit durch AH (Authentication Header) oder ESP mit Authentifizierung.
  • Authentifizierung (Authentication): Verifizierung der Identität der Tunnelendpunkte mittels IKE (Internet Key Exchange).
  • Schutz vor Replay-Angriffen: Erkennung und Ablehnung von wiederholten Paketen.

Wenn IPsec zum Schutz von L2TP verwendet wird, SOLLTE der IPsec-Tunnel so konfiguriert werden, dass er den gesamten L2TP-Datenverkehr zwischen den Tunnelendpunkten schützt. Die Kombination aus L2TP und IPsec wird häufig als L2TP/IPsec bezeichnet und ist eine weit verbreitete VPN-Lösung (Virtual Private Network, Virtuelles Privates Netzwerk).

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

L2TP unterstützt die Übertragung von PPP-Authentifizierungsinformationen vom LAC zum LNS mittels Proxy-Authentifizierungs-AVPs (Attribute Value Pairs, Attribut-Wert-Paare). Dies ermöglicht es dem LNS, die Authentifizierungsentscheidung des LAC zu akzeptieren oder eine erneute Authentifizierung durchzuführen.

Sicherheitshinweis: Der LNS SOLLTE die vom LAC übermittelten Proxy-Authentifizierungsinformationen sorgfältig prüfen. Wenn der LNS dem LAC nicht vollständig vertraut, SOLLTE er eine erneute Authentifizierung des Benutzers durchführen, anstatt sich auf die Proxy-Authentifizierungsdaten zu verlassen. Die Verwendung von Proxy-Authentifizierung ohne ausreichende Vertrauensbeziehung zwischen LAC und LNS kann zu Sicherheitslücken führen.

10. IANA Considerations (IANA-Überlegungen)​

Dieser Abschnitt beschreibt die Anforderungen an die IANA (Internet Assigned Numbers Authority) für die Verwaltung von L2TP-bezogenen Nummernräumen.

10.1 AVP Attributes (AVP-Attribute)​

Die IANA verwaltet den Nummernraum für L2TP-AVP-Attributtypen. Neue AVP-Attributtypen MÜSSEN durch die IANA zugewiesen werden. Anfragen für neue Attributtypen SOLLTEN eine vollständige Beschreibung des AVP, seiner Verwendung und seiner Kodierung enthalten.

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

Die IANA verwaltet die Werte für den Message Type AVP (Nachrichtentyp-Attribut-Wert-Paar). Folgende Nachrichtentypen sind definiert:

WertNachrichtentyp
1SCCRQ (Start-Control-Connection-Request)
2SCCRP (Start-Control-Connection-Reply)
3SCCCN (Start-Control-Connection-Connected)
4StopCCN (Stop-Control-Connection-Notification)
6Hello
7OCRQ (Outgoing-Call-Request)
8OCRP (Outgoing-Call-Reply)
9OCCN (Outgoing-Call-Connected)
10ICRQ (Incoming-Call-Request)
11ICRP (Incoming-Call-Reply)
12ICCN (Incoming-Call-Connected)
14CDN (Call-Disconnect-Notify)
15WEN (WAN-Error-Notify)
16SLI (Set-Link-Info)

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

Die IANA verwaltet die Werte für den Result Code AVP (Ergebniscode-Attribut-Wert-Paar), der in StopCCN- und CDN-Nachrichten verwendet wird. Ergebniscodes geben den Grund für den Verbindungsabbau an.

Ergebniscodes für StopCCN umfassen unter anderem:

  • 1: Allgemeiner Fehler (General error)
  • 2: Keine Ressourcen verfügbar (No resources available)
  • 3: Ungültige Gegenstellen-ID (Invalid peer ID)
  • 4: Protokollfehler (Protocol error)
  • 5: Verbindung wurde getrennt (Connection was disconnected)

10.4 Framing Capabilities & Bearer Capabilities (Rahmenfähigkeiten und Trägerfähigkeiten)​

Die IANA verwaltet die Bitwerte für die Framing Capabilities AVP (Rahmenfähigkeiten-Attribut-Wert-Paar) und die Bearer Capabilities AVP (Trägerfähigkeiten-Attribut-Wert-Paar):

Framing Capabilities:

  • Bit 0: Asynchrones Framing unterstützt
  • Bit 1: Synchrones Framing unterstützt

Bearer Capabilities:

  • Bit 0: Analoger Träger unterstützt
  • Bit 1: Digitaler Träger unterstützt

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

Die IANA verwaltet die Werte für den Proxy Authen Type AVP (Proxy-Authentifizierungstyp-Attribut-Wert-Paar):

WertAuthentifizierungstyp
0Reserviert
1Textuelles Passwort (Textual username/password exchange)
2PPP CHAP
3PPP PAP (Password Authentication Protocol)
4Kein Authentifizierungsprotokoll (No Authentication)
5Microsoft CHAP Version 1 (MSCHAPv1)

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

Die IANA verwaltet die Bitwerte im AVP-Header. Folgende Bits sind definiert:

  • M-Bit (Mandatory): Gibt an, ob das AVP für den Empfänger obligatorisch ist. Wenn dieses Bit gesetzt ist und der Empfänger das AVP nicht versteht, MUSS er die Verbindung abbauen.
  • H-Bit (Hidden): Gibt an, ob der AVP-Wert verborgen (verschlüsselt) ist.
  • Reservierte Bits: MÜSSEN auf 0 gesetzt und beim Empfang ignoriert werden.

11. References (Referenzen)​

Normative References (Normative Referenzen)​

  • [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Juli 1994.
  • [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, Juli 1994.
  • [RFC1700] Reynolds, J. und J. Postel, "Assigned Numbers", STD 2, RFC 1700, Oktober 1994.
  • [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, März 1997.

Informative References (Informative Referenzen)​

  • [RFC2138] Rigney, C., Rubens, A., Simpson, W. und S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
  • [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, Januar 1998.
  • [RFC2401] Kent, S. und R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
  • [RFC2406] Kent, S. und R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

12. Acknowledgments (Danksagungen)​

Die Autoren von RFC 2661 danken allen Mitgliedern der IETF L2TP-Arbeitsgruppe für ihre wertvollen Beiträge, Diskussionen und Überprüfungen, die zur Entwicklung dieses Standards geführt haben.

Besonderer Dank gilt den Personen, die frühere Entwürfe dieses Dokuments sorgfältig gelesen und kommentiert haben, sowie den Implementierern, die durch ihre praktische Erfahrung zur Verbesserung der Spezifikation beigetragen haben.

13. Authors' Addresses (Autorenanschriften)​

W. Mark Townsley
Cisco Systems
E-Mail: [email protected]

Allan Valencia
Cisco Systems
E-Mail: [email protected]

Gurdeep Singh Pall
Microsoft Corporation
E-Mail: [email protected]

Glen Zorn
Microsoft Corporation
E-Mail: [email protected]

Bay Leiner
E-Mail: [email protected]

Diese Übersetzung basiert auf RFC 2661 – "Layer Two Tunneling Protocol (L2TP)", August 1999. Das vollständige Originaldokument ist unter https://www.rfc-editor.org/rfc/rfc2661 verfügbar.

Letztes Update am