1. Introduction

Ce document suppose que le lecteur est familier avec les termes et concepts décrits dans "Security Architecture for the Internet Protocol" [Ken-Arch], ci-après dénommé le document Security Architecture. En particulier, le lecteur doit être familier avec les définitions des services de sécurité offerts par l'Encapsulating Security Payload (ESP) [Ken-ESP] et l'IP Authentication Header (AH), le concept d'associations de sécurité, les façons dont ESP peut être utilisé conjointement avec l'Authentication Header (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 d'authentification IP (AH) est utilisé pour fournir une intégrité sans connexion et une authentification de l'origine des données pour les datagrammes IP (ci-après dénommés simplement "intégrité") et pour fournir une protection contre les rejeux. Ce dernier service, optionnel, peut être sélectionné par le récepteur lors de l'établissement d'une association de sécurité (SA). (Le protocole par défaut exige que l'émetteur incrémente le numéro de séquence utilisé pour l'anti-rejeu, mais le service n'est effectif que si le récepteur vérifie le numéro de séquence.) Cependant, pour utiliser la fonctionnalité de numéro de séquence étendu de manière interopérable, AH impose une exigence aux protocoles de gestion de SA pour pouvoir négocier cette nouvelle fonctionnalité (voir section 2.5.1 ci-dessous).

AH fournit une authentification pour autant que possible de l'en-tête IP, ainsi que pour les données du protocole de niveau supérieur. Cependant, certains champs d'en-tête IP peuvent changer en transit et la valeur de ces champs, lorsque le paquet arrive au récepteur, peut ne pas être prévisible par l'émetteur. Les valeurs de tels champs ne peuvent pas être protégées par AH. Ainsi, la protection fournie à l'en-tête IP par AH est fragmentaire. (Voir Annexe A.)

AH peut être appliqué seul, en combinaison avec l'IP Encapsulating Security Payload (ESP) [Ken-ESP], ou de manière imbriquée (voir le document Security Architecture [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. ESP peut être utilisé pour fournir les mêmes services anti-rejeu et d'intégrité similaires, et il fournit également un service de confidentialité (chiffrement). La principale différence entre l'intégrité fournie par ESP et AH est l'étendue de la couverture. Plus précisément, ESP ne protège aucun champ d'en-tête IP à moins que ces champs ne soient encapsulés par ESP (par exemple, via l'utilisation du mode tunnel). Pour plus de détails sur la façon d'utiliser AH et ESP dans divers environnements réseau, voir le document Security Architecture [Ken-Arch].

La section 7 fournit un bref examen des différences entre ce document et la RFC 2402 [RFC2402].