1. Introduction
1. Introduction
Ce document suppose que le lecteur est familier avec les termes et concepts décrits dans la "Security Architecture for the Internet Protocol" [Ken-Arch], ci-après appelée le document d'architecture de sécurité. En particulier, le lecteur doit être familier avec les définitions des services de sécurité offerts par l'Encapsulating Security Payload (ESP) et l'IP Authentication Header (AH), le concept de Security Associations, les façons dont ESP peut être utilisé conjointement avec AH, et les différentes options de gestion des clés disponibles pour ESP et AH.
Les mots-clés MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, et OPTIONAL, lorsqu'ils apparaissent dans ce document, doivent être interprétés comme décrit dans la RFC 2119 [Bra97].
L'en-tête Encapsulating Security Payload (ESP) est conçu pour fournir un ensemble de services de sécurité dans IPv4 et IPv6 [DH98]. ESP peut être appliqué seul, en combinaison avec AH [Ken-AH], ou de manière imbriquée (voir le document d'architecture de sécurité [Ken-Arch]). Les services de sécurité peuvent être fournis entre une paire d'hôtes communicants, entre une paire de passerelles de sécurité communicantes, ou entre une passerelle de sécurité et un hôte. Pour plus de détails sur l'utilisation d'ESP et d'AH dans divers environnements réseau, consultez le document d'architecture de sécurité [Ken-Arch].
L'en-tête ESP est inséré après l'en-tête IP et avant l'en-tête du protocole de couche suivante (mode transport) ou avant un en-tête IP encapsulé (mode tunnel). Ces modes sont décrits plus en détail ci-dessous.
ESP peut être utilisé pour fournir la confidentialité, l'authentification de l'origine des données, l'intégrité sans connexion, un service anti-rejeu (une forme d'intégrité partielle de séquence), et une confidentialité (limitée) du flux de trafic. L'ensemble des services fournis dépend des options sélectionnées au moment de l'établissement de la Security Association (SA) et de l'emplacement de l'implémentation dans une topologie réseau.
L'utilisation du chiffrement seul pour la confidentialité est autorisée par ESP. Cependant, il convient de noter qu'en général, cela ne fournira une défense que contre les attaquants passifs. L'utilisation du chiffrement sans un mécanisme d'intégrité fort au-dessus (soit dans ESP, soit séparément via AH) peut rendre le service de confidentialité non sécurisé contre certaines formes d'attaques actives [Bel96, Kra01]. De plus, un service d'intégrité sous-jacent, tel qu'AH, appliqué avant le chiffrement ne protège pas nécessairement la confidentialité en chiffrement seul contre les attaquants actifs [Kra01]. ESP autorise les SA en chiffrement seul car cela peut offrir des performances considérablement meilleures et fournir néanmoins une sécurité adéquate, par exemple, lorsqu'une protection d'authentification/intégrité de couche supérieure est offerte indépendamment. Cependant, cette norme n'exige pas que les implémentations ESP offrent un service en chiffrement seul.
L'authentification de l'origine des données et l'intégrité sans connexion sont des services conjoints, ci-après appelés collectivement "integrity" (intégrité). (Ce terme est employé parce que, sur une base par paquet, le calcul effectué fournit directement l'intégrité sans connexion; l'authentification de l'origine des données est fournie indirectement en résultat de la liaison de la clé utilisée pour vérifier l'intégrité à l'identité du pair IPsec. Typiquement, cette liaison est effectuée par l'utilisation d'une clé symétrique partagée.) L'ESP en intégrité seule DOIT être offert comme option de sélection de service, par exemple, il doit être négociable dans les protocoles de gestion SA et DOIT être configurable via les interfaces de gestion. L'ESP en intégrité seule est une alternative attrayante à AH dans de nombreux contextes, par exemple, parce qu'il est plus rapide à traiter et plus adapté au pipeline dans de nombreuses implémentations.
Bien que la confidentialité et l'intégrité puissent être offertes indépendamment, ESP emploiera typiquement les deux services, c'est-à-dire que les paquets seront protégés en ce qui concerne la confidentialité et l'intégrité. Ainsi, il existe trois combinaisons possibles de services de sécurité ESP impliquant ces services:
- confidentiality-only (confidentialité seule) (PEUT être supporté)
- integrity only (intégrité seule) (DOIT être supporté)
- confidentiality and integrity (confidentialité et intégrité) (DOIT être supporté)
Le service anti-rejeu ne peut être sélectionné pour une SA que si le service d'intégrité est sélectionné pour cette SA. La sélection de ce service est uniquement à la discrétion du récepteur et n'a donc pas besoin d'être négociée. Cependant, pour utiliser la fonctionnalité de numéro de séquence étendu de manière interopérable, ESP impose une exigence aux protocoles de gestion SA de pouvoir négocier cette fonctionnalité (voir la section 2.2.1 ci-dessous).
Le service de confidentialité du flux de trafic (TFC) n'est généralement efficace que si ESP est employé d'une manière qui dissimule les adresses source et destination ultimes des correspondants, par exemple, en mode tunnel entre les passerelles de sécurité, et seulement si un trafic suffisant circule entre les pairs IPsec (soit naturellement, soit en résultat de la génération de trafic de masquage) pour dissimuler les caractéristiques des flux de trafic d'abonnés individuels spécifiques. (ESP peut être employé comme partie d'un système TFC de couche supérieure, par exemple, Onion Routing [Syverson], mais de tels systèmes sont en dehors de la portée de cette norme.) Les nouvelles fonctionnalités TFC présentes dans ESP facilitent la génération et l'élimination efficaces du trafic factice et un meilleur remplissage du trafic réel, de manière rétrocompatible.
La section 7 fournit un bref examen des différences entre ce document et la RFC 2406.