Pourquoi certaines implémentations traceroute courantes utilisent-elles par défaut des sondes UDP?

J'étais récemment en train de dépanner un méta-problème de connectivité réseau, en ce sens que je savais qu'une destination donnée était accessible, mais je n'ai pas pu le démontrer avec traceroutecar le chemin s'est refroidi après un certain nombre de sauts. Étant donné que le dernier saut observé était juste en amont du nœud d'intérêt, j'ai reniflé le trafic, m'attendant à confirmer que les sondes l'atteignaient et à savoir quelle règle de filtrage les bloquait. Effectivement, j'ai appris que les sondes étaient des datagrammes UDP destinés à un port élevé (et variable) que j'avais, bien sûr, bloqué pour le trafic entrant.

Cela me surprend, car j'ai supposé que toutes les traceroutesondes seraient par défaut sur ICMP, car les réponses sont ICMP. J'ai fait une enquête de documentation et j'ai constaté que différentes implémentations font des choix différents, et certaines ne permettent pas à l'utilisateur de faire une sélection non par défaut.

• UDP
  • Cisco
  • Linux
  • FreeBSD
• ICMP
  • Genévrier
  • Brocart
  • les fenêtres

L'abrégé de la méthode de sonde Traceroute et l'inférence de chemin IP vers l'avant confirme mon intuition que les sondes ICMP réussiront plus souvent à atteindre la destination.

Autoriser différentes méthodes de sonde semble être une excellente idée, mais le fait de choisir par défaut autre chose que ICMP semble être une mauvaise idée. Quelqu'un pourrait-il expliquer pourquoi il est préférable d'utiliser UDP par défaut?

La première version de a tracerouteété écrite par Van Jacobson et utilisait ICMP mais cela ne fonctionnait pas très bien. L'interprétation du fournisseur d'ICMP dans la RFC792 était que les routeurs ne devraient pas envoyer de message d'erreur ICMP en réponse à un paquet ICMP (voir les notes d'édition ci-dessous). Par conséquent, la plupart des routeurs n'enverraient pas de message de "dépassement de temps" en réponse à une demande d'écho avec un TTL de 1 ou 0. Il l'a donc changé pour utiliser UDP et voilà, cela fonctionnait très bien et il y avait beaucoup de réjouissances (et d'adoption). L' tracerouteoutil sur Linux et FreeBSD (et je suppose que Cisco) est basé sur le travail de Van Jacobson.

La spécification a ensuite été remplacée par «en réponse à un paquet d' erreur ICMP ». Le monde a progressé, les fournisseurs ont modifié leurs piles en autorisant les messages d'erreur ICMP en réponse aux demandes d'écho, et avec la montée des pare-feu et des listes de contrôle d'accès, les paquets UDP errants sont parfois bloqués, mais la demande d'écho ICMP pourrait passer. Bien sûr, votre succès à ce jour varie énormément. Je m'attendrais à ce que les tracertautres outils aient été écrits à un moment où l'utilisation des réponses d'écho ICMP n'était pas si problématique.

De nos jours, on ne peut pas vraiment dire qu'UDP est meilleur qu'ICMP. Ou que l'un ou l'autre est meilleur que TCP. Cela dépend complètement du chemin que vous traversez et des politiques de sécurité en place. Vous devrez peut-être essayer une, les deux ou les trois implémentations.

Sources:

http://ftp.arl.army.mil/~mike/ping.html http://www.inetdaemon.com/tutorials/troubleshooting/tools/traceroute/definition.shtml

Modifier :

RFC changé d'IP (RFC791) en ICMP (RFC792) qui dit dans l'intro:

Pour éviter la régression infinie des messages sur les messages, etc., aucun message ICMP n'est envoyé sur les messages ICMP.

C'est le bit qui a amené les fournisseurs à ne pas envoyer d'erreurs "Time Exceeded" pour les demandes d'écho.

RFC1122, Configuration requise pour les hôtes Internet, dans la section 3.2.2. est la mise à jour qui dit que les hôtes ne doivent pas répondre aux messages d' erreur ICMP .