3.3.3. Calcul de la valeur de vérification d'intégrité

L'ICV AH est calculé sur:

• les champs d'en-tête IP ou d'extension avant l'en-tête AH qui sont soit immuables en transit soit prévisibles en valeur à l'arrivée au point de terminaison pour la SA AH
• l'en-tête AH (Next Header, Payload Len, Reserved, SPI, Sequence Number (32 bits de poids faible), et l'ICV (qui est mis à zéro pour ce calcul), et les octets de remplissage explicites (le cas échéant))
• tout ce qui suit AH est supposé être immuable en transit
• les bits de poids fort de l'ESN (s'ils sont employés), et tout remplissage implicite requis par l'algorithme d'intégrité

3.3.3.1. Gestion des champs mutables

Si un champ peut être modifié pendant le transit, la valeur du champ est mise à zéro aux fins du calcul de l'ICV. Si un champ est mutable, mais que sa valeur au récepteur (IPsec) est prévisible, alors cette valeur est insérée dans le champ aux fins du calcul de l'ICV. Le champ Integrity Check Value est également mis à zéro en préparation de ce calcul. Notez qu'en remplaçant la valeur de chaque champ par zéro, plutôt qu'en omettant le champ, l'alignement est préservé pour le calcul de l'ICV. De plus, l'approche de remplissage à zéro garantit que la longueur des champs ainsi traités ne peut pas être modifiée pendant le transit, même si leur contenu n'est pas explicitement couvert par l'ICV.

