Encapsulation de charge utile de sécurité (ESP) IPabcdrfc.free.fr/rfc-vf/pdf/rfc4303.pdf · RFC...

RFC 4303 Encapsulation de charge utile de sécurité IP Kent

Groupe de travail Réseau S. Kent, BBN TechnologiesRequest for Comments : 4303RFC rendue obsolète : 2406 décembre 2005Catégorie : En cours de normalisation Traduction Claude Brière de L'Isle

Encapsulation de charge utile de sécurité (ESP) IP

Statut du présent mémoireLe présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, etappelle à des discussion et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normesofficielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. Ladistribution du présent mémoire n’est soumise à aucune restriction.

Notice de CopyrightCopyright (C) The Internet Society (2005).

RésuméLe présent document décrit une version mise à jour du protocole d'encapsulation de charge utile de sécurité (ESP), qui estdestinée à fournir un assortiment de services de sécurité dans IPv4 et IPv6. ESP est utilisé pour fournir des services deconfidentialité, d'authentification d'origine des données, d'intégrité sans connexion, et d'anti répétition (une formed'intégrité de séquence partielle) et une confidentialité limitée du flux de trafic. Le présent document rend obsolète laRFC 2406 (novembre 1998).

Table des matières1 Introduction.............................................................................................................................................................................22. Format de paquet d’encapsulation de charge utile de sécurité...............................................................................................3

2.1 Indice de paramètres de sécurité (SPI).............................................................................................................................52.2 Numéro de séquence........................................................................................................................................................72.3 Données de charge utile...................................................................................................................................................72.4 Bourrage (pour chiffrement)............................................................................................................................................82.5 Longueur de bourrage......................................................................................................................................................82.6 Prochain en-tête................................................................................................................................................................92.7 Bourrage de confidentialité du flux de trafic (TFC).........................................................................................................92.8 Valeur de vérification d’intégrité...................................................................................................................................10

3. Traitement de l’encapsulation de protocole de sécurité.......................................................................................................103.1 Situation de l’en-tête ESP..............................................................................................................................................103.2 Algorithmes....................................................................................................................................................................113.3 Traitement du paquet sortant..........................................................................................................................................123.4 Traitement de paquet entrant..........................................................................................................................................15

4. Révision................................................................................................................................................................................185. Exigences de conformité......................................................................................................................................................186. Considérations pour la sécurité............................................................................................................................................197. Différences avec la RFC 2406.............................................................................................................................................198. Considérations pour la rétro-compatibilité...........................................................................................................................199. Remerciements.....................................................................................................................................................................2010. Références..........................................................................................................................................................................20

10.1 Références normatives.................................................................................................................................................2010.2 Références pour information........................................................................................................................................20

Appendice A Numéros de séquence étendus (64 bits).............................................................................................................21A1 Généralités......................................................................................................................................................................21A2 Fenêtre anti répétition.....................................................................................................................................................21A.3 Traitement de la perte de synchronisation due à une perte de paquet significative......................................................24

Adresse de l'auteur...................................................................................................................................................................24Déclaration complète de droits de reproduction.......................................................................................................................25

page - 1 -


1 Introduction

Le présent document suppose que le lecteur est familier avec les termes et concepts décrits dans "Architecture de sécuritépour le protocole Internet" [RFC4301], auquel on se réfère ci-après comme au document Architecture de sécurité. Enparticulier, le lecteur devrait être familier avec les définitions des services de sécurité offerts par l'encapsulation de chargeutile de sécurité (ESP) et l'en-tête d'authentification (AH), le concept d'associations de sécurité, les façons dont ESP peutêtre utilisé en conjonction avec AH, et les différentes options de gestion de clés disponibles pour ESP et AH.

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS","DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décritdans la [RFC 2119].

L’en-tête d’encapsulation de charge utile de sécurité (ESP, Encapsulating Security Payload) est conçu pour fournir unmélange de services de sécurité dans IPv4 et IPv6 [RFC2460]. ESP peut s’appliquer seul, en combinaison avec AH[RFC4302], ou de façon incorporée (voir le document d’architecture de sécurité [RFC4301]). Les services de sécuritépeuvent être fournis entre une paire d’hôtes communicants, entre une paire de passerelles de sécurité communicantes, ouentre une passerelle de sécurité et un hôte. Pour les détails de la façon dont ESP et AH sont utilisés dans les diversenvironnements de réseau, voir le document sur l’architecture de sécurité [RFC4301].

L’en-tête ESP est inséré après l’en-tête IP et avant l’en-tête de protocole de prochaine couche (en mode transport) ou avantun en-tête IP encapsulé (mode tunnel). Ces modes sont décrits plus en détail ci-dessous.

ESP peut être utilisé pour assurer la confidentialité, l’authentification de l’origine des données, l’intégrité sans connexion,et un service anti-répétition (une forme d’intégrité de séquence partielle) et la confidentialité (limitée) du flux de trafic.L’ensemble des services fournis dépend des options choisies au moment de l’établissement de l’association de sécurité(SA, Security Association) et de la situation de la mise en œuvre dans la topologie du réseau.

L'utilisation du chiffrement seul pour la confidentialité est permis par ESP. Cependant, on devrait noter qu'en général, celane va défendre que contre les attaques passives. Utiliser le chiffrement sans avoir par dessus lui un fort mécanisme dedéfense de l'intégrité (soit dans ESP, soit séparément via AH) peut rendre le service de confidentialité non sûr contrecertaines formes d'attaque active [Bel96], [Kra01]. De plus, un service sous-jacent de protection de l’intégrité, comme AH,appliqué avant le chiffrement ne protège pas nécessairement la confidentialié par chiffrement seul contre les attaquesactives [Kra01]. ESP permet des SA de chiffrement seul parce que cela peut offrir des performances considérablementaméliorées et fournir quand même une sécurité adéquate, par exemple, lorsque une protection d'authentification/intégrité decouche supérieure est offerte indépendamment. Cependant, la présente norme n'exige pas que les mises en œuvre de ESPoffrent un service de chiffrement seul.

L'authentification de l'origine des données et l'intégrité sans connexion sont des services conjoints, qu'on regroupe ici sousle terme de "intégrité". (Ce terme est employé parce que, sur la base du paquet, le calcul effectué donne directementl'intégrité sans connexion ; l'authentification de l'origine des données est fournie indirectement par suite du lien de la cléutilisée pour vérifer l'intégrité avec l'identité de l'homologue IPsec. Normalement, ce lien est effectué au moyen del'utilisation d'une clé symétrique partagée.) ESP en intégrité seule DOIT être offert comme option de choix de service, parexemple, il doit être négocié dans les protocoles de gestion de SA et DOIT être configurable via des interfaces de gestion.ESP en intégrité seule est une solution de remplacement interessante à AH dans de nombreux contextes, par exemple, parcequ'il est de traitement plus rapide et plus favorable au traitement en parallèle dans de nombreuses mises en œuvre.

Bien que la confidentialité et l'intégrité puissent être offertes de façon indépendante, ESP va normalement employer lesdeux services, c’est-à-dire, les paquets seront protégés à l'égard de la confidentialité et de l'intégrité. Donc, il y a troiscombinaisons possibles de service de sécurité ESP qui impliquent ces services :- confidentialité seule (PEUT être pris en charge)- intégrité seule (DOIT être pris en charge)- confidentialité et intégrité (DOIT être pris en charge)

Le service anti répétition ne peut être choisi pour une SA que si le service de protection de l’intégrité a été retenu pour cetteSA. Le choix de ce service est à la seule discrétion du receveur et n'a donc pas besoin d'être négocié. Cependant, pourutiliser le dispositif de numéro de séquence étendu (ESN, Extended Sequence Number) de façon interopérable, ESP imposecomme exigence aux protocoles de gestion de SA qu'ils soient capables de négocier ce dispositif (voir au paragraphe 2.2.1).

Le service de confidentialité du flux de trafic (TFC, traffic flow confidentiality) n'est généralement efficace que si ESP estemployé de façon à dissimuler les adresses ultimes de source et de destination des correspondants, par exemple, en modetunnel entre des passerelles de sécurité, et seulement si un trafic suffisant s'écoule entre les homologues IPsec (soitnaturellement, soit par suite de la génération d'un trafic de masquage) pour dissimuler les caractéristiques des flux de trafic

page - 2 -


d'abonnés individuels spécifiques. (ESP peut être employé au titre d'un système de TFC de couche supérieure, par exemple,l'acheminement en pelure d'oignon (Onion Routing) [Syverson], mais de tels systèmes sortent du domaine d'application dela présente norme.) Les nouvelles caractéristiques de TFC présentes dans ESP facilitent une génération et éliminationefficaces du trafic factice et un meilleur bourrage du trafic réel, de façon rétro compatible.

La Section 7 passe brièvement en revue les différences entre le présent document et la RFC 2406.

2. Format de paquet d’encapsulation de charge utile de sécurité

L'en-tête (le plus externe) de protocole (IPv4, IPv6, ou Extension) qui précède immédiatement l'en-tête ESP DEVRAcontenir la valeur 50 dans son champ Protocole (IPv4) ou Prochain en-tête (IPv6, Extension) (voir la page de la Toile del'IANA à http://www.iana.org/assignments/protocol-numbers). La Figure 1 illustre le format général d'un paquet ESP. Lepaquet commence par deux champs de quatre octets (Indice de paramètres de sécurité (SPI, Security Parameters Index) etNuméro de séquence). Ces champs sont suivis des données de charge utile, dont la sous structure dépend du choix del'algorithme et du mode de chiffrement, et de l'utilisation du bourrage de TFC, qu'on examinera plus en détails plus loin.Suivent les champs Bourrage et Longueur de bourrage, et le champ Prochain en-tête. Le champ facultatif de valeur devérification d'intégrité (ICV, Integrity Check Value) termine le paquet.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----| Indice de paramètres de sécurité (SPI) | ^Intégrité+---------------+---------------+---------------+---------------+ |couverte| Numéro de séquence | |+---------------+---------------+---------------+---------------+ | ----| Données* (variables) | | ^~ de charge utile ~ | || | |Confidentialité+ +---------------+---------------+---------------+ |couverte| | Bourrage (0-255 octets) | | |*+---------------+ +---------------+---------------+ | || | Long. bourrage| Prochain en-t.| v v+---------------+---------------+---------------+---------------+ ------| Valeur de vérification d'intégrité (ICV) |~ (variable) ~| |+---------------+---------------+---------------+---------------+

Figure 1 : Format général d’un paquet d’ESP

* Si elles sont incluses dans le champ Charge utile, les données de synchronisation cryptographiques, par exemple, unevaleur d'initialisation (IV, voir au paragraphe 2.3) ne sont généralement pas chiffrées par elles-mêmes, bien qu'on yfasse souvent référence comme partie du texte chiffré.

L'en-queue ESP (transmis) consiste en les champs Bourrage (Padding), Longueur de bourrage, et Prochain en-tête. Desdonnées d'en-queue ESP supplémentaires implicites (qui ne sont pas transmises) sont incluses dans le calcul d'intégrité,comme décrit ci-dessous.

Si le service de protection de l’intégrité est choisi, le calcul d'intégrité englobe le SPI, le numéro de séquence, les donnéesde charge utile, et l'en-queue ESP (explicite et implicite).

Si le service de confidentialité est choisi, le texte chiffré consiste en les données de charge utile (excepté toutes données desynchronisation cryptographique qui pourraient être incluses) et l'en-queue ESP (explicite).

Comme noté ci-dessus, les données de charge utile peuvent avoir une sub-structure. Un algorithme de chiffrement qui exigeune valeur d'initialisation (IV) explicite, par exemple, le mode de chaînage de bloc de chiffrement (CBC, Cipher BlockChaining) fait souvent précéder de cette valeur les données de charge utile à protéger. Certains modes d'algorithmecombinent le chiffrement et l'intégrité dans une seule opération ; le présent document se réfère à de tels modes d'algorithmecomme à des "algorithmes en mode combiné". Le traitement des algorithmes en mode combiné exige que l'algorithmedécrive explicitement la sub-structure de charge utile utilisée pour convoyer les données d'intégrité.

page - 3 -

http://www.iana.org/assignments/protocol-numbers


Certains algorithmes en mode combiné fournissent l'intégrité seule pour les données qui sont chiffrées, tandis que d'autrespeuvent fournir l'intégrité pour des données supplémentaires qui ne sont pas chiffrées pour la transmission. Parce que leschamps SPI et Numéro de séquence exigent la protection de l'intégrité au titre du service de protection de l’intégrité, etqu'ils ne sont pas chiffrés, il est nécessaire de s'assurer qu'ils peuvent s'offrir la protection de l'intégrité chaque fois que leservice est choisi, sans considération du style de mode d'algorithme combiné employé.

Lorsque un algorithme en mode combiné est employé, l'algorithme lui-même est supposé retourner le texte source déchiffréet une indication de réussite/échec pour la vérification d'intégrité. Pour les algorithmes en mode combiné, l'ICV quiapparaîtrait normalement à la fin du paquet ESP (lorsque l'intégrité est choisie) peut être omise. Quand l'ICV est omise etque l'intégrité est choisie, il est de la responsabilité de l'algorithme en mode combiné de coder au sein des données decharge utile un moyen équivalent à l'ICV pour vérifier l'intégrité du paquet.

Si un algorithme en mode combiné offre l'intégrité seule aux données qui sont chiffrées, il sera nécessaire de dupliquer leSPI et le numéro de séquence au titre des données de charge utile.

Finalement, une nouvelle disposition est faite pour insérer du bourrage pour la confidentialité des flux de trafic après lesdonnées de charge utile et avant l'en-queue ESP. La Figure 2 illustre cette sub-structure pour les données de charge utile.(Note : ce diagramme montre les bits sur le réseau. De sorte que même si les numéros de séquence étendus sont utilisés,seuls 32 bits du numéro de séquence seront transmis (voir le paragraphe 2.2.1).)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Indice de paramètres de sécurité (SPI) |+---------------+---------------+---------------+---------------+| Numéro de séquence |+---------------+---------------+---------------+---------------+| IV (facultatif) | ^+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || Reste des données de charge utile (variable) | |charge~ ~ || | |utile+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || | Bourrage TFC * (facultatif, variable) | v+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---| | Bourrage (0-255 octets) |+---------------+---------------+---------------+---------------+| | LOng. bourrage| Prochain en-t.|+---------------+---------------+---------------+---------------+| Valeur de vérification d'intégrité ICV (variable) |~ ~| |+---------------+---------------+---------------+---------------+

Figure 2 : Sous structure des données de charge utile

* Si le mode tunnel est utilisé, la mise en œuvre IPsec peut alors ajouter le bourrage de confidentialité de flux de trafic(TFC, Traffic Flow Confidentiality) (voir le paragraphe 2.4) après les données de charge utile et avant le champBourrage (0-255 octets).

Si un algorithme en mode combiné est employé, l'ICV explicite montrée aux Figures 1 et 2 peut être omise (voir leparagraphe 3.3.2.2). Parce que les algorithmes et modes sont fixés quand une SA est établie, le format détaillé des paquetsESP pour une certaine SA (incluant la sous structure de données de charge utile) est fixé, pour tout le trafic sur la SA.

Les tableaux ci-dessous se réfèrent aux champs des figures précédantes et illustrent comment plusieurs categories d'optionsalgorithmiques, chacune ayant un modèle de traitement différent, affectent les champs notés ci-dessus. Les détails dutraitement sont décrits dans les paragraphes qui suivent.

page - 4 -


Tableau 1 : Algorithmes séparés de chiffrement et d’intégrité

Champ Nombred'octets

Exigence Couvert parchiffrement

Couvert parintégrité

Ce qui est émis

SPI 4 Obligé oui txt sourceN° séquence(bits mp) 4 Obligé oui txt sourceIV variable Facultatif oui txt source }chargeDatagramme IP [2] variable Obligé ou factice oui oui chiffré [3] } utileBourrage TFC[4] variable Facultatif oui oui chiffré [3] }Bourrage 0-255 Obligé oui oui chiffré [3] Longueur bourrage 1 Obligé oui oui chiffré [3]Prochain en-tête 1 Obligé oui oui chiffré [3]N° séquence (bits pf) 4 si ESN [5] oui non émisBourrage ICV variable si nécessaire oui non émisICV variable Obligé [6] txt source

