Path MTU discovery

Path MTU discovery (PMTUd) est une technique permettant de déterminer, dans un réseau informatique, la taille du MTU sur le chemin entre deux hôtes IP, afin d'éviter la fragmentation des paquets. Il est défini pour ICMP par le RFC 1191[1] et pour ICMPv6 par la RFC 8201[2].

La fragmentation IP affecte en effet les performances[3],[4] des routeurs et pose de plus des problèmes de sécurité[5],[6].

Fonctionnement

La découverte du MTU d'un chemin donné fonctionne en positionnant le bit DF (Don't Fragment) de l'en-tête IP sur tous les paquets sortants. Le long du chemin emprunté par un tel paquet, si l'un des hôtes traversés a un MTU plus petit que la taille du paquet, ce dernier sera rejeté et un message ICMP, contenant le MTU de l'hôte qui le génère, sera envoyé afin d'informer la source. Ce message est :

  • type 3 / code 4, "Destination Unreachable" / "Fragmentation Needed and Don't Fragment was Set" en ICMP
  • type 2 / code 0, "Packet Too Big" en ICMPv6.

La source adapte alors la taille du prochain paquet en fonction du MTU reçu dans le message ICMP. Le processus est répété jusqu'à ce que la source parvienne à atteindre la destination.

Si le MTU du chemin change après que la connexion a été établie et se trouve être plus petit que celui déterminé précédemment, le premier paquet trop grand à emprunter le chemin causera l'envoi d'un nouveau message ICMP, relançant le processus de PMTUD. De même, durant la connexion, la source peut périodiquement resonder le chemin pour découvrir si celui-ci permet désormais un MTU plus grand.

Bien que rares, ces cas de figure peuvent être provoqués par des changements de route, dus aux protocoles de routage dynamiques ou à une intervention humaine sur le réseau.

Problèmes

Malgré son utilité, la PMTUd souffre d'un certain nombre de problèmes, pour la plupart liés à des contraintes de sécurité mais également, parfois, à son effet sur les performances des transmissions sur Internet.

Filtrage par des équipements intermédiaires

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].

Interactions avec TCP

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.

Risques pour la sécurité

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.

Implémentations

La PMTUd fait partie des standards de l'IETF. Un hôte implémentant correctement ICMP supporte la PMTUd. Les compteurs utilisés peuvent par contre varier d'un système d'exploitation à l'autre.

Les RFC 1191[1] et RFC 1981[12] imposent que la PMTUd ne doit pas avoir lieu moins de 5 minutes ou plus de 1 minute après qu'un message ICMP a été reçu. Il est recommandé d'utiliser ces valeurs multipliées par deux (soit 10 et 2 minutes) lors des implémentations[14].

Linux et FreeBSD suivent cette recommandation.

Liens externes

Notes
  1. (en) Request for comments no 1191.
  2. (en) Request for comments no 8201.
  3. Voir J. Heffner, M. Mathis, B. Chandler, IPv4 Reassembly Errors at High Data Rates
  4. Voir Christopher A. Kent, Jeffrey C. Mogul, Fragmentation Considered Harmful
  5. Voir Tim Newsham, Thomas Ptacek, Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection
  6. Voir Michal Zalewski, A new TCP/IP blind injection technique ?
  7. (en) Request for comments no 1435.
  8. (en) Request for comments no 2923.
  9. Voir MSS Initiative
  10. Voir Vern Paxson, End-to-end Routing Behavior in the Internet.
  11. Voir Linux Advanced Routing & Traffic Control HOWTO (english)
  12. (en) Request for comments no 1981.
  13. Voir Fernando Gont, ICMP attacks against TCP, section 7
  14. Voir J. Mogul et S. Deering, Path MTU discovery - Host specification
  • Portail de l’informatique
  • Portail des télécommunications
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.