Résumé

  • Dans RFC 3423, l’ACK du transport détectait pertes et serveur injoignable ; l’ACK CRANE n’avançait qu’après traitement correct et placement de l’information comptable dans un stockage persistant.
  • Même cet ACK ne certifiait ni séquence complète, ni suppression des doublons, ni bon gabarit, ni facture juste : ces conclusions appartenaient à d’autres acteurs et à d’autres reçus.

La panne entre deux accusés

Prenons un équipement qui expédie un enregistrement d’usage. TCP confirme la livraison. Puis le processus destinataire s’arrête avant l’écriture durable. Le réseau peut afficher du vert sans mentir ; c’est l’étiquette « enregistrement sauvegardé » qui mentirait.

Publié en novembre 2002, RFC 3423 décrivait le Common Reliable Accounting for Network Element de XACCT. Le texte brut, la notice RFC Editor, la fiche IETF, son historique, ses références et la recherche d’errata fixent le statut : document Informational, proposition issue d’une entreprise, pas norme Internet et pas preuve d’un déploiement actuel.

CRANE visait l’export volumineux de données comptables depuis des éléments de réseau vers médiation, BSS ou OSS. Son choix le plus important n’était pas un format de champ, mais deux seuils de certitude.

Le transport ne tenait pas le grand livre

Le protocole exigeait un transport fiable, orienté connexion et ordonné. TCP convenait ; le SCTP historique de RFC 2960 était préféré dans le mémo pour ses messages, son authentification possible et une détection de panne plus rapide. Cette préférence appartient au texte de 2002, pas à une mesure d’adoption.

L’ACK du transport servait à détecter les paquets perdus et les serveurs qui ne répondaient plus. L’ACK CRANE intervenait après que le message avait été traité et que l’information comptable avait été placée en stockage persistant. La différence est temporelle, mais surtout institutionnelle : la pile réseau atteste ce qu’elle contrôle ; l’application réceptrice atteste ce qu’elle a traité et conservé.

RFC 2975 avait placé stockage non volatil et élimination des doublons dans le problème général de la comptabilité. CRANE transformait cette préoccupation en frontière observable. Le mot fiable ne pouvait plus s’arrêter au transport.

Le DSN dessinait une ligne continue

Chaque message DATA portait un Data Sequence Number. Après démarrage ou changement de serveur, le premier message fixait la synchronisation avec le bit S. Chaque nouveau message augmentait le DSN d’une unité. Le serveur devait accepter la séquence dans l’ordre et écarter ce qui arrivait hors séquence.

DATA ACK ne répétait pas simplement le plus grand numéro aperçu. Il donnait le dernier DSN correctement traité dans une séquence continue. Recevoir 3123 sans 3122 ne permettait donc pas d’avancer jusqu’à 3123. Un message hors ordre provoquait le renvoi de l’ACK courant afin de déclencher la retransmission du manque.

Ce front était précis mais limité. Il n’attestait ni tarification, ni rattachement au bon abonné, ni facture, ni règlement. Il ne promettait même pas que le support de stockage survivrait éternellement. Il exprimait la prétention du récepteur à un instant donné.

Une seule suite, plusieurs récepteurs

Une session pouvait compter plusieurs serveurs classés par priorité. Le client utilisait le serveur opérationnel qu’il jugeait prioritaire. Sans serveur disponible, il conservait les données dans sa propre file jusqu’au retour d’un récepteur ou jusqu’à épuisement de l’espace, situation qui devait produire une alarme.

Le changement pouvait suivre quatre indices : port déclaré injoignable par le transport, volume non acquitté au-dessus d’un seuil pendant une durée réglée, message STOP, ou retour du serveur mieux classé. L’algorithme exact restait une affaire d’implémentation.

RFC 3423 donne une topologie comptable saisissante : serveur 1 reçoit 3042–3095, serveur 2 reçoit 3096–3122, puis serveur 1 reprend à 3123. Aucun serveur ne possède tout ; le système de médiation doit néanmoins recevoir la suite entière.

La retransmission peut créer des copies. Le bit Duplicate marquait un enregistrement envoyé de nouveau vers un autre serveur ; le DSN devait permettre au système aval de dédoublonner. Ce bit ne disait pas qu’un doublon existait réellement, encore moins qu’il avait été supprimé. Il transformait un risque en signal, pas en résultat.

Stocker avec le mauvais gabarit reste une erreur durable

Pour économiser la bande passante, CRANE négociait des templates au lieu de joindre la description des champs à chaque enregistrement. Un template ordonnait les clés, leurs types et leur signification ; des clés pouvaient être actives ou non. Tous les serveurs d’une session devaient partager le même ensemble et le même état.

Chaque donnée portait Template ID et Configuration ID. Un serveur pouvait conserver un bref historique pour lire une ancienne configuration. Le transport était censé éviter l’arrivée prématurée d’une configuration future. Et avant de changer de template, le client devait de préférence attendre l’acquittement des données de la configuration précédente.

Le dialogue était volontairement asymétrique : chaque serveur proposait au plus une modification ; le client décidait l’ensemble final ; FINAL TMPL DATA obligeait ensuite les serveurs à accepter sans relancer la négociation. La règle coupait les boucles, mais montrait aussi qui détenait le dernier mot.

Ainsi, une écriture durable sans identité de configuration peut préserver fidèlement des octets mal interprétés. Persistance et sens sont deux garanties.

Un épisode parmi plusieurs familles comptables

Le texte situait CRANE face à RADIUS et Diameter. RFC 2865 décrit l’accès RADIUS et RFC 2866 sa comptabilité. Le Diameter de RFC 3588 a ensuite été remplacé par RFC 6733. RFC 3334 pose des exigences de comptabilité guidée par politique.

Plus tard, IPFIX a donné un autre cadre aux exports et modèles : protocole, modèle d’information, conseils d’implémentation. Ces rapprochements montrent des problèmes récurrents ; ils ne prouvent ni filiation de production ni compatibilité.

Les majuscules normatives suivent RFC 2119. Un MUST prouve ce que le document exigeait, jamais qu’un programme l’a fait.

La sécurité n’était pas incluse dans l’ACK

RFC 3423 reconnaissait l’absence de forte confidentialité et intégrité propres au protocole. Des adresses statiquement provisionnées pouvaient organiser les interlocuteurs, mais restaient exposées à l’usurpation sans protection supplémentaire. IPsec ou TLS étaient recommandés selon le déploiement.

La réussite de DATA ACK ne certifiait donc pas à elle seule l’identité du pair, l’intégrité des octets ou l’autorisation du serveur. Le canal, le pair, le template, le stockage et la décision comptable avaient chacun leur frontière.

Sources et limites

La méthode suit aussi Heng Lu sur les couches de réalité et la primauté du code en exécution : une spécification, une implémentation, une configuration et une observation ne se remplacent pas.

Le corpus explique le mécanisme et son époque. Il ne fournit aucun recensement présent, aucune performance mesurée, aucun incident nommé, aucune preuve qu’un produit actuel emploie CRANE. L’article conserve donc le passé composé et refuse de transformer une architecture documentaire en réalité opérationnelle actuelle.