Lorsqu'un nouvel en-tête d'extension ou une nouvelle option IPv4 est créé, il sera défini dans sa propre RFC et DEVRAIT inclure (dans la section Security Considerations) des directives sur la façon dont il doit être géré lors du calcul de l'ICV AH. Si l'implémentation IP (v4 ou v6) rencontre un en-tête d'extension qu'elle ne reconnaît pas, elle rejettera le paquet et enverra un message ICMP. IPsec ne verra jamais le paquet. Si l'implémentation IPsec rencontre une option IPv4 qu'elle ne reconnaît pas, elle doit mettre à zéro toute l'option, en utilisant le deuxième octet de l'option comme longueur. Les options IPv6 (dans les en-têtes d'extension Destination ou l'en-tête d'extension Hop-by-Hop) contiennent un indicateur de mutabilité, qui détermine le traitement approprié pour de telles options.

3.3.3.1.1. Calcul de l'ICV pour IPv4

3.3.3.1.1.1. Champs d'en-tête de base

Les champs d'en-tête de base IPv4 sont classés comme suit:

Immuable:

• Version
• Internet Header Length
• Total Length
• Identification
• Protocol (Cela devrait être la valeur pour AH.)
• Source Address
• Destination Address (sans routage source strict ou lâche)

Mutable mais prévisible:

• Destination Address (avec routage source strict ou lâche)

Mutable (mis à zéro avant le calcul de l'ICV):

• Differentiated Services Code Point (DSCP) (6 bits, voir RFC 2474 [NBBB98])
• Explicit Congestion Notification (ECN) (2 bits, voir RFC 3168 [RFB01])
• Flags
• Fragment Offset
• Time to Live (TTL)
• Header Checksum

DSCP - Les routeurs peuvent réécrire le champ DS selon les besoins pour fournir un service local ou de bout en bout souhaité, ainsi sa valeur à la réception ne peut pas être prédite par l'émetteur.

ECN - Cela changera si un routeur le long de la route rencontre une congestion, et ainsi sa valeur à la réception ne peut pas être prédite par l'émetteur.

Flags - Ce champ est exclu car un routeur intermédiaire pourrait définir le bit DF, même si la source ne l'a pas sélectionné.

Fragment Offset - Puisque AH est appliqué uniquement aux paquets IP non fragmentés, le champ Offset doit toujours être zéro, et il est donc exclu (même s'il est prévisible).

TTL - Cela est modifié en route dans le cours normal du traitement par les routeurs, et ainsi sa valeur au récepteur n'est pas prévisible par l'émetteur.

Header Checksum - Cela changera si l'un de ces autres champs change, et ainsi sa valeur à la réception ne peut pas être prédite par l'émetteur.

3.3.3.1.1.2. Options

Pour IPv4 (contrairement à IPv6), il n'y a pas de mécanisme pour marquer les options comme mutables en transit. Par conséquent, les options IPv4 sont explicitement listées dans l'Annexe A et classées comme immuables, mutables mais prévisibles, ou mutables. Pour IPv4, l'option entière est considérée comme une unité; donc même si les champs de type et de longueur dans la plupart des options sont immuables en transit, si une option est classée comme mutable, l'option entière est mise à zéro aux fins du calcul de l'ICV.

3.3.3.1.2. Calcul de l'ICV pour IPv6

3.3.3.1.2.1. Champs d'en-tête de base

Les champs d'en-tête de base IPv6 sont classés comme suit:

Immuable:

• Version
• Payload Length
• Next Header
• Source Address
• Destination Address (sans en-tête d'extension Routing)

Mutable mais prévisible:

• Destination Address (avec en-tête d'extension Routing)

Mutable (mis à zéro avant le calcul de l'ICV):

• DSCP (6 bits, voir RFC2474 [NBBB98])
• ECN (2 bits, voir RFC3168 [RFB01])
• Flow Label (*)
• Hop Limit

(*) L'étiquette de flux décrite dans AHv1 était mutable, et dans la RFC 2460 [DH98] était potentiellement mutable. Pour conserver la compatibilité avec les implémentations AH existantes, l'étiquette de flux n'est pas incluse dans l'ICV dans AHv2.

3.3.3.1.2.2. En-têtes d'extension contenant des options

Les options IPv6 dans les en-têtes d'extension Hop-by-Hop et Destination contiennent un bit qui indique si l'option peut changer (de manière imprévisible) pendant le transit. Pour toute option dont le contenu peut changer en route, le champ "Option Data" entier doit être traité comme des octets à valeur zéro lors du calcul ou de la vérification de l'ICV. L'Option Type et Opt Data Len sont inclus dans le calcul de l'ICV. Toutes les options pour lesquelles le bit indique l'immuabilité sont incluses dans le calcul de l'ICV. Voir la spécification IPv6 [DH98] pour plus d'informations.

3.3.3.1.2.3. En-têtes d'extension ne contenant pas d'options

Les en-têtes d'extension IPv6 qui ne contiennent pas d'options sont explicitement listés dans l'Annexe A et classés comme immuables, mutables mais prévisibles, ou mutables.

3.3.3.2. Remplissage et numéros de séquence étendus

3.3.3.2.1. Remplissage ICV

Comme mentionné dans la section 2.6, le champ ICV peut inclure un remplissage explicite si nécessaire pour garantir que l'en-tête AH est un multiple de 32 bits (IPv4) ou 64 bits (IPv6). Si un remplissage est requis, sa longueur est déterminée par deux facteurs:

• la longueur de l'ICV
• la version du protocole IP (v4 ou v6)

Par exemple, si la sortie de l'algorithme sélectionné est de 96 bits, aucun remplissage n'est requis pour IPv4 ou IPv6. Cependant, si un ICV de longueur différente est généré, en raison de l'utilisation d'un algorithme différent, alors un remplissage peut être requis en fonction de la longueur et de la version du protocole IP. Le contenu du champ de remplissage est arbitrairement sélectionné par l'émetteur. (Le remplissage est arbitraire, mais n'a pas besoin d'être aléatoire pour atteindre la sécurité.) Ces octets de remplissage sont inclus dans le calcul de l'ICV, comptés comme faisant partie de la longueur de charge utile, et transmis à la fin du champ ICV pour permettre au récepteur d'effectuer le calcul de l'ICV. L'inclusion de remplissage en excès du montant minimum requis pour satisfaire les exigences d'alignement IPv4/IPv6 est interdite.

3.3.3.2.2. Remplissage de paquet implicite et ESN

Si l'option ESN est choisie pour une SA, alors les 32 bits de poids fort de l'ESN doivent être inclus dans le calcul de l'ICV. Aux fins du calcul de l'ICV, ces bits sont ajoutés (implicitement) immédiatement après la fin de la charge utile, et avant tout remplissage de paquet implicite.

Pour certains algorithmes d'intégrité, la chaîne d'octets sur laquelle le calcul de l'ICV est effectué doit être un multiple d'une taille de bloc spécifiée par l'algorithme. Si la longueur du paquet IP (y compris AH et les 32 bits de poids fort de l'ESN, s'ils sont activés) ne correspond pas aux exigences de taille de bloc pour l'algorithme, un remplissage implicite DOIT être ajouté à la fin du paquet, avant le calcul de l'ICV. Les octets de remplissage DOIVENT avoir une valeur de zéro. La taille de bloc (et donc la longueur du remplissage) est spécifiée par la spécification de l'algorithme. Ce remplissage n'est pas transmis avec le paquet. Le document qui définit un algorithme d'intégrité DOIT être consulté pour déterminer si un remplissage implicite est requis comme décrit ci-dessus. Si le document ne spécifie pas de réponse à cela, alors la valeur par défaut est de supposer qu'un remplissage implicite est requis (selon les besoins pour faire correspondre la longueur du paquet à la taille de bloc de l'algorithme.) Si des octets de remplissage sont nécessaires mais que l'algorithme ne spécifie pas le contenu du remplissage, alors les octets de remplissage DOIVENT avoir une valeur de zéro.