Aller au contenu principal

RFC 2661 - Layer Two Tunneling Protocol (L2TP)

  • Statut: Proposed Standard
  • Publié: August 1999
  • Stream: IETF
  • Errata: Pas d'errata

Résumé (Abstract)​

Ce document décrit le Layer Two Tunneling Protocol (L2TP). STD 51, RFC 1661 définit l'accès multi-protocole via PPP. L2TP facilite le tunnelage des paquets PPP à travers les réseaux intermédiaires d'une manière aussi transparente que possible pour les utilisateurs finaux et les applications.

Table des matières (Contents)​

  • 1. Introduction
    • 1.1 Specification of Requirements (Spécification des exigences)
    • 1.2 Terminology (Terminologie)
  • 2. Topology (Topologie)
  • 3. Protocol Overview (Aperçu du protocole)
    • 3.1 L2TP Header Format (Format d'en-tête L2TP)
    • 3.2 Control Message Types (Types de messages de contrôle)
  • 4. Control Message Attribute Value Pairs (Paires attribut-valeur de messages de contrôle)
    • 4.1 AVP Format (Format AVP)
    • 4.2 Mandatory AVPs (AVPs obligatoires)
    • 4.3 Hiding of AVP Attribute Values (Masquage des valeurs d'attributs AVP)
    • 4.4 AVP Summary (Résumé AVP)
      • 4.4.1 AVPs Applicable To All Control Messages (AVPs applicables à tous les messages de contrôle)
      • 4.4.2 Result and Error Codes (Codes de résultat et d'erreur)
      • 4.4.3 Control Connection Management AVPs (AVPs de gestion de connexion de contrôle)
      • 4.4.4 Call Management AVPs (AVPs de gestion d'appels)
      • 4.4.5 Proxy LCP and Authentication AVPs (AVPs de proxy LCP et d'authentification)
      • 4.4.6 Call Status AVPs (AVPs d'état d'appel)
  • 5. Protocol Operation (Fonctionnement du protocole)
    • 5.1 Control Connection Establishment (Établissement de connexion de contrôle)
      • 5.1.1 Tunnel Authentication (Authentification du tunnel)
    • 5.2 Session Establishment (Établissement de session)
      • 5.2.1 Incoming Call Establishment (Établissement d'appel entrant)
      • 5.2.2 Outgoing Call Establishment (Établissement d'appel sortant)
    • 5.3 Forwarding PPP Frames (Transfert de trames PPP)
    • 5.4 Using Sequence Numbers on the Data Channel (Utilisation de numéros de séquence sur le canal de données)
    • 5.5 Keepalive (Hello) (Mécanisme keepalive)
    • 5.6 Session Teardown (Fermeture de session)
    • 5.7 Control Connection Teardown (Fermeture de connexion de contrôle)
    • 5.8 Reliable Delivery of Control Messages (Livraison fiable des messages de contrôle)
  • 6. Control Connection Protocol Specification (Spécification du protocole de connexion de contrôle)
    • 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 (Machines à états de connexion de contrôle)
    • 7.1 Control Connection Protocol Operation (Fonctionnement du protocole de connexion de contrôle)
    • 7.2 Control Connection States (États de connexion de contrôle)
      • 7.2.1 Control Connection Establishment (Établissement de connexion de contrôle)
    • 7.3 Timing considerations (Considérations temporelles)
    • 7.4 Incoming calls (Appels entrants)
      • 7.4.1 LAC Incoming Call States (États d'appels entrants LAC)
      • 7.4.2 LNS Incoming Call States (États d'appels entrants LNS)
    • 7.5 Outgoing calls (Appels sortants)
      • 7.5.1 LAC Outgoing Call States (États d'appels sortants LAC)
      • 7.5.2 LNS Outgoing Call States (États d'appels sortants LNS)
    • 7.6 Tunnel Disconnection (Déconnexion du tunnel)
  • 8. L2TP Over Specific Media (L2TP sur médias spécifiques)
    • 8.1 L2TP over UDP/IP
    • 8.2 IP
  • 9. Security Considerations (Considérations de sécurité)
    • 9.1 Tunnel Endpoint Security (Sécurité des points de terminaison du tunnel)
    • 9.2 Packet Level Security (Sécurité au niveau des paquets)
    • 9.3 End to End Security (Sécurité de bout en bout)
    • 9.4 L2TP and IPsec
    • 9.5 Proxy PPP Authentication (Authentification PPP proxy)
  • 10. IANA Considerations (Considérations 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 (Références)
  • 12. Acknowledgments (Remerciements)
  • 13. Authors' Addresses (Adresses des auteurs)

Annexes (Appendices)​

Ressources connexes​

7. Automates d'état de connexion de contrôle (Control Connection State Machines)​

Ce chapitre définit les automates d'état pour l'établissement, le maintien et la suppression des connexions de contrôle et des sessions L2TP.

7.1 Fonctionnement du protocole de connexion de contrôle (Control Connection Protocol Operation)​

L'automate d'état de connexion de contrôle décrit les transitions d'état pour l'établissement et la suppression du tunnel. Chaque état définit les événements acceptables, les actions correspondantes et l'état suivant.

7.2 États de connexion de contrôle (Control Connection States)​

La connexion de contrôle comprend les états suivants :

  • idle : état initial, aucune connexion établie
  • wait-ctl-reply : en attente de la réponse de connexion de contrôle du pair
  • wait-ctl-conn : en attente de la finalisation de la connexion de contrôle
  • established : connexion de contrôle établie
  • closing : fermeture de la connexion de contrôle en cours

7.2.1 Établissement de la connexion de contrôle (Control Connection Establishment)​

L'établissement de la connexion de contrôle s'effectue via une triple poignée de main (SCCRQ, SCCRP, SCCCN). Les transitions d'état sont :

  1. idle → wait-ctl-reply (envoi de SCCRQ)
  2. wait-ctl-reply → wait-ctl-conn (réception de SCCRP)
  3. wait-ctl-conn → established (réception de SCCCN)

7.3 Considérations temporelles (Timing Considerations)​

  • Minuterie de retransmission : retransmission des messages de contrôle pour une transmission fiable
  • Intervalle Hello : intervalle d'envoi périodique des messages Hello
  • Détection de délai d'attente : mécanisme de délai d'attente pour détecter les défaillances de tunnel

7.4 Appels entrants (Incoming Calls)​

L'établissement des appels entrants implique des transitions d'état coordonnées entre le LAC (L2TP Access Concentrator, concentrateur d'accès L2TP) et le LNS (L2TP Network Server, serveur réseau L2TP).

7.4.1 États d'appel entrant LAC (LAC Incoming Call States)​

États d'appel entrant côté LAC :

  • idle : aucun appel actif
  • wait-reply : en attente de l'ICRP du LNS
  • wait-connect : en attente de la connexion d'appel
  • established : session établie

7.4.2 États d'appel entrant LNS (LNS Incoming Call States)​

États d'appel entrant côté LNS :

  • idle : aucun appel actif
  • wait-connect : en attente de l'ICCN du LAC
  • established : session établie

7.5 Appels sortants (Outgoing Calls)​

Les appels sortants sont initiés par le LNS, et le LAC effectue l'opération d'appel réelle.

7.5.1 États d'appel sortant LAC (LAC Outgoing Call States)​

États d'appel sortant côté LAC :

  • idle : aucun appel actif
  • wait-reply : en attente de la réponse à l'OCRQ
  • wait-cs-answer : en attente de la réponse d'appel
  • established : session établie

7.5.2 États d'appel sortant LNS (LNS Outgoing Call States)​

États d'appel sortant côté LNS :

  • idle : aucun appel actif
  • wait-reply : en attente de l'OCRP du LAC
  • wait-connect : en attente de l'OCCN
  • established : session établie

7.6 Déconnexion du tunnel (Tunnel Disconnection)​

La déconnexion du tunnel peut être initiée par le LAC ou le LNS en envoyant un message StopCCN. À la réception d'un StopCCN, le pair DOIT acquitter le message et libérer toutes les ressources associées.

Remarque : Pour les tableaux complets de transitions d'état et les diagrammes détaillés des automates d'état, veuillez consulter le texte original du RFC 2661. Ce chapitre fournit une vue d'ensemble des automates d'état et des principales transitions d'état.

8. L2TP Over Specific Media (L2TP sur des médias spécifiques)​

Ce chapitre décrit les détails d'implémentation de L2TP sur des types de médias spécifiques. L2TP est conçu pour fonctionner sur divers médias de transport de paquets, notamment UDP/IP, Frame Relay, ATM, etc.

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

L2TP utilise le port UDP enregistré 1701 pour la communication entre les points d'extrémité du tunnel. UDP fournit un service de transport de paquets pour les messages de contrôle et les messages de données L2TP.

Attribution des ports:

  • Port source: L'expéditeur peut utiliser n'importe quel port UDP disponible comme port source.
  • Port de destination: Doit utiliser le port UDP 1701.

Encapsulation des paquets:

Le format d'encapsulation des paquets L2TP sur UDP/IP est le suivant:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    En-tête IP                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   En-tête UDP                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   En-tête L2TP                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Message de contrôle L2TP ou            |
|                  Charge utile PPP                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Somme de contrôle UDP:

La somme de contrôle UDP doit être calculée et incluse dans tous les paquets L2TP. Les récepteurs doivent vérifier la somme de contrôle si elle est présente. Si la vérification de la somme de contrôle échoue, le paquet doit être rejeté.

Considérations MTU:

Étant donné que L2TP ajoute des couches d'encapsulation supplémentaires (en-tête L2TP + en-tête UDP + en-tête IP), les implémentations doivent tenir compte du MTU de chemin. Surcharge d'encapsulation typique:

  • En-tête IP: 20 octets (IPv4) ou 40 octets (IPv6)
  • En-tête UDP: 8 octets
  • En-tête L2TP: Au moins 6 octets (peut être plus selon les options)

Fragmentation:

Il est recommandé aux implémentations L2TP d'éviter la fragmentation IP. Cela peut être réalisé par:

  1. Découverte du MTU de chemin
  2. Négociation du MRU (Maximum Receive Unit) lors de l'établissement du tunnel
  3. Effectuer la fragmentation au niveau PPP plutôt qu'au niveau IP

8.2 IP (Protocole Internet)​

Les paquets L2TP utilisent IP comme protocole de transport de paquets. IP fournit un service de transport de paquets de bout en bout pour L2TP.

Prise en charge des versions IP:

L2TP est conçu pour fonctionner sur IPv4 [RFC791] et IPv6 [RFC2460]. Les implémentations doivent prendre en charge au moins une version IP et peuvent éventuellement prendre en charge les deux.

Considérations spécifiques à IPv4:

  • Type de protocole: Lors de l'utilisation de l'encapsulation UDP, le champ de protocole IP est défini sur 17 (UDP).
  • Type de service (TOS): Les implémentations L2TP peuvent définir le champ TOS IP pour indiquer les exigences de qualité de service. Les messages de contrôle peuvent nécessiter une priorité plus élevée que les messages de données.
  • Durée de vie (TTL): Une valeur TTL appropriée doit être définie pour empêcher les paquets de boucler indéfiniment dans le réseau.

Considérations spécifiques à IPv6:

  • En-tête suivant: Lors de l'utilisation de l'encapsulation UDP, défini sur 17 (UDP).
  • Étiquette de flux: L'étiquette de flux IPv6 peut être utilisée pour identifier les flux de paquets appartenant au même tunnel pour le traitement QoS.
  • Limite de sauts: Équivalent au TTL d'IPv4.

Sélection d'adresse:

Les LAC et LNS doivent être capables de déterminer l'adresse IP du pair. Cela peut être réalisé par:

  • Configuration statique
  • Résolution DNS
  • Mécanismes de découverte dynamique

Considérations multi-hébergement:

Si un point d'extrémité de tunnel a plusieurs adresses IP (multi-hébergé), les implémentations doivent s'assurer que tous les paquets d'un tunnel utilisent une adresse source cohérente. Ceci est essentiel pour maintenir l'état du tunnel et éviter la confusion.

Sécurité:

Lorsque L2TP fonctionne sur IP, il est fortement recommandé d'utiliser IPsec [RFC2401] pour protéger le trafic du tunnel. IPsec peut fournir:

  • Confidentialité: Par le chiffrement ESP
  • Intégrité: Par l'authentification AH ou ESP
  • Authentification des points d'extrémité: Par IKE

Les considérations de sécurité détaillées sont couvertes au chapitre 9.

Notes d'implémentation:

  1. Multiplexage de ports: Plusieurs tunnels peuvent être établis entre la même paire d'adresses IP, différenciés par l'ID de tunnel.

  2. Traversée NAT: Lorsque L2TP doit traverser des périphériques NAT, des mécanismes supplémentaires peuvent être nécessaires (tels que L2TP/IPsec NAT-T).

  3. Considérations relatives au pare-feu: Les pare-feu doivent autoriser la communication bidirectionnelle sur le port UDP 1701 pour prendre en charge L2TP.

  4. Mappage QoS: Les implémentations peuvent mapper les exigences QoS de la couche PPP au champ DSCP ou TOS de la couche IP.

9. Security Considerations (Considérations de sécurité)​

Le protocole L2TP lui-même ne fournit pas de services de chiffrement ou d'authentification forte. Ce chapitre traite des considérations de sécurité dans les déploiements L2TP et des mécanismes de sécurité disponibles.

9.1 Tunnel Endpoint Security (Sécurité des points d'extrémité du tunnel)​

La relation de confiance entre les points d'extrémité du tunnel est fondamentale pour la sécurité L2TP.

Authentification des points d'extrémité:

Le LAC et le LNS doivent être capables de vérifier l'identité de l'autre. L2TP fournit un mécanisme d'authentification de tunnel optionnel:

  • Challenge AVP: L'initiateur envoie une valeur de défi aléatoire dans le SCCRQ (Start-Control-Connection-Request).
  • Challenge Response AVP: Le répondeur calcule une réponse basée sur un secret partagé et la renvoie dans le SCCRP (Start-Control-Connection-Reply).
  • Calcul de la réponse: Utilise la fonction de hachage MD5: MD5(Type de message + secret_partagé + Défi + ID_Session)

Gestion des secrets partagés:

  • Les secrets partagés doivent avoir une entropie suffisante (au moins 128 bits recommandés).
  • Les secrets partagés doivent être stockés en toute sécurité (stockage chiffré).
  • Les secrets partagés doivent être renouvelés périodiquement.
  • Différentes paires de tunnels doivent utiliser différents secrets partagés.

Autorisation de tunnel:

En plus de l'authentification, des mécanismes d'autorisation doivent être mis en œuvre:

  • Vérifier que le pair est autorisé à établir un tunnel.
  • Vérifier si le pair a la permission d'accéder à des ressources ou services spécifiques.
  • Utiliser des listes de contrôle d'accès (ACL) pour restreindre quels pairs peuvent établir des tunnels.

Vulnérabilités et atténuations:

  1. Attaque de l'homme du milieu:

    • Risque: L'authentification de tunnel L2TP basée sur des secrets partagés est vulnérable aux attaques MITM.
    • Atténuation: Utiliser IPsec pour fournir un chiffrement et une authentification de bout en bout.

  2. Attaque par rejeu:

    • Risque: Les attaquants peuvent rejouer des messages de contrôle capturés.
    • Atténuation: Utiliser des numéros de séquence et des mécanismes ZLB ACK pour détecter et prévenir les attaques par rejeu.

  3. Attaque par déni de service:

    • Risque: Les attaquants peuvent envoyer un grand nombre de demandes d'établissement de tunnel.
    • Atténuation:
      • Limiter le nombre de tunnels simultanés par adresse source.
      • Mettre en œuvre une limitation de débit.
      • Utiliser des mécanismes de Cookie (similaires aux cookies TCP SYN).

9.2 Packet Level Security (Sécurité au niveau des paquets)​

L2TP lui-même ne fournit pas de chiffrement de paquets ou de protection d'intégrité.

Risques de la transmission en clair:

  • Écoute clandestine: Les attaquants peuvent intercepter et lire le contenu des paquets PPP, y compris les informations d'identification des utilisateurs et les données d'application.
  • Falsification: Les attaquants peuvent modifier les paquets en transit.
  • Injection: Les attaquants peuvent injecter des paquets malveillants dans le tunnel.

Mécanisme de masquage AVP:

L2TP fournit un mécanisme de masquage AVP pour protéger les informations de contrôle sensibles:

  • Processus de masquage:

    1. Générer un hachage MD5 en utilisant le secret partagé et le vecteur aléatoire.
    2. Effectuer un XOR de la valeur de hachage avec la valeur AVP.
    3. Répéter le processus si la valeur AVP dépasse 16 octets.

  • Limitations:

    • Le masquage AVP est une obfuscation, pas un véritable chiffrement.
    • Ne protège pas le canal de données, seulement des AVP spécifiques dans le canal de contrôle.
    • Vulnérable aux attaques par dictionnaire (si le secret partagé est faible).

Recommandations:

  • Ne pas compter uniquement sur le masquage AVP comme seul mécanisme de sécurité.
  • Utiliser IPsec ou d'autres technologies de chiffrement au niveau du tunnel.

9.3 End to End Security (Sécurité de bout en bout)​

Même lorsque le tunnel L2TP lui-même est protégé, la sécurité de bout en bout reste importante.

Authentification au niveau PPP:

Une authentification indépendante doit avoir lieu entre le système distant et le LNS:

  • PAP (Password Authentication Protocol):

    • Authentification par mot de passe en clair simple.
    • Non recommandé, car les mots de passe sont transmis en clair (doit être évité même dans les tunnels L2TP chiffrés).

  • CHAP (Challenge Handshake Authentication Protocol):

    • Mécanisme d'authentification défi-réponse.
    • Les mots de passe ne sont pas transmis en clair.
    • Ré-authentification périodique pour prévenir les attaques par rejeu.

  • EAP (Extensible Authentication Protocol):

    • Prend en charge diverses méthodes d'authentification (EAP-TLS, EAP-TTLS, PEAP, etc.).
    • Peut fournir une authentification mutuelle et une négociation de clés.
    • EAP-TLS est recommandé pour la sécurité la plus forte.

Chiffrement de bout en bout:

Le chiffrement de la couche application fournit une couche de sécurité supplémentaire:

  • TLS/SSL: Utilisé pour protéger les données d'application (par exemple, HTTPS).
  • Logiciel client VPN: Fournit une couche de chiffrement supplémentaire au-dessus de PPP.

Stratégie de défense en profondeur:

Système distant <--Auth/Chiffr PPP--> LNS
    |                                   |
    +--<Tunnel L2TP>--LAC--------------+
              |
         <Protection IPsec>
  • Couche 1: Authentification au niveau PPP (CHAP/EAP)
  • Couche 2: Authentification de tunnel L2TP
  • Couche 3: Chiffrement et authentification IPsec
  • Couche 4: Chiffrement de la couche application (TLS/SSL)

9.4 L2TP and IPsec (L2TP et IPsec)​

Il est fortement recommandé d'utiliser L2TP en combinaison avec IPsec, communément appelé L2TP/IPsec.

Services de sécurité fournis par IPsec:

  1. Confidentialité:

    • Fournie par le chiffrement ESP (Encapsulating Security Payload).
    • Prend en charge plusieurs algorithmes de chiffrement: AES, 3DES, ChaCha20, etc.

  2. Intégrité:

    • Fournie par AH (Authentication Header) ou l'authentification ESP.
    • Utilise HMAC (par exemple, HMAC-SHA256) pour vérifier l'intégrité des données.

  3. Authentification de la source:

    • Vérifie l'authenticité des sources de paquets.
    • Empêche les attaques d'usurpation d'IP.

  4. Anti-rejeu:

    • Utilise des numéros de séquence pour prévenir les attaques par rejeu.

Architecture L2TP/IPsec:

+-------------------+
|   Charge utile PPP|
+-------------------+
|   En-tête L2TP    |
+-------------------+
|   En-tête UDP     |
+-------------------+
|   En-tête ESP     | <-- Chiffrement et authentification IPsec
+-------------------+
|   En-tête IP      |
+-------------------+

Options de configuration IPsec:

  • Mode transport:

    • Chiffre et authentifie uniquement la charge utile IP.
    • Adapté à la communication de bout en bout.
    • Recommandé pour L2TP/IPsec.

  • Mode tunnel:

    • Chiffre et authentifie l'intégralité du paquet IP.
    • Ajoute un nouvel en-tête IP externe.
    • Adapté à la communication de passerelle à passerelle.

Gestion des clés:

  • IKE (Internet Key Exchange):

    • IKEv1: Version originale, négociation en deux phases.
    • IKEv2: Version améliorée, plus rationalisée et efficace.
    • IKEv2 est recommandé pour la négociation de clés.

  • Clé pré-partagée vs Certificats:

    • Clé pré-partagée (PSK): Simple à configurer, mais difficile de distribuer les clés.
    • Certificats: Plus sûrs, prennent en charge les déploiements à grande échelle, fortement recommandés.

Traversée NAT (NAT-T):

Lorsque L2TP/IPsec doit traverser des périphériques NAT:

  • Utiliser l'encapsulation UDP d'ESP (port UDP 4500).
  • Envoyer périodiquement des paquets de maintien en vie NAT.
  • IKEv2 a un support NAT-T intégré.

Considérations de performance:

  • Le chiffrement IPsec ajoute une surcharge CPU.
  • Envisager d'utiliser l'accélération matérielle (AES-NI, etc.).
  • La réduction MTU doit être prise en compte (en-tête ESP + trailer ESP + données d'authentification).

9.5 Proxy PPP Authentication (Authentification PPP par proxy)​

L2TP permet au LAC d'effectuer l'authentification PPP initiale au nom du LNS.

Mécanisme d'authentification par proxy:

Le LAC peut négocier LCP et effectuer l'authentification avec le système distant avant de transférer l'appel au LNS:

  1. Le LAC effectue l'authentification PPP:

    • Le LAC négocie LCP avec le système distant.
    • Le LAC effectue l'authentification PAP ou CHAP.
    • Le LAC collecte les informations d'authentification (nom d'utilisateur, hachage de mot de passe, etc.).

  2. Le LAC transfère les informations d'authentification au LNS:

    • Utilise des AVP proxy pour transmettre les informations d'authentification:
      • Proxy Authen Type AVP (29): Type d'authentification (PAP, CHAP, etc.)
      • Proxy Authen Name AVP (30): Nom d'utilisateur
      • Proxy Authen Challenge AVP (31): Valeur de défi CHAP
      • Proxy Authen Response AVP (33): Réponse d'authentification

  3. Le LNS vérifie les informations d'authentification:

    • Le LNS vérifie l'utilisateur en fonction des informations fournies par le LAC.
    • Le LNS peut accepter ou rejeter la session.

Risques de sécurité:

  1. Compromission du LAC:

    • Si le LAC est compromis, les attaquants peuvent obtenir les informations d'identification des utilisateurs.
    • Atténuation: Utiliser IPsec pour protéger la communication entre le LAC et le LNS.

  2. Transmission de mot de passe en clair:

    • Les mots de passe PAP sont transmis en clair du LAC au LNS (dans les AVP).
    • Atténuation: Utiliser le mécanisme de masquage AVP ou le chiffrement IPsec.

  3. Limite de confiance:

    • Le LNS doit faire entièrement confiance aux informations d'authentification fournies par le LAC.
    • Un LAC malveillant peut falsifier les informations d'authentification.
    • Atténuation:
      • N'utiliser l'authentification par proxy qu'entre des domaines de gestion de confiance.
      • Envisager d'exiger une ré-authentification de bout en bout.

Meilleures pratiques:

  1. Éviter l'authentification PAP par proxy:

    • Les mots de passe PAP sont vulnérables aux attaques même lorsqu'ils sont masqués.
    • S'il doit être utilisé, s'assurer de la protection IPsec.

  2. Privilégier l'authentification de bout en bout:

    • Permettre au système distant de s'authentifier directement avec le LNS (sans proxy).
    • Utiliser des méthodes EAP pour une sécurité plus forte.

  3. Limiter les cas d'utilisation de l'authentification par proxy:

    • N'utiliser que lorsque nécessaire (par exemple, établissement d'appel rapide).
    • Utiliser dans des environnements réseau de confiance.

  4. Combiner plusieurs méthodes d'authentification:

    • Le LAC effectue l'authentification préliminaire (pour un filtrage rapide).
    • Le LNS effectue l'authentification secondaire (vérification de bout en bout).

Intégration de l'authentification par proxy avec RADIUS:

Système distant <--PAP/CHAP--> LAC <--RADIUS--> Serveur RADIUS
                                 |
                                 |
                                 v
                           (Transfert info auth)
                                 |
                                 v
                                LNS <--RADIUS--> Serveur RADIUS
  • Le LAC peut utiliser RADIUS pour vérifier les informations d'identification des utilisateurs.
  • Le LNS peut également vérifier indépendamment en utilisant RADIUS.
  • La double vérification fournit une couche de sécurité supplémentaire.

Liste de contrôle de configuration de sécurité:

  • Utiliser IPsec entre le LAC et le LNS
  • Utiliser des secrets partagés forts ou des certificats pour l'authentification de tunnel
  • Utiliser des secrets partagés uniques pour chaque paire de tunnels
  • Activer l'authentification au niveau PPP (CHAP ou EAP)
  • Éviter d'utiliser l'authentification PAP
  • Faire pivoter périodiquement les secrets partagés
  • Mettre en œuvre des listes de contrôle d'accès pour restreindre l'établissement de tunnels
  • Activer la journalisation et la surveillance
  • Déployer des systèmes de détection d'intrusion (IDS)
  • Effectuer des audits de sécurité réguliers et des tests de pénétration

10. IANA Considerations (Considérations IANA)​

Ce chapitre définit divers paramètres qui nécessitent l'attribution et la gestion par l'IANA (Internet Assigned Numbers Authority) pour le protocole L2TP.

10.1 AVP Attributes (Attributs AVP)​

L'IANA est responsable de la maintenance du registre des types d'attributs AVP L2TP. Le type d'attribut AVP est un champ de 16 bits.

Exigences d'enregistrement:

  • Plage de valeurs 0-1023: Attribuées par consensus IETF (nécessite la publication d'une RFC).
  • Plage de valeurs 1024-65535: Attribuées selon la politique "Premier arrivé, premier servi".

Types d'attributs AVP standard attribués:

Type d'attributNom AVPRéférence
0Type de messageRFC 2661 Section 4.4.1
1Code de résultatRFC 2661 Section 4.4.2
2Version du protocoleRFC 2661 Section 4.4.3
3Capacités de trameRFC 2661 Section 4.4.3
4Capacités du supportRFC 2661 Section 4.4.4
5Briseur d'égalitéRFC 2661 Section 4.4.3
6Révision du micrologicielRFC 2661 Section 4.4.3
7Nom d'hôteRFC 2661 Section 4.4.3
8Nom du fournisseurRFC 2661 Section 4.4.3
9ID de tunnel attribuéRFC 2661 Section 4.4.3
10Taille de fenêtre de réceptionRFC 2661 Section 4.4.3
11DéfiRFC 2661 Section 4.4.3
12Code de cause Q.931RFC 2661 Section 4.4.4
13Réponse au défiRFC 2661 Section 4.4.3
14ID de session attribuéRFC 2661 Section 4.4.4
15Numéro de série d'appelRFC 2661 Section 4.4.4
16BPS minimumRFC 2661 Section 4.4.4
17BPS maximumRFC 2661 Section 4.4.4
18Type de supportRFC 2661 Section 4.4.4
19Type de trameRFC 2661 Section 4.4.4
20Délai de traitement des paquetsRFC 2661 Section 4.4.6
21Numéro appeléRFC 2661 Section 4.4.4
22Numéro appelantRFC 2661 Section 4.4.4
23Sous-adresseRFC 2661 Section 4.4.4
24Vitesse de connexion TxRFC 2661 Section 4.4.4
25ID de canal physiqueRFC 2661 Section 4.4.4
26LCP CONFREQ reçu initialRFC 2661 Section 4.4.5
27Dernier LCP CONFREQ envoyéRFC 2661 Section 4.4.5
28Dernier LCP CONFREQ reçuRFC 2661 Section 4.4.5
29Type d'authentification proxyRFC 2661 Section 4.4.5
30Nom d'authentification proxyRFC 2661 Section 4.4.5
31Défi d'authentification proxyRFC 2661 Section 4.4.5
32ID d'authentification proxyRFC 2661 Section 4.4.5
33Réponse d'authentification proxyRFC 2661 Section 4.4.5
34Erreurs d'appelRFC 2661 Section 4.4.6
35ACCMRFC 2661 Section 4.4.6
36Vecteur aléatoireRFC 2661 Section 4.3
37ID de groupe privéRFC 2661 Section 4.4.4
38Vitesse de connexion RxRFC 2661 Section 4.4.4
39Séquençage requisRFC 2661 Section 4.4.4

AVP spécifiques au fournisseur:

Les AVP spécifiques au fournisseur utilisent le champ Vendor ID (basé sur les codes d'entreprise privés de gestion de réseau SMI) pour distinguer les extensions de différents fournisseurs.

10.2 Message Type AVP Values (Valeurs AVP de type de message)​

La valeur AVP de type de message (type d'attribut 0) est utilisée pour identifier le type de message de contrôle L2TP.

Valeurs de type de message attribuées:

ValeurType de messageAbréviationRéférence
0(Réservé)
1Demande de démarrage de connexion de contrôleSCCRQRFC 2661 Section 6.1
2Réponse de démarrage de connexion de contrôleSCCRPRFC 2661 Section 6.2
3Connexion de contrôle démarrée connectéeSCCCNRFC 2661 Section 6.3
4Notification d'arrêt de connexion de contrôleStopCCNRFC 2661 Section 6.4
5(Réservé)
6HelloHELLORFC 2661 Section 6.5
7Demande d'appel sortantOCRQRFC 2661 Section 6.9
8Réponse d'appel sortantOCRPRFC 2661 Section 6.10
9Appel sortant connectéOCCNRFC 2661 Section 6.11
10Demande d'appel entrantICRQRFC 2661 Section 6.6
11Réponse d'appel entrantICRPRFC 2661 Section 6.7
12Appel entrant connectéICCNRFC 2661 Section 6.8
13(Réservé)
14Notification de déconnexion d'appelCDNRFC 2661 Section 6.12
15Notification d'erreur WANWENRFC 2661 Section 6.13
16Définir les informations de lienSLIRFC 2661 Section 6.14

Politique d'enregistrement:

L'attribution de nouvelles valeurs de type de message nécessite la publication d'une RFC sur la piste des normes IETF ou d'une RFC informative approuvée par l'IESG.

10.3 Result Code AVP Values (Valeurs AVP de code de résultat)​

L'AVP de code de résultat (type d'attribut 1) est utilisé pour indiquer la raison de la terminaison de la connexion de contrôle ou de la session.

10.3.1 Result Code Field Values (Valeurs de champ de code de résultat)​

Codes de résultat généraux:

ValeurSignificationPortée
0Réservé
1Demande générale pour effacer la connexion de contrôleStopCCN
2Erreur généraleStopCCN, CDN
3Le canal de contrôle existe déjàStopCCN
4Le demandeur n'est pas autoriséStopCCN
5Version du protocole non prise en chargeStopCCN
6Le demandeur est en cours d'arrêtStopCCN
7Erreur de machine à états finisStopCCN

Codes de résultat de déconnexion d'appel:

ValeurSignificationPortée
1Perte de porteuseCDN
2Erreur généraleCDN
3Raison administrativeCDN
4Manque temporaire d'installations appropriéesCDN
5Manque permanent d'installations appropriéesCDN
6Destination invalideCDN
7Aucune porteuse détectéeCDN
8Signal occupéCDN
9Pas de tonalitéCDN
10Délai d'attente de porteuse dépasséCDN
11Aucune trame détectéeCDN

10.3.2 Error Code Field Values (Valeurs de champ de code d'erreur)​

Le champ de code d'erreur fournit des détails supplémentaires sur l'erreur.

ValeurMessage d'erreur
0Aucune erreur générale
1Aucune connexion de contrôle n'existe encore pour cette paire
2La longueur est incorrecte
3L'une des valeurs de champ était hors limites
4Ressources insuffisantes pour gérer cette opération maintenant
5ID de session invalide
6Une erreur générique spécifique au fournisseur s'est produite
7Essayer un autre (LNS/LAC)
8La session ou le tunnel a été arrêté en raison de la réception d'un AVP inconnu avec le bit M défini

Politique d'enregistrement:

L'attribution de nouvelles valeurs de code de résultat et de code d'erreur nécessite un consensus IETF (nécessite la publication d'une RFC).

10.4 Framing Capabilities & Bearer Capabilities (Capacités de trame et capacités de support)​

L'AVP Framing Capabilities (type d'attribut 3) et l'AVP Bearer Capabilities (type d'attribut 4) utilisent des masques de bits pour indiquer les capacités prises en charge.

Définitions de bits de capacités de trame:

BitSignification
0Trame asynchrone prise en charge
1Trame synchrone prise en charge
2-31Réservé

Définitions de bits de capacités de support:

BitSignification
0Accès analogique pris en charge
1Accès numérique pris en charge
2-31Réservé

Politique d'enregistrement:

L'attribution de nouveaux bits de capacité nécessite un consensus IETF (nécessite la publication d'une RFC).

10.5 Proxy Authen Type AVP Values (Valeurs AVP de type d'authentification proxy)​

L'AVP Proxy Authen Type (type d'attribut 29) est utilisé pour indiquer le type d'authentification utilisé par le LAC.

Valeurs de type d'authentification attribuées:

ValeurType d'authentificationRéférence
0Réservé
1Échange textuel nom d'utilisateur/mot de passeRFC 1334 (PAP)
2PPP CHAPRFC 1994
3PPP PAPRFC 1334
4Aucune authentification
5Microsoft CHAP Version 1RFC 2433
6Réservé
7Microsoft CHAP Version 2RFC 2759

Politique d'enregistrement:

L'attribution de nouvelles valeurs de type d'authentification utilise la politique "Premier arrivé, premier servi".

10.6 AVP Header Bits (Bits d'en-tête AVP)​

Les 6 premiers bits de l'en-tête AVP sont utilisés comme masque de bits pour contrôler le comportement AVP.

Bits d'en-tête AVP définis:

BitNomSignificationRéférence
0M (Obligatoire)Cet AVP doit être comprisRFC 2661 Section 4.1
1H (Caché)La valeur AVP est cachéeRFC 2661 Section 4.3
2-5RéservéRéservé, doit être défini à 0RFC 2661 Section 4.1

Politique d'enregistrement:

L'attribution de bits réservés nécessite une action normative - c'est-à-dire la publication d'une RFC sur la piste des normes IETF.

10.7 L2TP UDP Port (Port UDP L2TP)​

Port attribué:

  • Numéro de port: 1701
  • Protocole: UDP
  • Objectif: L2TP
  • Référence: RFC 2661

L'IANA a attribué le port UDP 1701 pour L2TP pour les connexions de contrôle et les sessions de données.

10.8 L2TP Protocol Number (Numéro de protocole L2TP)​

Bien que la spécification actuelle définisse L2TP fonctionnant sur UDP, L2TP peut également fonctionner directement sur d'autres protocoles de transport de paquets.

Numéro de protocole IP:

  • Numéro de protocole L2TP: 115
  • Nom: L2TP
  • Référence: RFC 3931 (L2TPv3, directement sur IP)

Maintenance du registre IANA:

L'IANA maintient les registres suivants liés à L2TP:

  1. Registre des attributs AVP L2TP

  2. Registre des types de messages L2TP

    • Contient tous les types de messages de contrôle

  3. Registre des codes de résultat L2TP

    • Contient les codes de résultat et les codes d'erreur

  4. Registre des types d'authentification proxy L2TP

    • Contient les valeurs de type d'authentification

  5. Ports et numéros de protocole L2TP

    • Attributions de port UDP et de numéro de protocole IP

Mises à jour et extensions:

Les RFC ultérieures peuvent définir de nouveaux AVP, types de messages ou autres paramètres. Toutes les nouvelles attributions doivent suivre les politiques d'enregistrement définies dans cette section.

Les extensions importantes incluent:

  • 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 (Références)​

Cette section liste toutes les références normatives et informatives citées dans la RFC 2661.

11.1 Normative References (Références normatives)​

Les références normatives sont les documents nécessaires à la mise en œuvre du protocole L2TP.

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

  • Titre en français : Point-to-Point Protocol (PPP)
  • Description : Définit le format de base et le processus de négociation des trames PPP tunnelisées par L2TP.

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

  • Titre en français : PPP en encapsulation de type HDLC
  • Description : Définit la méthode d'encapsulation des trames PPP sur les liaisons de type HDLC.

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

  • Titre en français : Numéros assignés
  • Description : Référence d'attribution des numéros IANA (remplacée par le registre IANA en ligne).

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

  • Titre en français : PPP Multilink Protocol (MP)
  • Description : Définit le mécanisme de regroupement de plusieurs liaisons physiques en une seule liaison logique.

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

  • Titre en français : PPP Challenge Handshake Authentication Protocol (CHAP)
  • Description : Protocole d'authentification utilisé dans le proxy d'authentification L2TP.

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

  • Titre en français : Mots-clés à utiliser dans les RFC pour indiquer les niveaux d'exigence
  • Description : Définit la signification des mots-clés tels que "MUST", "SHOULD", "MAY".

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

  • Titre en français : Cisco Layer Two Forwarding (Protocol) (L2F)
  • Description : Protocole ancien de L2TP, utilisé pour la détection de version.

11.2 Informative References (Références informatives)​

Les références informatives fournissent des informations contextuelles et des explications sur les protocoles associés.

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

  • Titre en français : Internet Protocol (IPv4)
  • Description : Définit le protocole IPv4 sur lequel L2TP peut fonctionner.

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

  • Titre en français : Protocoles d'authentification PPP
  • Description : Définit le 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.

  • Titre en français : Remote Authentication Dial In User Service (RADIUS)
  • Description : Protocole d'authentification, d'autorisation et de comptabilité centralisées.

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

  • Titre en français : Politique de l'IETF sur les jeux de caractères et les langues
  • Description : Lignes directrices sur le traitement des textes internationalisés.

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

  • Titre en français : Architecture de sécurité pour le protocole Internet
  • Description : Définit l'architecture IPsec, recommandée en combinaison avec L2TP.

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

  • Titre en français : Extensions Microsoft PPP CHAP
  • Description : Définition du protocole MS-CHAPv1.

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

  • Titre en français : Internet Protocol, Version 6 (IPv6) Specification
  • Description : Définit le protocole IPv6 sur lequel L2TP peut fonctionner.

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

  • Titre en français : Microsoft PPP CHAP Extensions, Version 2
  • Description : Définition du protocole 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.

  • Titre en français : Network Security: Private Communication in a Public World
  • Description : Ouvrage de référence sur les fondements cryptographiques du mécanisme de masquage AVP.

Voici les normes importantes associées à L2TP mais non directement citées :

Versions évolutives de L2TP :

  • RFC 3931 : Layer Two Tunneling Protocol - Version 3 (L2TPv3)
    • La troisième version de L2TP, qui prend en charge le tunnelage de trames de données non PPP.
  • RFC 5515 : Layer Two Tunneling Protocol (L2TP) Access Concentrator Configuration
    • Protocole de configuration du concentrateur d'accès L2TP.

Liés à 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)

Extensions 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 et gestion du trafic :

  • 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 (Organismes de normalisation)​

IETF (Internet Engineering Task Force)

IANA (Internet Assigned Numbers Authority)

IEEE (Institute of Electrical and Electronics Engineers)

  • Normes relatives aux technologies de couche 2

UIT-T (Union internationale des télécommunications - Secteur de la normalisation des télécommunications)

  • Q.931 : Signalisation ISDN (référencée dans l'AVP Q.931 Cause Code)

11.5 Historical Context (Contexte historique)​

Le protocole L2TP est la fusion des deux protocoles suivants :

  1. L2F (Layer 2 Forwarding Protocol) - développé par Cisco Systems

    • RFC 2341

  2. PPTP (Point-to-Point Tunneling Protocol) - développé par Microsoft et d'autres

    • RFC 2637

L2TP combine les forces de ces deux protocoles et est devenu un protocole de la voie normalisée de l'IETF.

11.6 Further Reading (Lecture complémentaire)​

Ouvrages techniques :

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

Ressources en ligne :

Notes sur le format de citation (Citation Format Notes) :

Dans ce document, les RFC sont citées au format [RFCXXXX], où XXXX est le numéro de RFC. Les autres documents sont référencés par un identifiant abrégé entre crochets (par exemple [KPS]).

Les documents RFC complets sont disponibles aux sources suivantes :

12. Acknowledgments (Remerciements)​

Les auteurs de la RFC 2661 remercient tous les membres du groupe de travail IETF L2TP pour leurs contributions au développement de cette spécification.

Major Contributors (Contributeurs principaux)​

Le développement de ce protocole a bénéficié des contributions techniques de nombreuses personnes et organisations. Nous remercions tout particulièrement les contributeurs suivants :

  • L'équipe d'ingénierie de Cisco Systems, en particulier les développeurs originaux du protocole L2F
  • L'équipe d'ingénierie de Microsoft Corporation, en particulier les contributeurs au protocole PPTP
  • Les experts techniques d'Ascend Communications et de Redback Networks

Working Group Members (Membres du groupe de travail)​

Les discussions et les revues techniques du groupe de travail L2TP ont été essentielles à la qualité de cette spécification. Nous remercions tout particulièrement tous les membres ayant participé aux discussions sur la liste de diffusion, fourni des retours d'implémentation et réalisé des tests d'interopérabilité.

Technical Review (Revue technique)​

Remerciements aux personnes suivantes pour la revue technique détaillée du projet et leurs commentaires constructifs :

  • Les experts en sécurité pour la revue du chapitre sur la sécurité
  • Les experts PPP et des protocoles de tunnel pour les suggestions de conception du protocole
  • Les représentants de l'IANA pour les conseils sur le chapitre d'attribution des paramètres

Editorial Support (Support éditorial)​

Remerciements à l'équipe des éditeurs RFC pour le soutien professionnel apporté à la mise en forme du document, à la cohérence terminologique et à la clarté de l'expression technique.

Note : La liste complète des contributeurs et des organisations figure dans le chapitre des remerciements du document RFC 2661 original.

13. Authors' Addresses (Adresses des auteurs)​

Cette section liste les principaux auteurs de la RFC 2661 et leurs coordonnées (à la date de publication).

W. Mark Townsley​

Cisco Systems

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

Contribution : Rédacteur principal et coordination technique

Allan Valencia​

Cisco Systems

Email : [email protected]

Contribution : Conception du protocole et intégration L2F

Représentant d'Ascend Communications​

Andrew Rubens

Email : [email protected]

Contribution : Conception du protocole de contrôle et des AVP

Représentant de Microsoft Corporation​

Gurdeep Singh Pall

Email : [email protected]

Contribution : Intégration du protocole PPTP et mécanismes de sécurité

Représentant de Microsoft Corporation​

Glen Zorn

Email : [email protected]

Contribution : Protocoles d'authentification et conception de la sécurité

Représentant de Redback Networks​

Bernard Palter

Email : [email protected]

Contribution : Implémentation du protocole et tests d'interopérabilité

Remarques (Notes) :

  1. Les coordonnées ci-dessus correspondent à la date de publication (août 1999).
  2. Certaines adresses e-mail peuvent ne plus être valides.
  3. Pour toute question ou discussion actuelle sur le protocole L2TP, veuillez vous référer à la liste de diffusion du groupe de travail IETF L2TP.
  4. La maintenance et l'extension actuelles de la norme L2TP sont assurées par l'IETF.

Mise à jour des coordonnées :

Pour obtenir les dernières informations sur le protocole L2TP ou signaler un problème, consultez :

Appendix A: Control Channel Slow Start and Congestion Avoidance​

A.1 Aperçu (Overview)​

Le canal de contrôle L2TP utilise un mécanisme de transmission de messages fiable. Pour éviter la congestion du réseau, il est recommandé de mettre en œuvre des algorithmes de démarrage lent (slow start) et d'évitement de congestion de type TCP.

A.2 Algorithme de démarrage lent (Slow Start Algorithm)​

Paramètres initiaux :

  • Fenêtre de congestion initiale (cwnd) : 1 message
  • Seuil de démarrage lent (ssthresh) : taille de la fenêtre de réception

Étapes de l'algorithme :

  1. À chaque ACK reçu, cwnd augmente de 1
  2. Lorsque cwnd >= ssthresh, on passe à la phase d'évitement de congestion
  3. Le nombre de messages envoyés non acquittés ne dépasse pas min(cwnd, fenêtre de réception)

A.3 Évitement de congestion (Congestion Avoidance)​

Stratégie de repli :

  • En cas de détection de timeout : ssthresh = max(cwnd/2, 2)
  • Réinitialiser cwnd = 1 et redémarrer le démarrage lent

Estimation du RTT (RTT Estimation) :

  • Utilisation de l'algorithme de Jacobson/Karels pour calculer le timeout de retransmission (RTO)
  • RTT lissé = (1-α) × RTT lissé + α × RTT mesuré
  • RTO = RTT lissé + 4 × écart RTT

Appendix C: Intellectual Property Notice​

C.1 Déclaration de PI (IP Statement)​

L'IETF ne prend aucune position sur la validité ou la portée de tout droit de propriété intellectuelle ou autre droit décrit dans ce document, ni sur la mesure dans laquelle une licence sous de tels droits pourrait ou non être disponible ; elle n'indique pas non plus qu'elle a entrepris des efforts pour identifier de tels droits.

C.2 Divulgation de brevet (Patent Disclosure)​

Conformément aux exigences de la section 10.4 de la RFC 2026, les informations sur la propriété intellectuelle divulguées et liées à cette spécification sont consultables sur le site web de l'IETF.

C.3 Informations de licence (Licensing Information)​

Les implémenteurs doivent noter que certaines fonctionnalités L2TP peuvent être protégées par des brevets. L'IETF n'est pas responsable de l'identification de tels brevets ni de l'évaluation de la validité ou de la portée de toute revendication de brevet.

Liens associés :