3.4. Traitement des paquets entrants

3.4.1. Réassemblage

Si nécessaire, le réassemblage est effectué avant le traitement ESP. Si un paquet offert à ESP pour traitement semble être un fragment IP, c'est-à-dire que le champ OFFSET est non nul ou que le flag MORE FRAGMENTS est activé, le récepteur DOIT rejeter le paquet; ceci est un événement auditable. L'entrée du journal d'audit pour cet événement DEVRAIT inclure la valeur SPI, la date/heure de réception, l'adresse source, l'adresse de destination, le numéro de séquence et (dans IPv6) l'ID de flux.

NOTE: Pour le réassemblage de paquets, la spécification IPv4 actuelle N'EXIGE PAS la mise à zéro du champ OFFSET ou l'effacement du flag MORE FRAGMENTS. Pour qu'un paquet réassemblé soit traité par IPsec (par opposition à être rejeté comme un fragment apparent), le code IP doit faire ces deux choses après avoir réassemblé un paquet.

3.4.2. Recherche d'association de sécurité

À la réception d'un paquet contenant un en-tête ESP, le récepteur détermine la SA (unidirectionnelle) appropriée via une recherche dans la SAD. Pour une SA unicast, cette détermination est basée sur le SPI ou le SPI plus le champ de protocole, comme décrit dans la Section 2.1. Si une implémentation supporte le trafic multicast, l'adresse de destination est également employée dans la recherche (en plus du SPI), et l'adresse de l'expéditeur peut également être employée, comme décrit dans la Section 2.1. (Ce processus est décrit plus en détail dans le document Security Architecture.) L'entrée SAD pour la SA indique également si le champ Sequence Number sera vérifié, si des numéros de séquence de 32 ou 64 bits sont employés pour la SA, et si le champ ICV (explicite) devrait être présent (et si oui, sa taille). De plus, l'entrée SAD spécifiera les algorithmes et les clés à employer pour le déchiffrement et le calcul de l'ICV (le cas échéant).

Si aucune association de sécurité valide n'existe pour ce paquet, le récepteur DOIT rejeter le paquet; ceci est un événement auditable. L'entrée du journal d'audit pour cet événement DEVRAIT inclure la valeur SPI, la date/heure de réception, l'adresse source, l'adresse de destination, le numéro de séquence et (dans IPv6) l'ID de flux en texte clair.

(Notez que le trafic de gestion SA, tel que les paquets IKE, n'a pas besoin d'être traité en fonction du SPI, c'est-à-dire que l'on peut démultiplexer ce trafic séparément en fonction des champs Next Protocol et Port, par exemple.)

3.4.3. Vérification du numéro de séquence

Toutes les implémentations ESP DOIVENT supporter le service anti-rejeu, bien que son utilisation puisse être activée ou désactivée par le récepteur sur une base par SA. Ce service NE DOIT PAS être activé à moins que le service d'intégrité ESP ne soit également activé pour la SA, car sinon le champ Sequence Number n'a pas été protégé en intégrité. L'anti-rejeu est applicable aux SA unicast ainsi qu'aux SA multicast. Cependant, cette norme ne spécifie aucun mécanisme pour fournir l'anti-rejeu pour une SA multi-expéditeur (unicast ou multicast). En l'absence de négociation (ou de configuration manuelle) d'un mécanisme anti-rejeu pour une telle SA, il est recommandé que la vérification par l'expéditeur et le récepteur du numéro de séquence pour la SA soit désactivée (via négociation ou configuration manuelle), comme noté ci-dessous.

Si le récepteur n'active pas l'anti-rejeu pour une SA, aucune vérification entrante n'est effectuée sur le Sequence Number. Cependant, du point de vue de l'expéditeur, la valeur par défaut est de supposer que l'anti-rejeu est activé au niveau du récepteur. Pour éviter que l'expéditeur ne fasse une surveillance inutile du numéro de séquence et une configuration SA (voir section 3.3.3), si un protocole d'établissement SA est employé, le récepteur DEVRAIT notifier l'expéditeur, pendant l'établissement SA, si le récepteur ne fournira pas de protection anti-rejeu.

