Résumé

  • La RFC 1472 rangeait les préférences de protocoles PPP et les couples identité/secret dans des tables dont la portée, le sens et l’état étaient explicites.
  • valid qualifiait une entrée disponible pour la configuration ; la preuve d’authentification exigeait encore un échange PAP ou CHAP et une décision de l’authentificateur.

Une base de gestion répond à la question « qu’est-ce que l’équipement est prêt à essayer ? ». Elle ne répond pas, par sa seule présence, à « qu’est-ce qui vient de se passer sur la liaison ? ».

Publiée en juin 1993, la RFC 1472 définissait les objets de gestion des protocoles de sécurité de PPP. Sa voisine, la RFC 1471, s’occupait du protocole de contrôle de liaison. Le groupe de sécurité était facultatif, car il réunissait des variables capables de lire des identités et des secrets ou de modifier le choix de l’authentification.

Une préférence n’était pas un résultat

La première table associait un protocole à une liaison et à un rang. Les valeurs de préférence les plus faibles devaient être essayées avant les autres. Une liaison numérotée zéro servait de règle par défaut lorsque aucune entrée particulière n’existait.

Ce mécanisme décrivait un ordre prévu. Il ne mesurait ni la robustesse du protocole, ni la probabilité de réussite, ni le soutien du pair. Une règle par défaut ne démontrait pas davantage qu’elle gouvernait réellement toutes les liaisons : une entrée locale pouvait la masquer.

Chaque ligne portait aussi un état valid ou invalid. Invalider une ligne ne forçait pas sa suppression. La RFC laissait ce choix à l’implémentation et avertissait les stations de gestion qu’elles pourraient recevoir des lignes toujours visibles mais plus utilisées. Il fallait lire l’état pour interpréter la présence.

La table contenait donc sa propre mise en garde : visible n’était pas synonyme d’actif.

Un couple de chaînes n’était pas une identité prouvée

La seconde table stockait plusieurs couples ID/Secret pour une même liaison. Un index les distinguait, mais le choix du couple appartenait à l’implémentation locale.

La direction changeait le sens opérationnel. local-to-remote désignait le couple que l’entité locale emploierait pour se faire authentifier. remote-to-local désignait celui qu’elle attendrait du pair distant. Le protocole changeait encore le sens des octets : avec PAP, il pouvait s’agir d’un Peer-ID et d’un mot de passe ; avec CHAP-MD5, d’un nom CHAP et d’un secret de calcul.

La MIB n’assimilait pas la chaîne « identité » à une personne. Elle ne disait pas qui détenait le secret au moment considéré. Elle ne consignait ni sélection effective, ni présentation par le pair, ni verdict.

valid voulait dire que l’entrée faisait partie de l’état de configuration utilisable. Ce n’était ni « correcte », ni « fraîche », ni « acceptée ».

La preuve se formait sur le fil

La RFC 1334, contemporaine, montre les actes absents de la table. PAP envoyait un Peer-ID et un mot de passe après l’établissement de la liaison, puis recevait un Authenticate-Ack ou un Authenticate-Nak. La RFC 1994 décrivit ensuite CHAP comme un défi, une réponse calculée, une comparaison par l’authentificateur et un succès ou un échec.

Ces événements doivent être reliés à la bonne version de configuration. Sans identifiant de liaison, protocole négocié, défi ou requête, réponse, version du secret et verdict, la lecture de la MIB ne reconstitue rien.

La RFC 1661 ajoutait une limite supplémentaire. PPP établissait d’abord la liaison, pouvait ensuite authentifier le pair, puis configurait les protocoles de couche réseau au moyen des NCP. Une authentification réussie ne prouvait donc pas qu’IP était ouvert ; encore moins qu’un paquet avait atteint une application.

Protéger la gestion ne prouvait pas le pair

La RFC 1472 recommandait vivement de ne pas mettre en œuvre ce groupe sans confidentialité SNMPv2. Des vues MIB protégées pouvaient restreindre le sous-arbre. Rendre les objets en lecture seule limitait l’écriture, mais n’éliminait pas le risque de lecture des secrets.

Cette protection concernait l’administration de l’équipement. Elle ne remplaçait pas l’échange d’authentification PPP. Un gestionnaire autorisé pouvait écrire une bonne ligne sans qu’aucun pair se présente. Inversement, un événement observé devait encore être rattaché à la ligne effectivement sélectionnée.

La centralisation rendait le système administrable, mais concentrait aussi le pouvoir : une préférence modifiée, un défaut trop large, une vue exposée ou une ancienne ligne mal interprétée pouvait affecter plusieurs liaisons.

Le registre nécessaire

Un historique fiable garde séparément la demande du gestionnaire, la ligne confirmée par l’agent, la portée de liaison, l’héritage du défaut, la préférence, le protocole, l’index, la direction, l’état et la lecture protégée. Une seconde chronologie conserve l’établissement LCP, le protocole négocié, la requête ou le défi, la réponse, le verdict, l’état NCP et le trafic.

Une ligne valide jamais choisie reste un inventaire. Une ligne invalide encore choisie est une anomalie d’exécution. Un succès impossible à rattacher à une version de secret est un défaut d’attribution. Une liaison authentifiée mais bloquée à IPCP est un autre incident.

La précision historique de la RFC 1472 tient à cette modestie. Elle permettait d’administrer une possibilité. Elle n’appelait pas cette possibilité un fait accompli.

Sources