Résumé

  • Le tunnel L2F est établi avec MID=0; chaque connexion cliente possède ensuite son propre MID non nul et sa propre décision d’acceptation.
  • CLID, MID, challenge et Key décrivent un contexte entre NAS et Home Gateway, pas l’identité autorisée d’une personne ni une session applicative.
  • RFC 2341 n’assure pas la livraison fiable du trafic de données : un contrôle sain ne constitue donc pas un reçu pour chaque trame.

Un aiguillage à deux étages

RFC 2341 organise un service de numérotation virtuelle. L’abonné appelle physiquement le serveur d’accès réseau, ou NAS, d’un fournisseur. Pourtant, la liaison PPP ou SLIP doit se terminer sur une Home Gateway distante. L2F transporte les trames de couche liaison entre les deux et permet ainsi de dissocier le lieu d’accès de l’endroit où le protocole est réellement terminé.

Cette séparation produit une série d’états qui ne sont pas interchangeables. L’appel peut atteindre le NAS sans qu’une liaison PPP soit configurée. Le NAS peut reconnaître une identité apparente et choisir une Home Gateway sans que celle-ci accepte le client. Le tunnel peut être ouvert alors qu’aucune connexion cliente n’existe. Une connexion peut être acceptée avant une authentification complémentaire. Enfin, les trames peuvent circuler sans qu’une application obtienne une réponse exploitable.

La première négociation utilise MID=0. Les pairs échangent L2F_CONF et L2F_OPEN, avec leurs noms, challenges et CLID attribués. Le texte indique qu’après cette étape le tunnel devient disponible pour l’établissement de clients. Il ne dit pas qu’un client est déjà établi.

La deuxième négociation concerne un MID non nul. Le NAS envoie un autre L2F_OPEN, qui peut transporter le type d’authentification et des éléments issus de CHAP, PAP ou LCP. La réponse L2F_OPEN de la Home Gateway signifie qu’elle accepte cette connexion cliente. Le transfert des trames PPP ou SLIP commence ensuite. Le même tunnel peut donc contenir plusieurs décisions distinctes, et le succès de l’une ne vaut pas pour les autres.

Le numéro sélectionne un état, pas une personne

Le CLID sert à démultiplexer des tunnels entremêlés lorsque le transport sous-jacent ne permet pas de les distinguer avec certitude. Le MID repère une connexion cliente à l’intérieur du tunnel. La valeur zéro est réservée au contrôle du tunnel; les valeurs non nulles décrivent les clients. Après fermeture, un MID réutilisé doit être initialisé comme une nouvelle connexion.

Ce sont des clés de contexte. Elles répondent à la question « quelle entrée de la machine d’état faut-il consulter ? », pas à la question « qui est juridiquement autorisé à agir ? ». Une base d’exploitation qui transforme automatiquement le MID en identité d’utilisateur ajoute une conclusion qui n’existe pas dans le protocole.

Le RFC nomme lui-même la limite. Chez le fournisseur d’accès, l’objectif est de découvrir l’« identité apparente » et la Home Gateway cible. La gateway décide ensuite d’accepter ou de refuser. Une troisième authentification peut encore avoir lieu après l’acceptation et se situe hors du champ de L2F. CHAP possède de son côté sa propre frontière de challenge-réponse dans RFC 1994. Collecter un nom, le transmettre, vérifier un secret, autoriser un protocole et ouvrir une session applicative sont cinq reçus différents.

Un plan de contrôle fiable sur un transport de données non fiable

L2F impose la retransmission des messages de contrôle. Il ne fournit cependant ni contrôle de flux ni livraison fiable au trafic de données; le protocole transporté doit gérer ses reprises. Les paquets de données ordinaires n’utilisent généralement pas le champ de séquence L2F.

Cette règle interdit une déduction fréquente. Un ECHO reçu, une Key correcte ou un OPEN confirmé prouve un événement du plan de contrôle. Cela ne prouve pas le destin de chaque trame. Un compteur qui augmente établit qu’un équipement a observé quelque chose à une frontière donnée; il ne constitue pas une chaîne de garde de bout en bout.

Pour PPP, L2F transporte une trame de liaison après retrait du framing physique, de la transparence et du FCS. Il ne cherche pas à interpréter le résultat supérieur. Les ECHO PPP, la négociation NCP et les demandes de terminaison restent des trames HDLC-like encapsulées. L2F ne détecte pas lui-même TERMREQ; le résultat au point terminal PPP doit provoquer la fermeture L2F correspondante.

PPP ajoute encore les phases LCP, l’authentification éventuelle et la configuration réseau par NCP. Une application doit ensuite établir sa propre session. Même une séquence parfaite jusqu’au client OPEN s’arrête donc avant la preuve d’un service utilisable.

La Key protège une relation délimitée

Lors de l’établissement du tunnel, les deux extrémités utilisent un secret partagé et un calcul de challenge-réponse. Une Key de 32 bits dérivée de la réponse peut accompagner les paquets suivants; CLID inconnus, mauvaises Keys et paquets invalides doivent être rejetés. Le mécanisme réduit certains risques d’usurpation dans une relation NAS–Home Gateway déjà configurée.

Il ne garantit ni confidentialité du contenu, ni autorisation de l’utilisateur final, ni authentification applicative. RFC 3193, consacré plus tard à la protection de L2TP par IPsec, sépare explicitement l’authentification du tunnel, l’intégrité par paquet, l’anti-rejeu, la confidentialité et la sécurité de bout en bout. Cette distinction ultérieure ne donne pas ces propriétés à L2F; elle permet de mieux nommer ce que son reçu ne couvre pas.

Un document historique, pas une preuve d’adoption

RFC 2341 est classé Historic. Son avis de statut précise qu’il ne définit aucune norme Internet. Le Datatracker le range dans le flux Legacy, sans approbation de l’IETF ni statut formel dans son processus de normalisation. Le document reste une source technique utile, mais sa publication ne démontre ni déploiement, ni interopérabilité, ni usage actuel.

La lecture opérationnelle correcte consiste à tenir un registre par frontière : appel physique, LCP, choix de la gateway, tunnel par CLID, client par MID, authentification ultérieure, trame émise et reçue, NCP, session applicative et résultat visible. Les compteurs du NAS et de la Home Gateway doivent rester séparés. Un reçu sans objet et sans frontière n’est pas une preuve de service.

Sources