RFC 2661 - Layer Two Tunneling Protocol (L2TP)

Stato: Proposed Standard
Pubblicato: August 1999
Stream: IETF
Errata: Nessun errata

Sommario (Abstract)

Questo documento descrive il Layer Two Tunneling Protocol (L2TP). STD 51, RFC 1661 definisce l'accesso multiprotocollo tramite PPP. L2TP facilita il tunneling dei pacchetti PPP attraverso reti intermedie in modo il più possibile trasparente per utenti finali e applicazioni.

Indice (Contents)

1. Introduction (Introduzione)
- 1.1 Specification of Requirements (Specifiche dei requisiti)
- 1.2 Terminology (Terminologia)
2. Topology (Topologia)
3. Protocol Overview (Panoramica del protocollo)
- 3.1 L2TP Header Format (Formato dell'intestazione L2TP)
- 3.2 Control Message Types (Tipi di messaggi di controllo)
4. Control Message Attribute Value Pairs (Coppie attributo-valore dei messaggi di controllo)
- 4.1 AVP Format (Formato AVP)
- 4.2 Mandatory AVPs (AVP obbligatori)
- 4.3 Hiding of AVP Attribute Values (Occultamento dei valori degli attributi AVP)
- 4.4 AVP Summary (Riepilogo AVP)
  - 4.4.1 AVPs Applicable To All Control Messages (AVP applicabili a tutti i messaggi di controllo)
  - 4.4.2 Result and Error Codes (Codici di risultato e di errore)
  - 4.4.3 Control Connection Management AVPs (AVP di gestione della connessione di controllo)
  - 4.4.4 Call Management AVPs (AVP di gestione delle chiamate)
  - 4.4.5 Proxy LCP and Authentication AVPs (AVP di proxy LCP e autenticazione)
  - 4.4.6 Call Status AVPs (AVP di stato delle chiamate)
5. Protocol Operation (Funzionamento del protocollo)
- 5.1 Control Connection Establishment (Stabilimento della connessione di controllo)
  - 5.1.1 Tunnel Authentication (Autenticazione del tunnel)
- 5.2 Session Establishment (Stabilimento della sessione)
  - 5.2.1 Incoming Call Establishment (Stabilimento di chiamata in ingresso)
  - 5.2.2 Outgoing Call Establishment (Stabilimento di chiamata in uscita)
- 5.3 Forwarding PPP Frames (Inoltro di frame PPP)
- 5.4 Using Sequence Numbers on the Data Channel (Utilizzo di numeri di sequenza sul canale dati)
- 5.5 Keepalive (Hello) (Meccanismo keepalive)
- 5.6 Session Teardown (Chiusura della sessione)
- 5.7 Control Connection Teardown (Chiusura della connessione di controllo)
- 5.8 Reliable Delivery of Control Messages (Consegna affidabile dei messaggi di controllo)
6. Control Connection Protocol Specification (Specifica del protocollo di connessione di controllo)
- 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 (Macchine a stati della connessione di controllo)
- 7.1 Control Connection Protocol Operation (Funzionamento del protocollo di connessione di controllo)
- 7.2 Control Connection States (Stati della connessione di controllo)
  - 7.2.1 Control Connection Establishment (Stabilimento della connessione di controllo)
- 7.3 Timing considerations (Considerazioni temporali)
- 7.4 Incoming calls (Chiamate in ingresso)
  - 7.4.1 LAC Incoming Call States (Stati di chiamata in ingresso LAC)
  - 7.4.2 LNS Incoming Call States (Stati di chiamata in ingresso LNS)
- 7.5 Outgoing calls (Chiamate in uscita)
  - 7.5.1 LAC Outgoing Call States (Stati di chiamata in uscita LAC)
  - 7.5.2 LNS Outgoing Call States (Stati di chiamata in uscita LNS)
- 7.6 Tunnel Disconnection (Disconnessione del tunnel)
8. L2TP Over Specific Media (L2TP su media specifici)
- 8.1 L2TP over UDP/IP
- 8.2 IP
9. Security Considerations (Considerazioni sulla sicurezza)
- 9.1 Tunnel Endpoint Security (Sicurezza degli endpoint del tunnel)
- 9.2 Packet Level Security (Sicurezza a livello di pacchetto)
- 9.3 End to End Security (Sicurezza end-to-end)
- 9.4 L2TP and IPsec
- 9.5 Proxy PPP Authentication (Autenticazione PPP proxy)
10. IANA Considerations (Considerazioni IANA)
- 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 (Riferimenti)
12. Acknowledgments (Ringraziamenti)
13. Authors' Addresses (Indirizzi degli autori)

Appendici (Appendices)

Risorse correlate

Testo originale ufficiale: RFC 2661
Pagina ufficiale: RFC 2661 DataTracker
Errata: RFC Editor Errata

7. Control Connection State Machines (Macchine a stati della connessione di controllo)

Questo capitolo definisce le macchine a stati per l'istituzione, la manutenzione e la chiusura delle connessioni di controllo e delle sessioni L2TP.

7.1 Control Connection Protocol Operation (Funzionamento del protocollo della connessione di controllo)

La macchina a stati della connessione di controllo descrive le transizioni di stato durante l'istituzione e la chiusura dei tunnel. Ogni stato definisce gli eventi accettabili, le azioni corrispondenti e lo stato successivo.

7.2 Control Connection States (Stati della connessione di controllo)

La connessione di controllo comprende gli stati seguenti:

idle: stato iniziale; non è stabilita alcuna connessione
wait-ctl-reply: attesa della risposta alla connessione di controllo dal peer
wait-ctl-conn: attesa del completamento della connessione di controllo
established: connessione di controllo stabilita
closing: connessione di controllo in chiusura

7.2.1 Control Connection Establishment (Istituzione della connessione di controllo)

L'istituzione della connessione di controllo viene completata tramite un handshake a tre vie (SCCRQ, SCCRP, SCCCN). Le transizioni di stato includono:

idle -> wait-ctl-reply (invio di SCCRQ)
wait-ctl-reply -> wait-ctl-conn (ricezione di SCCRP)
wait-ctl-conn -> established (ricezione di SCCCN)

7.3 Timing Considerations (Considerazioni sui temporizzatori)

Timer di ritrasmissione: usato per ritrasmettere in modo affidabile i messaggi di controllo
Intervallo Hello: intervallo per l'invio periodico dei messaggi Hello
Rilevamento del timeout: meccanismo di timeout per rilevare guasti del tunnel

7.4 Incoming Calls (Chiamate in ingresso)

L'istituzione delle chiamate in ingresso comporta transizioni di stato coordinate tra LAC e LNS.

7.4.1 LAC Incoming Call States (Stati LAC per chiamate in ingresso)

Stati delle chiamate in ingresso lato LAC:

idle: nessuna chiamata attiva
wait-reply: attesa di ICRP dal LNS
wait-connect: attesa della connessione della chiamata
established: sessione stabilita

7.4.2 LNS Incoming Call States (Stati LNS per chiamate in ingresso)

Stati delle chiamate in ingresso lato LNS:

idle: nessuna chiamata attiva
wait-connect: attesa di ICCN dal LAC
established: sessione stabilita

7.5 Outgoing Calls (Chiamate in uscita)

Le chiamate in uscita sono avviate dal LNS, mentre il LAC esegue l'operazione di chiamata effettiva.

7.5.1 LAC Outgoing Call States (Stati LAC per chiamate in uscita)

Stati delle chiamate in uscita lato LAC:

idle: nessuna chiamata attiva
wait-reply: attesa di una risposta a OCRQ
wait-cs-answer: attesa della risposta alla chiamata
established: sessione stabilita

7.5.2 LNS Outgoing Call States (Stati LNS per chiamate in uscita)

Stati delle chiamate in uscita lato LNS:

idle: nessuna chiamata attiva
wait-reply: attesa di OCRP dal LAC
wait-connect: attesa di OCCN
established: sessione stabilita

7.6 Tunnel Disconnection (Disconnessione del tunnel)

La disconnessione del tunnel può essere avviata dal LAC o dal LNS inviando un messaggio StopCCN. Dopo la ricezione di StopCCN, il peer dovrebbe confermare il messaggio e liberare tutte le risorse correlate.

Nota: per le tabelle complete delle transizioni di stato e i diagrammi dettagliati delle macchine a stati, consultare il testo originale di RFC 2661. Questo capitolo fornisce una panoramica delle macchine a stati e dei principali flussi di transizione.

8. L2TP Over Specific Media (L2TP su media specifici)

Questo capitolo descrive i dettagli implementativi di L2TP su tipi di media specifici. L2TP è progettato per operare su vari media di trasporto pacchetti, tra cui UDP/IP, Frame Relay, ATM, ecc.

8.1 L2TP over UDP/IP (L2TP su UDP/IP)

L2TP utilizza la porta UDP registrata 1701 per la comunicazione tra gli endpoint del tunnel. UDP fornisce il servizio di trasporto pacchetti sia per i messaggi di controllo L2TP che per i messaggi dati.

Assegnazione delle porte:

Porta sorgente: Il mittente può utilizzare qualsiasi porta UDP disponibile come porta sorgente.
Porta di destinazione: Deve utilizzare la porta UDP 1701.

Incapsulamento dei pacchetti:

Il formato di incapsulamento per i pacchetti L2TP su UDP/IP è il seguente:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Intestazione IP                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Intestazione UDP                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Intestazione L2TP                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Messaggio di controllo L2TP o          |
|                  Payload PPP                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Checksum UDP:

Il checksum UDP dovrebbe essere calcolato e incluso in tutti i pacchetti L2TP. I ricevitori devono verificare il checksum se presente. Se la verifica del checksum fallisce, il pacchetto deve essere scartato.

Considerazioni MTU:

Poiché L2TP aggiunge ulteriori livelli di incapsulamento (intestazione L2TP + intestazione UDP + intestazione IP), le implementazioni devono considerare il MTU del percorso. Overhead di incapsulamento tipico:

Intestazione IP: 20 byte (IPv4) o 40 byte (IPv6)
Intestazione UDP: 8 byte
Intestazione L2TP: Almeno 6 byte (può essere di più a seconda delle opzioni)

Frammentazione:

Si raccomanda alle implementazioni L2TP di evitare la frammentazione IP. Questo può essere ottenuto tramite:

Scoperta del MTU del percorso
Negoziazione della MRU (Maximum Receive Unit) durante l'istituzione del tunnel
Esecuzione della frammentazione a livello PPP anziché a livello IP

8.2 IP (Protocollo Internet)

I pacchetti L2TP utilizzano IP come protocollo di trasporto pacchetti. IP fornisce un servizio di trasporto pacchetti end-to-end per L2TP.

Supporto versioni IP:

L2TP è progettato per operare su IPv4 [RFC791] e IPv6 [RFC2460]. Le implementazioni dovrebbero supportare almeno una versione IP e possono opzionalmente supportare entrambe.

Considerazioni specifiche per IPv4:

Tipo di protocollo: Quando si utilizza l'incapsulamento UDP, il campo protocollo IP è impostato su 17 (UDP).
Tipo di servizio (TOS): Le implementazioni L2TP possono impostare il campo TOS IP per indicare i requisiti di qualità del servizio. I messaggi di controllo possono richiedere una priorità più alta rispetto ai messaggi dati.
Tempo di vita (TTL): Dovrebbe essere impostato un valore TTL appropriato per impedire che i pacchetti circolino indefinitamente nella rete.

Considerazioni specifiche per IPv6:

Intestazione successiva: Quando si utilizza l'incapsulamento UDP, impostato su 17 (UDP).
Etichetta di flusso: L'etichetta di flusso IPv6 può essere utilizzata per identificare i flussi di pacchetti appartenenti allo stesso tunnel per l'elaborazione QoS.
Limite di hop: Equivalente al TTL di IPv4.

Selezione dell'indirizzo:

LAC e LNS devono essere in grado di determinare l'indirizzo IP del peer. Questo può essere ottenuto tramite:

Configurazione statica
Risoluzione DNS
Meccanismi di scoperta dinamica

Considerazioni multi-homing:

Se un endpoint del tunnel ha più indirizzi IP (multi-homing), le implementazioni devono assicurarsi che tutti i pacchetti per un tunnel utilizzino un indirizzo sorgente coerente. Questo è fondamentale per mantenere lo stato del tunnel e prevenire confusione.

Sicurezza:

Quando L2TP opera su IP, si raccomanda vivamente di utilizzare IPsec [RFC2401] per proteggere il traffico del tunnel. IPsec può fornire:

Riservatezza: Attraverso la crittografia ESP
Integrità: Attraverso l'autenticazione AH o ESP
Autenticazione degli endpoint: Attraverso IKE

Le considerazioni dettagliate sulla sicurezza sono trattate nel Capitolo 9.

Note implementative:

Multiplexing delle porte: Più tunnel possono essere stabiliti tra la stessa coppia di indirizzi IP, differenziati dall'ID del tunnel.
Attraversamento NAT: Quando L2TP deve attraversare dispositivi NAT, possono essere necessari meccanismi aggiuntivi (come L2TP/IPsec NAT-T).
Considerazioni sul firewall: I firewall devono consentire la comunicazione bidirezionale sulla porta UDP 1701 per supportare L2TP.
Mappatura QoS: Le implementazioni possono mappare i requisiti QoS dal livello PPP al campo DSCP o TOS del livello IP.

9. Security Considerations (Considerazioni sulla sicurezza)

Il protocollo L2TP stesso non fornisce servizi di crittografia o autenticazione forte. Questo capitolo discute le considerazioni sulla sicurezza nelle distribuzioni L2TP e i meccanismi di sicurezza disponibili.

9.1 Tunnel Endpoint Security (Sicurezza degli endpoint del tunnel)

La relazione di fiducia tra gli endpoint del tunnel è fondamentale per la sicurezza L2TP.

Autenticazione degli endpoint:

LAC e LNS devono essere in grado di verificare reciprocamente l'identità. L2TP fornisce un meccanismo di autenticazione del tunnel opzionale:

Challenge AVP: L'iniziatore invia un valore di sfida casuale nello SCCRQ (Start-Control-Connection-Request).
Challenge Response AVP: Il risponditore calcola una risposta basata su un segreto condiviso e la restituisce nello SCCRP (Start-Control-Connection-Reply).
Calcolo della risposta: Utilizza la funzione hash MD5: MD5(Tipo di messaggio + segreto_condiviso + Sfida + ID_Sessione)

Gestione dei segreti condivisi:

I segreti condivisi dovrebbero avere un'entropia sufficiente (almeno 128 bit raccomandati).
I segreti condivisi dovrebbero essere memorizzati in modo sicuro (memorizzazione crittografata).
I segreti condivisi dovrebbero essere rinnovati periodicamente.
Coppie di tunnel diverse dovrebbero utilizzare segreti condivisi diversi.

Autorizzazione del tunnel:

Oltre all'autenticazione, dovrebbero essere implementati meccanismi di autorizzazione:

Verificare che il peer sia autorizzato a stabilire un tunnel.
Controllare se il peer ha il permesso di accedere a risorse o servizi specifici.
Utilizzare Access Control List (ACL) per limitare quali peer possono stabilire tunnel.

Vulnerabilità e mitigazioni:

Attacco Man-in-the-Middle:
- Rischio: L'autenticazione del tunnel L2TP basata su segreti condivisi è vulnerabile agli attacchi MITM.
- Mitigazione: Utilizzare IPsec per fornire crittografia e autenticazione end-to-end.
Attacco di replay:
- Rischio: Gli attaccanti possono riprodurre messaggi di controllo catturati.
- Mitigazione: Utilizzare numeri di sequenza e meccanismi ZLB ACK per rilevare e prevenire attacchi di replay.
Attacco Denial of Service:
- Rischio: Gli attaccanti possono inviare grandi quantità di richieste di stabilimento tunnel.
- Mitigazione:
  - Limitare il numero di tunnel simultanei per indirizzo sorgente.
  - Implementare la limitazione della velocità.
  - Utilizzare meccanismi Cookie (simili ai cookie TCP SYN).

9.2 Packet Level Security (Sicurezza a livello di pacchetto)

L2TP stesso non fornisce crittografia dei pacchetti o protezione dell'integrità.

Rischi della trasmissione in chiaro:

Intercettazione: Gli attaccanti possono intercettare e leggere il contenuto dei pacchetti PPP, incluse le credenziali utente e i dati dell'applicazione.
Manomissione: Gli attaccanti possono modificare i pacchetti in transito.
Iniezione: Gli attaccanti possono iniettare pacchetti dannosi nel tunnel.

Meccanismo di occultamento AVP:

L2TP fornisce un meccanismo di occultamento AVP per proteggere le informazioni di controllo sensibili:

Processo di occultamento:
1. Generare hash MD5 utilizzando il segreto condiviso e il vettore casuale.
2. Eseguire XOR del valore hash con il valore AVP.
3. Ripetere il processo se il valore AVP supera i 16 byte.
Limitazioni:
- L'occultamento AVP è offuscamento, non vera crittografia.
- Non protegge il canale dati, solo AVP specifici nel canale di controllo.
- Vulnerabile ad attacchi dizionario (se il segreto condiviso è debole).

Raccomandazioni:

Non fare affidamento sull'occultamento AVP come unico meccanismo di sicurezza.
Utilizzare IPsec o altre tecnologie di crittografia a livello tunnel.

9.3 End to End Security (Sicurezza end-to-end)

Anche quando il tunnel L2TP stesso è protetto, la sicurezza end-to-end rimane importante.

Autenticazione a livello PPP:

L'autenticazione indipendente dovrebbe avvenire tra il sistema remoto e l'LNS:

PAP (Password Authentication Protocol):
- Autenticazione tramite password in chiaro semplice.
- Non raccomandato, poiché le password vengono trasmesse in chiaro (dovrebbe essere evitato anche all'interno di tunnel L2TP crittografati).
CHAP (Challenge Handshake Authentication Protocol):
- Meccanismo di autenticazione sfida-risposta.
- Le password non vengono trasmesse in chiaro.
- Riautenticazione periodica per prevenire attacchi di replay.
EAP (Extensible Authentication Protocol):
- Supporta vari metodi di autenticazione (EAP-TLS, EAP-TTLS, PEAP, ecc.).
- Può fornire autenticazione reciproca e negoziazione delle chiavi.
- EAP-TLS è raccomandato per la sicurezza più forte.

Crittografia end-to-end:

La crittografia a livello applicazione fornisce un ulteriore livello di sicurezza:

TLS/SSL: Utilizzato per proteggere i dati dell'applicazione (ad es., HTTPS).
Software client VPN: Fornisce un ulteriore livello di crittografia sopra PPP.

Strategia di difesa in profondità:

Sistema remoto &lt;--Auth/Crittog PPP--> LNS
    |                                    |
    +--&lt;Tunnel L2TP>--LAC----------------+
              |
         &lt;Protezione IPsec>

Livello 1: Autenticazione a livello PPP (CHAP/EAP)
Livello 2: Autenticazione del tunnel L2TP
Livello 3: Crittografia e autenticazione IPsec
Livello 4: Crittografia a livello applicazione (TLS/SSL)

9.4 L2TP and IPsec (L2TP e IPsec)

Si raccomanda vivamente di utilizzare L2TP in combinazione con IPsec, comunemente indicato come L2TP/IPsec.

Servizi di sicurezza forniti da IPsec:

Riservatezza:
- Fornita tramite crittografia ESP (Encapsulating Security Payload).
- Supporta più algoritmi di crittografia: AES, 3DES, ChaCha20, ecc.
Integrità:
- Fornita tramite AH (Authentication Header) o autenticazione ESP.
- Utilizza HMAC (ad es., HMAC-SHA256) per verificare l'integrità dei dati.
Autenticazione della sorgente:
- Verifica l'autenticità delle sorgenti dei pacchetti.
- Previene attacchi di spoofing IP.
Anti-replay:
- Utilizza numeri di sequenza per prevenire attacchi di replay.

Architettura L2TP/IPsec:

+-------------------+
|   Payload PPP     |
+-------------------+
|   Intestazione L2TP|
+-------------------+
|   Intestazione UDP |
+-------------------+
|   Intestazione ESP | &lt;-- Crittografia e autenticazione IPsec
+-------------------+
|   Intestazione IP  |
+-------------------+

Opzioni di configurazione IPsec:

Modalità trasporto:
- Crittografa e autentica solo il payload IP.
- Adatto per comunicazione end-to-end.
- Raccomandato per L2TP/IPsec.
Modalità tunnel:
- Crittografa e autentica l'intero pacchetto IP.
- Aggiunge una nuova intestazione IP esterna.
- Adatto per comunicazione gateway-to-gateway.

Gestione delle chiavi:

IKE (Internet Key Exchange):
- IKEv1: Versione originale, negoziazione in due fasi.
- IKEv2: Versione migliorata, più snella ed efficiente.
- IKEv2 è raccomandato per la negoziazione delle chiavi.
Chiave pre-condivisa vs Certificati:
- Chiave pre-condivisa (PSK): Semplice da configurare, ma difficile distribuire le chiavi.
- Certificati: Più sicuri, supportano distribuzioni su larga scala, fortemente raccomandati.

Attraversamento NAT (NAT-T):

Quando L2TP/IPsec deve attraversare dispositivi NAT:

Utilizzare incapsulamento UDP di ESP (porta UDP 4500).
Inviare periodicamente pacchetti di keepalive NAT.
IKEv2 ha supporto NAT-T integrato.

Considerazioni sulle prestazioni:

La crittografia IPsec aggiunge overhead CPU.
Considerare l'utilizzo dell'accelerazione hardware (AES-NI, ecc.).
La riduzione MTU deve essere considerata (intestazione ESP + trailer ESP + dati di autenticazione).

9.5 Proxy PPP Authentication (Autenticazione PPP proxy)

L2TP consente al LAC di eseguire l'autenticazione PPP iniziale per conto dell'LNS.

Meccanismo di autenticazione proxy:

Il LAC può negoziare LCP ed eseguire l'autenticazione con il sistema remoto prima di inoltrare la chiamata all'LNS:

LAC esegue l'autenticazione PPP:
- LAC negozia LCP con il sistema remoto.
- LAC esegue l'autenticazione PAP o CHAP.
- LAC raccoglie informazioni di autenticazione (nome utente, hash password, ecc.).
LAC inoltra le informazioni di autenticazione all'LNS:
- Utilizza AVP proxy per passare le informazioni di autenticazione:
  - Proxy Authen Type AVP (29): Tipo di autenticazione (PAP, CHAP, ecc.)
  - Proxy Authen Name AVP (30): Nome utente
  - Proxy Authen Challenge AVP (31): Valore di sfida CHAP
  - Proxy Authen Response AVP (33): Risposta di autenticazione
LNS verifica le informazioni di autenticazione:
- LNS verifica l'utente in base alle informazioni fornite dal LAC.
- LNS può accettare o rifiutare la sessione.

Rischi per la sicurezza:

Compromissione LAC:
- Se il LAC viene compromesso, gli attaccanti possono ottenere le credenziali utente.
- Mitigazione: Utilizzare IPsec per proteggere la comunicazione tra LAC e LNS.
Trasmissione password in chiaro:
- Le password PAP vengono trasmesse in chiaro dal LAC all'LNS (negli AVP).
- Mitigazione: Utilizzare il meccanismo di occultamento AVP o la crittografia IPsec.
Confine di fiducia:
- L'LNS deve fidarsi completamente delle informazioni di autenticazione fornite dal LAC.
- Un LAC malevolo può falsificare le informazioni di autenticazione.
- Mitigazione:
  - Utilizzare l'autenticazione proxy solo tra domini di gestione fidati.
  - Considerare di richiedere la riautenticazione end-to-end.

Migliori pratiche:

Evitare l'autenticazione PAP proxy:
- Le password PAP sono vulnerabili agli attacchi anche quando occultate.
- Se deve essere utilizzato, assicurare la protezione IPsec.
Preferire l'autenticazione end-to-end:
- Consentire al sistema remoto di autenticarsi direttamente con l'LNS (senza proxy).
- Utilizzare metodi EAP per una sicurezza più forte.
Limitare i casi d'uso dell'autenticazione proxy:
- Utilizzare solo quando necessario (ad es., stabilimento rapido della chiamata).
- Utilizzare in ambienti di rete fidati.
Combinare più metodi di autenticazione:
- LAC esegue l'autenticazione preliminare (per filtraggio rapido).
- LNS esegue l'autenticazione secondaria (verifica end-to-end).

Integrazione dell'autenticazione proxy con RADIUS:

Sistema remoto &lt;--PAP/CHAP--> LAC &lt;--RADIUS--> Server RADIUS
                                |
                                |
                                v
                          (Inoltra info auth)
                                |
                                v
                               LNS &lt;--RADIUS--> Server RADIUS

LAC può utilizzare RADIUS per verificare le credenziali utente.
LNS può anche verificare indipendentemente utilizzando RADIUS.
La doppia verifica fornisce un ulteriore livello di sicurezza.

Lista di controllo configurazione sicurezza:

10. IANA Considerations (Considerazioni IANA)

Questo capitolo definisce vari parametri che richiedono l'assegnazione e la gestione da parte dell'IANA (Internet Assigned Numbers Authority) per il protocollo L2TP.

10.1 AVP Attributes (Attributi AVP)

L'IANA è responsabile della manutenzione del registro dei tipi di attributi AVP L2TP. Il tipo di attributo AVP è un campo a 16 bit.

Requisiti di registrazione:

Intervallo di valori 0-1023: Assegnati tramite consenso IETF (richiede la pubblicazione di una RFC).
Intervallo di valori 1024-65535: Assegnati utilizzando la politica "Primo arrivato, primo servito".

Tipi di attributi AVP standard assegnati:

Tipo di attributo	Nome AVP	Riferimento
0	Tipo di messaggio	RFC 2661 Section 4.4.1
1	Codice risultato	RFC 2661 Section 4.4.2
2	Versione del protocollo	RFC 2661 Section 4.4.3
3	Capacità di frame	RFC 2661 Section 4.4.3
4	Capacità del supporto	RFC 2661 Section 4.4.3
5	Spareggio	RFC 2661 Section 4.4.3
6	Revisione del firmware	RFC 2661 Section 4.4.3
7	Nome host	RFC 2661 Section 4.4.3
8	Nome del fornitore	RFC 2661 Section 4.4.3
9	ID tunnel assegnato	RFC 2661 Section 4.4.3
10	Dimensione finestra di ricezione	RFC 2661 Section 4.4.3
11	Sfida	RFC 2661 Section 4.4.3
12	Codice causa Q.931	RFC 2661 Section 4.4.4
13	Risposta alla sfida	RFC 2661 Section 4.4.3
14	ID sessione assegnato	RFC 2661 Section 4.4.4
15	Numero seriale chiamata	RFC 2661 Section 4.4.4
16	BPS minimo	RFC 2661 Section 4.4.4
17	BPS massimo	RFC 2661 Section 4.4.4
18	Tipo di supporto	RFC 2661 Section 4.4.4
19	Tipo di frame	RFC 2661 Section 4.4.4
20	Ritardo elaborazione pacchetti	RFC 2661 Section 4.4.6
21	Numero chiamato	RFC 2661 Section 4.4.4
22	Numero chiamante	RFC 2661 Section 4.4.4
23	Sottoindirizzo	RFC 2661 Section 4.4.4
24	Velocità connessione Tx	RFC 2661 Section 4.4.4
25	ID canale fisico	RFC 2661 Section 4.4.4
26	LCP CONFREQ ricevuto iniziale	RFC 2661 Section 4.4.5
27	Ultimo LCP CONFREQ inviato	RFC 2661 Section 4.4.5
28	Ultimo LCP CONFREQ ricevuto	RFC 2661 Section 4.4.5
29	Tipo autenticazione proxy	RFC 2661 Section 4.4.5
30	Nome autenticazione proxy	RFC 2661 Section 4.4.5
31	Sfida autenticazione proxy	RFC 2661 Section 4.4.5
32	ID autenticazione proxy	RFC 2661 Section 4.4.5
33	Risposta autenticazione proxy	RFC 2661 Section 4.4.5
34	Errori di chiamata	RFC 2661 Section 4.4.6
35	ACCM	RFC 2661 Section 4.4.6
36	Vettore casuale	RFC 2661 Section 4.3
37	ID gruppo privato	RFC 2661 Section 4.4.4
38	Velocità connessione Rx	RFC 2661 Section 4.4.4
39	Sequenziamento richiesto	RFC 2661 Section 4.4.4

AVP specifici del fornitore:

Gli AVP specifici del fornitore utilizzano il campo Vendor ID (basato sui codici di impresa privati di gestione di rete SMI) per distinguere le estensioni di diversi fornitori.

10.2 Message Type AVP Values (Valori AVP tipo di messaggio)

Il valore AVP del tipo di messaggio (tipo di attributo 0) viene utilizzato per identificare il tipo di messaggio di controllo L2TP.

Valori di tipo di messaggio assegnati:

Valore	Tipo di messaggio	Abbreviazione	Riferimento
0	(Riservato)
1	Richiesta avvio connessione controllo	SCCRQ	RFC 2661 Section 6.1
2	Risposta avvio connessione controllo	SCCRP	RFC 2661 Section 6.2
3	Connessione controllo avviata connessa	SCCCN	RFC 2661 Section 6.3
4	Notifica arresto connessione controllo	StopCCN	RFC 2661 Section 6.4
5	(Riservato)
6	Hello	HELLO	RFC 2661 Section 6.5
7	Richiesta chiamata in uscita	OCRQ	RFC 2661 Section 6.9
8	Risposta chiamata in uscita	OCRP	RFC 2661 Section 6.10
9	Chiamata in uscita connessa	OCCN	RFC 2661 Section 6.11
10	Richiesta chiamata in entrata	ICRQ	RFC 2661 Section 6.6
11	Risposta chiamata in entrata	ICRP	RFC 2661 Section 6.7
12	Chiamata in entrata connessa	ICCN	RFC 2661 Section 6.8
13	(Riservato)
14	Notifica disconnessione chiamata	CDN	RFC 2661 Section 6.12
15	Notifica errore WAN	WEN	RFC 2661 Section 6.13
16	Imposta informazioni collegamento	SLI	RFC 2661 Section 6.14

Politica di registrazione:

L'assegnazione di nuovi valori di tipo di messaggio richiede la pubblicazione di una RFC standard IETF o di una RFC informativa approvata dall'IESG.

10.3 Result Code AVP Values (Valori AVP codice risultato)

L'AVP codice risultato (tipo di attributo 1) viene utilizzato per indicare il motivo della terminazione della connessione di controllo o della sessione.

10.3.1 Result Code Field Values (Valori campo codice risultato)

Codici risultato generali:

Valore	Significato	Ambito
0	Riservato
1	Richiesta generale per cancellare la connessione di controllo	StopCCN
2	Errore generale	StopCCN, CDN
3	Il canale di controllo esiste già	StopCCN
4	Il richiedente non è autorizzato	StopCCN
5	Versione del protocollo non supportata	StopCCN
6	Il richiedente è in fase di arresto	StopCCN
7	Errore macchina a stati finiti	StopCCN

Codici risultato disconnessione chiamata:

Valore	Significato	Ambito
1	Portante persa	CDN
2	Errore generale	CDN
3	Motivo amministrativo	CDN
4	Mancanza temporanea di strutture appropriate	CDN
5	Mancanza permanente di strutture appropriate	CDN
6	Destinazione non valida	CDN
7	Nessuna portante rilevata	CDN
8	Segnale di occupato	CDN
9	Nessun tono di selezione	CDN
10	Timeout in attesa della portante	CDN
11	Nessun frame rilevato	CDN

10.3.2 Error Code Field Values (Valori campo codice errore)

Il campo codice errore fornisce dettagli aggiuntivi sull'errore.

Valore	Messaggio di errore
0	Nessun errore generale
1	Non esiste ancora alcuna connessione di controllo per questa coppia
2	La lunghezza è errata
3	Uno dei valori del campo era fuori intervallo
4	Risorse insufficienti per gestire questa operazione ora
5	ID sessione non valido
6	Si è verificato un errore generico specifico del fornitore
7	Prova un altro (LNS/LAC)
8	La sessione o il tunnel è stato arrestato a causa della ricezione di un AVP sconosciuto con bit M impostato

Politica di registrazione:

L'assegnazione di nuovi valori di codice risultato e codice errore richiede il consenso IETF (richiede la pubblicazione di una RFC).

10.4 Framing Capabilities & Bearer Capabilities (Capacità di frame e capacità del supporto)

L'AVP Framing Capabilities (tipo di attributo 3) e l'AVP Bearer Capabilities (tipo di attributo 4) utilizzano maschere di bit per indicare le capacità supportate.

Definizioni bit capacità di frame:

Bit	Significato
0	Frame asincrono supportato
1	Frame sincrono supportato
2-31	Riservato

Definizioni bit capacità del supporto:

Bit	Significato
0	Accesso analogico supportato
1	Accesso digitale supportato
2-31	Riservato

Politica di registrazione:

L'assegnazione di nuovi bit di capacità richiede il consenso IETF (richiede la pubblicazione di una RFC).

10.5 Proxy Authen Type AVP Values (Valori AVP tipo autenticazione proxy)

L'AVP Proxy Authen Type (tipo di attributo 29) viene utilizzato per indicare il tipo di autenticazione utilizzato dal LAC.

Valori tipo di autenticazione assegnati:

Valore	Tipo di autenticazione	Riferimento
0	Riservato
1	Scambio testuale nome utente/password	RFC 1334 (PAP)
2	PPP CHAP	RFC 1994
3	PPP PAP	RFC 1334
4	Nessuna autenticazione
5	Microsoft CHAP versione 1	RFC 2433
6	Riservato
7	Microsoft CHAP versione 2	RFC 2759

Politica di registrazione:

L'assegnazione di nuovi valori di tipo di autenticazione utilizza la politica "Primo arrivato, primo servito".

10.6 AVP Header Bits (Bit intestazione AVP)

I primi 6 bit dell'intestazione AVP vengono utilizzati come maschera di bit per controllare il comportamento AVP.

Bit intestazione AVP definiti:

Bit	Nome	Significato	Riferimento
0	M (Obbligatorio)	Questo AVP deve essere compreso	RFC 2661 Section 4.1
1	H (Nascosto)	Il valore AVP è nascosto	RFC 2661 Section 4.3
2-5	Riservato	Riservato, deve essere impostato a 0	RFC 2661 Section 4.1

Politica di registrazione:

L'assegnazione di bit riservati richiede un'azione sugli standard - ossia la pubblicazione di una RFC standard IETF.

10.7 L2TP UDP Port (Porta UDP L2TP)

Porta assegnata:

Numero porta: 1701
Protocollo: UDP
Scopo: L2TP
Riferimento: RFC 2661

L'IANA ha assegnato la porta UDP 1701 per L2TP sia per connessioni di controllo che per sessioni dati.

10.8 L2TP Protocol Number (Numero protocollo L2TP)

Sebbene la specifica attuale definisca L2TP operante su UDP, L2TP può anche operare direttamente su altri protocolli di trasporto pacchetti.

Numero protocollo IP:

Numero protocollo L2TP: 115
Nome: L2TP
Riferimento: RFC 3931 (L2TPv3, direttamente su IP)

Manutenzione registro IANA:

L'IANA mantiene i seguenti registri relativi a L2TP:

Registro attributi AVP L2TP
- URL: https://www.iana.org/assignments/l2tp-parameters/
Registro tipi di messaggi L2TP
- Contiene tutti i tipi di messaggi di controllo
Registro codici risultato L2TP
- Contiene codici risultato e codici errore
Registro tipi di autenticazione proxy L2TP
- Contiene valori tipo di autenticazione
Porte e numeri di protocollo L2TP
- Assegnazioni porta UDP e numero protocollo IP

Aggiornamenti ed estensioni:

Le RFC successive possono definire nuovi AVP, tipi di messaggi o altri parametri. Tutte le nuove assegnazioni devono seguire le politiche di registrazione definite in questa sezione.

Le estensioni importanti includono:

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 (Riferimenti)

Questa sezione elenca tutti i riferimenti normativi e informativi citati nella RFC 2661.

11.1 Normative References (Riferimenti normativi)

I riferimenti normativi sono i documenti necessari per l'implementazione del protocollo L2TP.

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

Titolo in italiano: Point-to-Point Protocol (PPP)
Descrizione: Definisce il formato di base e il processo di negoziazione dei frame PPP tunnelizzati da L2TP.

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

Titolo in italiano: PPP in incapsulamento di tipo HDLC
Descrizione: Definisce il metodo di incapsulamento dei frame PPP su linee di tipo HDLC.

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

Titolo in italiano: Numeri assegnati
Descrizione: Riferimento per l'assegnazione dei numeri IANA (sostituito dal registro IANA in linea).

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

Titolo in italiano: PPP Multilink Protocol (MP)
Descrizione: Definisce il meccanismo per raggruppare più linee fisiche in un'unica linea logica.

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

Titolo in italiano: PPP Challenge Handshake Authentication Protocol (CHAP)
Descrizione: Protocollo di autenticazione usato nel proxy di autenticazione L2TP.

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

Titolo in italiano: Parole chiave da usare nelle RFC per indicare i livelli di requisito
Descrizione: Definisce il significato di parole chiave come "MUST", "SHOULD", "MAY".

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

Titolo in italiano: Cisco Layer Two Forwarding (Protocol) (L2F)
Descrizione: Protocollo predecessore di L2TP, usato per il rilevamento della versione.

11.2 Informative References (Riferimenti informativi)

I riferimenti informativi forniscono informazioni contestuali e spiegazioni sui protocolli correlati.

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

Titolo in italiano: Internet Protocol (IPv4)
Descrizione: Definisce il protocollo IPv4 su cui L2TP può operare.

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

Titolo in italiano: Protocolli di autenticazione PPP
Descrizione: Definisce il 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.

Titolo in italiano: Remote Authentication Dial In User Service (RADIUS)
Descrizione: Protocollo per autenticazione, autorizzazione e accounting centralizzati.

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

Titolo in italiano: Politica IETF su set di caratteri e lingue
Descrizione: Linee guida per la gestione dei testi internazionalizzati.

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

Titolo in italiano: Architettura di sicurezza per il protocollo Internet
Descrizione: Definisce l'architettura IPsec, raccomandata in combinazione con L2TP.

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

Titolo in italiano: Estensioni Microsoft PPP CHAP
Descrizione: Definizione del protocollo MS-CHAPv1.

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

Titolo in italiano: Internet Protocol, Version 6 (IPv6) Specification
Descrizione: Definisce il protocollo IPv6 su cui L2TP può operare.

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

Titolo in italiano: Microsoft PPP CHAP Extensions, Version 2
Descrizione: Definizione del protocollo MS-CHAPv2.

[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.

Titolo in italiano: Network Security: Private Communication in a Public World
Descrizione: Riferimento sulle basi crittografiche del meccanismo di offuscamento AVP.

Di seguito sono riportati gli standard importanti correlati a L2TP ma non citati direttamente:

Versioni evolutive di L2TP:

RFC 3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3)
- La terza versione di L2TP, che supporta il tunneling di frame dati non PPP.
RFC 5515: Layer Two Tunneling Protocol (L2TP) Access Concentrator Configuration
- Protocollo di configurazione per il concentratore di accesso L2TP.

Correlati a IPsec:

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)

Estensioni PPP:

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 e gestione del traffico:

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 (Organizzazioni di standardizzazione)

IETF (Internet Engineering Task Force)

Sito web: https://www.ietf.org/
Archivio del gruppo di lavoro L2TP: https://datatracker.ietf.org/wg/l2tpext/

IANA (Internet Assigned Numbers Authority)

Sito web: https://www.iana.org/
Registro dei parametri L2TP: https://www.iana.org/assignments/l2tp-parameters/

IEEE (Institute of Electrical and Electronics Engineers)

Standard nelle tecnologie di livello 2

ITU-T (Unione Internazionale delle Telecomunicazioni - Settore della standardizzazione delle telecomunicazioni)

Q.931: Segnalazione ISDN (referenziata nell'AVP Q.931 Cause Code)

11.5 Historical Context (Contesto storico)

Il protocollo L2TP è la fusione dei due protocolli seguenti:

L2F (Layer 2 Forwarding Protocol) - sviluppato da Cisco Systems
- RFC 2341
PPTP (Point-to-Point Tunneling Protocol) - sviluppato da Microsoft e altri
- RFC 2637

L2TP combina i punti di forza di questi due protocolli ed è diventato un protocollo nello standard track dell'IETF.

11.6 Further Reading (Letture consigliate)

Libri di testo:

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

Risorse online:

Carta IETF L2TP: https://datatracker.ietf.org/wg/l2tpext/charter/
Guide di configurazione L2TP/IPsec (specifiche per fornitore)
Documentazione delle best practice per la sicurezza di rete

Note sul formato di citazione (Citation Format Notes):

In questo documento le RFC sono citate nel formato [RFCXXXX], dove XXXX è il numero RFC. Gli altri documenti sono referenziati con un breve identificatore tra parentesi quadre (es. [KPS]).

I documenti RFC completi sono disponibili alle fonti seguenti:

IETF RFC Editor: https://www.rfc-editor.org/
IETF Datatracker: https://datatracker.ietf.org/

12. Acknowledgments (Ringraziamenti)

Gli autori della RFC 2661 ringraziano tutti i membri del gruppo di lavoro IETF L2TP per i loro contributi allo sviluppo di questa specifica.

Major Contributors (Principali contributori)

Lo sviluppo di questo protocollo ha tratto beneficio dai contributi tecnici di molte persone e organizzazioni. Un ringraziamento particolare va ai seguenti contributori:

Il team di ingegneria di Cisco Systems, in particolare gli sviluppatori originali del protocollo L2F
Il team di ingegneria di Microsoft Corporation, in particolare i contributori al protocollo PPTP
Gli esperti tecnici di Ascend Communications e Redback Networks

Working Group Members (Membri del gruppo di lavoro)

Le discussioni e le revisioni tecniche del gruppo di lavoro L2TP sono state essenziali per la qualità di questa specifica. Un ringraziamento particolare a tutti i membri che hanno partecipato alle discussioni sulla mailing list, fornito feedback di implementazione e condotto test di interoperabilità.

Technical Review (Revisione tecnica)

Ringraziamenti alle seguenti persone per la dettagliata revisione tecnica della bozza e i costruttivi commenti:

Esperti di sicurezza per la revisione del capitolo sulla sicurezza
Esperti di PPP e protocolli di tunneling per i suggerimenti sulla progettazione del protocollo
Rappresentanti IANA per i consigli sul capitolo di assegnazione dei parametri

Editorial Support (Supporto editoriale)

Ringraziamenti al team degli editor RFC per il supporto professionale nella formattazione del documento, nella coerenza terminologica e nella chiarezza dell'esposizione tecnica.

Nota: L'elenco completo dei contributori e delle organizzazioni è nel capitolo dei ringraziamenti del documento RFC 2661 originale.

13. Authors' Addresses (Indirizzi degli autori)

Questa sezione elenca i principali autori della RFC 2661 e i loro recapiti (alla data di pubblicazione).

W. Mark Townsley

Cisco Systems

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

Contributo: Caporedattore e coordinamento tecnico

Allan Valencia

Cisco Systems

Email: [email protected]

Contributo: Progettazione del protocollo e integrazione L2F

Rappresentante di Ascend Communications

Andrew Rubens

Email: [email protected]

Contributo: Progettazione del protocollo di controllo e degli AVP

Rappresentante di Microsoft Corporation

Gurdeep Singh Pall

Email: [email protected]

Contributo: Integrazione del protocollo PPTP e meccanismi di sicurezza

Rappresentante di Microsoft Corporation

Glen Zorn

Email: [email protected]

Contributo: Protocolli di autenticazione e progettazione della sicurezza

Rappresentante di Redback Networks

Bernard Palter

Email: [email protected]

Contributo: Implementazione del protocollo e test di interoperabilità

Note:

I recapiti sopra riportati corrispondono alla data di pubblicazione (agosto 1999).
Alcuni indirizzi e-mail potrebbero non essere più validi.
Per domande o discussioni attuali sul protocollo L2TP, fare riferimento alla mailing list del gruppo di lavoro IETF L2TP.
La manutenzione e l'estensione della norma L2TP sono tuttora curate dall'IETF.

Aggiornamento dei recapiti:

Per le informazioni più recenti sul protocollo L2TP o per segnalare problemi, consultare:

IETF Datatracker: https://datatracker.ietf.org/doc/rfc2661/
Gruppo di lavoro L2TP: https://datatracker.ietf.org/wg/l2tpext/

Appendix A: Control Channel Slow Start and Congestion Avoidance

A.1 Panoramica (Overview)

Il canale di controllo L2TP utilizza un meccanismo di trasmissione affidabile dei messaggi. Per prevenire la congestione della rete, si raccomanda di implementare algoritmi di Slow Start e Congestion Avoidance di tipo TCP.

A.2 Algoritmo di Slow Start (Slow Start Algorithm)

Parametri iniziali:

Finestra di congestione iniziale (cwnd): 1 messaggio
Soglia di Slow Start (ssthresh): dimensione della finestra di ricezione

Passi dell'algoritmo:

Ad ogni ACK ricevuto, cwnd aumenta di 1
Quando cwnd >= ssthresh, si passa alla fase di Congestion Avoidance
Il numero di messaggi inviati non confermati non supera min(cwnd, finestra di ricezione)

A.3 Congestion Avoidance (Avoidance della congestione)

Strategia di backoff:

Al rilevamento di un timeout: ssthresh = max(cwnd/2, 2)
Reimpostare cwnd = 1 e riavviare lo Slow Start

Stima del RTT (RTT Estimation):

Uso dell'algoritmo di Jacobson/Karels per calcolare il timeout di ritrasmissione (RTO)
RTT smussato = (1-α) × RTT smussato + α × RTT misurato
RTO = RTT smussato + 4 × deviazione RTT

Appendix C: Intellectual Property Notice

C.1 Dichiarazione IP (IP Statement)

L'IETF non prende alcuna posizione sulla validità o sull'ambito di eventuali diritti di proprietà intellettuale o altri diritti descritti in questo documento, né sulla misura in cui una licenza su tali diritti possa o meno essere disponibile; non indica inoltre di aver cercato di identificare tali diritti.

C.2 Divulgazione di brevetto (Patent Disclosure)

Ai sensi dei requisiti della sezione 10.4 della RFC 2026, le informazioni sulla proprietà intellettuale divulgate e correlate a questa specifica sono consultabili sul sito web dell'IETF.

C.3 Informazioni di licenza (Licensing Information)

Gli implementatori devono notare che alcune funzionalità L2TP possono essere protette da brevetti. L'IETF non è responsabile dell'identificazione di tali brevetti né della valutazione della validità o dell'ambito di eventuali rivendicazioni di brevetto.

Link correlati:

IETF IPR Disclosures: https://datatracker.ietf.org/ipr/
RFC 2026 Section 10: https://www.rfc-editor.org/rfc/rfc2026.html

Sommario (Abstract)​

Indice (Contents)​

Appendici (Appendices)​

Risorse correlate​

7. Control Connection State Machines (Macchine a stati della connessione di controllo)​

7.1 Control Connection Protocol Operation (Funzionamento del protocollo della connessione di controllo)​

7.2 Control Connection States (Stati della connessione di controllo)​

7.2.1 Control Connection Establishment (Istituzione della connessione di controllo)​

7.3 Timing Considerations (Considerazioni sui temporizzatori)​

7.4 Incoming Calls (Chiamate in ingresso)​

7.4.1 LAC Incoming Call States (Stati LAC per chiamate in ingresso)​

7.4.2 LNS Incoming Call States (Stati LNS per chiamate in ingresso)​

7.5 Outgoing Calls (Chiamate in uscita)​

7.5.1 LAC Outgoing Call States (Stati LAC per chiamate in uscita)​

7.5.2 LNS Outgoing Call States (Stati LNS per chiamate in uscita)​

7.6 Tunnel Disconnection (Disconnessione del tunnel)​

8. L2TP Over Specific Media (L2TP su media specifici)​

8.1 L2TP over UDP/IP (L2TP su UDP/IP)​

8.2 IP (Protocollo Internet)​

9. Security Considerations (Considerazioni sulla sicurezza)​

9.1 Tunnel Endpoint Security (Sicurezza degli endpoint del tunnel)​

9.2 Packet Level Security (Sicurezza a livello di pacchetto)​

9.3 End to End Security (Sicurezza end-to-end)​

9.4 L2TP and IPsec (L2TP e IPsec)​

9.5 Proxy PPP Authentication (Autenticazione PPP proxy)​

10. IANA Considerations (Considerazioni IANA)​

10.1 AVP Attributes (Attributi AVP)​

10.2 Message Type AVP Values (Valori AVP tipo di messaggio)​

10.3 Result Code AVP Values (Valori AVP codice risultato)​

10.3.1 Result Code Field Values (Valori campo codice risultato)​

10.3.2 Error Code Field Values (Valori campo codice errore)​

10.4 Framing Capabilities & Bearer Capabilities (Capacità di frame e capacità del supporto)​

10.5 Proxy Authen Type AVP Values (Valori AVP tipo autenticazione proxy)​

10.6 AVP Header Bits (Bit intestazione AVP)​

10.7 L2TP UDP Port (Porta UDP L2TP)​

10.8 L2TP Protocol Number (Numero protocollo L2TP)​

11. References (Riferimenti)​

11.1 Normative References (Riferimenti normativi)​

11.2 Informative References (Riferimenti informativi)​

11.3 Related Standards (Standard correlati)​

11.4 Standards Organizations (Organizzazioni di standardizzazione)​

11.5 Historical Context (Contesto storico)​

11.6 Further Reading (Letture consigliate)​

12. Acknowledgments (Ringraziamenti)​

Major Contributors (Principali contributori)​

Working Group Members (Membri del gruppo di lavoro)​

Technical Review (Revisione tecnica)​

Editorial Support (Supporto editoriale)​

13. Authors' Addresses (Indirizzi degli autori)​

W. Mark Townsley​

Allan Valencia​

Rappresentante di Ascend Communications​

Rappresentante di Microsoft Corporation​

Rappresentante di Microsoft Corporation​

Rappresentante di Redback Networks​

Appendix A: Control Channel Slow Start and Congestion Avoidance​

A.1 Panoramica (Overview)​

A.2 Algoritmo di Slow Start (Slow Start Algorithm)​

A.3 Congestion Avoidance (Avoidance della congestione)​

Appendix C: Intellectual Property Notice​

C.1 Dichiarazione IP (IP Statement)​

C.2 Divulgazione di brevetto (Patent Disclosure)​

C.3 Informazioni di licenza (Licensing Information)​

Sommario (Abstract)

Indice (Contents)

Appendici (Appendices)

Risorse correlate

7. Control Connection State Machines (Macchine a stati della connessione di controllo)

7.1 Control Connection Protocol Operation (Funzionamento del protocollo della connessione di controllo)

7.2 Control Connection States (Stati della connessione di controllo)

7.2.1 Control Connection Establishment (Istituzione della connessione di controllo)

7.3 Timing Considerations (Considerazioni sui temporizzatori)

7.4 Incoming Calls (Chiamate in ingresso)

7.4.1 LAC Incoming Call States (Stati LAC per chiamate in ingresso)

7.4.2 LNS Incoming Call States (Stati LNS per chiamate in ingresso)

7.5 Outgoing Calls (Chiamate in uscita)

7.5.1 LAC Outgoing Call States (Stati LAC per chiamate in uscita)

7.5.2 LNS Outgoing Call States (Stati LNS per chiamate in uscita)

7.6 Tunnel Disconnection (Disconnessione del tunnel)

8. L2TP Over Specific Media (L2TP su media specifici)

8.1 L2TP over UDP/IP (L2TP su UDP/IP)

8.2 IP (Protocollo Internet)

9. Security Considerations (Considerazioni sulla sicurezza)

9.1 Tunnel Endpoint Security (Sicurezza degli endpoint del tunnel)

9.2 Packet Level Security (Sicurezza a livello di pacchetto)

9.3 End to End Security (Sicurezza end-to-end)

9.4 L2TP and IPsec (L2TP e IPsec)

9.5 Proxy PPP Authentication (Autenticazione PPP proxy)

10. IANA Considerations (Considerazioni IANA)

10.1 AVP Attributes (Attributi AVP)

10.2 Message Type AVP Values (Valori AVP tipo di messaggio)

10.3 Result Code AVP Values (Valori AVP codice risultato)

10.3.1 Result Code Field Values (Valori campo codice risultato)

10.3.2 Error Code Field Values (Valori campo codice errore)

10.4 Framing Capabilities & Bearer Capabilities (Capacità di frame e capacità del supporto)

10.5 Proxy Authen Type AVP Values (Valori AVP tipo autenticazione proxy)

10.6 AVP Header Bits (Bit intestazione AVP)

10.7 L2TP UDP Port (Porta UDP L2TP)

10.8 L2TP Protocol Number (Numero protocollo L2TP)

11. References (Riferimenti)

11.1 Normative References (Riferimenti normativi)

11.2 Informative References (Riferimenti informativi)

11.3 Related Standards (Standard correlati)

11.4 Standards Organizations (Organizzazioni di standardizzazione)

11.5 Historical Context (Contesto storico)

11.6 Further Reading (Letture consigliate)

12. Acknowledgments (Ringraziamenti)

Major Contributors (Principali contributori)

Working Group Members (Membri del gruppo di lavoro)

Technical Review (Revisione tecnica)

Editorial Support (Supporto editoriale)

13. Authors' Addresses (Indirizzi degli autori)

W. Mark Townsley

Allan Valencia

Rappresentante di Ascend Communications

Rappresentante di Microsoft Corporation

Rappresentante di Microsoft Corporation

Rappresentante di Redback Networks

Appendix A: Control Channel Slow Start and Congestion Avoidance

A.1 Panoramica (Overview)

A.2 Algoritmo di Slow Start (Slow Start Algorithm)

A.3 Congestion Avoidance (Avoidance della congestione)

Appendix C: Intellectual Property Notice

C.1 Dichiarazione IP (IP Statement)

C.2 Divulgazione di brevetto (Patent Disclosure)

C.3 Informazioni di licenza (Licensing Information)