Résumé

  • RFC 10011 fournit des modules YANG pour configurer les clients et serveurs RESTCONF, y compris Call Home. Une intention déclarée dans ce modèle ne constitue pas une observation de session.
  • RFC 8071 inverse l’initiateur TCP, mais conserve les rôles RESTCONF et de transport sécurisé. Le client de gestion doit encore valider la clé ou le certificat présenté par le serveur.
  • Une exploitation sûre conserve séparément la configuration voulue, l’acceptation TCP, la validation d’identité, l’authentification RESTCONF et l’autorisation locale d’une action.

Le premier paquet n’a pas le pouvoir de nommer son auteur

Call Home répond à un problème de topologie, non à un problème magique d’identité. L’équipement peut se trouver derrière une traduction d’adresses, ne pas publier son adresse, ne disposer d’aucun port de gestion ouvert, ou devoir rejoindre un système de gestion lors de son premier démarrage. RFC 8071 permet alors au serveur RESTCONF de commencer le TCP vers le client RESTCONF. La solution évite à l’opérateur de rendre chaque équipement directement joignable.

Ce mouvement inverse peut pourtant créer un raccourci mental. Une équipe voit l’équipement comme initiateur du flux et conclut que le flux l’authentifie. RFC 8071 ne dit pas cela. Il précise que l’inversion ne concerne que TCP. L’équipement reste le serveur pour TLS et pour RESTCONF; le système de gestion reste le client. L’ordre des paquets ne réécrit pas la relation de confiance.

L’adresse source, le port, une heure attendue ou une ligne de configuration correspondante sont des indices de transport. Ils peuvent aider à rechercher un problème. Ils ne remplacent pas la référence d’identité que le client devait connaître avant la connexion. Un attaquant, un équipement mal enrôlé ou une erreur de configuration peut aussi atteindre un écouteur. La réception d’un flux décrit une arrivée, non l’attribution d’une personne technique.

RFC 10011 décrit une possibilité; il ne certifie pas son exécution

RFC 10011 apporte deux modules YANG, l’un pour le client RESTCONF, l’autre pour le serveur. Ils s’inscrivent avec les modèles de magasin de confiance, de clés, de TCP, SSH, TLS, HTTP et NETCONF. Cette cohérence a une valeur considérable : les composants peuvent décrire une relation de connexion avec un vocabulaire commun, plutôt qu’avec des conventions locales impossibles à comparer.

Mais un nœud YANG est une donnée de configuration ou d’état modélisée. Il n’est pas un témoin autonome. Une entrée qui nomme une destination, un port ou une confiance ne montre pas qu’un processus écoute réellement, qu’une route fonctionne, qu’un pair tente une connexion, qu’une négociation TLS aboutit, ni que le pair reçu est celui que l’équipe attendait.

La séparation de l’architecture NMDA entre configuration et état opérationnel protège précisément contre cette confusion. La configuration répond : « que voulons-nous permettre ou tenter ? » L’état opérationnel répond : « qu’observons-nous maintenant ? » Une console qui répond à la première question avec un voyant vert de la seconde invente une certitude qui n’existe pas.

Un dossier de preuve utile contient donc quatre couches. D’abord, l’intention : identité attendue, écouteur, transport et matériau de confiance. Ensuite, le fait réseau : quelle connexion TCP a été acceptée, quand et par quel écouteur. Puis la validation : quelle clé ou quel certificat a été présenté, contre quelle ancre ou épingle a-t-il été vérifié, et quel identifiant préconnu a été comparé. Enfin, la session : quelle authentification RESTCONF a réussi et sous quel compte. Une demande de changement vient après ces quatre couches, avec sa propre autorisation.

Le certificat doit répondre à une attente antérieure

RFC 8071 exige du client qu’il valide la clé d’hôte ou le certificat présenté par le serveur. La validation peut suivre une chaîne vers un émetteur préconfiguré ou comparer une valeur déjà approuvée. Lorsque la chaîne de certificats est utilisée, l’identifiant porté par le certificat doit correspondre à un identifiant dont le client avait connaissance avant la tentative. Les identifiants de client utilisés ensuite doivent aussi être associés au serveur présenté.

La grammaire est importante. Le pair ne peut pas faire autorité en déclarant son propre nom. Le système qui se fie à lui doit posséder une attente indépendante. C’est ce qui sépare une preuve de correspondance d’une affirmation arrivée avec le paquet.

RFC 8071 souligne aussi le risque d’envoyer un secret partagé à un autre serveur portant un identifiant apparemment identique, si l’émetteur de certificats est trop général. La leçon n’est pas de rejeter Call Home. Elle est de rendre la chaîne de confiance et l’association des identifiants assez précises pour que la commodité de la connexion inverse n’efface pas le contrôle d’identité.

La session ne reçoit pas un mandat par défaut

RESTCONF est une interface HTTP vers des données YANG de configuration et d’état. Il donne un protocole de consultation et de modification; il ne décide pas si une modification particulière est souhaitable, à quel moment, pour quel service ou avec quel retour arrière.

Le principe de Heng Lu s’applique sans métaphore. La spécification minimale commune peut définir des structures de connexion et des vérifications déterministes. Les choix futurs restent localisés : identités admises, émetteurs reconnus, comptes de service, périmètres de changement, présence humaine, fenêtre de maintenance et conditions de restauration. L’adoption volontaire signifie aussi qu’un opérateur peut refuser un mode d’enrôlement ou une action, même si les deux parlent le même modèle YANG.

Le contrôle ne devient pas moins technique parce qu’il reste local. Au contraire, il devient attribuable. La connexion peut être standardisée; la décision qui affecte un service doit garder son propriétaire.

Une chaîne de preuves plus utile qu’un statut unique

Pour chaque événement Call Home, conserver la révision qui a permis l’écoute, l’identité attendue, le tuple de transport accepté, le résultat de validation, le résultat d’authentification RESTCONF, la requête formulée, l’approbation applicable et l’état antérieur nécessaire au retour arrière.

Cette discipline donne un sens limité mais solide aux signaux. Une connexion sans validation est un fait de transport. Une validation sans session est un fait cryptographique. Une session sans autorisation est un fait d’accès. Une modification réussie sans preuve de restauration n’est pas une clôture de risque. Aucun de ces termes ne doit emprunter le poids de l’autre.