[2] Si mode tunnel -> datagramme IP. Si mode transport -> prochain en-tête et données[3] Texte chiffré si le chiffrement a été choisi[4] Ne peut être utilisé que si la charge utile spécifie sa longueur "réelle"[5] Voir au paragraphe 2.2.1[6] Obligatoire si un algorithme d'intégrité séparé est utilisé

Tableau 2 : Algorithmes en mode combiné

Champ Nombred'octets

Exigence Couvert parchiffrement

Couvert parintégrité

Ce qui est émis

SPI 4 Obligé txt sourceN° séqu. (bits mp) 4 Obligé txt sourceIV variable Facultatif oui txt source }chargeDatagr. IP [2] variable Obligé ou factice oui oui chiffré } utileBourrage TFC[3] variable Facultatif oui oui chiffré }Bourrage 0-255 Obligé oui oui chiffréLongueur bourrage 1 Obligé oui oui chiffréProchain en-tête 1 Obligé oui oui chiffréN° séqu. (bits pf) 4 si ESN [4] oui [5]Bourr. ICV variable si nécessaire oui [5]ICV variable Facultatif [6] txt source

[2] Si mode tunnel -> datagramme IP. Si mode transport -> prochain en-tête et données[3] Ne peut être utilisé que si la charge utile spécifie sa longueur "réelle"[4] Voir au paragraphe 2.2.1[5] Le choix de l'algorithme détermine si ils sont émis, mais dans tous les cas, le résultat est invisible à ESP[6] La spécification de l'algorithme détermine si le champ est présent

Les paragraphes qui suivent décrivent les champs dans le format d'en-tête. "Facultatif" signifie que le champ est omis sil'option n'est pas choisie, c’est-à-dire, il n'est présent ni dans le paquet transmis ni comme formaté pour le calcul d'une ICV(voir le paragraphe 2.7). Qu'une option soit choisie ou non est déterminé au titre de l'établissement de l'association desécurité (SA, Security Association). Donc, le format des paquets ESP pour une certaine SA est fixe, pour la durée de la SA.À l'opposé, les champs "obligés" sont toujours présents dans le format de paquet ESP, pour toutes les SA.

Note : Tous les algorithmes cryptographiques utilisés dans IPsec attendent leur entrée dans l'ordre canonique des octets duréseau (voir l'Appendice de la [RFC0791]) et génèrent leur résultat dans l'ordre canonique des octets du réseau. Lespaquets IP sont aussi transmis dans l'ordre des octets du réseau.

ESP ne contient pas de numéro de version, et si il y a des problèmes de rétro compatibilité, ils DOIVENT être traités enutilisant un mécanisme de signalisation entre les deux homologues IPsec pour s'assurer de versions compatibles de ESP(par exemple, échange de clé Internet (IKEv2) [RFC4306]) ou un mécanisme de configuration hors bande.

page - 5 -


2.1 Indice de paramètres de sécurité (SPI)

Le SPI est une valeur arbitraire de 32 bits qui est utilisée par un receveur pour identifier la SA à laquelle est lié un paquetentrant. Le champ SPI est obligé.

Pour une SA d'envoi individuel, le SPI peut être utilisé par lui-même pour spécifier une SA, ou il peut être utilisé enconjonction avec le type de protocole IPsec (dans ce cas, ESP). Parce que la valeur du SPI est générée par le receveur pourune SA d'envoi individuel, si la valeur est suffisante pour identifier une SA par elle-même ou si elle doit être utilisée enconjonction avec la valeur de protocole IPsec est une affaire locale. Ce mécanisme pour transposer le trafic entrant en SAd'envoi individuel DOIT être pris en charge par toutes les mises en œuvre de ESP.

Si une mise en œuvre IPsec prend en charge la diffusion groupée, elle DOIT alors prendre en charge les SA de diffusiongroupée en utilisant l'algorithme ci-dessous pour transposer les datagrammes IPsec entrants en SA. Les mises en œuvre quiprennent en charge seulement le trafic en envoi individuel n'ont pas besoin de mettre en œuvre cet algorithme dedémultiplexage.

Dans de nombreuses architectures de diffusion groupée sûre (par exemple, [RFC3740]), un contrôleur de groupe/serveur declés central alloue unilatéralement le SPI de l'association de sécurité de groupe. Cette allocation de SPI n'est ni négociée nicoordonnée avec les sous systèmes de gestion de clé (par exemple, IKE) qui résident dans les systèmes d'extrémitéindividuels qui composent le groupe. Par conséquent, il est possible qu'une association de sécurité de groupe et uneassociation de sécurité d'envoi individuel puissent simultanément utiliser le même SPI. Une mise en œuvre IPsec capablede diffusion groupée DOIT correctement démultiplexer le trafic entrant même dans le contexte de collisions de SPI.

Chaque entrée dans la base de données des associations de sécurité (SAD, Security Association Database) [RFC4301] doitindiquer si la recherche de SA peut utiliser les adresses IP de destination, ou de destination et de source, en plus du SPI.Pour les SA de diffusion groupée, le champ protocole n'est pas employé pour les recherches de SA. Pour chaque paquetentrant, protégé par IPsec, une mise en œuvre doit conduire sa recherche dans la SAD de façon telle qu'elle trouve l'entréequi correspond au "plus long" identifiant de SA. Dans ce contexte, si deux ou plusieurs entrées de SAD correspondent surla base de la valeur du SPI, l'entrée qui correspond aussi sur la base de la comparaison d'adresse de destination, ou dedestination et de source (comme indiqué dans l'entrée de la SAD) est la "plus longue" correspondance. Cela implique unordre logique de la recherche dans la SAD :

1. Rechercher dans la SAD une correspondance sur {SPI, adresse de destination, adresse de source}. Si une entréecorrespond, traiter alors le paquet ESP entrant avec cette entrée de SAD qui correspond. Autrement, passer à l'étape 2.

2. Rechercher dans la SAD une correspondance sur {SPI, adresse de destination}. Si l'entrée de SAD correspond, traiteralors le paquet ESP entrant avec cette entrée de SAD qui correspond. Autrement, passer à l'étape 3.

3. Rechercher dans la SAD une correspondance sur {SPI} seulement si le receveur a choisi de tenir un seul espace de SPIpour AH et ESP, ou sur {SPI, protocole} autrement. Si une entrée de SAD correspond, traiter le paquet ESP entrantavec cette entrée de SAD qui correspond. Autrement, éliminer le paquet et enregistrer un événement sur le journal.

En pratique, une mise en œuvre PEUT choisir toute méthode pour accélérer cette recherche, bien que le comportementvisible de l'extérieur DOIVE être fonctionnellement équivalent à avoir cherché dans la SAD dans l'ordre ci-dessus. Parexemple, une mise en œuvre fondée sur le logiciel pourrait indexer par SPI dans un tableau. Les entrées de SAD danschaque liste reliée d'un baquet de table de hachage sont triées pour avoir en premier les entrées de SAD qui ont les pluslongs identifiants de SA dans cette liste reliée. Les entrées de SAD qui ont les plus courts identifiants de SA sont triés detelle sorte qu'elles soient les dernières entrées dans la liste reliée. Une mise en œuvre fondée sur le matériel peut êtrecapable d'effectuer la recherche de la plus longue correspondance de façon intrinsèque, en utilisant les dispositifscouramment disponibles de mémoire ternaire à contenu adressable (TCAM, Ternary Content-Addressable Memory).

L'indication qu'il est exigé que la correspondance d'adresse de source et de destination transpose le trafic IPsec entrant endes SA DOIT être réglée soit comme un effet collatéral de la configuration manuelle de SA, soit via la négociation enutilisant un protocole de gestion de SA, par exemple, IKE ou le domaine d'interprétation de groupe (GDOI, Group Domainof Interpretation) [RFC3547]. Normalement, les groupes de diffusion groupée spécifique de source (SSM, Source-SpecificMulticast) [RFC4607] utilisent un identifiant de SA en triplet composé d'un SPI, d'une adresse de destination de diffusiongroupée, et d'une adresse de source. Une SA de groupe de diffusion groupée toutes sources exige seulement un SPI et uneadresse de destination comme identifiant.

L'ensemble des valeurs de SPI dans la gamme de 1 à 255 est réservé par l'autorité d'allocation des numéros de l'Internet(IANA, Internet Assigned Numbers Authority) pour des utilisations futures ; une valeur réservée de SPI ne seranormalement pas allouée par l'IANA sans que l'utilisation de la valeur de SPI allouée soit spécifiée dans une RFC. La

page - 6 -