Si le récepteur a activé le service anti-rejeu pour cette SA, le compteur de paquets reçus pour la SA DOIT être initialisé à zéro lorsque la SA est établie. Pour chaque paquet reçu, le récepteur DOIT vérifier que le paquet contient un Sequence Number qui ne duplique pas le Sequence Number d'autres paquets reçus pendant la durée de vie de cette SA. Ceci DEVRAIT être la première vérification ESP appliquée à un paquet après qu'il ait été associé à une SA, pour accélérer le rejet des paquets dupliqués.

ESP permet une vérification en deux étapes des numéros de séquence de paquets. Cette capacité est importante chaque fois qu'une implémentation ESP (typiquement la portion de module cryptographique de celle-ci) n'est pas capable d'effectuer le déchiffrement et/ou la vérification d'intégrité au même taux que l'interface(s) vers les réseaux non protégés. Si l'implémentation est capable d'une telle opération à "débit de ligne", alors il n'est pas nécessaire d'effectuer l'étape de vérification préliminaire décrite ci-dessous.

La vérification préliminaire du Sequence Number est effectuée en utilisant la valeur Sequence Number dans l'en-tête ESP et est effectuée avant la vérification d'intégrité et le déchiffrement. Si cette vérification préliminaire échoue, le paquet est rejeté, évitant ainsi le besoin d'opérations cryptographiques par le récepteur. Si la vérification préliminaire est réussie, le récepteur ne peut pas encore modifier son compteur local, car l'intégrité du Sequence Number n'a pas été vérifiée à ce stade.

Les doublons sont rejetés par l'utilisation d'une fenêtre de réception glissante. La manière dont la fenêtre est implémentée est une question locale, mais le texte suivant décrit la fonctionnalité que l'implémentation doit présenter.

Le bord "droit" de la fenêtre représente la valeur de Sequence Number la plus élevée et validée reçue sur cette SA. Les paquets qui contiennent des numéros de séquence inférieurs au bord "gauche" de la fenêtre sont rejetés. Les paquets tombant dans la fenêtre sont vérifiés contre une liste de paquets reçus dans la fenêtre. Si l'option ESN est sélectionnée pour une SA, seuls les 32 bits de poids faible du numéro de séquence sont explicitement transmis, mais le récepteur emploie le numéro de séquence complet calculé en utilisant les 32 bits de poids fort pour la SA indiquée (de son compteur local) lors de la vérification du Sequence Number reçu contre la fenêtre de réception. En construisant le numéro de séquence complet, si les 32 bits de poids faible transportés dans le paquet sont inférieurs en valeur aux 32 bits de poids faible du numéro de séquence du récepteur, le récepteur suppose que les 32 bits de poids fort ont été incrémentés, passant à un nouveau sous-espace de numéro de séquence. (Cet algorithme accommode des écarts de réception pour une seule SA aussi grands que 2^32-1 paquets. Si un écart plus grand se produit, des vérifications heuristiques supplémentaires pour la re-synchronisation du compteur de numéro de séquence du récepteur PEUVENT être employées, comme décrit dans l'Annexe.)

Si le paquet reçu tombe dans la fenêtre et n'est pas un duplicata, ou si le paquet est à droite de la fenêtre, et si un algorithme d'intégrité séparé est employé, alors le récepteur procède à la vérification d'intégrité. Si un algorithme en mode combiné est employé, la vérification d'intégrité est effectuée en même temps que le déchiffrement. Dans les deux cas, si la vérification d'intégrité échoue, le récepteur DOIT rejeter le datagramme IP reçu comme invalide; ceci est un événement auditable. L'entrée du journal d'audit pour cet événement DEVRAIT inclure la valeur SPI, la date/heure de réception, l'adresse source, l'adresse de destination, le numéro de séquence et (dans IPv6) l'ID de flux. La fenêtre de réception est mise à jour uniquement si la vérification d'intégrité réussit. (Si un algorithme en mode combiné est utilisé, alors le Sequence Number protégé en intégrité doit également correspondre au Sequence Number utilisé pour la protection anti-rejeu.)

