Résumé

  • RFC 9900 désaffecte les ports TCP et UDP 831, 832 et 833, mais conserve les noms historiques des services NETCONF : le registre change, pas automatiquement les systèmes déployés.
  • Une preuve de retrait doit borner l’inventaire des images, configurations, écoutes, équipements intermédiaires et flux ; le seul numéro ne prouve ni le protocole ni son absence.

La règle de pare-feu n’avait plus reçu un paquet depuis des mois. Elle restait pourtant active, copiée dans deux modèles et décrite comme « NETCONF historique ». L’équipe voulut la supprimer en citant RFC 9900. Le changement paraissait mécanique, jusqu’à ce qu’un équipement hors inventaire apparaisse dans un ancien plan d’adressage.

La bonne question n’était pas de savoir si l’IETF avait eu raison. Le registre avait été correctement modifié. Il fallait savoir ce que la règle protégeait encore, si un processus écoutait, quel contenu circulait et quelle population n’avait jamais été observée.

RFC 9900 retire 831 de netconf-beep, 832 de netconfsoaphttp et 833 de netconfsoapbeep, pour TCP comme pour UDP. Les RFC historiques 4744 et 4743 décrivaient ces transports. Le nouveau texte ne retire pas les noms de service ; il libère leurs numéros et laisse une note sur leur usage antérieur.

Cette distinction vient de RFC 6335. Le nom est une clé symbolique durable. Le numéro est une ressource finie, coordonnée par IANA. Lorsqu’un numéro n’est plus utilisé, IANA peut le désaffecter après avoir raisonnablement établi ce retrait, le marquer Reserved et conserver l’historique. Le nom, moins rare, devrait rester attribué.

Le résultat est volontairement asymétrique. Le registre public peut dire : « ce numéro n’est plus assigné à ce service ». Une base locale peut encore contenir l’ancienne association. Un binaire peut l’avoir intégrée. Une appliance isolée peut conserver une écoute. Un firewall peut autoriser la destination. Aucun de ces résidus ne redonne une affectation mondiale au service ; aucun changement mondial ne les supprime.

RFC 9900 emploie la formule « aucune implémentation ou aucun déploiement connu ». C’est une affirmation sérieuse, mais bornée par ce qui a pu être connu. Le texte le reconnaît lui-même en demandant de réévaluer et mettre à jour toute configuration qui associerait encore les ports aux noms historiques. Il ne transforme pas une recherche communautaire en télémétrie universelle.

L’absence demande donc une méthode. Quels fabricants, versions, images, dépôts, segments, fichiers de services et plans de pare-feu ont été interrogés ? Pendant quelle période ? Quels équipements étaient injoignables ? Les collecteurs de flux conservaient-ils assez longtemps les tentatives rares ? Sans ce dénominateur, « rien trouvé » signifie seulement « rien trouvé dans une surface inconnue ».

L’inverse est tout aussi important. Une socket ouverte sur 831 ne prouve pas NETCONF over BEEP. RFC 7605 rappelle qu’une affectation ne garantit pas l’usage exclusif : configuration erronée ou emploi volontaire peuvent placer n’importe quel service sur n’importe quel port. Le contenu et le comportement du protocole doivent confirmer l’étiquette.

Une enquête mature sépare cinq lignes. La première enregistre l’époque du registre IANA. La deuxième cherche les noms et numéros dans les configurations et images. La troisième observe les sockets et les politiques réseau. La quatrième examine les échanges, sans déduire le protocole du port. La cinquième demande au système de gestion si une session authentifiée et une opération NETCONF ont effectivement abouti.

Ces lignes ne sont pas interchangeables. Un objet de pare-feu non référencé n’est pas une autorisation active. Une écoute n’est pas une session. Une connexion TCP n’est pas NETCONF. Une session NETCONF n’est pas une modification validée. La concision d’un tableau de conformité ne doit pas effacer ces juridictions.

Les transports qui restent actifs empêchent aussi les nettoyages par motif. RFC 6242 conserve le port 830 pour NETCONF over SSH. RFC 7589 concerne NETCONF over TLS et 6513. RFC 8071 couvre le Call Home, notamment 4334. RFC 9900 ne libère aucun de ces numéros. Supprimer « tous les ports NETCONF » serait une extrapolation dangereuse.

La réutilisation future est le point irréversible. RFC 6335 conseille de ne réassigner un numéro désaffecté qu’après épuisement des numéros encore libres dans la plage. Il traite la réutilisation comme deux actes : désaffectation, puis nouvelle affectation. Il demande un examen lorsque des utilisateurs anciens peuvent subsister. RFC 7605 note même que la récupération est pratiquement impossible malgré sa possibilité procédurale.

Une future affectation serait juridiquement et techniquement valide au niveau du registre. Elle ne convertirait pas magiquement les vieux paquets au nouveau protocole. Le nouveau service devrait observer les collisions, classer le contenu, limiter les sources ambiguës et garder un canal de retrait. Le port fournirait un point de rendez-vous ; il ne serait pas une preuve d’identité.

Le retour arrière doit lui aussi rester local. On peut restaurer une règle ou une image. On ne peut pas annuler RFC 9900 depuis un réseau privé. Après une éventuelle réaffectation, restaurer l’ancien couple nom-numéro créerait peut-être précisément le conflit que le registre cherchait à éviter.

La primauté du code en fonctionnement décrite par Heng Lu dans Running-Code Primacy ne nie pas le registre ; elle empêche de lui faire témoigner pour les machines. Minimum Initial Specification justifie une coordination mondiale mince, laissant l’observation et le retrait aux opérateurs.

Reality Layers aide à résister à la capture symbolique : une ligne exacte n’est pas la réalité entière. Data Sovereignty distingue pareillement l’autorité formelle et le contrôle pratique. RFC 9900 ferme proprement une affectation. Une organisation ne peut fermer son dossier qu’après avoir montré ce qu’elle a réellement retiré.

Sources