valeur de SPI de zéro (0) est réservée pour une utilisation spécifique de mise en œuvre locale et NE DOIT PAS êtreenvoyée sur le réseau. (Par exemple, une mise en œuvre de gestion de clé peut utiliser la valeur de SPI de zéro poursignifier "aucune association de sécurité n'existe" durant la période où la mise en œuvre IPsec a demandé que son entité degestion de clé établisse une nouvelle SA, mais où la SA n'a pas encore été établie.)

2.2 Numéro de séquence

Ce champ de 32 bits non signé contient une valeur de compteur qui augmente de un pour chaque paquet envoyé, c’est-à-dire, un numéro de séquence de paquet par SA. Pour une SA d'envoi individuel ou une SA de diffusion groupée d'un seulenvoyeur, l'envoyeur DOIT incrémenter ce champ pour chaque paquet transmis. Il est permis de partager une SA entreplusieurs envoyeurs, bien que généralement non recommandé. ESP ne fournit pas de moyen pour synchroniser lescompteurs de paquet parmi de multiples envoyeurs ou de gérer de façon significative un compteur de paquets en réceptionet une fenêtre dans le contexte d'envoyeurs multiples. Donc, pour une SA multi envoyeurs, le dispositif anti répétition deESP n'est pas disponible (voir les paragraphes 3.3.3 et 3.4.3.)

Ce champ est obligé et DOIT toujours être présent même si le receveur ne choisit pas d'activer le service anti répétitionpour une SA spécifique. Le traitement du champ de numéro de séquence est à la discrétion du receveur, mais toutes lesmises en œuvre ESP DOIVENT être capables d'effectuer le traitement décrit aux paragraphes 3.3.3 et 3.4.3. Donc,l'envoyeur DOIT toujours transmettre ce champ, mais le receveur n'a pas besoin d'agir sur lui (voir la discussion de lavérification de numéro de séquence au paragraphe 3.4.3 "Traitement de paquet entrant".

Les compteurs de l'envoyeur et du receveur sont initialisés à 0 quand une SA est établie. (Le premier paquet envoyé enutilisant une certaine SA aura un numéro de séquence de 1 ; voir au paragraphe 3.3.3 plus de détails sur la façon dont lenuméro de séquence est généré.) Si l'anti répétition est activée (par défaut) le numéro de séquence transmis ne doit jamaisêtre admis à revenir à zéro. Donc, le compteur de l'envoyeur et le compteur du receveur DOIVENT être remis à zéro parl'établissement d'une nouvelle SA et d'une nouvelle clé avant la transmission du 2^32ème paquet sur une SA.

2.2.1 Numéro de séquence étendu (64 bits)

Pour prendre en charge les mises en œuvre IPsec à grande vitesse, les numéros de séquence étendus (ESN) DEVRAIENTêtre mis en œuvre, comme extension au champ actuel de 32 bits de numéro de séquence. L'utilisation d'un ESN DOIT êtrenégociée par un protocole de gestion de SA. Noter que dans IKEv2, cette négociation est implicite ; ESN est par défaut saufsi les numéros de séquence à 32 bits sont explicitement négociés. (Le dispositif ESN est applicable aux SA de diffusiongroupée aussi bien que d'envoi individuel.)

La facilité ESN permet l'utilisation de numéros de séquence de 64 bits pour une SA. (Voir les détails à l'Appendice A,"Numéros de séquence étendus (64 bits)".) Seuls les 32 bits de moindre poids du numéro de séquence sont transmis dansl'en-tête ESP en texte source de chaque paquet, minimisant donc les frais généraux par paquet. Les 32 bits de poids fortsont conservés au titre du compteur de numéro de séquence par l'émetteur et le receveur et sont inclus dans le calcul del'ICV (si le service de protection de l’intégrité est choisi). Si un algorithme séparé d'intégrité est employé, les bits de poidsforts sont inclus dans l'en-queue ESP implicite, mais ne sont pas transmis, comme les bits de bourrage des algorithmesd'intégrité. Si un algorithme en mode combiné est employé, le choix de l'algorithme détermine si les bits ESN de poids fortsont transmis ou sont inclus implicitement dans le calcul. Voir au paragraphe 3.3.2.2 les détails du traitement.

2.3 Données de charge utile

Données de charge utile est un champ de longueur variable contenant les données (provenant du paquet IP original) décritpar le champ Prochain en-tête. Le champ Données de charge utile est obligatoire et a un nombre entier d'octets. Sil'algorithme utilisé pour chiffrer la charge utile exige des données de synchronisation cryptographiques, par exemple, unevaleur d'initialisation (IV), ces données doivent alors être portées explicitement dans le champ Charge utile, mais il n'estpas invoqué comme un champ séparé dans ESP, c’est-à-dire, la transmission d'une IV explicite est invisible à ESP. (Voir laFigure 2.) Tout algorithme de chifffrement qui exige de telles données de synchronisation explicites par paquet DOITindiquer la longueur, toute structure de telles données, et la localisation de ces données, au titre d'une RFC spécifiantcomment l'algorithme est utilisé avec ESP. Normalement, la IV précède immédiatement le texte chiffré. (Voir la Figure 2.)Si de telles données de synchronisation sont implicites, l'algorithme pour déduire les données DOIT faire partie de la RFCde définition de l'algorithme. (Si elles sont incluses dans le champ Charge utile, les données de synchronisationcryptographique, par exemple, une valeur d'initialisation (IV) ne sont généralement par chiffrées par elles-même (voir lesTableaux 1 et 2) bien que parfois on s'y réfère comme faisant partie du texte chiffré.)

page - 7 -


Noter que le début de l'en-tête du protocole de couche suivante DOIT être aligné par rapport au début de l'en-tête ESPcomme suit. Pour IPv4, cet alignement est un multiple de 4 octets. Pour IPv6, l'alignement est un multiple de 8 octets.

En ce qui concerne la vérification de l'alignement du texte chiffré (réel) en présence d'une IV, noter que :o Pour certains modes de fonctionnement fondés sur l'IV, le receveur traite l'IV comme début du texte chiffré, le

fournissant directement à algorithme. Dans ces modes, l'alignement du début du texte chiffré (réel) n'est pas unproblème chez le receveur.

o Dans certains cas, le receveur lit la IV séparément du texte chiffré. Dans ce cas, la spécification de l'algorithme DOITindiquer comment l'alignement du texte chiffré réel doit être réalisé.

2.4 Bourrage (pour chiffrement)

Deux principaux facteurs exigent ou motivent l'utilisation du champ Bourrage.

o Si on emploie un algorithme de chiffrement qui exige que le texte source soit un multiple d'un certain nombre d'octets,par exemple, la taille de bloc d'un chiffrement par blocs, le champ Bourrage est utilisé pour compléter le texte source(consistant en les champs Données de charge utile, Bourrage, Longueur de bourrage , et Prochain en-tête) à la taillerequise par l'algorithme.

o Le bourrage peut aussi être requis, sans considération des exigences de l'algorithme de chiffrement, pour s'assurer quele texte chiffré résultant se termine sur une limite de 4 octets. Précisément, les champs Longueur de bourrage etProchain en-tête dovenit être alignés à droite au sein d'un mot de 4 octets, comme illustré dans les figures de format depaquet ESP ci-dessus, pour s'assurer que le champ ICV (si présent) est aligné sur une limite de 4 octets.

Un bourrage au delà de ce qui est requis pour l'algorithme ou pour les raisons d'alignement citées ci-dessus pourrait êtreutilisé pour dissimuler la longueur réelle de la charge utile, à l'appui de TFC. Cependant, le champ Bourrage décrit est troplimité pour être efficace pour TFC et donc ne devrait pas être utilisé à cette fin. À la place, le mécanisme distinct décrit ci-dessous (voir le paragraphe 2.7) devrait être utilisé quand TFC est exigé.

L'envoyeur PEUT ajouter de 0 à 255 octets de bourrage. L'inclusion du champ Bourrage dans un paquet ESP estfacultative, sous réserve des exigences notées ci-dessus, mais toutes les mises en œuvre DOIVENT prendre en charge lagénération et la consommation du bourrage.

o Afin de s'assurer que les bits à chiffrer sont un multiple de la taille de bloc de l'algorithme (premier facteur ci-dessus)le calcul du bourrage s'applique aux données de charge utile à l'exclusion de toute IV, mais incluant les champs dequeue d'ESP. Si un algorithme en mode combiné exige la transmission du SPI et du numéro de séquence pour effectuerla protection de l'intégrité, par exemple, duplication du SPI et du numéro de séquence dans les données de charge utile,alors les versions dupliquées de ces éléments de données, et toutes données associées équivalentes à l'ICV sontincluses dans le calcul de la longueur de bourrage. (Si l'option ESN est choisie, les 32 bits de poids fort de ESN vontaussi entrer dans le calcul, si l'algorithme en mode combiné exige leur transmission pour l'intégrité.)

o Afin de s'assurer que l'ICV est aligné sur une limite de quatre octets (second facteur ci-dessus) le calcul du bourrages'applique aux données de charge utile incluant les champs IV, Longueur de bourrage, et Prochain en-tête. Si unalgorithme en mode combiné est utilisé, toutes les données dupliquées et les données équivalentes à l'ICV sont inclusesdans les données de charge utile couvertes par le calcul du bourrage.

Si des octets de bourrage sont nécessaires mais si l'algorithme de chiffrement ne spécifie pas le contenu du bourrage, letraitement par défaut suivant DOIT être utilisé. Les octets de bourrage sont initialisés avec une série de valeurs d'entier(non signés, d'un octet). Le premier octet de bourrage ajouté au texte source est numéroté 1, et les octets de bourragesuivants formant une séquence à croissance monotone : 1, 2, 3, .... Quand ce schéma de bourrage est employé, le receveurDEVRAIT inspecter le champ Bourrage. (Ce schéma a été choisi à cause de sa relative simplicité, de la facilité de mise enœuvre dans les matériels, et parce qu'il offre une protection limitée contre certaines formes d'attaques de "couper coller" enl'absence d'autres mesures de protection de l'intégrité si le receveur vérifie les valeurs de bourrage au déchiffrement.)

Si un algorithme de chiffrement ou en mode combiné impose des contraintes sur les valeurs des octets utilisés pour lebourrage, elles DOIVENT être spécifiées par la RFC qui définit comment l'algorithme est employé avec ESP. Sil'algorithme exige de vérifier les valeurs des octets utilisés pour le bourrage, cela DOIT aussi être spécifié dans cette RFC.

page - 8 -


2.5 Longueur de bourrage

Le champ Longueur de bourrage indique le nombre d'octets de bourrage qui le précèdent immédiatement dans le champBourrage. La gamme des valeurs valides est de 0 à 255, où une valeur de zéro indique qu'aucun octet de bourrage n'estprésent. Comme noté ci-dessus, cela n'inclut aucun octet de bourrage TFC. Le champ Longueur de bourrage est obligatoire.

2.6 Prochain en-tête

Le champ Prochain en-tête de 8 bits est obligatoire, il identifie le type de données contenues dans le champ Données decharge utile, par exemple, un paquet IPv4 ou IPv6, ou un en-tête et des données de la couche suivante. La valeur de cechamp est choisie dans l'ensemble des numéros de protocole IP définis sur la page d'accueil de l'IANA, par exemple, unevaleur de 4 indique IPv4, une valeur de 41 indique IPv6, et une valeur de 6 indique TCP.

Pour faciliter la génération et l'élimination rapide du trafic de bourrage à l'appui de la confidentialité des flux de trafic (voirle paragraphe 2.4) la valeur de protocole 59 (qui signifie "pas de prochain en-tête") DOIT être utilisée pour désigner unpaquet "factice". Un émetteur DOIT être capable de générer des paquets factices marqués de cette valeur dans le champProchain protocole, et un receveur DOIT être prêt à éliminer de tels paquets, sans indiquer une erreur. Tous les autreschamps d'en-tête et d'en-queue ESP (SPI, Numéro de séquence, Bourrage, Longueur de bourrage, Prochain en-tête, et ICV)DOIVENT être présents dans les paquets factices, mais la portion de texte source de la charge utile, à part ce champProchain en-tête, n'a pas besoin d'être bien formée, par exemple, le reste des données de charge utile peut consisterseulement en octets aléatoires. Les paquets factices sont éliminés sans dommage.

Les mises en œuvre DEVRAIT fournir des commandes de gestion locales pour permettre l'utilisation de cette capacité SApar SA. Les commandes devraient permettre à l'utilisateur de spécifier si cette caractéristique est à utiliser et fournir aussides commandes paramétriques ; par exemple, les commandes pourraient permettre à un administrateur de générer despaquets factices de longueur aléatoire ou fixe.

Discussion : Les paquets factices peuvent être insérés à des intervalles aléatoires pour masquer l'absence de trafic réel. Onpeut aussi "formater" le trafic réel pour correspondre à une certaine distribution à laquelle le trafic factice est ajoutécomme indiqué par les paramètres de distribution. Comme avec la facilité de bourrage de la longueur de paquet pourla sécurité des flux de trafic (TFS, Traffic Flow Security) l'approche la plus sûre serait de générer des paquetsfactices au taux nécessaire pour maintenir un taux constant sur une SA. Si les paquets sont tous de la même taille, laSA présente alors l'apparence d'un flux de données à taux binaire constant, analogue à ce qu'un chiffrement deliaison offrirait aux couches 1 ou 2. Cependant, il est peu probable que cela soit praticable dans de nombreuxcontextes, par exemple, quand il y a plusieurs SA actives, parce que cela impliquerait de réduire la bande passanteadmise pour un site, sur la base du nombre de SA, et cela détruirait les avantages de la commutation de paquets. Lesmises en œuvre DEVRAIENT fournir des commandes pour permettre aux administrateurs locaux de gérer lagénération des paquets factices pour les besoins de TFC.

2.7 Bourrage de confidentialité du flux de trafic (TFC)

Comme noté ci-dessus, le champ Bourrage est limité en longueur à 255 octets. Cela ne va généralement pas être adéquatpour cacher les caractéristiques du trafic par rapport aux exigences de confidentialité des flux de trafic. Un champfacultatif, au sein des données de charge utile, est spécifiquement fourni pour traiter cette exigence de TFC.

