Path MTU discovery

De nombreux équipements — par exemple les routeurs ou les pare-feux — permettent de bloquer tout ou partie du trafic ICMP, soit par défaut, soit à la suite d'une décision d'un administrateur. À cause des nombreuses vulnérabilités existantes liées à ICMP, il est devenu très répandu de considérer ICMP dans son ensemble comme une vulnérabilité, au même titre que Telnet ou rsh. Le filtrage sans aucune distinction de tous les messages ICMP peut pourtant provoquer de graves dysfonctionnements de l'infrastructure réseau.

Si les messages ICMP type 3 / code 4 sont filtrés, la PMTUd échoue. Les hôtes tentant d'effectuer la PMTUd persisteront à envoyer des paquets trop gros qui ne passeront pas et pour lesquels aucun message d'erreur ne parviendra à la source. On dit alors que les paquets sont aspirés dans un « trou noir ».

Ce problème est difficile à résoudre car si le filtrage n'est que partiel, ping ou traceroute peuvent encore fonctionner. De même, des connexions TCP ont pu s'initialiser et, tant qu'aucun gros segment n'est envoyé (par exemple lors de transmissions interactives), fonctionnent sans problème. Le symptôme principal d'un trou noir sera des connexions TCP qui n'effectuent aucun transfert pendant une très longue période.

Le sujet a été longuement abordé depuis de nombreuses années, notamment dans la RFC 1435[7] et la RFC 2923[8]. Au début des années 2000, une initiative avait même été lancée — avec succès — afin d'inciter plusieurs sites web importants agissant comme des trous noirs à corriger ce comportement[9].

Bien que n'importe quel protocole de la couche transport puisse profiter de la PMTUd, par son ubiquité, TCP en est le premier consommateur et par conséquent, il est également le protocole souffrant le plus de ses dysfonctionnements. Pour illustrer ce fait, la RFC 2923[8], intitulée TCP Problems with Path MTU Discovery, est entièrement consacrée aux interactions malheureuses entre TCP et la PMTUd.

À titre d'exemple, l'un des problèmes importants réside dans la relation entre la MTU et la MSS. Ce dernier paramètre indique, dans une transmission TCP, la taille maximale de segment qu'une source est capable de recevoir. De nombreux systèmes se fondent sur le résultat de la PMTUd pour déterminer la valeur de la MSS à annoncer à l'autre extrémité de la connexion. Or plusieurs études[10] ont montré la prépondérance des routes asymétriques sur Internet, ce qui peut impliquer un MTU différent entre le chemin aller et le chemin retour pour une transmission donnée. En utilisant la PMTUd pour déterminer la MSS annoncée, on s'expose ainsi à des performances suboptimales. Bien que cette méthode ne contrevienne pas aux RFC, il est préférable d'utiliser le MTU des interfaces du système comme base de la MSS.

Pour d'autres exemples et des explications plus complètes, se référer à la RFC 2923[8].

Cependant une des solutions utilisées est de limiter la taille maximum d'un segment afin qu'il soit inférieur à celui d'Ethernet (1500 octets). Ainsi vous forcez le correspondant à ne vous envoyer que des segments de maximum 1500 octets. Cette technique, appelée MSS Clamping[11], permet d’éviter d'utiliser le PMTUd.

Le champ associé au MSS Clamping est une option TCP dans un paquet SYN lors de l'initialisation d'une communication entre deux pairs.

Les RFC 1191[1] et RFC 1981[12], décrivant PMTUd pour IPv4 et IPv6 respectivement, abordent au chapitre des considérations de sécurité plusieurs attaques possibles. La plus sérieuse est déni de service à faible volume consistant pour l'attaquant à se faire passer pour le destinataire d'une connexion légitime avec la victime. L'attaquant envoie alors à la victime des messages ICMP déclenchant le processus de PMTUd, entraînant une réduction de la taille des paquets jusqu'au MTU minimum du protocole (68 octets en IPv4, 1280 octets en IPv6, comprenant en-tête IP et données). Les RFC recommandent d'attendre dix minutes avant de tenter à nouveau une phase de PMTUd destinée à augmenter la taille des paquets. Il suffit donc à l'attaque d'envoyer un message ICMP forgé à la victime toutes les dix minutes seulement.

Le débit est certes réduit de façon très significative mais l'impact réel se trouve ailleurs. Pour conserver le même débit, la victime devra envoyer énormément de paquets de taille réduite ce qui entraînera une tempête d'interruptions sur tous les équipements le long de la transmission et plus particulièrement sur la victime. Sous l'effet de la surcharge, la machine peut alors cesser complètement de répondre, surtout si l'attaque a été répétée à plusieurs connexions.

En 2005, Fernando Gont introduit plusieurs attaques contre TCP utilisant les messages d'erreur ICMP[13] dont celle décrite ci-dessus. Pour y remédier, il propose de séparer PMTUd en deux parties: Initial Path-MTU et Path-MTU Update. Il propose également d'ajouter de nouvelles variables d'état à TCP: maxsizesent, la taille du plus gros paquet envoyé, et maxsizeacked, la taille du plus gros paquet reçu.

L'Initial Path-MTU est la phase en début de connexion où TCP n'a aucune connaissance du MTU. Path-MTU Update est la phase pendant la transmission où TCP a déjà une connaissance du MTU et doit donc être plus prudent quant aux messages ICMP reçus. Lors de la réception d'un message ICMP impliquant en temps normal un ajustement du MTU, de nouvelles vérifications sont introduites :

• Si le MTU annoncé par le message ICMP comme dépassé est supérieur à maxsizesent, le message ICMP est ignoré.
• Si le MTU annoncé par le message ICMP comme dépassé est supérieur ou égal à maxsizeacked, le message ICMP est pris en compte et le MTU ajusté. Nous sommes en Initial Path-MTU.
• Si le MTU annoncé par le message ICMP comme dépassé est inférieur à maxsizeacked, le message ICMP est juste noté et l'ajustement du MTU est retardé. Si un acquittement de segment TCP arrive pendant ce délai d'ajustement, le message ICMP est ignoré, sinon il est pris en compte et le MTU ajusté.

Le délai avant ajustement est fonction du nombre de fois qu'un segment TCP particulier a dépassé le délai de retransmission (RTO). Plusieurs segments retransmis sans résultat est en effet une métrique classique qu'utilise TCP pour détecter un problème dans la transmission.

Cette solution est implémentée par NetBSD et OpenBSD depuis 2005.