5. Considérations de sécurité (Security Considerations)

La sécurité des données utilisateur transmises sur la connexion PPP tunnelisée est traitée par PPP, tout comme l'authentification des pairs PPP.

Étant donné que les messages du canal de contrôle PPTP ne sont ni authentifiés ni protégés en intégrité, il pourrait être possible pour un attaquant de détourner la connexion TCP sous-jacente. Il est également possible de fabriquer de faux messages de canal de contrôle et de modifier les messages authentiques en transit sans détection.

Les paquets GRE formant le tunnel lui-même ne sont pas protégés cryptographiquement. Étant donné que les négociations PPP sont effectuées sur le tunnel, il peut être possible pour un attaquant d'écouter et de modifier ces négociations.

À moins que les données de charge utile PPP ne soient protégées cryptographiquement, elles peuvent être capturées et lues ou modifiées.

6. Adresses des auteurs (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. Références (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. Déclaration complète de copyright (Full Copyright Statement)

Ce document et ses traductions peuvent être copiés et fournis à d'autres, et les œuvres dérivées qui commentent ou expliquent autrement ce document ou aident à sa mise en œuvre peuvent être préparées, copiées, publiées et distribuées, en tout ou en partie, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soient inclus dans toutes ces copies et œuvres dérivées. Cependant, ce document lui-même ne peut être modifié d'aucune manière, par exemple en supprimant l'avis de copyright ou les références à l'Internet Society ou à d'autres organisations Internet, sauf si cela est nécessaire dans le but de développer des normes Internet, auquel cas les procédures de copyright définies dans le processus des normes Internet doivent être suivies, ou selon les besoins pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par l'Internet Society ou ses successeurs ou ayants droit.

Ce document et les informations qu'il contient sont fournis "TELS QUELS" et l'Internet Society et l'Internet Engineering Task Force DÉCLINENT TOUTES GARANTIES, EXPRESSES OU IMPLICITES, Y COMPRIS MAIS SANS S'Y LIMITER TOUTE GARANTIE QUE L'UTILISATION DES INFORMATIONS ICI CONTENUES NE VIOLE AUCUN DROIT OU TOUTE GARANTIE IMPLICITE DE QUALITÉ MARCHANDE OU D'ADÉQUATION À UN USAGE PARTICULIER.