Une taille de fenêtre minimale de 32 paquets DOIT être supportée lorsque des numéros de séquence de 32 bits sont employés; une taille de fenêtre de 64 est préférée et DEVRAIT être employée par défaut. Une autre taille de fenêtre (plus grande que le minimum) PEUT être choisie par le récepteur. (Le récepteur NE notifie PAS l'expéditeur de la taille de la fenêtre.) La taille de la fenêtre de réception devrait être augmentée pour les environnements à vitesse plus élevée, indépendamment des questions d'assurance. Les valeurs pour les tailles de fenêtre de réception minimales et recommandées pour les dispositifs à très haute vitesse (par exemple multi-gigabit/seconde) ne sont pas spécifiées par cette norme.

3.4.4. Vérification de la valeur de vérification d'intégrité

Comme pour le traitement sortant, il existe plusieurs options pour le traitement entrant, en fonction des caractéristiques des algorithmes employés.

3.4.4.1. Algorithmes de confidentialité et d'intégrité séparés

Si des algorithmes de confidentialité et d'intégrité séparés sont employés, le traitement se déroule comme suit:

Si l'intégrité a été sélectionnée, le récepteur calcule l'ICV sur le paquet ESP moins l'ICV, en utilisant l'algorithme d'intégrité spécifié et vérifie qu'il est identique à l'ICV transporté dans le paquet. Les détails du calcul sont fournis ci-dessous.

Si les ICV calculés et reçus correspondent, alors le datagramme est valide et il est accepté. Si le test échoue, alors le récepteur DOIT rejeter le datagramme IP reçu comme invalide; ceci est un événement auditable. Les données du journal DEVRAIENT inclure la valeur SPI, la date/heure de réception, l'adresse source, l'adresse de destination, le numéro de séquence et (pour IPv6) l'ID de flux en texte clair.

Note d'implémentation:

Les implémentations peuvent utiliser n'importe quel ensemble d'étapes qui aboutit au même résultat que l'ensemble d'étapes suivant. Commencer par retirer et sauvegarder le champ ICV. Ensuite, vérifier la longueur globale du paquet ESP moins le champ ICV. Si un remplissage implicite est requis, en fonction de la taille de bloc de l'algorithme d'intégrité, ajouter des octets remplis de zéros à la fin du paquet ESP directement après le champ Next Header, ou après les 32 bits de poids fort du numéro de séquence si ESN est sélectionné. Effectuer le calcul de l'ICV et comparer le résultat avec la valeur sauvegardée, en utilisant les règles de comparaison définies par la spécification de l'algorithme.
Le récepteur déchiffre les ESP Payload Data, Padding, Pad Length et Next Header en utilisant la clé, l'algorithme de chiffrement, le mode d'algorithme et les données de synchronisation cryptographique (le cas échéant), indiqués par la SA. Comme dans la Section 3.3.2, nous parlons ici en termes de chiffrement toujours appliqué en raison des implications de formatage. Cela est fait avec la compréhension que "aucune confidentialité" est offerte en utilisant l'algorithme de chiffrement NULL (RFC 2410).
- Si des données de synchronisation cryptographique explicites, par exemple un IV, sont indiquées, elles sont prises du champ Payload et entrées dans l'algorithme de déchiffrement selon la spécification de l'algorithme.
- Si des données de synchronisation cryptographique implicites sont indiquées, une version locale de l'IV est construite et entrée dans l'algorithme de déchiffrement selon la spécification de l'algorithme.
Le récepteur traite tout Padding comme spécifié dans la spécification de l'algorithme de chiffrement. Si le schéma de remplissage par défaut (voir Section 2.4) a été employé, le récepteur DEVRAIT inspecter le champ Padding avant de retirer le remplissage avant de passer les données déchiffrées à la couche suivante.
Le récepteur vérifie le champ Next Header. Si la valeur est "59" (pas d'en-tête suivant), le paquet (factice) est rejeté sans traitement supplémentaire.
Le récepteur reconstruit le datagramme IP original à partir de:
- pour le mode transport -- en-tête IP externe plus les informations du protocole de couche suivante original dans le champ ESP Payload
- pour le mode tunnel -- l'intégralité du datagramme IP dans le champ ESP Payload.
Les étapes exactes pour reconstruire le datagramme original dépendent du mode (transport ou tunnel) et sont décrites dans le document Security Architecture. Au minimum, dans un contexte IPv6, le récepteur DEVRAIT s'assurer que les données déchiffrées sont alignées sur 8 octets, pour faciliter le traitement par le protocole identifié dans le champ Next Header. Ce traitement "rejette" tout remplissage TFC (optionnel) qui a été ajouté pour la confidentialité du flux de trafic. (S'il est présent, cela aura été inséré après le datagramme IP (ou la trame de couche transport) et avant le champ Padding (voir Section 2.4).)

Si la vérification d'intégrité et le déchiffrement sont effectués en parallèle, la vérification d'intégrité DOIT être terminée avant que le paquet déchiffré ne soit transmis pour un traitement ultérieur. Cet ordre de traitement facilite la détection et le rejet rapides des paquets rejués ou faux par le récepteur, avant de déchiffrer le paquet, réduisant ainsi potentiellement l'impact des attaques par déni de service.

Note: Si le récepteur effectue le déchiffrement en parallèle avec la vérification d'intégrité, il faut prendre soin d'éviter les conditions de course possibles en ce qui concerne l'accès au paquet et l'extraction du paquet déchiffré.

3.4.4.2. Algorithmes de confidentialité et d'intégrité combinés

Si un algorithme combiné de confidentialité et d'intégrité est employé, alors le récepteur procède comme suit:

Déchiffre et vérifie l'intégrité des ESP Payload Data, Padding, Pad Length et Next Header, en utilisant la clé, l'algorithme, le mode d'algorithme et les données de synchronisation cryptographique (le cas échéant), indiqués par la SA. Le SPI de l'en-tête ESP, et la valeur du compteur de paquets (récepteur) (ajustée selon les besoins du traitement décrit dans la Section 3.4.3) sont des entrées de cet algorithme, car ils sont requis pour la vérification d'intégrité.
- Si des données de synchronisation cryptographique explicites, par exemple un IV, sont indiquées, elles sont prises du champ Payload et entrées dans l'algorithme de déchiffrement selon la spécification de l'algorithme.
- Si des données de synchronisation cryptographique implicites, par exemple un IV, sont indiquées, une version locale de l'IV est construite et entrée dans l'algorithme de déchiffrement selon la spécification de l'algorithme.
Si la vérification d'intégrité effectuée par l'algorithme en mode combiné échoue, le récepteur DOIT rejeter le datagramme IP reçu comme invalide; ceci est un événement auditable. Les données du journal DEVRAIENT inclure la valeur SPI, la date/heure de réception, l'adresse source, l'adresse de destination, le numéro de séquence et (dans IPv6) l'ID de flux en texte clair.
Traiter tout Padding comme spécifié dans la spécification de l'algorithme de chiffrement, si l'algorithme ne l'a pas déjà fait.
Le récepteur vérifie le champ Next Header. Si la valeur est "59" (pas d'en-tête suivant), le paquet (factice) est rejeté sans traitement supplémentaire.
Extraire le datagramme IP original (mode tunnel) ou la trame de couche transport (mode transport) du champ ESP Payload Data. Cela rejette implicitement tout remplissage (optionnel) qui a été ajouté pour la confidentialité du flux de trafic. (S'il est présent, le remplissage TFC aura été inséré après la charge utile IP et avant le champ Padding (voir Section 2.4).)