Résumé

  • La somme de contrôle IPv4 sur 16 bits couvre uniquement l’en-tête, afin de vérifier les informations nécessaires au traitement du datagramme.
  • Comme certains champs changent en transit, elle est vérifiée puis recalculée à chaque point de traitement de l’en-tête.

Protéger ce que les routeurs utilisent

Le RFC 791 définit une somme en complément à un, calculée sur les mots de 16 bits de l’en-tête. Le champ de somme est considéré comme nul pendant le calcul. Le résultat est ensuite placé dans l’en-tête.

Cette portée est intentionnelle. Destination, longueur, fragmentation, durée de vie et protocole déterminent la manière dont le datagramme est traité. Le RFC 791 précise que la somme vérifie ces informations de traitement, tout en reconnaissant que les données peuvent encore comporter des erreurs. Une somme invalide entraîne l’abandon immédiat du datagramme par l’entité qui la détecte.

IPv4 n’offre donc pas une intégrité de bout en bout du contenu. La protection des données dépend d’un autre mécanisme éventuel, dont l’existence ne peut pas être déduite d’une somme d’en-tête valide.

Une valeur qui évolue en transit

Le TTL diminue lors du traitement. La fragmentation, une modification d’adresse ou d’option peut également changer l’en-tête. Le RFC 791 impose donc une vérification et un recalcul à chaque point où l’en-tête est traité.

Un recalcul complet est simple, mais une mise à jour incrémentale peut éviter de reprendre tous les mots. Le RFC 1624 rappelle toutefois que le raccourci doit produire exactement le même résultat.

Le piège des deux zéros

L’arithmétique en complément à un possède deux représentations de zéro, positive et négative. La formule du RFC 1141 pouvait produire une représentation différente de celle du calcul complet dans un cas limite. Le RFC 1624 corrige la procédure incrémentale sans modifier la largeur du champ ni sa portée limitée à l’en-tête.

Sources