Résumé

  • La RFC 5381 décrit un client et un serveur NETCONF/SOAP dont les artefacts Java sont générés à partir de WSDL et de schémas XML, mais dont la logique de service reste à implémenter.
  • En recopiant l’identifiant de session NETCONF dans un cookie HTTP, le système a créé un registre de corrélation pratique mais non interopérable avec le modèle conforme à la RFC 4743.

Trois traces pour une seule conversation

Le scénario paraît ordinaire. Un NMS envoie hello. L’équipement alloue un identifiant de session. La réponse le transporte dans l’élément NETCONF prévu à cet effet et dans un cookie HTTP. Le NMS conserve la valeur puis la renvoie dans les requêtes suivantes. À la fermeture, les deux côtés effacent l’état.

Pris isolément, chaque geste est cohérent. Ensemble, ils déplacent pourtant l’autorité de session. La RFC 4743 liait l’état NETCONF à la connexion de transport persistante. L’expérience décrite dans la RFC 5381 ajoute une corrélation par cookie afin de composer avec des serveurs HTTP qui traitent les requêtes indépendamment. Le document reconnaît que ce choix constitue une liaison alternative et qu’elle n’interopère pas avec une implémentation conforme à la RFC 4743.

Le cookie n’était donc pas un simple détail d’en-tête. Il était devenu un second registre de session.

Cette distinction est décisive lors d’une reconnexion, d’un basculement, d’un passage par un mandataire ou d’un rejeu. La connexion peut changer tandis que le cookie reste. Le cookie peut disparaître tandis que le processus serveur conserve un état. L’identifiant XML peut correspondre à une entrée différente de celle qu’indique le transport. Tant que les deux extrémités partagent la même convention privée, l’écart reste invisible. Il apparaît au premier pair indépendant.

La description ne possédait pas l’état

WSDL décrit des opérations, des messages, des liaisons et des points de service. Apache Axis pouvait transformer cette description en classes Java. Côté client, les stubs donnaient l’impression d’appeler des méthodes locales. Côté serveur, les squelettes fournissaient une structure à compléter.

La génération ne décidait pas qui possédait la session. Elle ne décidait pas davantage si le cookie devait survivre à la connexion, si un intermédiaire pouvait le recopier, si deux requêtes pouvaient être traitées en parallèle ou si la fermeture NETCONF suffisait à purger tout l’état HTTP. Ces choix vivaient dans le code et dans l’exploitation.

La RFC 5381 donne un indice utile : le fichier WSDL de liaison n’était pas suffisant à lui seul, car il manquait un élément de service. Un second fichier devait fournir le point d’accès. De même, les modèles de données des fonctions réseau devaient être décrits séparément. La description partagée réduisait le travail mécanique, sans réunir tous les objets de gouvernance.

Une preuve d’interface doit donc porter son périmètre. Le condensat du WSDL prouve quelle description a été utilisée. La version du générateur prouve quel transformateur a produit les classes. Aucun des deux ne prouve la politique de session effectivement exécutée.

Un acquittement n’est pas une modification d’équipement

Le trajet complet traverse plusieurs juridictions techniques. HTTPS établit un canal protégé. Le serveur HTTP reçoit la requête. Le module SOAP retire l’enveloppe. Le fournisseur de service NETCONF analyse le RPC. Un contrôle d’autorisation décide si l’opération est permise. Un datastore est modifié et éventuellement validé ou validé puis confirmé. Enfin, l’équipement réalise la configuration et le réseau présente — ou non — l’effet attendu.

Un code HTTP positif ne prouve que le début de cette chaîne. Une enveloppe SOAP valide ne prouve pas que le message NETCONF a été accepté. Un rpc-reply peut signaler un traitement protocolaire sans démontrer qu’un effet opérationnel durable existe. Même une modification du datastore ne remplace pas une observation indépendante du comportement de l’équipement.

La RFC n’affirme pas qu’un incident précis s’est produit. Elle expose assez clairement les couches pour empêcher leur fusion. Sur une plateforme contrainte, un démon HTTP, un module SOAP en C et le fournisseur NETCONF peuvent être des composants distincts. Cette architecture rend visibles des frontières que les bibliothèques Java masquent au développeur.

La conformité n’était pas implicite dans la sécurité

La RFC 5381 reprend les exigences de sécurité de NETCONF et de sa liaison SOAP. Elle demande que l’authentification et le chiffrement de transport soient assurés par TLS, soit NETCONF/SOAP/HTTPS.

TLS protège une relation de transport. Il ne résout pas le conflit entre connexion et cookie comme source de vérité. Il n’accorde pas automatiquement le droit d’exécuter edit-config. Il ne garantit ni le bon datastore, ni l’application matérielle, ni l’effet de service. L’identification du pair et l’autorité de gestion sont deux décisions.

La note de l’IESG ajoute qu’une implémentation ne proposant que SOAP, sans au moins SSH, ne satisfaisait pas le profil NETCONF requis à l’époque. Un canal SOAP pouvait donc être authentifié, chiffré et fonctionnel tout en restant incomplet du point de vue de la conformité globale.

Une dette d’état survit au protocole

Les textes ultérieurs ont déplacé le paysage. La RFC 6241 a remplacé la base NETCONF initiale et la RFC 6242 a encadré le transport SSH actualisé. La RFC 9900 a ensuite rendu historiques les RFC 4743 et 4744 et libéré leurs numéros de port, tout en conservant les noms de service comme traces historiques.

Cette évolution ne supprime pas les conventions locales. Un cookie de session, une classe générée, un fichier WSDL copié, un objet de pare-feu ou une image ancienne peuvent rester dans un réseau privé. L’article BTW consacré à la RFC 9900 traite déjà de l’écart entre registre public et retrait local. La RFC 5381 apporte ici autre chose : la dette naît lorsque l’organisation ne sait plus quel registre de session faisait autorité.

La discipline de Heng Lu impose de distinguer la déclaration et le code en fonctionnement. Dans ce cas, il faut encore distinguer trois états : la description de l’interface, la convention de corrélation et la réalisation de la commande. Un même identifiant ne doit pas les confondre.

Sources