5. Considerazioni sulla sicurezza (Security Considerations)

La sicurezza dei dati utente trasmessi sulla connessione PPP tunnelizzata è gestita da PPP, così come l'autenticazione dei peer PPP.

Poiché i messaggi del canale di controllo PPTP non sono né autenticati né protetti in integrità, potrebbe essere possibile per un attaccante dirottare la connessione TCP sottostante. È anche possibile fabbricare falsi messaggi del canale di controllo e alterare messaggi genuini in transito senza rilevamento.

I pacchetti GRE che formano il tunnel stesso non sono protetti crittograficamente. Poiché le negoziazioni PPP vengono effettuate sul tunnel, potrebbe essere possibile per un attaccante intercettare e modificare tali negoziazioni.

A meno che i dati del payload PPP non siano protetti crittograficamente, possono essere catturati e letti o modificati.

6. Indirizzi degli autori (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. Riferimenti (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. Dichiarazione completa di copyright (Full Copyright Statement)

Questo documento e le sue traduzioni possono essere copiati e forniti ad altri, e opere derivate che commentano o spiegano altrimenti o assistono nella sua implementazione possono essere preparate, copiate, pubblicate e distribuite, in tutto o in parte, senza restrizioni di alcun tipo, purché l'avviso di copyright sopra riportato e questo paragrafo siano inclusi in tutte tali copie e opere derivate. Tuttavia, questo documento stesso non può essere modificato in alcun modo, come rimuovendo l'avviso di copyright o i riferimenti all'Internet Society o ad altre organizzazioni Internet, tranne quando necessario per lo scopo di sviluppare standard Internet, nel qual caso devono essere seguite le procedure di copyright definite nel processo degli standard Internet, o come richiesto per tradurlo in lingue diverse dall'inglese.

I permessi limitati concessi sopra sono perpetui e non saranno revocati dall'Internet Society o dai suoi successori o cessionari.

Questo documento e le informazioni in esso contenute sono fornite "COSÌ COME SONO" e l'Internet Society e l'Internet Engineering Task Force DECLINANO TUTTE LE GARANZIE, ESPRESSE O IMPLICITE, INCLUSE MA NON LIMITATE A QUALSIASI GARANZIA CHE L'USO DELLE INFORMAZIONI QUI CONTENUTE NON VIOLI ALCUN DIRITTO O QUALSIASI GARANZIA IMPLICITA DI COMMERCIABILITÀ O IDONEITÀ PER UN PARTICOLARE SCOPO.