Résumé

  • RFC 3385 montrait que « somme de contrôle sur 32 bits » restait une description incomplète : polynôme générateur, longueur du bloc, distribution des erreurs et biais des données modifiaient le risque de non-détection.
  • CRC32C était présenté comme un bon mécanisme de base pour iSCSI dans un modèle de corruption accidentelle déclaré, jamais comme une garantie cryptographique ou universelle.

Une rafale serrée de bits altérés traverse une somme additive et bute sur un CRC. Les deux résultats tiennent pourtant dans 32 bits. L’étiquette visible décrit le volume de redondance, pas les motifs que chaque code sait distinguer. En septembre 2002, RFC 3385 a rendu cette différence calculable avant qu’un nom rassurant ne devienne un choix de protocole.

Le mémo était Informational. Il estimait la probabilité d’erreurs non détectées afin d’éclairer la sélection d’un code pour iSCSI ; il ne normalisait pas à lui seul le protocole complet et ne prouvait aucun déploiement. Cette limite importe, car ses nombres sont les sorties d’un modèle, non des fréquences universelles observées.

iSCSI transportait commandes SCSI et données de stockage sur IP. Une altération silencieuse pouvait atteindre un disque ou un système de fichiers comme contenu apparemment valide. Le volume amplifiait le problème : le texte envisageait des pétaoctets transférés et voulait une très bonne protection au moins jusqu’à des blocs de 8 Kio.

RFC 3347 avait déjà expliqué pourquoi le checksum TCP ne suffisait pas comme histoire de bout en bout. Certaines erreurs pouvaient lui échapper. Un proxy pouvait terminer le flux TCP, reconstruire les en-têtes iSCSI et recalculer le checksum. Le bloc SCSI, les commandes et le statut exigeaient donc une frontière de digest appartenant à iSCSI.

RFC 3385 séparait deux phénomènes : rafales sur canal bruyant et erreurs indépendantes sur canal peu bruité. Une mémoire, une interconnexion interne ou un logiciel pouvait aussi produire une corruption groupée. La fréquence des bits faux ne suffisait pas ; leur disposition, leur durée et la longueur protégée comptaient.

Un CRC ajoute des bits de parité calculés par un polynôme générateur. Une erreur n’échappe au contrôle que si son motif possède lui-même la structure d’un mot du code. Distance minimale et distribution des poids déterminent donc la surface invisible. Deux polynômes de degré 32 ne créent pas nécessairement la même surface.

Les codes raccourcis rendaient l’écart concret. À des longueurs pratiques, le choix du polynôme pouvait modifier fortement la performance. Les travaux cités montraient plusieurs ordres de grandeur d’écart entre polynômes de 32 bits pour une condition de rafale. Les classer par largeur aurait effacé le fait décisif.

Le CRC IEEE 802 et CRC32C avaient la même largeur, mais CRC32C utilisait le générateur 0x11EDC6F41. Cette valeur n’était pas un détail d’implémentation : elle modifiait les motifs divisibles, la distance selon la longueur et, finalement, la probabilité de laisser passer certaines altérations.

Les estimations reposaient sur un taux de rafales, un taux d’erreurs indépendantes, une distribution de durée et un bloc de 8 Kio. Une rafale de durée fixe touche davantage de bits quand le débit monte. Changer le canal, la charge, la taille ou la distribution change la portée du résultat. Une borne minuscule ne devient pas une promesse hors contexte.

La comparaison avec Fletcher et Adler allait dans le même sens. Sous les hypothèses analysées, le CRC était estimé environ 12 000 fois meilleur que Fletcher et 22 000 fois meilleur qu’Adler pour les erreurs indépendantes. Des motifs courts pouvaient annuler une somme additive. Sur des données réelles biaisées, les points chauds affaiblissaient encore les checksums plus que les CRC.

Le tableau final réunissait Fletcher32, Adler32, CRC IEEE-802 et CRC32C : même largeur, distances et estimations différentes. Les auteurs jugeaient CRC32C adapté à iSCSI grâce au niveau de protection, à sa moindre sensibilité aux données biaisées et à sa capacité sur de longs blocs.

Le coût matériel fut mesuré au lieu d’être nié. Dans la synthèse citée, CRC32C occupait plus de cellules que CCITT-CRC32, mais le circuit restait sous un pour cent d’une petite puce d’environ un million de cellules. Le compromis associait un gain de détection à un coût replacé dans le budget global.

L’interopérabilité exigeait aussi ordre des bits, initialisation, complément, bourrage et placement du reste. Le mémo donnait des exemples matériels série et parallèle ; le logiciel pouvait employer des tables. Partager le nom du polynôme sans partager la procédure ne garantissait pas le même digest.

La linéarité du CRC permettait une mise à jour incrémentale lorsqu’un intermédiaire modifiait un en-tête. Le destinataire final pouvait vérifier l’ensemble et inclure les changements accidentels introduits en route. Cette propriété améliorait coût et couverture ; elle n’authentifiait pas l’intermédiaire.

RFC 7143 a ensuite consolidé le contrat iSCSI. HeaderDigest et DataDigest valent None par défaut, mais initiateurs et cibles doivent implémenter CRC32C et None. Une fois négocié, le digest s’applique aux PDU de la phase complète. Le texte le qualifie de non cryptographique.

Supporter CRC32C, le proposer, le négocier, couvrir un PDU, réussir la vérification et préserver l’intégrité après la frontière iSCSI sont des faits distincts. Un écran « compatible CRC32C » ne prouve pas que chaque session l’utilise.

La frontière de sécurité était explicite. Un attaquant capable de changer les données peut recalculer le code correspondant. Le CRC détecte des changements involontaires ; il n’authentifie ni l’émetteur ni l’autorisation. Un contrôle réussi ne constitue pas une preuve contre un adversaire actif.

RFC 3309, RFC 4960 et RFC 9260 montrent aussi CRC32C dans SCTP. Cette chronologie illustre la réutilisation d’un code étudié, pas l’identité des modèles. Longueurs, champs couverts, couches basses et récupération changent la valeur de la preuve.

RFC 1071 décrivait le checksum Internet ; RFC 1141 puis RFC 1624 son calcul incrémental, le second corrigeant une difficulté du premier. RFC 2151 présentait Fletcher pour UDP et RFC 1950 Adler-32 pour zlib. « Checksum » désigne ainsi une famille de structures et de frontières, pas un niveau interchangeable.

Le texte rappelait enfin qu’un CRC supérieur ne pouvait pas stabiliser seul le risque à mesure que les liens accéléraient. Une rafale temporelle couvrait plus de bits ; le codage des couches basses et leur taux d’erreur restaient dans la surface de contrôle.

La spécification initiale minimale de Lu Heng éclaire le partage : le protocole fixe polynôme, représentation et couverture commune, tandis que les implémentations optimisent librement matériel ou logiciel. La liberté commence après que « vérifié » signifie la même chose partout.

Sa grille des couches de réalité sépare champ présent, algorithme disponible, digest négocié, PDU couvert, valeur validée, corruption accidentelle exclue sous un modèle et intégrité adversariale. Dire « checksum 32 bits » contracte ces sept faits en un symbole qui n’en prouve presque aucun.

La contribution historique de RFC 3385 ne fut donc pas seulement de recommander CRC32C. Elle transforma un slogan d’intégrité en affirmation bornée. La largeur était l’enveloppe ; polynôme, bloc, charge, parcours et modèle de menace donnaient à cette enveloppe son sens honnête.

Sources