Une mise en œuvre IPsec DEVRAIT être capable de bourrer le trafic en ajoutant des octets après la fin des données decharge utile, avant le début du champ Bourrage. Cependant, ce bourrage (qu'on appelle ici bourrage TFC) ne peut êtreajouté que si le champ Données de charge utile contient une spécification de la longueur du datagramme IP. Ceci esttoujours vrai en mode tunnel, et peut être vrai en mode transport selon que le protocole de la prochaine couche (parexemple, IP, UDP, ICMP) contient des informations explicites de longueur. Ces informations de longueur vont permettreau receveur d'éliminer le bourrage TFC, parce que la vraie longueur des données de charge utile sera connue. (Les champsd'en-queue ESP sont localisés en comptant à rebours depuis la fin du paquet ESP.) En conséquence, si le bourrage TFC estajouté, le champ qui contient la spécification de la longueur du datagramme IP NE DOIT PAS être modifié pour refléter cebourrage. Aucune exigence sur la valeur de ce bourrage n'est établie par la présente norme.

En principe, les mises en œuvre IPsec existantes auraient pu utiliser cette capacité antérieurement, de façon transparente.Cependant, parce que les receveurs peuvent n'avoir pas été préparés à traiter ce bourrage, le protocole de gestion de SADOIT négocier ce service avant qu'un émetteur l'emploie, pour s'assurer de la rétro compatibilité. Combiné avec les

page - 9 -


convention décrites au paragraphe 2.6, sur l'utilisation de l'identifiant de protocole 59, une mise en œuvre ESP est capablede générer des paquets factices et réels qui présentent une bien plus grande variabilité de longueur, à l'appui de TFC.

Les mises en œuvre DEVRAIENT fournir des commandes de gestion locales pour permettre l'utilisation de cette capacitéSA par SA. Les commandes devraient permettre à l'utilisateur de spécifier si cette caractéristique doit être utilisée et aussifournir des commandes paramétriques pour cette caractéristique.

2.8 Valeur de vérification d’intégrité

Valeur de vérifiation d'intégrité (ICV, Integrity Check Value) est un champ de longueur variable calculé sur les champs En-tête ESP, Charge utile, et En-queue ESP. Les champs implicites d'en-queue ESP (bourrage d'intégrité et bits ESN de poidsfort, si applicables) sont inclus dans le calcul d'ICV. Le champ ICV est facultatif. Il n'est présent que si le service deprotection de l’intégrité est choisi et il est fourni par un algorithme d'intégrité séparé ou un algorithme en mode combinéqui utilise une ICV. La longueur du champ est spécifiée par l'algorithme d'intégrité choisi et associé à la SA. Laspécification de l'algorithme d'intégrité DOIT spécifier la longueur de l'ICV et les règles de comparaison et les étapes detraitement pour la validation.

3. Traitement de l’encapsulation de protocole de sécurité

3.1 Situation de l’en-tête ESP

ESP peut être employé de deux façons : en mode transport ou en mode tunnel.

3.1.1 Traitement du mode transport

En mode transport, ESP est inséré après l'en-tête IP et avant un protocole de prochaine couche, par exemple, TCP, UDP,ICMP, etc. Dans le contexte de IPv4, cela se traduit par le placement d'ESP après l'en-tête IP (et toutes les options qu'ilcontient) mais avant le protocole de prochaine couche. (Si AH est aussi appliqué à un paquet, c'est appliqué à l'en-tête ESP,à la charge utile, à l'en-queue ESP, et à l'ICV, si présente.) (Noter que le terme de mode "transport" ne devrait pas être malinterprété comme restreignant son utilisation à TCP et UDP.) Le diagramme suivant illustre le positionnement du modetransport ESP pour un paquet IPv4 normal, fondé sur "avant et après". (Ce diagramme et le suivant montrent le champ ICV,dont la présence est fonction des services de sécurité et de l'algorithme/mode choisis.)

Avant l’application de ESP +----------------------+------+-----------+IPv4 |En-tête IP d'origine| | | | (toutes options) | TCP | Données | +-----------------------+------+-----------+

Après l’application de ESP +----------------------+--------+------+---------+------------+-----+IPv4 |En-tête IP d'origine|En-tête | | | En-queue | ICV | | (toutes options) | ESP |TCP |Données| ESP | ESP | +----------------------+--------+------+----------+-----------+-----+ |<----- chiffrement ------->| |<------------- intégrité ------------->|

Dans le contexte IPv6, ESP est vu comme une charge utile de bout en bout, et donc devrait apparaître après les en-têtesbond par bond, acheminement, et extension de fragmentation. Le ou les en-têtes d'extension d'options de destinationpourraient apparaître avant, après, ou à la fois avant et après l'en-tête ESP selon la sémantique désirée. Cependant, commeESP protège seulement les champs après l'en-tête ESP, il sera généralement désirable de placer les en-têtes d'options dedestination après l'en-tête ESP. Le diagramme suivant illustre le positionnement d'ESP en mode transport pour un paquetIPv6 normal.

Avant l’application de ESP +------------+----------------+------+---------+IPv6 |En-tête IP |En-têtes d'ext. | |Données| | d'origine | si presents | TCP | | +------------+----------------+------+---------+

page - 10 -


Après l’application de ESP +-----------+-------------------------+----+-------+-----+---------+----------+-----+Ipv6 |En-tête IP|Bond par bond,dest*. | |option| |Données|En-queue|ICV| | d'origine |Achemin.,fragmentat.|ESP| dest* |TCP| | ESP |ESP| +-----------+-------------------------+----+-------+-----+---------+-----------+----+ |<------- chiffrement ------------>| |<-------------- intégrité--------------->|

* = si present, pourrait être avant ESP, après ESP, ou les deux,

Noter qu'en mode transport, pour les mises en œuvre "prises dans la pile" ou "prises dans le réseau", comme défini dans ledocument d'architecture de la sécurité, les fragments IP entrants et sortants peuvent exiger qu'une mise en œuvre IPseceffectue un réassemblage/fragmentation IP supplémentaire afin de se conformer à la présente spécification et fournir uneprise en charge transparente d'IPsec. Une attention particulière est requise pour effectuer de telles opérations au sein de cesmises en œuvre quand plusieurs interfaces sont utilisées.

3.1.2 Traitement en mode tunnel

En mode tunnel, l'en-tête IP "interne" porte les dernières adresses (IP) de source et destination, tandis que l'en-tête IP"externe" contient les adresses des "homologues" IPsec, par exemple, les adresses des passerelles de sécurité. Des versionsmixtes IP internes et externes sont permises, c’est-à-dire, IPv6 sur IPv4 et IPv4 sur IPv6. En mode tunnel, ESP protège lepaquet IP interne entier, incluant l'en-tête IP interne entier. La position de ESP en mode tunnel, par rapport à l'en-tête IPexterne, est la même que pour ESP en mode transport. Le diagramme suivant illustre le positionnement d'ESP en modetunnel pour les paquets normaux IPv4 et IPv6.

Avant l’application de ESP --------------------------------------------IPv4 |en-tête IP d'origine| | | | (toutes options) | TCP | Données | --------------------------------------------

Après l’application de ESP --------------------------------------------------------------------------------------------IPv4 | nouvel en-tête IP* | |en-tête IP d'origine*| | |En-queue| ICV| | (toutes options) | ESP | (toutes options) |TCP|Données| ESP | ESP| --------------------------------------------------------------------------------------------- |<-------------- chiffrement --------------------->| |<--------------------- intégrité ------------------------->|

Avant l’application de ESP ---------------------------------------------------------IPv6 | En-tête IP | en-têtes externes | | | | d'origine | si présents | TCP |Données| ---------------------------------------------------------

Après l’application de ESP ----------------------------------------------------------------------------------------------------------------IPv6 | nouvel* | nouveaux | |En-tête IP*|En-têtes externes| | |En-queue| ICV| |en-tête IP| en-têtes externes*|ESP| d'origine | d'origine* |TCP|Données| ESP | ESP| ---------------------------------------------------------------------------------------------------------------- |<----------------- chiffrement ---------------------------->| |<----------------------- intégrité -------------------------------->|

* = si présent, la construction des en-têtes/extensions IP externes et la modification des en-têtes/extensions IP internes estdiscutée dans le document d'architecture de sécurité.

3.2 Algorithmes

Les algorithmes de mise en œuvre obligatoire pour l'utilisation avec ESP sont décrits dans une RFC séparée, pour faciliterla mise à jour des exigences des algorithmes indépendement du protocole lui-même. Des algorithmes supplémentaires, au

page - 11 -


delà de ceux obligatoires pour ESP, PEUVENT être pris en charge. Noter que bien que la confidentialité et l'intégrité soienttoutes deux facultatives, au moins un de ces services DOIT être choisi, donc les deux algorithmes NE DOIVENT PAS êtresimultanément NULS.

3.2.1 Algorithmes de chiffrement

L'algorithme de chiffrement employé pour protéger un paquet ESP est spécifié par la SA via laquelle le paquet esttransmis/reçu. Parce que les paquets IP peuvent arriver déclassés, et que tous les paquets peuvent ne pas arriver (perte depaquet) chaque paquet doit porter toutes les données requises pour permettre au receveur d'établir la synchronisationcryptographique pour le déchiffrement. Ces données peuvent être portées explicitement dans le champ Charge utile, parexemple, comme une IV (comme décrit ci-dessus) ou les données peuvent être déduites de portions de texte source de l'en-tête de paquet (IP ou ESP externe). (Noter que si les informations d'en-tête de texte source sont utilisées pour déduire uneIV, ces informations peuvent devenir critiques pour la sécurité et donc la limite de protection associée au processus dechiffrement peut croître. Par exemple, si on utilise le numéro de séquence ESP pour déduire une IV, la logique degénération de numéro de séquence (matérielle ou logicielle) devra être évaluée au titre de la mise en œuvre de l'algorithmede chiffrement. Dans le cas de FIPS 140-2 [NIST01], cela peut étendre significativement la portée de l'évaluation dumodule de chiffrement.) Parce que ESP a des dispositions pour le bourrage du texte source, les algorithmes de chiffrementemployés avec ESP peuvent présenter des caractéristiques de mode de bloc ou de flux. Noter que parce que le chiffrement(confidentialité) PEUT être un service facultatif (par exemple, ESP en intégrité seule) cet algorithme PEUT être "NUL"[RFC4301].

Pour permettre à une mise en œuvre d'ESP de calculer le bourrage de chiffrement exigé par un algorithme de chiffrementen mode bloc, et pour déterminer l'impact de la MTU de l'algorithme, la RFC pour chaque algorithme de chiffrement utiliséavec ESP doit spécifier le module de bourrage pour l'algorithme.

3.2.2 Algorithmes d'intégrité

L'algorithme d'intégrité employé pour le calcul de l'ICV est spécifié par la SA via laquelle le paquet est transmis/reçu.Comme c'était le cas pour les algorithmes de chiffrement, tout algorithme d'intégrité employé avec ESP doit prendre desdispositions pour permettre le traitement des paquets qui arrivnt déclassés et pour s'accommoder de la perte de paquets. Lemême avertissement que ci-dessus s'applique à l'utilisation de toutes les données de texte source pour faciliter lasynchronisation des algorithmes d'intégrité par le receveur. Noter que parce que le service de protection de l’intégritéPEUT être facultatif, cet algorithme peut être "NUL".

Pour permettre à une mise en œuvre ESP de calculer tout bourrage implicite d'algorithme d'intégrité requis, la RFC pourchaque algorithme utilisé avec ESP doit spécifier le module de bourrage pour l'algorithme

3.2.3 Algorithmes de mode combiné

Si un algorithme en mode combiné est employé, les deux services de protection de la confidentialité et de l’intégrité sontfournis. Comme c'était le cas pour les algorithmes de chiffrement, un algorithme en mode combiné doit présenter desdispositions pour la synchronisation du chiffrement paquet par paquet, pour permettre le déchiffrement des paquets quiarrivent déclassés et pour s'accommoder de la perte de paquets. Les moyens par lesquels un algorithme en mode combinéfournit l'intégrité pour la charge utile, et pour le SPI et les champs de numéro de séquence (étendus) peuvent varier pourdes choix différents d'algorithmes. Afin de fournir une approche uniforme, indépendante de l'algorithme pour l'invocationdes algorithmes en mode combiné, aucune sous structure de charge utile n'est définie. Par exemple, les champs SPI etNuméro de séquence peuvent être dupliqués au sein de l'enveloppe de texte chiffré et une ICV peut être ajoutée à l'en-queue ESP. Aucun de ces détails ne devrait être observable en externe.

Pour permettre à une mise en œuvre ESP de déterminer l'impact de la MTU d'un algorithme en mode combiné, la RFC pourchaque algorithme utilisé avec ESP doit spécifier une formule (simple) qui donne la taille chiffrée de la charge utile,comme fonction de la taille de la charge utile et du numéro de séquence du texte source.

3.3 Traitement du paquet sortant

En mode transport, l'envoyeur encapsule les informations de protocole de prochaine couche entre les champs d'en-tête etd'en-queue ESP, et conserve l'en-tête IP spécifié (et tous en-têtes d'extension IP dans le contexte IPv6). En mode tunnel, lesen-têtes/extensions IP externe et interne peuvent être en interrelation de diverses façons. La construction des en-têtes/extensions IP externe interne durant le processus d'encapsulation est décrit dans le document d'architecture de lasécurité.

page - 12 -


3.3.1 Recherche d’association de sécurité

ESP n'est appliqué à un paquet sortant qu'après qu'une mise en œuvre IPsec a déterminé que le paquet est associé à une SAqui invoque le traitement ESP. Le processus de détermination de quel traitement IPsec, si il en est, est appliqué au traficsortant est décrit dans le document d'architecture de la sécurité.

3.3.2 Calcul de valeur de vérification de chiffrement et d’intégrité de paquet

Dans ce paragraphe le chiffrement est toujours appliqué à cause des implications de formatage. Ceci implique en sousentendu que la "non confidentialité" est offerte en utilisant l'algorithme de chiffrement NUL (RFC 2410). Il y a plusieursoptions algorithmiques.

3.3.2.1 Algorithmes séparés de confidentialité et d’intégritéSi des algorithmes séparés de confidentialité et d'intégrité sont employés, l'envoyeur procède comme suit :

1. Encapsuler (dans le champ Charge utile ESP) :- pour le mode transport -- juste les informations de protocole original de prochaine couche.- pour le mode tunnel – le datagramme IP original entier.

2. Ajouter le bourrage nécessaire – bourrage TFC facultatif et bourrage (de chiffrement),

3. Chiffrer le résultat en utilisant la clé, l'algorithme de chiffrement, et le mode d'algorithme spécifiés pour la SA et enutilisant toutes les données de synchronisation cryptographiques requises.

- Si des données explicites de synchronisation cryptographiques, par exemple, une IV, sont indiquées, elles sontentrées dans l'algorithme de chiffrement selon la spécification de l'algorithme et placées dans le champ Charge utile.

- Si des données implicites de synchronisation cryptographiques sont employées, elles sont construites et entrées àl'algorithme de chiffrement selon la spécification de l'algorithme.

- Si l'intégrité est choisie, le chiffrement est effectué d'abord, avant l'application de l'algorithme d'intégrité, et lechiffrement n'englobe pas le champ ICV. Cet ordre de traitement facilite la détection rapide et le rejet des paquetsrépétés ou mal formés par le receveur, avant de déchiffrer le paquet, réduisant donc potentiellement l'impactd'attaques de déni de service (DoS). Cela permet aussi un possible traitement en parallèle des paquets chez lereceveur, c’est-à-dire, le déchiffrement peut avoir lieu en parallèle avec la vérification d'intégrité. Noter que parceque l'ICV n'est pas protégée par le chiffrement, un algorithme d'intégrité chiffré doit être employé pour la calculer.

4. Calculer l'ICV sur le paquet ESP moins le champ ICV. Donc, le calcul de l'ICV englobe le SPI, le numéro deséquence, les données de charge utile, le bourrage (si présent), la longueur de bourrage et le prochain en-tête. (Noterque les 4 derniers champs vont être en forme de texte chiffré, parce que le chiffrement est effectué d'abord.) Si l'optionESN est activée pour la SA, les 32 bits de poids fort du numéro de séquence sont ajoutés après le champ Prochain en-tête pour les besoins de ce calcul, mais ils ne sont pas transmis.

Pour certains algorithmes d'intégrité, la chaîne d'octets sur laquelle est effectué le calcul de l'ICV doit être un multiple d'unetaille de bloc spécifiée par l'algorithme. Si la longueur du paquet ESP (comme décrite ci-dessus) ne correspond pas auxexigences de taille de bloc pour l'algorithme, un bourrage implicite DOIT être ajouté à la fin du paquet ESP. (Ce bourrageest ajouté après le champ Prochain en-tête, ou après les 32 bits de poids fort du numéro de séquence, si ESN est choisi.) Lataille de bloc (et donc la longueur du bourrage) est spécifiée par la spécification de l'algorithme d'intégrité. Ce bourragen'est pas transmis avec le paquet. Le document qui définit un algorithme d'intégrité DOIT être consulté pour déterminer sile bourrage implicite est requis comme décrit ci-dessus. Si le document ne spécifie pas une réponse à cette question, on doitsupposer par défaut que le bourrage implicite est exigé (comme nécessaire pour faire correspondre la longueur de paquet àla taille de bloc de l'algorithme.) Si des octets de bourrage sont nécessaires mais si l'algorithme ne spécifie pas le contenudu bourrage, les octets de bourrage DOIVENT avoir une valeur de zéro.

3.3.2.2 Algorithmes combinés de confidentialité et d’intégritéSi un algorithme combiné de confidentialité/intégrité est employé, l'envoyeur procède comme suit :1. Encapsuler dans le champ ESP Données de charge utile :

- pour le mode transport -- juste les informations de protocole original de prochaine couche.- pour le mode tunnel -- le datagramme IP original entier.

2. Ajouter tout bourrage nécessaire – inclus le bourrage TFC facultatif et le bourrage (de chiffrement).

3. Chiffrer et protéger en intégrité le résultat en utilisant la clé et l'algorithme en mode combiné spécifié pour la SA et enutilisant toutes les données requises pour la synchronisation cryptographique.

page - 13 -


- Si des données explicites de synchronisation cryptographique, par exemple, une IV, sont indiquées, elles sontentrées à l'algorithme en mode combiné selon la spécification de l'algorithme et placées dans le champ Charge utile.

- Si des données implicites de synchronisation cryptographique sont employées, elles sont construites et entrées àl'algorithme de chiffrement conformément à la spécification de l'algorithme.

- Le numéro de séquence (ou le numéro de séquence étendu, comme approprié) et le SPI sont entrés à l'algorithme,car ils doivent être inclus dans le calcul de vérification d'intégrité. Les moyens par lesquels ces valeurs sont inclusesdans ce calcul sont fonction de l'algorithme en mode combiné employé et donc non spécifiés dans cette norme.

- Le champ (explicite) ICV PEUT faire partie du format de paquet ESP quand un algorithme en mode combiné estemployé. Si il n'est pas utilisé, un champ analogue va généralement faire partie de la charge utile de texte chiffré. Lalocalisation de tous les champs d'intégrité, et les moyens par lesquels le numéro de séquence et le SPI sont inclusdans le calcul de l'intégrité, DOIVENT être définis dans une RFC sur l'utilisation de l'algorithme en mode combinéavec ESP.

3.3.3 Génération de numéro de séquence

Le compteur de l'envoyeur est initialisé à 0 quand une SA est établie. L'envoyeur incrémente le compteur de numéro deséquence (ou ESN) pour cette SA et insère les 32 bits de moindre poids de la valeur dans le champ Numéro de séquence.Donc, le premier paquet envoyé en utilisant une certaine SA va contenir un numéro de séquence de 1.

Si l'anti répétition est activée (par défaut) l'envoyeur vérifie que le compteur n'a pas fait un tour complet avant d'insérer lanouvelle valeur dans le champ Numéro de séquence. En d'autres termes, l'envoyeur NE DOIT PAS envoyer un paquet surune SA si le faisant il causerait la fin du cycle des numéros de séquence. Une tentative de transmission d'un paquet quirésulterait en un débordement de numéro de séquence est un événement à signaler dans le journal. L'enregistrement à entrerpour cet événement DEVRAIT inclure la valeur de SPI, la date et l'heure en cours, l'adresse de source, l'adresse dedestination, et (dans IPv6) l'identifiant de flux du texte source.

L'envoyeur suppose que l'anti répétition est activée par défaut, sauf notification contraire du receveur (voir auparagraphe 3.4.3). Donc, le comportement normal d'une mise en œuvre ESP invite l'envoyeur à établir une nouvelle SAquand le numéro de séquence (ou ESN) a accompli un cycle, ou en anticipation de l'accomplissement du cycle par cettevaleur.

Si la clé utilisée pour calculer une ICV est distribuée manuellement, une mise en œuvre conforme NE DEVRAIT PASfournir de service anti répétition. Si un utilisateur choisit d'employer l'anti répétition en conjonction avec des SA qui sontchiffrées manuellement, le compteur de numéros de séquence chez l'envoyeur DOIT être correctement conservé à traversles réinitialisations locales, etc., jusqu'à ce que la clé soit remplacée. (Voir la Section 5.)

Si l'anti répétition est désactivée (comme noté ci-dessus) l'envoyeur n'a pas besoin de surveiller ou réinitialiser le compteur.Cependant, l'envoyeur incrémente toujours le compteur et quand il atteint la valeur maximum, le compteur revient à zéro.(Ce comportement est recommandé pour les SA multi envoyeurs en diffusion groupée, sauf si des mécanismes antirépétition qui sortent du domaine d'application de la présente norme, sont négociés entre envoyeur et receveur.)

Si ESN (voir l'Appendice) est choisi, seuls les 32 bits de moindre poids du numéro de séquence sont transmis dans lechamp Numéro de séquence, bien que envoyeur et receveur tiennent tous deux des compteurs ESN complets de 64 bits. Les32 bits de poids fort sont inclus dans la vérification d'intégrité d'une façon spécifique de l'algorithme/mode, par exemple,les 32 bits de poids fort peuvent être ajoutés après le champ Prochain en-tête quand on emploie un algorithme d'intégritéséparé.

Note : Si un receveur choisit de ne pas activer l'anti répétition pour une SA, le receveur NE DEVRAIT alors PAS négocierESN dans un protocole de gestion de SA. L'utilisation de ESN crée le besoin que le receveur gère une fenêtre d'antirépétition (afin de déterminer la valeur correcte pour les bits de poids fort de l'ESN, qui sont employés dans le calculde l'ICV) ce qui est généralement contraire à la notion de désactivation de l'anti répétition pour une SA.

3.3.4 Fragmentation

Si necessaire, la fragmentation est effectuée après le traitement ESP au sein d'une mise en œuvre IPsec. Donc, le modetransport ESP n'est appliqué qu'aux datagrammes IP complets (pas aux fragments IP). Un paquet IP auquel ESP a étéappliqué peut lui-même être fragmenté par les routeurs en chemin, et de tels fragments doivent être rassembleés avant letraitement ESP chez un receveur. En mode tunnel, ESP est appliqué à un paquet IP, qui peut être un fragment d'undatagramme IP. Par exemple, une passerelle de sécurité ou une mise en œuvre IPsec "prise dans la pile" ou "prise dans leréseau" (comme défini dans le document d'architecture de sécurité) peut appliquer ESP en mode tunnel à de tels fragments.

page - 14 -


Note : pour le mode transport – comme mentionné à la fin du paragraphe 3.1.1, les mises en œuvre prises dans la pile etprises dans le réseau peuvent avoir d'abord à rassembler un paquet fragmenté par la couche IP locale, puisd'appliquer IPsec, et ensuite de fragmenter le paquet résultant.

Note : pour IPv6 -- pour les mises en œuvre prises dans la pile et prises dans le réseau, il sera nécessaire d'examiner tous lesen-têtes d'extension pour déterminer si il y a un en-tête de fragmentation et donc si le paquet doit être réassembliéavant le traitement IPsec.

La fragmentation, qu'elle soit effectuée par une mise en œuvre IPsec ou par les routeurs sur le chemin entre homologuesIPsec, réduit significativement les performances. De plus, l'exigence qu'un receveur ESP accepte les fragments auréassemblage crée des vulnérabilités au déni de service. Donc, une mise en œuvre ESP PEUT choisir de ne pas prendre encharge la fragmentation et peut marquer les paquets transmis avec le bit DF (ne pas fragmenter) pour faciliter la découvertede la MTU de chemin (PMTU, Path MTU). Dans tous les cas, une mise en œuvre ESP DOIT prendre en charge lagénération des messages PMTU ICMP (ou leur équivalent en signalisation interne pour les mises en œuvre d'hôte natives)pour minimiser la probabilité de fragmentation. Les détails de la prise en charge requise pour la gestion de la MTU sontcontenus dans le document d'architecture de sécurité.

3.4 Traitement de paquet entrant

3.4.1 Réassemblage

Si exigé, le réassemblag est effectué avant le traitement ESP. Si un paquet offert pour traitement à ESP paraît être unfragment IP, c’est-à-dire, si le champ OFFSET n'est pas zéro ou si le fanion Plus de fragments est établi, le receveur DOITéliminer le paquet ; ceci est un événement auditable. L'entrée d'enregistrement d'audit pour cet événement DEVRAITinclure la valeur de SPI, la date/heure de réception, l'adresse de source, l'adresse de destination, le numéro de séquence, et(dans IPv6) tl'identifiant de flux.

Note : pour le réassemblage de paquet, la spécification IPv4 actuelle N'EXIGE PAS la mise à zéro du champ Décalage nil'a mise à zéro du fanion Plus de fragments. Afin qu'un paquet réassemblé soit traité par IPsec (par opposition àéliminé comme fragment apparent) le code IP doit faire ces deux choses après avoir rassemblé un paquet.

3.4.2 Recherche d’association de sécurité

À réception d'un paquet contenant un en-tête ESP, le receveur détermine la SA appropriée (unidirectionnelle) via unerecherche dans la SAD. Pour une SA d'envoi individuel, cette détermination se fonde sur le SPI ou le SPI plus le champProtocole, comme décrit au paragraphe 2.1. Si une mise en œuvre prend en charge le trafic de diffusion groupée, l'adressede destination est aussi employée dans la recherche (en plus du SPI) et l'adresse de l'envoyeur peut aussi être employée,comme décrit au paragraphe 2.1. (Ce processus est décrit plus en détails dans le document d'architecture de sécurité.)L'entrée de SAD pour la SA indique aussi si le champ Numéro de séquence va être vérifié, si des numéros de séquence de32 ou 64 bits sont employés pour la SA, et si le champ ICV (explicite) devrait être présent (et sa taille si c'est le cas). Aussi,l'entrée de SAD va spécifier les algorithmes et les clés à employer pour le déchiffrement et le calcul d'ICV (si c'estapplicable).

Si il n'existe aucune association de sécurité valide pour ce paquet, le receveur DOIT éliminer le paquet; c'est un événementqui peut faire l'objet d'un examen. L'entrée d'enregistrement d'audit pour cet événement DEVRAIT inclure la valeur du SPI,la date/heure de réception, l'adresse de source, l'adresse de destination, le numéro de séquence, et (en IPv6) l'identifiant deflux du texte source.

(Noter que le trafic de gestion de SA, comme les paquets IKE, n'ont pas besoin d'être traités sur la base du SPI, c’est-à-dire,on peut démultiplexer ce trafic séparément sur la base des champs Prochain protocole et Accès, par exemple.)

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

Toutes les mises en œuvre ESP DOIVENT prendre en charge le service anti répétition, bienque son utilisation puisse êtreactivée ou désactivée par le receveur SA par AS. Ce service NE DOIT PAS être activé à moins que le service ESP deprotection de l’intégrité soit aussi activé pour la SA, parce que autrement le champ Numéro de séquence n'a pas été protégéen intégrité. L'anti répétition est applicable aux SA en envoi individuel aussi bien qu'en diffusion groupée. Cependant, laprésente norme ne spécifie aucun mécanisme pour fournir l'anti répétition pour une SA multi envoyeurs (en envoiindividuel ou en diffusion groupée). En l'absence de négociation (ou configuration manuelle) d'un mécanisme antirépétition pour une telle SA, il est recommandé que l'envoyeur et le receveur vérifient que le numéro de séquence pour laSA est désactivê (via négociation ou configuration manuelle) comme noté ci-dessous.

page - 15 -


Si le receveur n'active pas l'anti répétition pour une SA, aucune vérification d'entrée n'est effectuée sur le numéro deséquence. Cependant, du point de vue de l'envoyeur, on suppose par défaut que l'anti répétition est activée au receveur.Pour éviter que l'envoyeur fasse une surveillance non nécessaire des numéros de séquence et d'établissement de SA (voir leparagraphe 3.3.3) si un protocole d'établissement de SA est employé, le receveur DEVRAIT notifier à l'envoyeur, durantl'établissement de SA, si le receveur ne va pas fournir de protection anti répétition.

Si le receveur a activé le service anti répétition pour cette SA, le compteur de réception de paquets pour la SA DOIT êtreinitialisé à zéro quand la SA est établie. Pour chaque paquet reçu, le receveur DOIT vérifier que le paquet contient unnuméro de séquence qui ne duplique pas le numéro de séquence d'un autre paquet reçu durant la vie de cette SA. CelaDEVRAIT être la première vérification ESP appliquée à un paquet après qu'il a été confronté à une SA, pour accélérer lerejet des paquets dupliqués.

ESP permet une vérification en deux étapes des numéros de séquence des paquets. Cette capacité est importante chaquefois qu'une mise en œuvre ESP (normalement sa portion de module cryptographique) n'est pas capable d'effectuer ledéchiffrement et/ou la vérification d'intégrité au même rythme que la ou les interfaces avec des réseaux non protégés. Si lamise en œuvre est capable d'un tel fonctionnement "au débit de ligne", il n'est alors pas nécessaire d'effectuer l'étape devérification préliminaire décrite ci-dessous.

La vérification préliminaire du numéro de séquence est effectuée en utilisant la valeur de numéro de séquence dans l'en-têteESP et est effectuée avant de vérifier l'intégrité et le déchiffrement. Si cette vérification préliminaire échoue, le paquet estéliminé, évitant donc d'avoir besoin d'aucune opération cryptographique de la part du receveur. Si la vérificationpréliminaire est réussie, le receveur ne peut pas encore modifier son compteur local, parce que l'intégrité du numéro deséquence n'a pas encore été vérifiée à ce moment.

Les dupliqués sont rejetés au moyen d'une fenêtre de réception glissante. Comment la fenêtre est mise en œuvre est uneaffaire locale, mais le texte qui suit décrit la fonctionnalité que doit exhiber la mise en œuvre.

Le bord "droit" de la fenêtre représente la plus haute valeur de numéro de séquence validée reçue sur cette SA. Les paquetsqui contiennent des numéros de séquence inférieurs au bord "gauche" de la fenêtre sont rejetés. Les paquets qui tombentdans la fenêtre sont vérifiés par rapport à une liste de paquets reçus au sein de la fenêtre. Si l'option ESN est choisie pourune SA, seuls les 32 bits de moindre poids du numéro de séquence sont explicitement transmis, mais le receveur emploie lenuméro de séquence complet calculé en utilisant les 32 bits de poids fort pour la SA indiquée (à partir de son compteurlocal) quand il vérifie le numéro de séquence reçu par rapport à la fenêtre de réception. En construisant le numéro deséquence complet, si les 32 bits de moindre poids portés dans le paquet sont inférieurs en valeur aux 32 bits de moindrepoids du numéro de séquence du receveur, le receveur va supposer que les 32 bits de poids fort ont été incrémentés, passantà un nouveau sous espace de numéros de séquence. (Cet algorithme s'accommode de trous de réception pour une seule SAde jusqu'à 2**32-1 paquets. Si un trou plus grand se produit, des vérifications heuristiques supplémentaires pour la re-synchronisation du compteur de numéro de séquence du receveur PEUVENT être employées, comme décrit dansl'Appendice.)

Si le paquet reçu tombe dans la fenêtre et n'est pas un dupliqué, ou si le paquet est à droite de la fenêtre, et si un algorithmed'intégrité séparé est employé, le receveur procède alors à une vérification d'intégrité. Si un algorithme en mode combinéest employé, la vérification d'intégrité est effectuée avec le déchiffrement. Dans l'un et l'autre cas, la vérification d'intégritééchoue, le receveur DOIT éliminer le datagramme IP reçu comme invalide ; c'est un événement susceptible d'un examen.L'entrée d'enregistrement d'audit pour cet événement DEVRAIT inclure la valeur du SPI, la date/heure de réception,l'adresse de source, l'adresse de destination, le numéro de séquence, et (dans IPv6) l'identifiant de flux. La fenêtre deréception n'est mise à jour que si la vérification d'intégrité réussit. (Si un algorithme en mode combiné est utilisé, le numérode séquence protégé en intégrité doit aussi correspondre au numéro de séquence utilisé pour la protection anti répétition.)

Une taille minimum de fenêtre de 32 paquets DOIT être prise en charge quand des numéros de séquence de 32 bits sontemployé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(supérieure au minimum) PEUT être choisie par le receveur. (Le receveur NE notifie PAS à l'envoyeur la taille de fenêtre.)La taille de la fenêtre de réception devrait être augmentée pour les environnements de haut débit, sans considération desquestions d'assurance. Les valeurs pour les tailles minimum et recommandées de fenêtre de réception pour chaque appareilà haut débit (par exemple, plusieurs gigabit/s) ne sont pas spécifiés par la présente norme.

3.4.4 Vérification de la valeur de vérification d’intégrité

Comme avec le processus sortant, il y a plusieurs options pour le traitement entrant, fondées sur les caractéristiques desalgorithmes employés.

page - 16 -


3.4.4.1 Algorithmes séparés de confidentialité et d’intégritéSi des algorithmes sépares de confidentialité et d'intégrité sont employés, le traitement se fait comme suit :

1. Si l'intégrité a été choisie, le receveur calcule la ICV sur le paquet ESP moins l'ICV, en utilisant l'algorithme d'intégritéspécifié et vérifie qu'elle est la même que l'ICV portée dans le paquet. Les détails du calcul sont données ci-dessous.

Si l'ICV calculée et celle reçue correspondent, le datagramme est alors valide, et il est accepté. Si l'essai échoue, le receveurDOIT alors éliminer le datagramme IP reçu comme invalide ; c'est un événement qui peut faire l'objet d'un examen. Lesdonnées enregistrées DEVRAIENT inclure la valeur du SPI, la date/heure de réception, l'adresse de source, l'adresse dedestination, le numéro de séquence, et (pour IPv6) l'identifiant de flux en texte source.

Note de mise en œuvre : Les mises en œuvre peuvent utiliser tout ensemble d'étapes qui résulte en le même résultat quel'ensemble d'étapes suivant. Commencer par retirer et sauvegarder le champ ICV. Vérifier ensuite la longueur totaledu paquet ESP moins le champ ICV. Si un bourrage implicite est requis, sur la base de la taille de bloc del'algorithme d'intégrité, ajouter des octets de zéros à la fin du paquet ESP directement après le champ Prochain en-tête, ou après les 32 bits de poids fort du numéro de séquence si ESN est choisi. Effectuer le calcul d'ICV etcomparer le résultat à la valeur sauvegardée, en utilisant les règles de comparaison définies par la spécification del'algorithme.

2. Le receveur déchiffre les données ESPde charge utile, le bourrage, la longueur de bourrage, et le prochain en-tête enutilisant la clé, l'algorithme de chiffrement, le mode d'algorithme, et les données de synchronisation cryptographique(si il en est) indiqués par la SA. Comme au paragraphe 3.3.2, on parle ici en termes de chiffrement toujours appliqué àcause des implications de formatage. Ceci est fait en comprenant que "pas de confidentialité" est offert en utilisantl'algorithme de chiffrement NUL (RFC 2410).

- Si des données de synchronisation cryptographique explicites, par exemple, une IV, sont indiquées, elles sont tiréesdu champ Charge utile et entrées dans l'algorithme de déchiffrement conformément à la spécification del'algorithme.

- Si des données de synchronisation cryptographique implicites sont indiquées, une version locale de l'IV estconstruite et entrée à l'algorithme de déchiffrement conformément à la spécification de l'algorithme.

3. Le receveur traite tout bourrage comme spécifié dans la spécification de l'algorithme de chiffrement. Si le schéma debourrage par défaut (voir le paragraphe 2.4) a été employé, le receveur DEVRAIT inspecter le champ Bourrage avantde retirer le bourrage et de passer les données déchiffrées à la couche suivante.

4. Le receveur vérifie le champ Prochain en-tête. Si la valeur est "59" (pas de prochain en-tête) le paquet (factice) estéliminé sans autre traitement.

5. Le receveur reconstruit le datagramme IP original à partir :- pour le mode transport -- l'en-tête IP externe plus les informations originales de protocole de prochaine couche dans

le champ Charge utile ESP,- pour le mode tunnel -- le datagramme IP entier dans le champ Charge utile ESP.

Les étapes exactes pour reconstruire le datagramme original dépendent du mode (transport ou tunnel) et sont décrites dansle document d'architecture de sécurité. Au minimum, dans un contexte IPv6, le receveur DEVRAIT s'assurer que lesdonnées déchiffrées sont alignées sur huit octets, pour faciliter le traitement par le protocole identifié dans le champProchain en-tête. Ce traitement "élimine" tout bourrage TFC (facultatif) qui a été ajouté pour la confidentialité du flux detrafic. (Si présent, il aura été inséré après le datagramme IP (ou trame de couche transport) et avant le champ Bourrage(voir le paragraphe 2.4).)

Si les vérifications d'intégrité et de chiffrement sont effectuées en parallèle, la vérification d'intégrité DOIT être achevéeavant que le paquet déchiffré soit passé à la suite du traitement. Cet ordre de traitement facilite une rapide détection et rejetdes paquets répété ou bogués par le receveur, avant de déchiffrer le paquet, réduisant donc potentiellement l'impactd'attaques de déni de service.

Note : Si le receveur effectue le déchiffrement en parallèle à la vérification d'intégrité, il faut faire attention à éviter depossibles conditions de compétition entre l'accès au paquet et l'extraction du paquet déchiffré.

3.4.4.2 Algorithmes combinés de confidentialité et d’intégritéSi un algorithme combiné de confidentialité et d'intégrité est employé, le receveur procède alors comme suit :

1. Il déchiffre et vérifie l'intégrité des données de charge utile ESP, du bourrage, longueur de bourrage, et prochain en-tête, en utilisant la clé, l'algorithme, le mode d'algorithme, et les données de synchronisation cryptographique (si il enest) indiqués par la SA. Le SPI provenant de l'en-tête ESP, et la valeur du compteur de paquets (du receveur) (ajustée

page - 17 -


comme requis par le traitement décrit au paragraphe 3.4.3) sont entrés à cet algorithme, comme ils sont requis pour lavérification d'intégrité.

- Si des données de synchronisation cryptographique explicite, par exemple, une IV, sont indiquées, elle sont prisesdans le champ Charge utile et entrées à l'algorithme de déchiffrement conformément à la spécification del'algorithme.

- Si des données de synchronisation cryptographique implicites, par exemple, une IV, sont indiquées, une versionlocale de l'IV est construite et entrée à l'algorithme de déchiffrement conformément à la spécification del'algorithme.

2. Si la vérification d'intégrité effectuée par l'algorithme en mode combiné échoue, le receveur DOIT éliminer ledatagramme IP reçu comme invalide ; c'est un événement qui peut faire l'objet d'un examen. Les données enregistréesDEVRAIENT inclure la valeur de SPI, la date/heure de réception, l'adresse de source, l'adresse de destination, lenuméro de séquence, et (en IPv6) l'identifiant de flux du texte source.

3. Il traite tous les bourrages comme spécifié dans la spécification de l'algorithme de chiffrement, si cet algorithme ne l'apas déjà fait.

4. Le receveur vérifie le champ Prochain en-tête. Si la valeur est "59" (pas de prochain en-tête) le paquet (factice) estéliminé sans autre traitement.

5. Il extrait le datagramme IP d'origine (mode tunnel) ou la trame de couche transport (mode transport) du champDonnées de charge ESP. Cela élimine implicitement tout bourrage (facultatif) qui aurait été ajouté pour assurer laconfidentialité du flux de trafic. (Si il est présent, le bourrage TFC devra être inséré après la charge utile IP et avant lechamp Bourrage (voir le paragraphe 2.4).)

4. Révision

Tous les systèmes qui mettent en œuvre ESP ne vont pas mettre en œuvre de fonction d'audit. Cependant, si ESP estincorporé dans un système qui prend en charge une telle fonction, la mise en œuvre ESP DOIT alors aussi la prendre encharge et DOIT permettre à l'administrateur de système d'activer ou désactiver l'audit pour ESP. Pour la plus grande part, lagranularité de l'examen est une affaire locale. Cependant, plusieurs événements pouvant faire l'objet d'un examen ont étéidentifiés dans la présente spécification et pour chacun de ces événements un ensemble minimum d'informations quiDEVRAIT être inclus dans un enregistrement d'audit est défini.

- Aucune association de sécurité valide n'existe pour une session. L'entrée d'enregistrement d'audit pour cet événementDEVRAIT inclure la valeur de SPI, la date/heure de réception, l'adresse de source, l'adresse de destination, le numérode séquence, et (pour IPv6) l'identifiant de flux du texte source.

- Un paquet offert à ESP pour traitement paraît être un fragment IP, c’est-à-dire, le champ OFFSET n'est pas zéro ou lefanion Plus de fragments est établi. L'entrée d'enregistrement d'audit pour cet événement DEVRAIT inclure la valeurde SPI, la date/heure de réception, l'adresse de source, l'adresse de destination, le numéro de séquence, et (pour IPv6)l'identifiant de flux.

- Tentative de transmission d'un paquet qui résulterait en débordement de numéro de séquence. L'entrée d'enregistrementd'audit pour cet événement DEVRAIT inclure la valeur de SPI, la date/heure de réception, l'adresse de source, l'adressede destination, le numéro de séquence, et (pour IPv6) l'identifiant de flux du texte source.

- Le paquet reçu échoue aux essais d'anti répétition. L'entrée d'enregistrement d'audit pour cet événement DEVRAITinclure la valeur de SPI, la date/heure de réception, l'adresse de source, l'adresse de destination, le numéro de séquence,et (pour IPv6) l'identifiant de flux.

- La vérification d'intégrité échoue. L'entrée d'enregistrement d'audit pour cet événement DEVRAIT inclure la valeur deSPI, la date/heure de réception, l'adresse de source, l'adresse de destination, le numéro de séquence, et (pour IPv6)l'identifiant de flux.

Des informations supplémentaires PEUVENT aussi être incluses dans l'enregistrement d'audit pour chacun de cesévénements, et des événements supplémentaires, non explicitement invoqués dans la présente spécification, PEUVENTaussi résulter en entrées d'enregistrements d'audit. Il n'est pas exigé que le receveur transmette de message à l'envoyeurprétendu en réponse à la détection d'un événement auditable, à cause du potentiel d'induction d'attaque de déni de servicevia une telle action.

page - 18 -


5. Exigences de conformité

Les mises en œuvre qui revendiquent la conformité à la présente spécification DOIVENT mettre en œuvre la syntaxe ESPet le traitement décrits ici pour le trafic en envoi individuel, et DOIVENT se conformer à toutes les exigencessupplémentaires de traitement de paquet posées par le document d'architecture de sécurité [RFC4301]. De plus, si une miseen œuvre prend en charge le trafic de diffusion groupée, elle DOIT se conformer aux exigences supplémentaires spécifiéespour la prise en charge d'un tel trafic. Si la clé utilisée pour calculer une ICV est distribuée manuellement, la fourniturecorrecte du service anti répétition exige une maintenance correcte de l'état du compteur chez l'envoyeur (à travers lesréamorçages locaux, etc.) jusqu'à ce que la clé soit remplacée, et il est probable qu'il n'y a pas de disposition derécupération automatique si le débordement du compteur est imminent. Donc, une mise en œuvre conforme NE DEVRAITPAS fournir de service anti répétition conjointement avec des SA qui sont chiffrées manuellement.

Les algorithmes de mise en œuvre obligatoire avec ESP sont décrits dans un document séparé [RFC4305], pour faciliter lamise à jour des exigences de l'algorithme indépendamment du protocole lui-même. Des algorithmes supplémentaires, audelà de ceux obligatoires pour ESP, PEUVENT être pris en charge.

Parce que l'utilisation du chiffrement dans ESP est facultative, la prise en charge de l'algorithme de chiffrement "NUL" estaussi exigée pour garder la cohérence avec la façon dont les services ESP sont négociés. La prise en charge de la version deservice de confidentialité de ESP est facultative. Si une mise en œuvre offre ce service, elle DOIT aussi prendre en chargela négociation de l'algorithme d'intégrité "NUL". Noter que bien que intégrité et chiffrement puissent chacun être "NUL"dans les circonstances notées ci-dessus, ils NE DOIVENT PAS être "NUL" tous les deux.

6. Considérations pour la sécurité

La sécurité est centrale pour la conception de ce protocole, et donc les considérations de sécurité imprègnent cettespécification. Des aspects supplémentaires pertinents pour la sécurité de l'utilisation du protocole IPsec sont discutés dansle document d'architecture de sécurité.

7. Différences avec la RFC 2406

Le présent document diffère de la RFC 2406 d'un certain nombre de façons significatives.

o Service de confidentialité seule – maintenant un PEUT, non un DOIT.o SPI – modifié pour spécifier un algorithme uniforme pour la recherche de SAD pour les SA en envoi individuel et en

diffusion groupée, couvrant une gamme plus large de technologies de diffusion groupée. Pour l'envoi individuel, le SPIpeut être utilisé seul pour choisir une SA, ou peut être combiné avec le protocole, au choix du receveur. Pour les SA dediffusion groupée, le SPI est combiné avec l'adresse de destination, et facultativement l'adresse de source, pour choisirune SA.

o Numéro de séquence étendu – ajout d'une nouvelle option pour un numéro de séquence à 64 bits pour lescommunications à très haut débit. Les exigences de traitement de l'envoyeur et du receveur ont été précisées pour lesSA de diffusion groupée et multi envoyeurs.

o Données de charge utile – le modèle a été élargi pour s'accommoder des algorithmes en mode combiné.o Bourrage pour une confidentialité améliorée du flux de trafic – une exigence a été ajoutée pour être capable d'ajouter

des octets après la fin de la charge utile IP, avant le début du champ Bourrage.o Prochain en-tête – ajout d'une exigence pour être capable de générer et éliminer les paquets factices de bourrage

(Prochain en-tête = 59)o ICV – modèle élargi pour s'accommoder des algorithmes en mode combiné.o Algorithmes – Ajout des algorithmes de mode combiné de confidentialité.o Déplacement des références aux algorithmes obligatoires dans un document séparé.o Traitement de paquet entrant et sortant – il y a maintenant deux chemins :

(1) algorithmes séparés de confidentialité et d'intégrité et(2) algorithmes de mode combiné de confidentialité. À cause de l'ajout des algorithmes en mode combiné, les sections

de chiffrement/déchiffrement et d'intégrité ont été combinées pour le traitement des paquets entrants et sortants.

page - 19 -


8. Considérations pour la rétro-compatibilité

Cette caractéristique n'existe pas dans ESP et aucun mécanisme ne permet aux homologues IPsec de découvrir ou négocierquelle version de ESP chacun utilise ou devrait utiliser. Cette section discute des problèmes de rétro-compatibilité qui endécoulent.

D'abord, si aucune des nouvelles caractéristiques disponibles dans ESP v3 n'est employée, le format d'un paquet ESP estalors identique dans ESP v2 et v3. Si un algorithme de chiffrement en mode combiné est employé, caractéristique prise encharge seulement dans ESP v3, le format de paquet résultant peut différer de celui de la spécification ESP v2. Cependant,un homologue qui ne met en œuvre que ESP v2 ne va jamais négocier un tel algorithme, car ils sont définis pour la seuleutilisation dans le contexte ESP v3.

La négociation de numéros de séquence étendus (ESN) est prise en charge par IKE v2 et a été traitée pour IKE v1 parl'Addendum ESN au domaine d'interprétation de IKE v1.

Dans le nouvel ESP (v3), on fait deux dispositions pour mieux prendre en charge la confidentialité des flux de trafic :- bourrage arbitraire après la fin d'un paquet IP- une convention d'élimination qui utilise Prochain en-tête = 59

La première caractéristique ne devrait pas causer de problèmes à un receveur, car le champ Longueur totale IP indique oùse termine le paquet IP. Donc, tous les octets de bourrage TFC après la fin du paquet devraient être retirés à un certain pointdu traitement du paquet IP, après le traitement ESP, même si le logiciel IPsec ne retire pas un tel bourrage. Donc, c'est unecaractéristique ESP v3 qu'un envoyeur peut employer sans considération de si le receveur met en œuvre ESP v2 ou v3.

La seconde caractéristique permet à un envoyeur d'envoyer une charge utile qui est une chaîne arbitraire d'octets qui neconstitue pas nécessairement un paquet IP bien formé, à l'intérieur d'un tunnel, pour les besoins de TFC. La question desavoir ce qu'un receveur ESP v2 va faire avec le champ Prochain en-tête dans un paquet ESP qui contient la valeur "59"reste ouverte. Il peut éliminer le paquet quand il trouve un en-tête IP mal formé, et enregistrer cet événement, mais il nedevrait certainement pas avoir une défaillance, parce que un tel comportement constituerait une vulnérabilité aux attaquesde DoS par rapport au trafic reçu des homologues authentifiés. Donc cette caractéristique est une optimisation qu'unenvoyeur ESP v3 peut utiliser sans considération de si un receveur met en œuvre ESP v2 ou ESP v3.

9. Remerciements

L'auteur tient à remercier de ses contributions Ran Atkinson, qui a joué un rôle éminent dans les activités IPsec initiales, etqui est l'auteur des premières séries des normes IPsec : les RFC 1825 à 1827. Karen Seo mérite des remerciementsparticuliers pour l'aide qu'elle a apportée à l'édition de la présente version de cette spécification ainsi que de la précédente.L'auteur tient aussi à remercier les membres des groupes de travail IPSEC et MSEC qui ont contribué au développement decette spécification de protocole.

10. Références

10.1 Références normatives

[RFC0791] J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2460] S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6) ", décembre 1998. (MàJ par5095, 6564 ; D.S)

[RFC4301] S. Kent et K. Seo, "Architecture de sécurité pour le protocole Internet", décembre 2005. (P.S. ; Remplace laRFC2401)

[RFC4305] D. Eastlake 3rd, "Exigences de mise en œuvre d'algorithme cryptographique pour l'encapsulation de charge utilede sécurité (ESP) et l'en-tête d'authentification (AH)", décembre 2005. (P.S. ; Obsolète, voir RFC4835)

page - 20 -

http://www.rfc-editor.org/rfc/rfc4835.txt



http://abcdrfc.free.fr/rfc-vf/rfc4301.html


http://abcdrfc.free.fr/rfc-vf/pdf/rfc2460.pdf







10.2 Références pour information

[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix UnixSecurity Symposium, juillet 1996.

[Kra01] Krawczyk, H., "The Order of Encryption et Authentication for Protecting Communications (Or: How Secure IsSSL?)", CRYPTO' 2001.

[NIST01] Federal Information Processing Standards Publication 140-2 (FIPS PUB 140-2), "Security Requirements forCryptographic Modules", Information Technology Laboratory, National Institute of Standards et Technology,25 mai 2001.

[RFC3547] M. Baugher, B. Weis, T. Hardjono et H. Harney, "Le domaine d'interprétation de groupe", juillet 2003.(Obsolète, voir la RFC6407)

[RFC3740] T. Hardjono et B. Weis, "Architecture de sécurité de groupe de diffusion groupée", mars 2004.

[RFC4302] S. Kent, "En-tête d'authentification IP", décembre 2005. (P.S.)

[RFC4306] C. Kaufman, "Protocole d'échange de clés sur Internet (IKEv2)", décembre 2005.

[RFC4607] H. Holbrook, B. Cain, "Diffusion groupée spécifique de source pour IP", août 2006. (P.S.)

[Syverson] P. Syverson, D. Goldschlag, et M. Reed, "Anonymous Connections et Onion Routing", Proceedings of theSymposium on Security et Privacy, Oakland, CA, mai 1997, pages 44-54.

Appendice A Numéros de séquence étendus (64 bits)

A1 Généralités

Le présent appendice décrit un schéma de numéro de séquence étendu (ESN) à utiliser avec IPsec (ESP et AH) qui emploieun numéro de séquence à 64 bits, mais dans lequel seuls les 32 bits de moindre poids sont transmis au titre de chaquepaquet. Il couvre à la fois le schéma de fenêtre utilisé pour détecter les paquets répétés et pour déterminer les bits de poidsfort du numéro de séquence qui sont utilisés à la fois pour le rejet des dupliqués et pour le calcul de l'ICV. Il discute aussid'un mécanisme pour traiter la perte de synchronisation relative aux bits de poids fort (non transmis).

A2 Fenêtre anti répétition

Le receveur va tenir une fenêtre anti répétition de taille W. Cette fenêtre va limiter l'importance du déclassement que peutavoir un paquet, par rapport au paquet avec le plus fort numéro de séquence qui a été authentifié jusqu'alors. (Aucuneexigence n'est établie pour des tailles minimum ou recommandées pour cette fenêtre, au delà des valeurs de 32 et 64 parpaquet déjà établies pour la fenêtre de numéro de séquence de 32 bits.Cependant, il est suggéré qu'un développeur évalue ces valeurs par rapport au débit de l'interface prise en charge par unemise en œuvre qui utilise l'option ESN. Aussi, l'algorithme décrit ci-dessous suppose que la fenêtre ne dépasse pas2^31 paquets.) Tous les 2^32 numéros de séquence associés à une valeur fixée pour les 32 bits de poids fort (Seqh) serontci-après appelés un sous espace de numéro de séquence. Le tableau qui suit fait la liste des variables pertinentes et de leurdéfinition.

Nom de variable Taille (bits) SignificationW 32 Taille de fenêtreT 64 Plus grand numéro de séquence authentifié, limite supérieure de fenêtreTl 32 32 bits de moindre poids de TTh 32 32 bits de poids fort de TB 64 Limite inférieure de fenêtreBl 32 32 bits de moindre poids de BBh 32 32 bits de poids fort de BSeq 64 Numéro de séquence du paquet reçuSeql 32 32 bits de moindre poids de SeqSeqh 32 32 bits de poids fort de Seq

page - 21 -












Quand on effectue une vérification anti répétition, ou quand on détermine quels bits de poids fort utiliser pour authentifierun paquet entrant, il y a deux cas :+ Cas A : Tl ≥ (W - 1). Dans ce cas, la fenêtre est dans un seul sous espace de numéro de séquence. (Voir la Figure 1)+ Cas B : Tl < (W - 1). Dans ce cas, la fenêtre s'étend sur deux sous espaces de numéro de séquence. (Voir la Figure 2)

Dans les figures ci-dessous, la ligne du bas ("----") montre deux sous espaces de numéro de séquence consécutifs, avec deszéros pour indiquer le début de chaque sous espace. Les deux lignes plus courtes au dessus d'elle montrent les bits de poidsfort qui s'appliquent. Le "====" représente la fenêtre. Le "****" représente les futurs numéros de séquence, c’est-à-dire,ceux au delà du plus fort numéro de séquence authentifié actuellement (ThTl).

Th+1 *********Th =======***** --0--------+-----+-----0--------+-----------0-- Bl Tl Bl (Bl+2^32) mod 2^32

Figure 1 -- Cas A

Th ====**************Th-1 === --0-----------------+--0--+--------------+--0-- Bl Tl Bl (Bl+2^32) mod 2^32

Figure 2 -- Cas B

A2.1 Gestion et utilisation de la fenêtre anti-répétition

La fenêtre anti répétition peut être vue comme une chaîne de bits où `W' définit la longueur de la chaîne. W = T - B + 1 etne peut pas excéder la valeur de 2^32 - 1. Le bit plancher correspond à B et le bit plafond correspond à T, et chaque numérode séquence de Bl à Tl est représenté par un bit correspondant. La valeur du bit indique si un paquet avec ce numéro deséquence a été reçu ou non et authentifié, de sorte que les répétitions puissent être détectées et rejetées.

Quand un paquet qui a un numéro de séquence (Seq) de 64 bits supérieur à T est reçu et validé,+ B est augmenté de (Seq - T)+ (Seq - T) bits sont éliminés de l'extrémité inférieure de la fenêtre+ (Seq - T) bits sont ajoutés à l'extrémité supérieure de la fenêtre+ le bit plafond est établi pour indiquer qu'un paquet avec ce numéro de séquence a été reçu et authentifié+ les nouveaux bits entre T et le bit plafond sont établis pour indiquer qu'aucun paquet avec ces numéros de séquence n'a

encore été reçu.+ T est réglé au nouveau numéro de séquence

En vérifiant si des paquets sont répétés,+ Dans le cas A :Si Seql ≥ Bl (où Bl = Tl - W + 1) ET Seql ≤ Tl, on vérifie le bit correspondant dans la fenêtre pour voir si ce Seql a déjà étévu. Si oui, rejeter le paquet. Si non, effectuer une vérification d'intégrité (voir le paragraphe A2.2. Sur la détermination deSeqh).

+ Dans le cas B :Si Seql ≥ Bl (où Bl = Tl - W + 1) OU Seql ≥ Tl, on vérifie alors le bit correspondant dans la fenêtre pour voir si ce Seql adéjà été vu. Si oui, rejeter le paquet. Si non, effectuer une vérification d'intégrité (voir le paragraphe A2.2. Sur ladétermination de Seqh).

A2.2 Détermination des bits de poids fort (Seqh) du numéro de séquence

Comme seul `Seql' va être transmis avec le paquet, le receveur doit déduire et tracer le sous espace de numéro de séquencedans lequel chaque paquet entre, c’est-à-dire, déterminer la valeur de Seqh. Les équations suivantes définissent commentchoisir Seqh dans des conditions "normales" ; voir le paragraphe A3 pour une discussion de comment récupérer d'une perteextrême de paquets.

+ Dans le cas A (Figure 1) :

page - 22 -


Si Seql ≥ Bl (où Bl = Tl - W + 1), alors Seqh = ThSi Seql < Bl (où Bl = Tl - W + 1), alors Seqh = Th + 1

+ Dans le cas B (Figure 2) :Si Seql ≥ Bl (où Bl = Tl - W + 1), alors Seqh = Th - 1Si Seql < Bl (où Bl = Tl - W + 1), alors Seqh = Th

A2.3 Exemple de pseudo-code

Le pseudo-code suivant illustre les algorithmes précédents pour les vérifications d'anti répétition et d'intégrité. Les valeurspour `Seql', `Tl', `Th' et `W' sont des entiers non signés de 32 bits. L'arithmétique est mod 2^32.

Si (Tl ≥ W - 1) Cas A Si (Seql ≥ Tl - W + 1) Seqh = Th Si (Seql ≤ Tl) Si (passe la vérification de répétition) Si (passe la vérification d'intégrité) Établir le bit correspondant à Seql Passer le paquet Sinon rejeter le paquet Sinon rejeter le paquet Sinon Si (passe la vérification d'intégrité) Tl = Seql (faire glisser les bits) Établir le bit correspondant à Seql Passer le paquet Sinon rejeter le paquet Sinon Seqh = Th + 1 Si (passe la vérification d'intégrité) Tl = Seql (faire glisser les bits) Th = Th + 1 Établir le bit correspondant à Seql Passer le paquet Sinon rejeter le paquetSinon Cas B Si (Seql ≥ Tl - W + 1) Seqh = Th - 1 Si (passe la vérification de répétition) Si (passe la vérification d'intégrité) Établir le bit correspondant à Seql Passer le paquet Sinon rejeter le paquet Sinon rejeter le paquet Sinon Seqh = Th Si (Seql ≤ Tl) Si (passe la vérification de répétition) Si (passe la vérification d'intégrité) Établir le bit correspondant à Seql Passer le paquet Sinon rejeter le paquet Sinon rejeter le paquet Sinon Si (passe la vérification d'intégrité) Tl = Seql (faire glisser les bits) Établir le bit correspondant à Seql Passer le paquet Sinon rejeter le paquet

page - 23 -


A.3 Traitement de la perte de synchronisation due à une perte de paquet significative

Si il y a une perte de paquets non détectée de 2^32 paquets consécutifs ou plus sur une seule SA, l'émetteur et le receveurvont perdre la synchronisation des bits de poids fort, c’est-à-dire, les équations du paragraphe A2.2 vont échouer à donnerla valeur correcte. Sauf si ce problème est détecté et réglé, les paquets suivants sur cette SA vont échouer àl'authentification et être éliminés. La procédure suivante DEVRAIT être appliquée par toute mise en œuvre IPsec (ESP ouAH) qui prend en charge l'option ESN.

Noter que cette sorte de perte de trafic étendue va probablement être détectée aux couches supérieures dans la plupart descas, avant qu'IPsec doive invoquer le mécanisme de re-synchronisation décrit en A3.1 et A3.2. Si une fraction significativedu trafic sur la SA en question est sur TCP, la source va échouer à recevoir les ACK et va arrêter d'envoyer bien avant que2^32 paquets soient perdus. Aussi, pour toute application bidirectionnelle, même celles qui fonctionnent sur UDP, une tellepanne étendue va probablement résulter en le déclenchement d'une certaine forme de fin de temporisation. Cependant, uneapplication unidirectionnelle, fonctionnant sur UDP, peut manquer des retours qui causeraient une détection automatiqued'une perte de cette ampleur, d'où les motivations pour développer une méthode de récupération pour ce cas.

Noter que les observations ci-dessus s'appliquent aux SA entre passerelles de sécurité, ou entre hôtes, ou entre hôte etpasserelles de sécurité.

La solution choisie a été retenue pour :+ minimiser l'impact sur le traitement du trafic normal,+éviter de créer une opportunité pour une nouvelle attaque de déni de service comme il pourrait se produire si on permet à

un attaquant de forcer un détournement de ressources sur un processus de re-synchronisation,+ limiter le mécanisme de récupération au receveur – parce que l'anti répétition est un service pour le seul receveur, et que

l'émetteur n'est généralement pas au courant de si le receveur utilise les numéros de séquence à l'appui de ce servicefacultatif, il est préférable que les mécanismes de récupération soit locaux chez le receveur. Cela permet aussi la rétrocompatibilité.

A3.1 Déclenchement de la resynchronisation

Pour chaque SA, le receveur enregistre le nombre de paquets consécutifs qui échouent à l'authentification. Ce compte estutilisé pour déclencher le processus de re-synchronisation, qui devrait être effectué en arrière plan, ou en utilisant unprocesseur séparé. La réception d'un paquet valide sur la SA remet le compteur à zéro. La valeur utilisée pour déclencher leprocessus de re-synchronisation est un paramètre local. Il n'est pas exigé de prendre en charge des valeurs dedéclenchement distinctes pour des SA différentes, bien qu'une mise en œuvre puisse choisir de le faire.

A3.2 Processus de resynchronisation

Quand le point de déclenchement ci-dessus est atteint, un "mauvais" paquet est choisi, pour lequel l'authentification estréessayée en utilisant des valeurs successivement supérieures pour la moitié supérieure du numéro de séquence (Seqh). Cesvaleurs sont générées en incrémentant de un chaque essai. Le nombre d'essais devrait être limité, au cas où ce paquetviendrait du "passé" ou serait un paquet bogué. La valeur limite est un paramètre local. (Comme la valeur de Seqh estimplicitement placée après la charge utile ESP (ou AH), il est possible d'optimiser cette procédure en exécutant l'algorithmed'intégrité sur le paquet jusqu'au point de fin de la charge utile, puis de calculer des ICV candidates différentes en variant lavaleur de Seqh.) L'authentification réussie d'un paquet via cette procédure remet le compte des échecs consécutifs à zéro etétablit la valeur de T à celle du paquet reçu.

Cette solution n'exige de soutien que de la part du receveur, permettant par là la rétro compatibilité. Aussi, comme l'effortde re-synchronisation va se produire en arrière plan ou utiliser un autre processeur, cette solution n'impacte pas letraitement du trafic et une attaque de déni de service ne peut pas détourner des ressources du traitement du trafic.

Adresse de l'auteur

Stephen KentBBN Technologies10 Moulton StreetCambridge, MA 02138USAtéléphone : +1 (617) 873-3988mél : [email protected]

page - 24 -

mailto:[email protected]


Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, etsauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations qui y sont contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur,l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNETENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toutegarantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite decommercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelleL’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits quipourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent documentou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle neprétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujetdes droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultatde tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux quimettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF àhttp://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous droits de reproduction, licences ou applications delicence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre enœuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- [email protected].

Remerciement Le financement de la fonction d’édition des RFC est actuellement fourni par l’activité de soutien administratif (IASA) de l’IETF.

page - 25 -

Encapsulation de charge utile de sécurité (ESP) IPabcdrfc.free.fr/rfc-vf/pdf/rfc4303.pdf · RFC...

Documents

Transcript of Encapsulation de charge utile de sécurité (ESP) IPabcdrfc.free.fr/rfc-vf/pdf/rfc4303.pdf · RFC...