¿Por qué algunas implementaciones de traceroute comunes usan por defecto las sondas UDP?

18

Recientemente estaba solucionando un metaproblema de conectividad de red, ya que sabía que se podía llegar a un destino determinado, pero no pude demostrarlo tracerouteporque la ruta se bloqueó después de un cierto número de saltos. Dado que el último salto observado estaba justo aguas arriba del nodo de interés, olfateé el tráfico, esperando confirmar que las sondas lo estaban alcanzando y saber qué regla de filtro los estaba bloqueando. Efectivamente, aprendí que las sondas eran datagramas UDP destinados a un puerto alto (y variable) que, por supuesto, había bloqueado para el tráfico entrante.

Esto me sorprende, porque asumí que todas las traceroutesondas usarían ICMP por defecto, ya que las respuestas son ICMP. Hice una encuesta de documentación y descubrí que diferentes implementaciones toman diferentes decisiones, y algunas no permiten que el usuario realice una selección no predeterminada.

El resumen del método de la sonda Traceroute y la inferencia de la ruta IP hacia adelante respalda mi intuición de que las sondas ICMP con mayor frecuencia lograrán llegar al destino.

Permitir diferentes métodos de sonda parece una gran idea, pero el hecho de no usar ICMP parece una mala idea. ¿Podría alguien describir la justificación de por qué es mejor usar UDP de forma predeterminada?

neirbowj
fuente

Respuestas:

20

La primera versión de traceroutefue escrita por Van Jacobson y usó ICMP pero no funcionó muy bien. La interpretación del proveedor de ICMP en RFC792 fue que los enrutadores no deberían enviar un mensaje de error ICMP en respuesta a un paquete ICMP (consulte las notas de edición a continuación). Por lo tanto, la mayoría de los enrutadores no enviarían un mensaje de "tiempo excedido" en respuesta a una solicitud de eco con un TTL de 1 o 0. Así que lo cambió para usar UDP y lo y he aquí que funcionó muy bien y hubo mucha alegría (y adopción). La tracerouteherramienta en Linux y FreeBSD (y supongo que Cisco) se basa en el trabajo de Van Jacobson.

La especificación se cambió más tarde a "en respuesta a un paquete de error ICMP ". El mundo progresó, los proveedores hicieron cambios en sus pilas permitiendo mensajes de error ICMP en respuesta a solicitudes de eco, y con el aumento de firewalls y ACL, los paquetes UDP perdidos a veces se bloquean, pero la solicitud de eco ICMP podría pasar. Por supuesto, su éxito en eso hoy varía enormemente. Esperaría que las tracertotras herramientas se escribieran en un momento en que el uso de respuestas de eco ICMP no fuera tan problemático.

En estos días no se puede decir que UDP es mejor que ICMP. O que cualquiera de esos es mejor que TCP. Depende completamente de la ruta que esté recorriendo y de las políticas de seguridad vigentes. Es posible que deba probar una, ambas o las tres implementaciones.

Fuentes:

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

Editar :

Cambió RFC de IP (RFC791) a ICMP (RFC792) que dice en la introducción:

Para evitar la regresión infinita de mensajes sobre mensajes, etc., no se envían mensajes ICMP sobre mensajes ICMP.

Ese es el bit que provocó que los proveedores no enviaran errores de "Tiempo excedido" para solicitudes de eco.

RFC1122, Requisitos para hosts de Internet, en la sección 3.2.2. es la actualización que dice que los hosts no deberían responder a los mensajes de error de ICMP .

karyhead
fuente
Para su información, ahora tiene suficiente reputación como para dejar comentarios sobre la pregunta que me envió por correo electrónico
Mike Pennington el
Bien hecho. Me gustó especialmente la historia en el primer enlace sobre la computadora gritando "Ping! Ping! Ping!" en la parte superior de sus pulmones.
neirbowj
Mike, sí, estoy empezando a entender cómo funciona este sitio :-)
karyhead