7. Security Considerations (Considérations de sécurité)
Cette section examine les questions de sécurité soulevées par l'introduction de services différenciés, principalement la possibilité d'attaques par déni de service et la possibilité connexe de vol de service par du trafic non autorisé (Section 7.1). La Section 7.2 traite du fonctionnement des services différenciés en présence d'IPsec, y compris les interactions avec le mode tunnel IPsec et d'autres protocoles de tunneling. Un traitement plus large des préoccupations de sécurité soulevées par l'architecture globale des services différenciés peut être trouvé dans [ARCH].
7.1 Theft and Denial of Service (Vol et déni de service)
L'objectif principal des services différenciés est de permettre de fournir différents niveaux de service aux flux de trafic sur une infrastructure réseau commune. Diverses techniques peuvent être utilisées pour y parvenir, mais le résultat final est que certains paquets reçoivent un service différent (par exemple, meilleur) que les autres. Étant donné que le mappage du trafic réseau aux comportements spécifiques qui en résultent dans un service différent (par exemple, meilleur ou pire) est indiqué principalement par le point de code DS, un adversaire pourrait être en mesure d'obtenir un meilleur service en modifiant les points de code pour indiquer un comportement utilisé pour un service étendu, ou en injectant des paquets avec de telles valeurs de point de code. Poussé à l'extrême, un tel vol de service (theft-of-service) devient une attaque par déni de service (denial-of-service attack) lorsque le trafic modifié ou injecté épuise les ressources disponibles pour transférer ce trafic et d'autres flux de trafic.
La défense contre cette classe d'attaques de vol et de déni de service consiste en une combinaison de conditionnement de trafic aux limites du domaine DS et de sécurité et d'intégrité de l'infrastructure réseau au sein du domaine DS. Les nœuds de limite de domaine DS doivent (MUST) s'assurer que tout le trafic entrant dans le domaine est marqué avec des valeurs de point de code appropriées pour le trafic et le domaine, en re-marquant le trafic avec de nouvelles valeurs de point de code si nécessaire. Ces nœuds de limite DS constituent la ligne de défense principale (primary line of defense) contre les attaques de vol et de déni de service basées sur des points de code modifiés. Le succès d'une telle attaque indique que les points de code utilisés par le trafic attaquant étaient inappropriés. Une instance importante de nœuds de limite est que les nœuds d'origine de trafic dans un domaine DS sont les nœuds de limite initiaux pour ce trafic. Les nœuds internes dans un domaine DS reposent sur les points de code DS pour associer le trafic aux PHB de transmission et ne sont pas tenus (are NOT REQUIRED) de vérifier les valeurs de point de code avant de les utiliser. En conséquence, les nœuds internes reposent sur le fonctionnement correct des nœuds de limite de domaine DS pour empêcher l'arrivée de trafic avec des points de code inappropriés ou de trafic dépassant les niveaux provisionnés (provisioned levels) et perturbant le fonctionnement du domaine.
7.2 IPsec and Tunneling Interactions (Interactions IPsec et tunneling)
Les protocoles IPsec définis dans [ESP, AH] n'incluent pas le champ DS de l'en-tête IP dans leurs calculs cryptographiques (dans le cas du mode tunnel, c'est le champ DS de l'en-tête IP externe qui n'est pas inclus). Par conséquent, la modification du champ DS par les nœuds réseau ne peut pas provoquer l'échec des contrôles d'intégrité IPsec et n'affecte donc pas la sécurité de bout en bout d'IPsec. En conséquence, IPsec ne fournit pas de défense contre la modification du champ DS par un adversaire (c'est-à-dire une attaque de l'homme du milieu, man-in-the-middle attack), précisément parce que la modification par l'adversaire n'affecte pas non plus la sécurité de bout en bout d'IPsec.
Le mode tunnel IPsec fournit une sécurité pour le champ DS de l'en-tête IP encapsulé. Un paquet IPsec en mode tunnel contient deux en-têtes IP: un en-tête externe fourni par le nœud d'entrée du tunnel (tunnel ingress node) et un en-tête interne encapsulé fourni par la source originale du paquet. Lorsqu'un tunnel IPsec est hébergé (en totalité ou en partie) sur un réseau de services différenciés, les nœuds réseau intermédiaires manipulent le champ DS de l'en-tête externe. Au nœud de sortie du tunnel (tunnel egress node), le traitement IPsec comprend la suppression de l'en-tête externe et (si nécessaire) la transmission du paquet en utilisant l'en-tête interne. Les protocoles IPsec exigent (REQUIRES) que ce traitement de décapsulation (decapsulation processing) ne modifie pas le champ DS de l'en-tête interne afin de s'assurer que les modifications du champ DS ne peuvent pas être utilisées pour lancer des attaques de vol ou de déni de service au-delà des points de terminaison du tunnel IPsec. Ce document n'apporte aucun changement à cette exigence. Si l'en-tête IP interne n'a pas été traité par un nœud de limite DS du domaine DS du nœud de sortie du tunnel, alors le nœud de sortie du tunnel est le nœud de limite pour le trafic sortant du tunnel et doit donc (MUST) s'assurer que le trafic résultant a des points de code DS appropriés.
Si le traitement de décapsulation de sortie du tunnel IPsec inclut un contrôle d'intégrité cryptographique suffisamment fort (cryptographic integrity check) du paquet encapsulé (la suffisance est déterminée par la politique de sécurité locale), alors le nœud de sortie du tunnel peut supposer en toute sécurité que le champ DS de l'en-tête interne a la même valeur qu'il avait au nœud d'entrée du tunnel. Un résultat important est que d'autres liaisons non sécurisées dans un domaine DS peuvent être protégées par un tunnel IPsec suffisamment fort. Cette analyse et ses implications s'appliquent à n'importe quel protocole de tunneling qui effectue des contrôles d'intégrité, bien que le niveau d'assurance (level of assurance) du champ DS de l'en-tête interne dépende de la force du contrôle d'intégrité effectué par le protocole de tunneling. En l'absence d'assurance suffisante pour un tunnel qui peut passer par des nœuds en dehors du domaine DS actuel (ou autrement vulnérable, otherwise vulnerable), les paquets encapsulés doivent (MUST) être traités comme s'ils arrivaient à une limite depuis l'extérieur du domaine DS.