ANTI-REJEU IPSEC
Pourquoi un paquet chiffré peut-il tout de même être un rejeu ?
Un texte chiffré copié peut arriver de nouveau sans avoir été modifié. Le mécanisme anti-rejeu ESP associe des numéros de séquence à une association de sécurité, vérifie une fenêtre de réception bornée et valide l’état après authentification. La protection s’applique aux extrémités du tunnel sélectionnées ; les commandes applicatives nécessitent toujours leurs propres règles de gestion des doublons et des délais.
Extrémités du tunnel
Les passerelles aux extrémités authentifient le trafic ; le commutateur intermédiaire le transmet.
Fenêtre de séquence
Un numéro de séquence non encore reçu et situé dans la fenêtre peut être vérifié ; les doublons sont rejetés.
Validation après vérification
Seul un paquet authentifié fait progresser l’état de réception de confiance.
Repérer les extrémités et le périmètre.
Confirmer le protocole et les paramètres réellement utilisés.
Effectuer des essais autorisés avec des données inoffensives.
Liste de contrôle de sélection et de vérification — développer
Identifier les extrémités et la SA ; confirmer les paramètres anti-rejeu ; tester des paquets réordonnés, dupliqués et non valides au moyen d’essais autorisés avec des données inoffensives.
Une liaison de données distante est chiffrée : pourquoi une passerelle de sécurité enregistre-t-elle encore les numéros de séquence des paquets ? Empêcher des tiers de lire un message et empêcher que le même message soit accepté de nouveau sont deux objectifs différents. Une personne peut copier un paquet légitime et le renvoyer sans en comprendre le contenu. Le mécanisme anti-rejeu permet au récepteur de conserver une trace des paquets qu’il a déjà acceptés.
Un paquet inchangé peut tout de même être un doublon
Imaginez un ordre de travail scellé. Le sceau peut contribuer à montrer que le contenu n’a pas été modifié, mais il ne prouve pas à lui seul que le même ordre n’a pas déjà été remis. De même, un paquet chiffré capturé peut être renvoyé sans que l’attaquant le déchiffre ou crée une nouvelle commande valide.
Cette analogie explique uniquement la remise répétée. Les protocoles réels utilisent des clés et des algorithmes d’authentification. La confidentialité, l’intégrité et la protection anti-rejeu répondent à des besoins différents. La détection des erreurs Ethernet ne remplace pas l’authentification cryptographique : détecter des erreurs de transmission est différent de vérifier qu’un paquet a été créé par un détenteur de la clé appropriée.
Une description de produit mentionnant le chiffrement ne permet pas, à elle seule, d’établir comment les anciens paquets sont rejetés. Identifiez le protocole, ses véritables extrémités de sécurité, les paramètres négociés et les contrôles du récepteur. Cet article prend IPsec ESP comme exemple ; il n’attribue pas une capacité anti-rejeu à chaque équipement industriel situé sur le trajet.
Repérer les deux extrémités qui conservent l’historique
IPsec peut protéger le trafic sur un réseau IP, et ESP est l’un de ses mécanismes de protection des paquets. Une association de sécurité, ou SA, est un ensemble de dispositions de protection pour un seul sens de communication, comprenant notamment les clés, les algorithmes et l’état correspondants. Les historiques des deux sens ne doivent pas être considérés comme un compteur partagé unique.
L’émetteur numérote les paquets appartenant à une SA. Le récepteur sélectionne l’association concernée et vérifie son propre historique ; il ne compare pas un numéro à tous les équipements du réseau. L’indice des paramètres de sécurité ESP (SPI) aide à identifier l’association, tandis que le numéro de séquence ESP permet les contrôles anti-rejeu. Ces champs doivent bénéficier de la protection d’intégrité appropriée.
Un serveur série, un commutateur Ethernet industriel et une passerelle de sécurité externe peuvent tous être présents sur la même liaison. Le serveur de périphériques série FCT-1100-F1S1 de Feichang fournit un exemple concret de produit de conversion série-réseau ; cela ne signifie pas qu’il implémente IPsec. Si des passerelles externes constituent les extrémités du tunnel, elles effectuent les contrôles associés. Un commutateur assurant une transmission ordinaire ne dispose pas automatiquement d’une fenêtre anti-rejeu.
Pourquoi ne pas accepter uniquement les numéros supérieurs au dernier reçu ?
Les paquets n’arrivent pas toujours dans l’ordre d’émission. Les chemins, les files d’attente et le traitement parallèle peuvent faire arriver en premier un paquet émis plus tard. Un récepteur qui rejette tout numéro inférieur au plus grand numéro reçu pourrait éliminer du trafic légitime retardé. Le contrôle doit reconnaître les doublons tout en tolérant un certain réordonnancement.
Imaginez une fenêtre glissante composée de cases numérotées. Chaque case indique si un paquet portant ce numéro de séquence a déjà été authentifié et accepté ; elle ne stocke pas le paquet entier. La borne supérieure suit le plus grand numéro authentifié et la borne inférieure limite le retard admissible pour un paquet non encore reçu arrivant dans le désordre. Un paquet trop ancien est rejeté.
À titre pédagogique, supposons que la fenêtre contienne les numéros 101 à 108 et que 106 ait déjà été accepté. Un second 106 est un doublon. Si 105 n’a pas encore été reçu, il peut passer à l’authentification. Ces huit cases ne sont qu’une illustration, et non une taille de fenêtre normalisée ou une spécification d’un produit Feichang.
Ne déplacer la fenêtre qu’après une authentification réussie
Lorsque le paquet 109 arrive, le récepteur ne doit pas faire progresser son historique simplement parce que le numéro est plus grand. Sinon, un attaquant pourrait falsifier un numéro très élevé et repousser le trafic légitime hors de la fenêtre. L’ordre des contrôles est plus important que la mémorisation de l’expression « faire glisser la fenêtre ».
Une implémentation peut d’abord effectuer un contrôle préliminaire du numéro de séquence et rejeter un doublon évident ou un paquet ancien. Un paquet admissible doit encore réussir le contrôle d’intégrité ou d’authentification approprié. Ce n’est qu’après cette réussite qu’il est enregistré comme reçu et que la fenêtre avance si nécessaire. Un contrôle préliminaire ne rend pas le paquet digne de confiance.
Un paquet dont l’authentification échoue ne doit pas occuper une nouvelle case ni faire progresser le plus grand numéro authentifié. Les différents algorithmes et implémentations peuvent organiser différemment les traitements internes. La distinction essentielle est celle entre le filtrage initial, la validation cryptographique et la validation de l’état. Un numéro plus grand ne suffit pas à autoriser la remise du paquet.
La perte, le réordonnancement et le rejeu peuvent se ressembler
La fenêtre peut accepter un numéro non encore reçu qui arrive dans ses limites, mais elle ne peut pas accepter du trafic avec un retard arbitrairement long. Un réordonnancement important peut placer un paquet légitime sous la borne inférieure. Une augmentation du nombre de rejets ne prouve donc pas, à elle seule, une attaque, une fibre endommagée ou un port de commutateur défaillant.
Recoupez l’heure, le sens de communication, l’association de sécurité et les journaux applicatifs. Vérifiez si un changement de route, une accumulation dans les files d’attente ou une variation de la charge de la passerelle est survenu au même moment. Agrandir une fenêtre n’est pas une solution universelle : vérifiez les limites de l’implémentation, les coûts de traitement et le retard acceptable. Ne désactivez pas la protection simplement pour masquer une alarme.
La fenêtre ne récupère pas un paquet perdu. Elle détermine si un paquet peut poursuivre son traitement ; la retransmission, la reprise de session et le comportement en cas d’expiration des délais applicatifs relèvent du mécanisme de transport ou d’application approprié. Une fenêtre anti-rejeu n’est ni un protocole de livraison fiable ni un tampon général de réordonnancement des paquets.
Un nouveau paquet de tunnel peut contenir une ancienne commande applicative
Une application peut envoyer de nouveau la même opération. L’extrémité de sécurité peut encapsuler cette seconde requête dans un nouveau paquet externe portant un nouveau numéro de séquence. Au niveau du tunnel, il ne s’agit pas du paquet ESP précédemment accepté ; au niveau applicatif, il peut néanmoins s’agir d’une opération en double.
Le mécanisme anti-rejeu ne garantit donc pas que chaque commande ne s’exécute qu’une seule fois. Selon le protocole réellement utilisé, les opérations importantes peuvent nécessiter des identifiants de transaction, une gestion des requêtes en double, une expiration, des autorisations et des vérifications par rapport à l’état actuel. Ces fonctions nécessitent un accord et une vérification aux deux extrémités ; l’ajout d’un champ ne suffit pas à établir une sécurité complète.
Un paquet valide, non encore reçu et situé dans la fenêtre n’arrive pas non plus nécessairement à temps pour l’opération métier. La décision d’exécuter ou non une commande retardée relève de l’application. Distinguez la duplication des paquets, l’authenticité de l’émetteur et la pertinence de l’action au moment présent.
Documenter le mécanisme dans un dossier de projet vérifiable
Repérez les extrémités du tunnel et le périmètre qu’elles protègent réellement. Vérifiez le protocole, la négociation, la fenêtre prise en charge et la signification des journaux. Les interfaces série, la transmission Ethernet et le traitement de sécurité relèvent de couches différentes. La prise en charge de la fibre, de VLAN ou de la mise en réseau série ne prouve pas la prise en charge d’un algorithme cryptographique particulier ni l’obtention d’une certification.
Dans un environnement de test autorisé, utilisez des données isolées et inoffensives pour observer l’ordre normal, le réordonnancement permis, les paquets répétés et les échecs d’authentification. Consignez la version de la documentation, la configuration et les résultats. Ne rejouez pas de véritables commandes de contrôle de production et ne présentez pas les nombres illustratifs du schéma comme des mesures.
Retenez trois responsabilités : le chiffrement protège le contenu, une fenêtre anti-rejeu enregistre les numéros des paquets acceptés, et l’application gère toujours les opérations en double et les délais. L’authentification empêche qu’un numéro de séquence inventé fasse simplement progresser l’historique de confiance. Ensemble, ces délimitations facilitent l’évaluation d’une architecture de communication industrielle.
Références principales
RFC 4303 : charge utile de sécurité encapsulée IP, sections 2.1, 2.2 et 3.4.3; RFC 6479 : algorithme anti-rejeu IPsec (document informatif, et non norme Internet obligatoire). Contexte produit : serveur de périphériques série FCT-1100-F1S1 ; cela ne signifie pas que ce produit prend en charge IPsec.
Traduit de l’article technique en chinois : Lire l’article original en chinois.
Questions pratiques fréquentes
Le chiffrement seul empêche-t-il le rejeu ?
Non. La protection contre le rejeu nécessite également un suivi des numéros de séquence, une authentification et un état correct du récepteur.
Tous les numéros de séquence plus anciens sont-ils rejetés ?
Non. Un numéro non encore reçu et situé dans la fenêtre peut passer à l’authentification ; les doublons et les numéros trop anciens sont rejetés.
Le mécanisme anti-rejeu du tunnel garantit-il qu’une commande ne s’exécute qu’une seule fois ?
Non. Un nouveau paquet externe peut contenir une commande applicative répétée ; l’application a besoin de ses propres règles.
Périmètre et lectures complémentaires
Concepts génériques d’anti-rejeu ESP, sans revendication concernant un produit particulier.
Demi-fermeture TCP et réponses série · Charges unitaires RS485 et budget de charge du circuit de commande
