5. Sicherheitsüberlegungen (Security Considerations)

Die Sicherheit von Benutzerdaten, die über die getunnelte PPP-Verbindung übertragen werden, wird von PPP behandelt, ebenso wie die Authentifizierung der PPP-Peers.

Da PPTP-Steuerkanalnachrichten weder authentifiziert noch integritätsgeschützt sind, könnte es einem Angreifer möglich sein, die zugrunde liegende TCP-Verbindung zu entführen. Es ist auch möglich, falsche Steuerkanalnachrichten herzustellen und echte Nachrichten während der Übertragung unentdeckt zu ändern.

Die GRE-Pakete, die den Tunnel selbst bilden, sind nicht kryptographisch geschützt. Da die PPP-Verhandlungen über den Tunnel durchgeführt werden, kann es einem Angreifer möglich sein, diese Verhandlungen abzuhören und zu modifizieren.

Sofern die PPP-Nutzdaten nicht kryptographisch geschützt sind, können sie erfasst und gelesen oder modifiziert werden.

6. Autorenadressen (Authors' Addresses)

Kory Hamzeh
Ascend Communications
1275 Harbor Bay Parkway
Alameda, CA 94502
Email: [email protected]

Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
Email: [email protected]

William Verthein
U.S. Robotics/3Com

Jeff Taarud
Copper Mountain Networks

W. Andrew Little
ECI Telematics

Glen Zorn
Microsoft Corporation
Redmond, WA
Email: [email protected]

7. Referenzen (References)

[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.

[2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.

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

[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.

[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html

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

[8] Ethertype for PPP, Reserved with Xerox Corporation.

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

[10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.

[11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-Wesley, 1994.

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

8. Vollständige Urheberrechtserklärung (Full Copyright Statement)

Dieses Dokument und Übersetzungen davon dürfen kopiert und anderen zur Verfügung gestellt werden, und abgeleitete Werke, die es kommentieren oder anderweitig erklären oder bei seiner Implementierung helfen, dürfen ganz oder teilweise ohne Einschränkung jeglicher Art vorbereitet, kopiert, veröffentlicht und verteilt werden, vorausgesetzt, dass der obige Urheberrechtshinweis und dieser Absatz in allen solchen Kopien und abgeleiteten Werken enthalten sind. Dieses Dokument selbst darf jedoch in keiner Weise geändert werden, z. B. durch Entfernen des Urheberrechtshinweises oder Verweisen auf die Internet Society oder andere Internet-Organisationen, außer wenn dies für die Entwicklung von Internet-Standards erforderlich ist, in welchem Fall die im Internet Standards Process definierten Urheberrechtsverfahren befolgt werden müssen, oder wie erforderlich, um es in andere Sprachen als Englisch zu übersetzen.

Die oben gewährten eingeschränkten Berechtigungen sind unbefristet und werden von der Internet Society oder ihren Nachfolgern oder Rechtsnachfolgern nicht widerrufen.

Dieses Dokument und die hierin enthaltenen Informationen werden "WIE BESEHEN" bereitgestellt, und die Internet Society und die Internet Engineering Task Force LEHNEN ALLE GARANTIEN AB, AUSDRÜCKLICH ODER STILLSCHWEIGEND, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF JEGLICHE GARANTIE, DASS DIE VERWENDUNG DER HIERIN ENTHALTENEN INFORMATIONEN KEINE RECHTE VERLETZT ODER JEGLICHE STILLSCHWEIGENDE GARANTIEN DER MARKTGÄNGIGKEIT ODER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK.