UNIVERSIDAD DE CUENCA FACULTAD DE INGENIERÍA ESCUELA DE INFORMÁTICA REDES DE COMPUTADORES 1 PRÁCTICA 7: 7: ANÁLISIS DEL PROTOCOLO IP CON WIRESHARK NOMBRES: ANGEL OSWALDO VÁZQUEZ PATIÑO NOTA: ______________ ______________ INTRODUCCIÓN Antes de comenzar con esta práctica, es necesario revisar la sección 3.4 del RFC 2151 que puede ser obtenido de http://www.ietf.org/rfc/rfc2151.txt para familiarizarse con la operación del programa traceroute. También se debe revisar el RFC 791 disponible en http://www.ietf.org/rfc/rfc791.txt para una discusión del protocolo IP. Haga un resumen de estas secciones antes de iniciar con la práctica. Resumen Internet Protocol (Protocolo Internet IP, RFC 791) Este protocolo está diseñado para su uso en sistemas interconectados de redes de comunicación por intercambio de paquetes. IP proporciona los medios para la transmisión de bloques de datos (datagramas) desde el origen al destino, donde origen y destino son hosts identificados por direcciones de longitud fija. f ija. Este protocolo es utilizado por protocolos host-a-host en un entorno de internet, además utiliza a su vez protocolos de red locales para llevar el datagrama internet a la puerta de enlace o host de destino. Operación IP implementa dos funciones básicas: 1. Direccionamiento, y 2. Fragmentación. Los módulos internet usan las direcciones que se encuentran en la cabecera internet para transmitir los datagramas hacia sus destinos, también, para fragmentar y re ensamblar los datagramas internet cuando sea necesario para su transmisión a través de redes de "trama pequeña". La selección de un camino para la transmisión se llama encaminamiento. Además trata cada datagrama internet como una entidad independiente no relacionada con ningún otro datagrama internet. El protocolo internet utiliza cuatro mecanismos clave para prestar su servicio: Tipo de Servicio.- se utiliza para indicar la calidad del servicio deseado.
Tiempo de Vida.- es una indicación de un límite superior en el período de vida de un datagrama internet. Es fijado por el remitente del datagrama y reducido en los puntos a lo largo de la ruta donde es procesado. Opciones.- proporcionan funciones de control control útiles en algunas situaciones. Las opciones incluyen recursos para marcas de tiempo, seguridad y encaminamiento especial. Checksum de Cabecera.- proporciona una verificación de que la información utilizada al procesar el datagrama internet ha sido sido transmitida correctamente. correctamente. Si esta falla, el datagrama internet es descartado inmediatamente por la entidad que detecta el error. El protocolo internet no proporciona ningún mecanismo de comunicación fiable. No existen acuses de recibo ni entre extremos ni entre entre saltos No hay control de errores para los datos, sólo una suma de control de cabecera. No hay retransmisiones. No existe control de flujo. Formato de la cabecera IP.
Resumen del RFC 2151 la Sección Traceroute Traceroute es otra herramienta común de TCP/IP, esta permite a los usuarios aprender sobre la ruta que los paquetes toman desde su máquina local a un host remoto. Aunque a menudo utilizado por la red y los administradores de los sistemas como una simple, pero potente, la l a herramienta de depuración, traceroute puede ser usado por los usuarios finales para aprender algo acerca de la l a siempre cambiante estructura de la Internet. Traceroute tiene el siguiente formato general (donde "#" representa representa un valor valor positivo asociado con el índice): traceroute [-m #] [-q #] [-w #] [-p #] (dirección_IP | host_name) Dónde •
• •
•
m: valor máximo TTL permitido, medida como el número de saltos permitido antes de que el programa termina (por defecto = 30). q: número de paquetes UDP que se enviará con cada time-to-live (por defecto 3). w: cantidad de tiempo, en segundos, que espera a que una respuesta de un router antes de darse por vencido (por defecto 5). p: dirección de puerto puerto no válido en el el host remoto (default = 33434). 33434).
La versión original de Traceroute funciona mediante el envío de una secuencia de datagramas UDP a un puerto de dirección no válido en un host remoto. Usando la
configuración por defecto, tres datagramas son enviados, cada uno con un valor de campo time-to-Live (TTL) de 1. El valor TTL de 1 provoca que el datagrama a "timeout" tan pronto como éste llegue l legue al primer Router en la ruta de acceso; este Router responderá con un mensaje ICMP de tiempo excedido (TEM) que indica que el datagrama ha caducado. Otros tres mensajes UDP se envían, cada uno con el valor TTL de 2, lo que provoca que el segundo Router devuelva ICMP. TEMs. Este proceso continúa hasta que los paquetes realmente lleguen al otro destino. Dado que estos datagramas están intentando acceder a una dirección de puerto de host destino no válido, ICMP (Destination Unreachable Messages). Los mensajes se devuelven indicando un puerto inalcanzable; este evento señala que el programa Traceroute se acabó. Traceroute no comenzó la vida como para fines generales de utilidad, sino como una rápida y sucia depuración utilizado la ayuda para encontrar un problema de enrutamiento. OBJETIVOS DE LA PRÁCTICA • Esta práctica investigará el protocolo IP, haciendo énfasis en el datagrama IP. Para ello se procederá a analizar una traza de datagramas IP enviados y recibidos mediante la ejecución del programa traceroute. • Se investigarán los campos del datagrama IP, y se estudiará fragmentación IP en detalle. PROCEDIMIENTO Paso 1. Captura de paquetes de una ejecución de traceroute Para generar una traza de datagramas IP para la práctica, se empleará el programa traceroute para enviar datagramas de diferentes tamaños hacia algún destino, XYZ. Traceroute opera enviando primero uno o más datagramas con el campo time-to-live (TTL) en el header IP establecido a 1; luego envía una serie de uno o más datagramas hacia el mismo destino con un TTL con valor 2; luego envía una serie de datagramas hacia el mismo destino con un TTL con valor 3; y así sucesivamente. sucesivamente. Recuerde que un enrutador debe reducir en 1 el TTL en cada datagrama recibido (en realidad, el RFC 791 dice que el enrutador debe reducir el TTL por lo menos en uno). Si el TTL llega a cero (0), el enrutador retorna un mensaje ICMP (type 11 – TTLexceeded) al host emisor. Como resultado de este comportamiento, un datagrama con un TTL de 1 (enviado por el host que ejecuta traceroute) ocasionará que el enrutador que está a un salto de distancia desde el emisor envíe un mensaje ICMP TTL-exceeded al emisor; el datagrama enviado con un TTL de 2 ocasionará que el enrutador que se encuentra a dos saltos de distancia envíe un mensaje ICMP al emisor; el datagrama enviado con un TTL de 3 hará que el enrutador a una distancia de tres saltos envíe un mensaje ICMP al emisor; y así sucesivamente.
De esta manera, el host que está ejecutando traceroute puede aprender aprender las identidades de los enrutadores entre el mismo y el destino XYZ mirando a las direcciones IP origen en los datagramas que contienen los l os mensajes ICMP TTL-exceeded. Deberá ejecutar traceroute y hacer que envíe datagramas de varias longitudes. El programa tracert incluido en el sistema Microsoft Windows no permite cambiar el tamaño del ICMP de requerimiento de eco enviado por el programa.
Un mejor programa para trazar rutas que funciona en Windows es pingplotter. Descárguelo desde http://www.pingplotter.com e instálelo.
Haga pruebas ejecutando algunos trazados de rutas a algún sitio de su preferencia.
El tamaño del mensaje de requerimiento de eco ICMP puede ser explícitamente establecido en pingplotter seleccionando el ítem de menú Edit->Advanced Options>Packet Options y luego llenando el campo Packet Size.
El tamaño de paquete por defecto es 56 bytes. Una vez que pingplotter ha enviado una serie de paquetes con valores crecientes para TTL, reinicia el proceso de envío de nuevo con un TTL de 1, después de esperar la cantidad de tiempo Trace Interval. El valor de Trace Interval y el número de intervalos puede ser establecido explícitamente en pingplotter. Haga lo siguiente: • Inicie Wireshark, comience la captura de paquetes (Capture->Start) y luego presione OK en la pantalla Ethereal Packet Capture Options (no necesita seleccionar ninguna opción aquí).
• Inicie pingplotter e ingrese el nombre de un destino en la ventana Address to Trace, ponga 3 en el campo # of times to trace, así no reúne demasiados datos. Seleccione el ítem de menú Edit- >Advanced Options->Packet Options y entre un valor de 56 en el
campo Packet Size y luego presione OK. Luego presione el botón Trace. Usted verá una ventana de pingplotter como la siguiente:
A continuación, envíe un conjunto de datagramas con mayor longitud, seleccionando Edit ->Options->Packet e ingrese un valor de 2000 en el campo Packet Size y luego presione OK. Luego presione el botón Resume.
Finalmente, envíe un conjunto de datagramas con una longitud mayor, seleccionando Edit ->Options -> Packet y entre un valor de 3500 en el campo Packet Size y luego presione OK. Luego presione el botón Resume.
Detenga el trazado con Wireshark.
Paso 2. Inspección del trazado capturado
En el trazado capturado, se debería observar la serie de ICMP Echo Request (en el caso de un computador con Microsoft Windows) o el segmento UDP (en el caso de un computador con Linux/Unix) enviado por su computadora y los mensajes ICMP TTL exceeded retornados a su computadora por los enrutadores intermedios. En las preguntas que siguen, se asume que está usando un computador con el sistema Microsoft Windows; las preguntas correspondientes para el caso de un computador con Linux/Unix deberían ser claras. Si es posible, cuando responda las preguntas tenga a mano un listado impreso de los paquetes dentro del trazado que usó para responder la pregunta. Para imprimir un paquete, use File->Print, elija Selected packet only, elija Packet summary line, y seleccione la mínima cantidad de detalles del paquete que sea necesaria para responder la pregunta. 1. Seleccione el primer mensaje ICMP Echo Request enviado por su computadora, y expanda la parte Internet Protocol del paquete en la ventana packet details.
¿Cuál es la dirección IP de su computadora? La dirección IP es: es : 172.31.9.133 2. Dentro de la cabecera (header) del paquete IP, ¿cuál es el valor en el campo upper layer protocol?
El valor de ICMP 0x01 (en hexadecimal). 3. ¿Cuántos bytes hay en la cabecera (header) IP? ¿Cuántos bytes hay en el payload del datagrama IP? Explique cómo determinó el número de bytes de payload.
En la cabecera IP hay 20 bytes.
En el payload del datagrama IP hay 28 bytes. Explique cómo determinó el número de bytes de payload. El número de bytes de payload es la información útil del mensaje, el cual estaba indicado en la cabecera. 4. ¿Ha sido fragmentado este datagrama IP? Explique cómo determinó si el datagrama fue o no fragmentado. El paquete IP no ha sido fragmentado, porque en el campo Flags (More fragments) tenemos Not set; y en Fragment offset está 0 (cero), entonces el datagrama IP no ha sido fragmentado.
A continuación, ordene los paquetes trazados de acuerdo a la dirección IP origen haciendo click en la cabecera de la columna Source; al lado de la palabra Source hay una pequeña punta de flecha. Si la flecha apunta hacia arriba, haga click otra vez en la cabecera de columna Source. Seleccione el primer mensaje ICMP Echo Request enviado por su computadora, y expanda la porción Internet Protocol en la ventana “details of selected packet header”. En la ventana “listing of captured packets”, debería ver todos los subsecuentes mensajes ICMP (quizás con paquetes adicionales intercalados enviados por otros protocolos que están ejecutándose en su computadora) después del primer ICMP. Use la tecla con flecha hacia abajo para moverse a través de los mensajes ICMP enviados por su computadora. 5. ¿Cuáles campos en el datagrama IP siempre cambian de un datagrama al próximo dentro de esta serie de mensajes ICMP enviados por su computadora? En primer lugar obviamente cambia el valor de Frame. Cambia el valor de Identification, el valor de checksum y el número de secuencia. 6. ¿Cuáles campos permanecen constantes? ¿Cuáles de los campos deben permanecer constantes? ¿Cuáles campos deben cambiar? ¿Por qué? Los campos que permanecen constantes: Header Length, Total Length, Protocol.
Donde: Type Especifica el tipo del mensaje: 0 3 4 5 8 9 10 11 12 13 14 15 16 17 18
Echo reply Destination unreachable Source quench Redirect Echo Router Advertisement Router Solicitation Time exceeded Parameter Problem Timestamp request Timestamp reply Information request(obsolete) Information reply(obsolete) Adress mask request Adress mask reply
Code Contiene el código de error para el datagrama del que da parte el mensaje ICMP. La interpretación depende del tipo de mensaje. Checksum Contiene el complemento a 1 de 16 bits de la suma del "ICMP message starting with the ICMP Type field". Data Contiene información para el mensaje ICMP. Los campos que deben cambiar: El campo Type el valor TTL, porque el Protocolo de Mensajes de Control y Error de Internet, ICMP, que es de características similares a UDP, pero con un formato mucho más simple, y su utilidad no está en el transporte de datos de usuario, sino en controlar si un paquete no puede alcanzar su destino, si su vida ha expirado, si el encabezamiento lleva un valor no permitido, si es un paquete de eco o respuesta, etc. Es decir, se usa para manejar mensajes de error y de control necesarios para los sistemas de la red, informando con ellos a la fuente original para que evite o corrija el problema detectado. ICMP proporciona así una comunicación entre el software IP de una máquina y el mismo software en otra.
7. Describa el modelo que ve en los valores en el campo Identification del datagrama IP. Luego (con los paquetes aún ordenados por source address) encuentre la serie de respuestas ICMP TTL exceeded enviadas a su computadora por el primer enrutador (primer salto). Identificador: Identificador: numero de secuencia. Es el mismo para todos los datagramas generados al segmentar e igual al del datagrama original. Con el primer mensaje ICMP tenemos en el campo Identification en hexadecimal 0x2b90 (en decimal 11152):
En el siguiente mensaje tenemos en el campo Identification en hexadecimal 0x2b91 (en decimal 11153):
Como vemos es un campo que tiene un número en secuencia. La serie de respuestas ICMP TTL exceeded enviadas a su computadora por el primer enrutador (primer salto) son:
8. ¿Cuál es el valor en el campo Identification y el campo TTL? Teniendo en cuenta el gráfico anterior vemos que en el primer mensaje ICMP TTL exceeded enviado al computador tenemos: Identification: 0x228b (8843)
Time to Live (TTL): 40 9. Estos valores, ¿permanecen inalterados para todas las respuestas ICMP TTL exceded enviadas a su computadora por el enrutador más cercano (primer salto)? ¿Por qué? En cuanto al campo Identification, este cambia porque es el número de secuencias de los mensajes (como se explica al comienzo de esta práctica). Por otra parte el campo TTL tienen que cambiar, por la siguiente razón: Los datagramas IP tienen un campo TTL (tiempo de vida) que impide que un mensaje esté dando vueltas indefinidamente por la red de redes. El número contenido en este campo disminuye en una unidad cada vez que el datagrama atraviesa un router. Cuando el TTL de un datagrama llega a 0, éste se descarta y se envía un mensaje ICMP de tipo 11 (Time Exceeded) para informar al origen. Los mensajes ICMP de tipo 11 se pueden utilizar para hacer una traza del camino que siguen los datagramas hasta llegar a su destino. ¿Cómo? Enviando una secuencia de datagramas con TTL=1, TTL=2, TTL=3, TTL=4, etc.... hasta alcanzar el host o superar el límite de saltos (30 si no se indica lo contrario). El primer datagrama caducará al atravesar el primer router y se devolverá un mensaje ICMP de tipo 11 informando al origen del router que descartó el datagrama. El segundo datagrama hará lo propio con el segundo router y así sucesivamente. Los mensajes ICMP recibidos permiten definir la traza. Paso 3. Fragmentación Ordene el listado de paquetes en función del tiempo haciendo clic en la columna Time.
10. Encuentre el primer mensaje ICMP Echo Request que fue enviado por su computadora después que cambió el tamaño del paquete a 2000 bytes. Dicho mensaje, ¿ha sido fragmentado a través de más de un datagrama IP? Sí, este mensaje ha sido fragmentado, observe el campo Flags tenemos More fragments: set.
11. Imprima el primer fragmento del datagrama IP fragmentado. ¿Qué información en la cabecera (header) de IP indica que el datagrama ha sido fragmentado? ¿Qué información en la cabecera (header) IP indica si este es el primer fragmento versus el último fragmento? ¿Cuál es la longitud de este datagrama IP?
El campo Fragment offset: 1480; indica que el datagrama ha sido fragmentado. Número de byte del datagrama (sí ha sido fragmentado). Si está en cero entonces no ha sido fragmentado. Los Flags son los siguientes O, DT Y MF:
El único que nos va a interesar es MF. Éste se pone a ´0´ si el datagrama es el último fragmento de una segmentación. En caso contrario estará a ´1´ La longitud del datagrama IP es de 520 bytes. 12. Imprima el segundo fragmento del datagrama IP fragmentado. ¿Qué información en la cabecera (header) IP indica que este no es el primer fragmento del datagrama? ¿Hay más fragmentos? ¿En base a qué puede decirlo?
En Flags el campo More fragments está en 0 (cero), indica que este no es el primer fragmento del datagrama. No hay más fragmentos de este mismo paquete IP, porque en Flags el campo More fragments está como Not set. 13. ¿Qué campos cambian en la cabecera (header) IP entre el primer y segundo fragmento? Ahora encuentre el primer mensaje ICMP Echo Request que fue enviado por su computadora después que usted cambió el tamaño del paquete a 3500 bytes. Primer fragmento de un paquete IP; en Flags el campo More fragments está en 1 (uno), lo cual indica que este es el primer fragmento fr agmento del datagrama:
El siguiente fragmento es; en Flags el campo More fragments está en 0 (cero), indica que este es el último fragmento del datagrama:
Cambian los campos: Total Length (tamaño del paquete); Flags (More ( More fragments) y Fragment offset. El primer mensaje ICMP Echo Request que fue enviado después que se cambió el tamaño del paquete a 3500 bytes:
14. ¿Cuántos fragmentos fueron creados desde el datagrama original? Fueron creados 2 fragmentos El mensaje original es:
El primer fragmento es:
El segundo y último fragmento es:
Éste es último porque en Flags en More fragments se pone en cero si el datagrama es el último fragmento de una segmentación. 15. ¿Cuáles campos cambiaron en la cabecera IP entre los fragmentos? Observando los reportes anteriores, cambian los siguientes campos: Total Length; Flags (More fragments) y Fragment offset.
Trabajos citados 1. [Online] [Cited: Junio http://neo.lcc.uma.es/evirtual/cdd/tutorial/red/icmp.html.
4,
2009.]
2. [Online] [Cited: Junio 3, 2009.] http://www.profesores.frc.utn.edu.ar/sistemas/ings http://www.profesores.frc.utn.e du.ar/sistemas/ingsanchez/Redes anchez/Redes/Archivos/datagramaIP. /Archivos/datagramaIP. asp.
