Laboratorio #2­ Análisis de Protocolos

Infraestructura de comunicaciones Ana María Cárdenas, Andrea Navas

Universidad de los Andes, Bogotá, Colombia

Fecha de presentación: Agosto 16 de 2015

1. Introducción

1. Introducción

En el estudio de la infraestructura de comunicaciones es esencial comprender las reglas que permiten que el origen y destino puedan comunicarse entre sí. Éstas, que en el mundo de la

informática se conocen como protocolos, son establecidas de tal manera que pueda darse un flujo de mensajes eficaz en el cual se comprenda correctamente el contenido de los mismos. Existen muchos protocolos que rigen las comunicaciones en una red definiendo un emisor y receptor específico, una cierta codificación de los mensajes, un formato y encapsulación, así como el tamaño del mensaje entre otras características del flujo de información.

Los protocolos se agrupan en lo que se conoce como una pila de protocolos y trabajan juntos. La que de Internet se conoce como protocolo de control de transmisión/IP (TCP/IP) e incluye a los protocolos de transferencia de hipertexto (HTTP), de transferencia de hipertexto seguro (HTTPS), para transferencia simple de correo (SMTP), de transferencia de archivos (FTP) y el de control de transmisión (TCP) entre otros. Cada uno de ellos funciona de una manera especial de acuerdo a su definición y permite que se propicie una comunicación efectiva. La importancia de conocer y comprender los protocolos es entonces esencial para poder entender cómo funciona la red y la comunicación que se da a través de la misma.

El presente laboratorio tiene como objetivo la comprensión de la pila de protocolos que componen TCP/IP y la interacción entre ellos para proveer servicios sobre una red de datos a pequeña escala. Asimismo, se pretende identificar los procesos de encapsulación de datos, así como establecer las funcionalidades de cada protocolo y de los servicios de red. Para lograr esta comprensión se realizará un análisis y monitorización de los protocolos y servicios sobre una topología de red a pequeña escala utilizando Wireshark: una herramienta de análisis de paquetes.

El análisis de paquetes es el proceso de captura e interpretación en tiempo real de los datos obtenidos cuando los paquetes circulan en una red. Utilizando Wireshark se pueden visualizar los datos de los paquetes que se capturan.Además de un análisis adecuado de los resultados arrojados por esta herramienta permite comprender cómo funcionan los protocolos más utilizados en internet.

El laboratorio se compone de varias pruebas de conectividad y de pruebas de conexión utilizando los protocolos FTP,HTTPS, HTTP, SMTP y de oficina postal (POP3) utilizando Wireshark.

2. Pruebas de conectividad

Las pruebas de conectividad permiten verificar si se puede realizar una conexión de red entre dos sistemas finales.En este caso realizamos pruebas con el protocolo de mensajes de control de internet (ICMP) utilizando la herramientaping para probar la conectividad con el

enrutador de clientes, con dos usuarios de la red , con el servidor1 y con el servidor Web. Para estas pruebas se realizó la conexión utilizando las direcciones IP correspondientes y para el caso de la conexión con el servidor Web la prueba también se realizó con la url del mismo.

El protocolo utilizado para realizar estas pruebas, es decir el ICMP, pertenece a la capa de red a la cual pertenecen también los protocolos IP y los protocolos de enrutamiento de Internet. Este protocolo es utilizado para comunicar información de la capa de red y sobretodo para reportar errores. Aunque en ocasiones se considera como parte del protocolo IP en realidad se encuentra por encima de éste, pues los mensajes propios del mismo son transmitidos dentro de datagramas de IP, es decir como parte de la carga (payload) del IP.

Los mensajes de este protocolo tienen varios campos: el tipo y el código, un encabezado y los primeros 8 bytes del datagrama IP que lo causó (esto último en el caso de ser utilizado para reportar un error). Cuando se utiliza ping se envía un ICMP tipo 8 y código cero al sistema final con el que quiere establecerse la conexión. Ante esta petición, que se conoce como echo request, el sistema final responde con un mensaje tipo 8 y código 0 que es una respuesta conocida como echo reply.

2.1 Pruebas de conectividad con el enrutador local de clientes y con dos usuarios de red.

Se envían 4 paquetes ICMP al enrutador local y a los dos usuarios de red : en la primera ocasión se supone que no llegan los 4 sino sólo 3 de los paquetes enviados. Pero al ejecutar la prueba una segunda vez si llegan los 4 paquetes. En la realización de esta prueba, sin embargo pudimos observar que llegaron los 4 paquetes en las dos oportunidades. La prueba de conectividad con el enrutador local se ilustra a continuación (el segundo intento).

En este caso se aplicó en Wireshark el filtro ((ip.src==192.168.20.6 and

(ip.dst==192.168.20.1 or ip.dst==192.168.20.3 or

ip.dst==192.168.20.4)) or (ip.dst==192.168.20.6 and

(ip.src==192.168.20.1 or ip.src==192.168.20.3 or

ip.src==192.168.20.4)))como se muestra en la Figura 2.1.1 para obtener sólo los resultados correspondientes al ping con el enrutador local de clientes y los dos usuarios locales (teniendo en cuenta que la dirección IP del equipo que se utilizó es: 192.168.20.6, la del enrutador local de clientes es: 192.168.20.1 y las de los usuarios son: 192.168.20.3, 192.168.20.4)). En las columnas de la imagen se puede observar, para cada solicitud de ping, la IP de origen y destino, el protocolo correspondiente (que es en este caso el protocolo ICMP), la dirección de control de acceso de medio (MAC) de origen y destino, el

tiempo y la información correspondiente a la comunicación. Asimismo, se dividen con líneas de color azul los registros de cada uno de los paquetes enviados a los diversos destinos. No se incluye el puerto de origen ni de destino en la medida en la que el protocolo ICMP no hace uso de los mismos.

Figura 2.1.1 Envío de paquetes por ICMP al enrutador local de clientes y usuarios locales

A continuación, se ilustra la conversación entre los sistemas finales para este protocolo a partir de la conversación para el protocolo de internet versión 4 (IPV4) y Ethernet que corresponde al envío deping. Se presenta esta ilustración porque ICMP al encontrarse en la capa de red utiliza la capa de enlace a la que pertenece Ethernet y se encuentra dentro de la misma capa con IPV4 pero se despliega por encima de éste haciendo uso de los datagramas de IP. En ambas visualizaciones se muestran las columnas que corresponden a las direcciones de origen y de destino, el número de paquetes transmitidos, la cantidad de bytes transmitidos, así como la duración de tal conversación. Se especifica por cada sentido de la conversación, a saber de A a B y de B a A, (siendo A siempre el equipo desde donde se envían los ping y B el destino) el número de paquetes de bytes y la velocidad de transmisión (bps). Sólo se observa una diferencia en la manera en la que se muestra la dirección de origen y destino considerando que Ethernet va a transmitir utilizando las direcciones MAC y en IPV4 se utilizan las direcciones IP. No existen otras diferentes, pues ambas visualizaciones ilustran las mismas conversaciones que dan cuenta de los pings enviados.

Figura 2.1.2 Conversaciones entre sistemas finales( Ethernet)

Figura 2.1.3 Conversaciones entre sistemas finales (IPV4)

Los mensajes que se envían utilizando el protocolo ICMP para esta prueba se ilustran a continuación en las Figuras 2.1.4 y 2.1.5 que corresponden a la petición y a la respuesta respectivamente. Como se mencionó anteriormente corresponden a un echo request yecho reply. Estos mensajes corresponden al primer paquete enviado al enrutador local de clientes y la respuesta recibida por el mismo, los demás mensajes son bastante similares por lo que sólo se muestra éste a modo de ilustración.

Figura 2.1.4 Mensaje echo request (ping).

Figura 2.1.5. Mensaje echo reply(ping).

Para estas pruebas de conectividad se muestra a continuación un resumen de las capturas realizadas en la Figura 2.1.6. En este se muestra una relación con todas las capturas obtenidas y las que corresponden a los pings las cuales sólo son el 6.87% del total de capturas realizadas.

Figura 2.1.6. Resumen de capturas tomadas

En las figuras 2.1.8 y 2.1.9 se ilustran las conexiones con otros sistemas finales que corresponden a IPV4 y Ethernet por la misma razón que se incluyeron en las conversaciones (es decir, porque ICMP utiliza la capa de enlace a la que pertenece Ethernet y se encuentra dentro y hace uso de los datagramas de IP.)

Figura 2.1.8 Conexiones con sistemas finales ( IPV4)

Figura 2.1.9 Conexiones con sistemas finales ( Ethernet)

Adicionalmente se ilustra en la figura 2.1.10 cómo se distribuye el tráfico en estas capturas. Se filtra por ICMP para poder ver cómo fluctúa este tráfico y cómo se relaciona con respecto a la fluctuación del tráfico en general.

Figura 2.1.10 Tráfico de capturas

2.2 Pruebas de conectividad con el servidor1. Se realiza una prueba de conectividad con el servidor1 utilizando su IP y a continuación se ilustra todo el proceso. Se envían 4 paquetes ICMP se supone que no llegan los 4 sino sólo 3 de los paquetes enviados, sin embargo pudimos observar que llegaron los 4 paquetes.

En este caso se aplicó en Wireshark el filtro (icmp.type and

((ip.src==192.168.20.6 and ip.dst==192.168.40.2) or

(ip.src==192.168.40.2andip.dst==192.168.20.6)))como se muestra en la Figura 2.2.1 para obtener sólo los resultados correspondientes al ping con el servidor1 que corresponde al servidorDNS (teniendo en cuenta que la dirección IP del equipo que se utilizó es: 192.168.20.6 y la del servidorDNS es 192.168.40.2)). En el filtro se incluye icmp.typepara que sólo se muestren las capturas correspondientes alping, en este caso es necesario teniendo en cuenta que se envían al servidor DNS y durante el tiempo de captura también se envían solicitudes de tipo DNS a este servidor. Éstas últimas no son pertinentes para la evaluación de las pruebas de conectividad y por tanto no se incluyen. Las columnas de la imagen son las mismas que se utilizan en la prueba de conectividad anterior.

Figura 2.1.1 Envío de paquetes por ICMP al servidorDNS

Las figuras 2.2.2 y 2.2.3 corresponden a la conversación que se ilustra nuevamente desde IPV4 y ethernet respectivamente. Éstas incluyen la misma información que las de la prueba anterior.

Figura 2.2.2. Conversación entre sistemas finales (IPV4)

Figura 2.2.3. Conversación entre sistemas finales (Ethernet)

En este caso los mensajes tienen la misma estructura que en la prueba anterior por lo que no se considera necesario incluirlos. Se muestra a continuación un resumen de las capturas realizadas en la Figura 2.2.4. En este resumen se muestra una relación con todas las capturas obtenidas respecto a las que corresponden a lospings las cuales sólo son el 4,73% del total de capturas realizadas.

Figura 2.2.4 Resumen capturas para prueba de conectividad con servidor1.

En las figuras 2.2.5 y 2.2.6 se ilustran las conexiones con otros sistemas finales que corresponden a IPV4 y Ethernet respectivamente por la misma razón que se incluyeron en las conversaciones (es decir, porque ICMP utiliza la capa de enlace a la que pertenece Ethernet y se encuentra dentro y hace uso de los datagramas de IP.)

Figura 2.2.5 Conexiones con sistemas finales (IPV4)

Figura 2.2.6 Conexiones con sistemas finales (Ethernet)

A continuación se muestra cómo fluctúa el tráfico en estas capturas en la Figura 2.2.7: se realiza una filtración por el protocolo ICMP para visualizar cómo es el tráfico que involucra

a este protocolo. Se puede observar así cómo se relacionan lospings con todo el tráfico que pasa por la red.

Figura 2.2.7Tráfico de las capturas

2.3 Pruebas de conectividad con el servidorWeb.

Se realizan en este caso dos pruebas de conectividad con el servidor: la primera utilizando su URL y la segunda haciendo uso de su dirección IP, a continuación se ilustra todo el proceso. Se envían 4 paquetes ICMP en cada caso.

Para la prueba realizada con la URL se observa que primero es necesario obtener la IP para que puede llevarse a cabo la comunicación con el servidor Web. El servicio de directorio para traducir el hostname, que es lo que se obtiene de la URL, en una dirección IP es ofrecido por el sistema de nombres de dominio (DNS) por lo que se observa en esta prueba de conectividad una petición de este tipo. El DNS es una base de datos distribuida implementada en servidores y un protocolo en la capa de aplicación que permite hacer queries a dicha base de datos. El protocolo DNS corre sobre el protocolo de datagrama de usuario (UDP), es decir que las queries así como los mensajes de respuesta son enviados con datagramas UDP al puerto 53. Es esencial tener en cuenta que DNS agrega undelay en este caso.

El DNS utiliza un gran número de servidores organizados de forma jerárquica alrededor del mundo: no existe un solo servidor DNS. Estos servidores guardan registros de recursos (RRs) algunos de los cuales tienen el mapping entre el hostname y la dirección IP. Los mensajes de respuesta de DNS contienen uno o más de estos registros los cuales se componen de cuatro campos a saber: nombre, valor, tipo y el tiempo de vida (TTL) (este último determina cuando debe retirarse un recurso del caché). El nombre y el valor dependen del tipo de registro: existen cuatro tipos el A, el NS, el CNAME y el MX. El tipo A ese el que resulta pertinente analizar en este caso pues corresponde al caso en que el

nombre es el hostname y el valor es la dirección IP. En cuanto a los mensajes de respuesta y query (existen otros tipos de mensajes DNS, pero estos son los que se utilizan en este caso) tienen la primero una encabezado con varios campos. Entre ellos se identifican uno que tiene un número de identificación de la query, un campo de banderas que contiene varios tipos de banderas entre las que se destaca una tipo query/reply ( indica si es una query o un reply, en el primer caso es un 0 y de lo contrario es un 1). En el header también se encuentran cuatro campos que indican el número de ocurrencias de cuatro secciones que siguen al encabezado. Así después de éste se encuentra una sección de pregunta que contiene la información de la query realizada, o los registros de recurso de ser una respuesta. Además hay otras dos secciones que incluyen información correspondiente a registros para otros servidores y otra información adicional.

Teniendo esto en cuenta se aplicó en Wireshark el filtro((ip.src==192.168.20.6or

ip.src==192.168.10.3)or ip.src==192.168.40.2) and

((ip.dst==192.168.20.6 or ip.dst==192.168.10.3)or

ip.dst==192.168.40.2)como se muestra en la Figura 2.3.1 para obtener sólo los resultados correspondientes al ping con el servidorWeb así como la solicitud DNS (teniendo en cuenta que la dirección IP del equipo que se utilizó es: 192.168.20.6, la del servidorDNS es 192.168.40.2 y la del servidorWeb es 192.168.10.3)). Utilizando tal filtro aún se muestran resultados que no corresponden a la prueba de conectividad, estos se ignoran pues pertenecen a otras solicitudes DNS que se dan durante el tiempo de captura por lo tanto no se incluyen en la figura. Las columnas de la imagen son las mismas que se utilizan en la prueba de conectividad anterior más los puertos de origen y destino para ilustrar el uso de los mismos en DNS.

Figura 2.3.1. Envío de paquetes por ICMP al servidor Web con URL

A continuación se ilustra la conversación entre los sistemas finales en este caso observamos también la conversación en UDP que corresponde a la petición DNS. Tanto en la conversación de Ethernet y de IPV4 se observa que hay 2 paquetes más que corresponden a la petición DNS realizada. Las figuras 2.3.2, 2.3.3 y 2.3.4 corresponden a las conversaciones UDP, IPV4 y Ethernet respectivamente.

Figura 2.3.2. Conversación entre sistemas finales (UDP)

Figura 2.3.3. Conversación entre sistemas finales (IPV4)

Figura 2.3.4. Conversación entre sistemas finales (Ethernet)

En este caso los mensajes del ICMP tienen la misma estructura que en la prueba anterior por lo que no se considera necesario incluirlos. Se incluyen entonces los mensajes de la petición DNS cuya estructura ya fue precisada anteriormente. Las figuras 2.3.5 y 2.3.6 corresponden a la query y a la respuesta para la misma respectivamente.

Figura 2.3.5. Query DNS

Figura 2.3.6. Reply DNS

Se muestra a continuación un resumen de las capturas realizadas en la Figura 2.3.7. En este resumen se muestra una relación con todas las capturas obtenidas respecto a las que corresponden a los pings y la petición DNS las cuales sólo son el 7,58% del total de capturas realizadas.

Figura 2.3.7. Resumen capturas prueba de conectividad con URL

En las figuras 2.3.8, 2.3.9 y 2.3.10 se ilustran las conexiones con otros sistemas finales que corresponden a UDP, IPV4 y Ethernet respectivamente.

Figura 2.3.8. Conexiones con sistemas finales (UDP)

Figura 2.3.9. Conexiones con sistemas finales (IPV4)

Figura 2.3.10. Conexiones con sistemas finales (Ethernet)

A continuación se muestra cómo fluctúa el tráfico en estas capturas en la Figura 2.3.11: se realiza una filtración por el protocolo ICMP y DNS para visualizar cómo es el tráfico que involucra a este protocolo(teniendo en cuenta que aquí se requiere realizar peticiones al servidor DNS como parte del proceso del ping). Se puede observar así cómo se relacionan los pings con todo el tráfico que pasa por la red.

Figura 2.3.11 Tráfico de las capturas

En la prueba de conectividad con el servidor Web desde la IP únicamente hay diferencias con respecto a la petición DNS, pues no hay necesidad de realizarla. En este sentido se considera pertinente incluir sólo la Figura 2.3.12 que ilustra el proceso. El filtro utilizado para la misma fue: (ip.src==192.168.20.6orip.src==192.168.10.3)and

(ip.dst==192.168.20.6 or ip.dst==192.168.10.3).

Figura 2.3.12 Envío de paquetes por ICMP al servidor Web con IP

3. Análisis de protocolo FTP

El protocolo FTP que se encarga de la transferencia de archivos se encuentra incluido en la pila TCP/IP : la que se pretende explorar y comprender a través del presente laboratorio. Para el análisis de este protocolo se realizaron dos conexiones a través de un navegador web utilizando en un caso la IP y en el otro la URL (ftp://192.168.10.4 ,

ftp://ftp.labredes.com respectivamente). El navegador actúo como cliente FTP solicitando la autenticación y listando los archivos disponibles para la descarga. Posteriormente se realizó el proceso de descarga de uno de los archivos antes listados.

Este protocolo, que pertenece a la capa de aplicación dentro de la pila TCP/IP, funciona a grandes rasgos de la siguiente manera: en primera instancia es necesario que el usuario pueda acceder a la cuenta remota por lo que debe proporcionar los datos de autenticación lo que le permite transferir archivos desde y hacia el sistema de archivos remoto. El usuario debe proporcionar el hostname del cliente remoto lo que permite que se establezca una conexión TCP con el cliente remoto; específicamente con el proceso del servidor de FTP de éste último. El usuario además debe proporcionar su identificación y contraseña que se envían a través de la conexión antes establecida. El servidor autoriza al usuario y ya se puede iniciar la transferencia de archivos.

Es importante resaltar que en el protocolo FTP se utilizan dos conexiones paralelas de TCP: una de control y otra de datos. La primera permite enviar información relacionada con el proceso de conexión como tal, del usuario,y comando GETyPUT. La de datos es a través de la cual se realiza la transferencia de archivos. La conexión de control se inicia primero y se da a través del puerto 21: es a través de ella que se envían los datos de identificación. El servidor inicia la conexión de datos: ésta se cierra tras enviar un archivo y se abre una nueva conexión en caso de querer transferir otro archivo.

Los mensajes que se envían por la conexión de control incluyen comando FTP entre los cuales se incluyen USER,PASS,LIST,STRyRETR. Estos permiten al usuario enviar su nombre de usuario , su contraseña , solicitar la lista de archivos, obtener un archivo , y enviar un archivo. El usuario es quien envía estos comandos a los que obtiene una respuesta por parte del servidor : la cual está estructurada como un número de tres dígitos.

3.1 Establecimiento de conexión FTP

A continuación se ilustra el proceso que se lleva a cabo antes de poder iniciar la transferencia de archivos a través del protocolo FTP. El mismo proceso se realizó

utilizando la IP y la URL pero sólo se muestra el realizado con la IP. La diferencia radica en que al utilizar la URL existe la necesidad de crear una petición DNS , la cual ya ha sido explicada de manera completa en la sección anterior.

En este caso se aplicó en Wireshark el filtro (ip.src==192.168.20.6 and

ip.dst==192.168.10.4) or (ip.src==192.168.10.4 and

ip.dst==192.168.20.6)como se muestra en la Figura 3.1.1 para obtener sólo los resultados correspondientes a la conexión FTP (teniendo en cuenta que la dirección IP del equipo que se utilizó es: 192.168.20.6 y la del servidorFTP es 192.168.10.4). Las columnas de la imagen son las mismas que se utilizan en las pruebas de conectividad incluyendo los puertos de origen y destino.

Figura 3.1.1 Conexión FTP y solicitud de lista de archivos.

Las figuras 3.1.2 , 3.1.3 y 3.1.4 corresponden a la conversación que se ilustra desde TCP IPV4 y Ethernet respectivamente. Se puede observar que hay tres conexiones TCP: esto se debe a que el primer intento de login falló (primera conexión). Las otras dos conexiones corresponden a la de datos y la control que fueron mencionadas anteriormente. La conexión

exitosa de control se establece entre los puertos 55221 y 21 y la de datos se establece entre 55223 y 32584 en las cuales el primer puerto corresponde al servidor y el segundo al cliente.

Figura 3.1.2 Conversación entre sistemas finales (TCP)

Figura 3.1.3 Conversación entre sistemas finales (IPV4)

Figura 3.1.4 Conversación entre sistemas finales (Ethernet)

A continuación se ilustra el flujo de mensajes entre cliente y servidor por FTP. El primer flujo se da una vez se ha logrado establecer la conexión TCP y corresponde al flujo que falla (Figura 3.1.5). Se cierra la conexión y se debe establecer una nueva para iniciar el segundo flujo que se da de manera adecuada a través de la conexión de control , se solicita la lista de archivos y se envía ( esto ocurre por otra conexión TCP: la que corresponde a los datos y se cierra al transmitir) (Figura 3.1.6).

Figura 3.1.5 Flujo de mensajes FTP fallido.

En este flujo se ilustra que el servidor responde que está listo, el usuario envía su nombre de usuario, el servidor lo acepta y solicita la contraseña. El usuario la envía pero el servidor responde que el login es incorrecto.

Figura 3.1.6 Flujo de mensajes inicio y solicitud de lista de archivos.

Se observa en este flujo que el login se realiza de manera satisfactoria. Posteriormente (la línea punteada indica que ha pasada un tiempo que no se documenta) se realiza una solicitud de cambio de directorio por parte del usuario que el servidor realiza e informa que ha realizado. El cliente solicita una lista de archivos del directorio y el servidor le responde que los enviara: esto sucederá en un flujo de mensajes por una conexión TCP diferente. Finalmente el servidor informa que ha cerrado tal conexión y que se ha enviado exitosamente la lista de archivos.

Se muestra a continuación un resumen de las capturas realizadas en la Figura 3.1.7 En este resumen se muestra una relación con todas las capturas obtenidas respecto a las que corresponden a la conexión FTP las cuales son el 46,156% del total de capturas realizadas.

Figura 3.1.8 Resumen capturas conexión FTP

En las figuras 3.1.9, 3.1.10 y 3.1.11 se ilustran las conexiones con otros sistemas finales que corresponden a TCP, IPV4 y Ethernet respectivamente.

Figura 3.1.6 Conexiones con sistemas finales (TCP)

Figura 3.1.7 Conexiones con sistemas finales (IPV4)

Figura 3.1.8 Conexiones con sistemas finales (Ethernet).

A continuación se muestra cómo fluctúa el tráfico en estas capturas en la Figura 3.1.9: se realiza una filtración por el protocolo TCP y FTP para visualizar cómo es el tráfico que involucra a estos protocolos(teniendo en cuenta que aquí se requiere de las conexiones TCP para poder llevar a cabo la transferencia de archivos). Adicionalmente, se hace un filtro sobre FTP que se conoce como FTP­DATA que corresponde a la conexión de datos por medio de la cual se transmiten los archivos.

Figura 3.1.9 Tráfico de capturas

3.2 Transferencia de archivos por FTP A continuación se ilustra el proceso que se lleva a cabo para descargar un archivo de la lista de archivos. En este caso se aplicó en Wireshark el filtro (ip.src==192.168.20.6

and ip.dst==192.168.10.4) or (ip.src==192.168.10.4 and

ip.dst==192.168.20.6)como se muestra en la Figura 3.2.1 para obtener sólo los resultados correspondientes a la conexión FTP (teniendo en cuenta que la dirección IP del equipo que se utilizó es: 192.168.20.6 y la del servidorFTP es 192.168.10.4)). Las columnas de la imagen son las mismas que las que se utilizan en la sección anterior.

Figura 3.2.1 Transferencia de archivos vía FTP.

Las figuras 3.2.2 , 3.2.3 y 3.2.4 corresponden a la conversación que se ilustra desde TCP IPV4 y Ethernet respectivamente. Se puede observar que hay dos conexiones TCP: la de control se establece entre los puertos 54746 y 21 y la de datos se establece entre 54757 y 25307 en las cuales el primer puerto corresponde al servidor y el segundo al cliente.

Figura 3.2.2 Conversación entre sistemas finales (TCP)

Figura 3.2.3 Conversación entre sistemas finales (IPV4)

Figura 3.2.3 Conversación entre sistemas finales (Ethernet)

A continuación se ilustra el flujo de mensajes entre cliente y servidor por FTP para la transferencia del archivo.

Figura 3.2.4 Flujo de mensajes para transmisión de archivos por FTP

En este flujo de mensajes el cliente solicita al servidor que acepte una conexión de datos en un nuevo puerto TCP: utilizando el comando PASV. El servidor acepta con el código 227. El cliente solicita al servidor a través del comando SIZEque le proporciona información sobre el tamaño del archivo que desea descargar. El servidor responde y el cliente utilizando el comando MDTMsolicita la fecha de la última modificación de tal archivo a lo que responde el servidor. Posteriormente con el comando RETRel cliente solicita al servidor el archivo deseado y el servidor le indica que iniciará la transmisión. El archivo empieza a descargarse a través de la conexión de datos ( otra conexión TCP) en paquetes de 1460 bytes hasta que termina ( en la figura solo se muestra una vez cómo se envía este mensaje pero en realidad se envía hasta que finaliza la descarga). Finalmente el servidor indica que ha finalizado la transmisión y cierra la conexión de datos.

Se muestra a continuación un resumen de las capturas realizadas en la Figura 3.2.5. En este resumen se muestra una relación con todas las capturas obtenidas respecto a las que corresponden a la conexión FTP las cuales son el 98,614% del total de capturas realizadas.

Figura 3.2.5 Resumen de capturas transmisión de archivo FTP

En las figuras 3.2.6, 3.2.7 y 3.2.8 se ilustran las conexiones con otros sistemas finales que corresponden a TCP, IPV4 y Ethernet respectivamente.

Figura 3.2.6 Conexiones con sistemas finales (TCP)

Figura 3.2.7 Conexiones con sistemas finales (IPV4)

Figura 3.2.7 Conexiones con sistemas finales (Ethernet)

A continuación se muestra cómo fluctúa el tráfico en estas capturas en la Figura 3.2.8: se realiza una filtración por el protocolo TCP y FTP para visualizar cómo es el tráfico que involucra a estos protocolos(teniendo en cuenta que aquí se requiere de las conexiones TCP para poder llevar a cabo la transferencia de archivos). Adicionalmente, se hace un filtro sobre FTP que se conoce como FTP­DATA que corresponde a la conexión de datos por medio de la cual se transmiten los archivos. Se puede observar aquí cómo crece el tráfico de FTP­DATA con respecto al ejercicio anterior, pues aquí se transfiere un archivo pesado.

Figura 3.2.8 Tráfico de capturas

4. Análisis de protocolos de correo electrónico: SMTP y POP3

En esta sección se documentará el análisis de intercambio de paquetes en el protocolo SMTP y POP3 a través de la herramienta de análisis de paquetes Wireshark. Se

documentará el intercambio de paquetes en momentos clave de los protocolos, siendo estos: autenticación al servicio de correo electrónico, envío y recepción de correos electrónicos.

4.1. Proceso de configuración de correo

En este caso se aplicó en Wireshark el filtro ((ip.src==192.168.20.6and

ip.dst==192.168.10.5) or (ip.dst==192.168.20.6 and

ip.src==192.168.10.5))como se muestra en la Figura 4.1.5 para obtener sólo los resultados correspondientes al intercambio con el servidor de correo. Se utilizaron las credenciales de usuario6@labredes.com y contraseña usuario6

A continuación se presenta el proceso general de autenticación que establece la conexión con el servidor de correo y envía los datos de autenticación. En las columnas de la imagen se puede observar, para cada mensaje, la IP de Origen y Destino el protocolo correspondiente, MAC de destino, MAC de origen, puerto origen, puerto de destino e información adicional.

.

Figura 4.1.1 Paquetes intercambiados en autenticación de correo a través de POP3.

Figura 4.1..2 . Conversación entre endpoints TCP

Descripción del protocolo en autenticación : La Figura 4.1.1 contiene los últimos mensajes intercambiados durante la etapa de autenticación. En esta etapa se establece una conexión a través de TCP tras la cual por medio de POP se solicita inicialmente el set of initial capabilities (1) que lista los comandos USER, UIDL y TOP como se muestra en la Figura 4.1.3. El cliente procede a utilizar el comando USER y el nombre de usuario completo (de lo contrario falla este paso como se observa en la Figura 4.1.1 ). Tras este paso el servidor solicita la contraseña con lo que el servidor responde con OK. En la gráfica de conversación entre endpoints se puede observar que las conversaciones entre endpoints que se dan en el puerto 110 son aquellas que corresponden al protocolo POP (2)

Estructura de mensaje de autenticación: Como se puede observar en las figuras 4.1.3 y 4.4 los mensajes no están encriptados (son enviados y recibidos en el puerto 110). En el caso del cliente se componen de comandos y parámetros y en el caso del servidor un indicador de OK o ERROR y el resto de la respuesta.

Figura 4.1.3 . Mensajes de autenticación POP desde el servidor

Figura 4.1.4 . Mensajes de autenticación POP desde el cliente

Figura 4.1.5 . Resúmen de la captura correspondiente a la autenticación y las conexiones con otros sistemas finales para la captura

4.2. Proceso de envío de correo Para el caso de envío se redactó un correo que tenía como remitente el usuario6 y destinatario el usuario1. Se aplicó en Wireshark el mismo filtro del proceso anterior.

Figura 4.2.1 . Paquetes intercambiados en el envío de correo.

Figura 4.2.2. Conversación entre endpoints TCP

Descripción del protocolo en envío de correo: Como se puede observar en la Figura 4.2.2 toda la conexión se lleva a cabo en el puerto 587 que es el puerto por defecto para el protocolo SMTP. Los mensajes que llegan a este puerto se entienden como submissions aunque en algunos casos se encuentra el servidor de correo configurado para escuchar en el puerto 25 (3). Después de establecer la conexión por medio de TCP el servidor envía un mensaje al cliente indicando que el servicio está listo por medio del protocolo SMTP. Seguidamente el cliente envía el comando EHLO que “indica que el cliente es capaz de procesar las extensiones de servicio y pide que el servidor proporcione una lista de las extensiones que soporta” (4). El cliente responde con el comando AUTH y tras autenticarse usa el comando MAIL para enviar un correo. Por último un mensaje con formato IMF es enviado desde el cliente. “Cuando SMTP es equivalente al sobre del mensaje, el FMI es equivalente a la carta dentro del sobre. Contiene el autor, destinatarios, asunto y fechas” (5).

Figura 4.2.3 . Mensajes de envío de correo de SMTP desde el servidor

Figura 4.2.4 . Mensajes de envío de correo de SMTP desde el cliente

Figura 4.2.5 . Mensajes de envío de correo con formato IMF desde el cliente

Estructura de los mensajes : En este caso la estructura de los mensajes es más interesante ya que al momento de la autenticación nos encontramos con elementos como que el nombre de usuario y contraseña ya no se encuentran en el mensaje como texto plano. Del mismo modo el IMF es el formato enviado por SMTP para poder intercambiar el correo entre el cliente y el servidor y enviarlo a su destinatario.

Figura 4.2.6 . Resúmen de la captura correspondiente a la autenticación , Tráfico según protocolo y las conexiones con otros sistemas finales para la captura

4.3. Proceso de recepción de correo

Para el caso de recepción de correo el usuario remitente fue el grupo 3. Se aplicó en Wireshark el mismo filtro del proceso inicial.

Figura 4.3.1 . Paquetes intercambiados en autenticación de correo a través de POP3.

Figura 4.3.2 .Endpoints presentes en el proceso de recepción de correo..

Descripción del proceso de recepción de un correo: Como se puede observar en la Figura 4.3.1 el proceso de recepción de correo inicia con un proceso de autenticación similar al observado al momento de configurar la cuenta. Se establece inicialmente una conexión a partir de TCP. Todas las comunicaciones a través de TCP y POP son recibidas en el servidor en el puerto 110 que es el puerto estándar para el protocolo POP. Una vez se inicia la conexión entre los 2 servidores. Después de utilizar el comando CAPA y el servidor lista los posibles comandos el cliente usa el comando USER y PASS para autenticarse. Después de que el servidor responde OK el cliente envía el comando STAT que es válido en el estado de transacción del servidor y solo puede ser respondido como “OK” o “­ERR” junto con el número de mensajes en el mailbox y su tamaño en bytes (2). Posteriormente el cliente utiliza el comando LIST con el cual el servidor retorna una lista de resúmen de los mensajes presentes en elmailbox donde esta línea se llama una "lista de exploración" para ese mensaje (2). Luego el cliente utiliza el comando RETR pasando un id del mensaje que busca obtener y el servidor “Después del + OK inicial, el servidor POP3 envía el mensaje correspondiente al id de mensaje dado, teniendo cuidado de byte­stuff el caracter de terminación” (2). Finalmente se cierra la conexión entre el cliente y el servidor.

Figura 4.3.3 . Estructura de paquetes enviados por el servidor.

Figura 4.3.4 . Estructura de paquetes enviados por el cliente

Estructura de los mensajes : En este caso resultan interesantes los nuevos comandos utilizados por parte del cliente para obtener los mensajes que no se observaron durante el proceso de autenticación, en este caso particular LIST que le permite obtener un resúmen de los mensajes presentes en el mailbox y el comando RETR que le permite obtener un correo con un id determinado. Observamos que en este proceso el servidor usa de nuevo el formato IMF, en este caso para enviar el list del mailbox para el caso de el correo consultado con el comando RETR el servidor responde por medio del protocolo POP donde todo el contenido del correo solicitado se envía a través del mensaje de POP.

5. Protocolo HTTP y HTTPS La interacción con la página web www.facebook.com se llevó a cabo de la siguiente manera :

1. Tras borrar el caché de resolución DNS se ingresó a través de Google Chrome a la página www.facebook.com

2. Como ya se tenía registrada la página no se llegó a la página de login sino directamente al newsfeed de facebook.

3. En la barra de búsquedas se ingresó Semana 4. Se accedió al perfil de la revista Semana 5. Se accedió a las fotos de la revista Semana 6. Se navegó a través de las fotografías. 7. Se accedió al menú de videos.

Figura 5.0.1. Resúmen de la captura sin Filtros y gráfico de Tráfico según Protocolo

5.1. Protocolos de red que participan en el intercambio de datos generado al ingresar al sitio web Facebook:

Figura 5.1.1 . Protocolos involucrados en la captura

Dentro de los protocolos involucrados en la captura se observan protocolos ya tratados a lo largo de este laboratorio y del laboratorio anterior como TCP, UDP, DNS, ARP, ICMPv6.

Nuevos protocolos observados en el intercambio de paquetes son:

SSL : El objetivo principal del protocolo SSL es proporcionar privacidad y fiabilidad entre dos aplicaciones que se comunican. El protocolo es compuesto de dos capas. En el nivel más bajo, sobre algún protocolo de transporte fiable (por ejemplo, TCP [RFC0793]), está el protocolo de registro SSL. El protocolo SSL de registro se utiliza para la encapsulación de diferentes protocolos de nivel superior. Uno de tales protocolos encapsulados, el Protocolo de handshake SSL, permite que

el servidor y el cliente se autentiquen entre sí y negocien un algoritmo de cifrado y llaves criptográficas antes de que el protocolo de aplicación transmita o reciba su primer byte de datos. Una ventaja de SSL es que es independiente del protocolo de aplicación. Un protocolo de nivel superior puede ubicarse en la parte superior del protocolo SSL de forma transparente.

El protocolo SSL proporciona una conexión de seguridad que tiene tres propiedades básicas:

1. La conexión es privada. El cifrado se utiliza después de un handshake inicial para definir una clave secreta. Se utiliza la criptografía simétrica para el cifrado de datos (por ejemplo, DES, 3DES , RC4 ).

2. La identidad del grupo puede ser autenticada utilizando una clave asimétrica, o pública (por ejemplo, RSA ,DSS ).

3. La conexión es fiable. Transporte de mensajes incluye un mensaje de comprobación de integridad mediante un mensaje con llave Código de autenticación (MAC) [RFC2104]. Funciones de hash seguras (por ejemplo, SHA, MD5) se utiliza para cálculos MAC. (7)

QUIC : Es un protocolo experimental destinado a reducir la latencia web sobre la de TCP. En la superficie, QUIC es muy similar a TCP + TLS + SPDY implementado en UDP. Debido a que TCP es implementado en los núcleos del sistema operativo y middlebox firmware, hacer cambios significativos a TCP es casi imposible. Sin embargo, dado que QUIC se construye en la parte superior de la UDP, carece de tales limitaciones. Las principales características de QUIC sobre un existente TCP + TLS + SPDY incluyen :

Reducción dramática del tiempo de establecimiento de conexión, mejora del control de congestión, multiplexación sin la cabeza de la línea de bloqueo ,corrección de errores de reenvío, migración de conexión (8).

TLS : El objetivo principal del Protocolo TLS es proporcionar privacidad e integridad de los datos entre dos aplicaciones que se comunican. El protocolo esta compuesto por dos capas: El TLS Register Protocol y el TLS Handshake Protocol. En el nivel más bajo, sobre algún protocolo de transporte confiable (por ejemplo, TCP ) está el TLS Register Protocol . Este proporciona seguridad de conexión que tiene dos propiedades básicas:

1. La conexión es privada. Criptografía simétrica se utiliza para el cifrado de datos. Las claves para este cifrado simétrico se generan únicamente para cada conexión y

se basa en un secreto negociado por otro protocolo (como el TLS Handshake Protocol). El Record protocol también se puede utilizar sin cifrado.

2. La conexión es fiable. El transporte de mensajes incluye un mensaje de comprobación de integridad usando un MAC con llave. (9)

HTTP: El Protocolo de transferencia de hipertexto (HTTP) es un protocolo de nivel de aplicación para sistemas colaborativos distribuidos de información hipermedia . HTTP ha estado en uso por el World­Wide Web global information initiative desde 1990. La primera versión de HTTP, referido como HTTP / 0.9, fue un protocolo simple de transferencia de datos sin procesar a través de Internet. HTTP / 1.0, tal como se define en el RFC 1945, mejora el protocolo permitiendo que los mensajes estén en un formato similar al MIME, que contiene metainformación acerca de los datos transferidos y modificadores de la semántica de petición / respuesta. (10)

SSDP: Protocolo Simple de descubrimiento de servicios. Consiste en un HTTP request con la instrucción NOTIFY para anunciar o M­SEARCH para buscar un servicio..

5.2. Tráfico de HTTPS generado al ingresar a Facebook:

Figura 5.2.1 .Gráfica de resúmen de captura con el filtro tcp.port= 443

En la gráfica de resúmen de la captura se puede observar que el 93.615% del tráfico capturado corresponde a un intercambio hecho con TCP en el puerto 443, es decir que más del 90% del tráfico generado durante la interacción corresponde a HTTPS.

Mecanismos o filtros de “Wireshark” para estudiar las comunicaciones HTTPS:

El puerto 443 está definido por defecto para las comunicaciones de HTP sobre TLS/SSL (es decir HTTPS). De esta manera podemos filtrar en Wireshark el tráfico de HTTPS con el filtro TCP.port == 443

5.3. Tráfico de HTTP identificado:

Figura 5.3.1 .Gráfica de resúmen de captura con el filtro http

Como se observa en la gráfica 5.3.1 el tráfico correspondiente al protocolo http dentro de la captura es sólo el 1.73% del tráfico total capturado. Esto hace que el tráfico de HTTP no sea significativo comparado al porcentaje de tráfico HTTPS (más del 90%).

La mayoría del tráfico HTTP estaba conformado por mensajes M­SEARCH que se utilizan en espacios residenciales (en este caso las pruebas se realizaron en el domicilio de una de las integrantes del equipo) con el fin de descubrir servicios de red.

Figura 5.3.1 .Ejemplos de mensajes HTTP para M­SEARCH y NOTIFY

Se identificaron ciertos request de HTTP relacionados al Windows media player en el cual se hacía una petición get sobre el ícono de dicha aplicación sin embargo no nos resultó posible asociar dichas aplicaciones con el desarrollo de la interacción 1

1 El request fue realizado al siguiente LINK http://[fe80::9405:f44:fdac:c5e4]:2869/upnphost/udhisapi.dll?content=uuid:70c7c061­9123­47bd­8747­24bb5071dfbb

5.4. Proceso de Handshake:

En el caso del análisis del proceso de Handshake para un protocolo de TLS se observa que este proceso se lleva a cabo con el servidor de la compañía Akamai que se encarga de almacenar y proveer contenido multimedia para diversas compañías entre ellas Facebook lo cual explicaría el intercambio con los servidores de akamai para una interacción con contenidos como fotografías o videos desde Facebook. Durante el proceso de Handshake se observan las siguientes etapas principales: El mensaje de Hello del Cliente, mensaje de Hello del Servidor, envío de llaves por parte del servidor, Server Hello Done , intercambio de llaves por parte del Cliente y envío de Application Data. En la figura 5.4.1 se puede observar los distintos pasos aquí descritos en cuanto a intercambio de paquetes así como su abstracción teórica en la Figura 5.4.2.

Figura 5.4.1 .Snapshot de los paquetes intercambiados en SSL

Figura 5.4.2 .Overview teórico del proceso de SSL/TLS 2

2 Tomado de Microsoft techNet artículo SSL/TLS in detail disponible en : https://technet.microsoft.com/en­us/library/cc785811(v=ws.10).aspx

Client Hello Message: El cliente inicia la sesión enviando un mensaje de Hello al servidor. Como se puede observar en la Figura 5.4.3, el mensaje contiene un número random que será utilizado junto con el número random del servidor para generar el master secret con el cual las llaves serán enviadas (11), un session ID, Cipher Suites disponibles en el cliente y el algoritmo de compresión.

Figura 5.4.3 .Client Hello Message

Server Hello Message: El servidor envía un mensaje de Hello que contiene datos aleatorios, el cipher suite seleccionado de los disponibles en el cliente y el algoritmo de compresión. Se puede observar los detalles en la Figura 5.4.4

Figura 5.4.4 .Server Hello Message

Server Certificate: El servidor envía su certificado al cliente. Los certificados son visibles debido a que éstos son públicos. El cliente verifica el certificado para cerciorarse de que tenga el mismo nombre con el que el cliente se conectó. Un paso adicional a éste es una solicitud para el certificado del cliente sin embargo en la captura sólo el servidor envía su certificado ya que quien realmente está enviando información sensible y quiere verificar la autoridad de su contraparte es el cliente.

Figura 5.4.5 .Server Certificate

Server Key Exchange: El Servidor envía una clave temporal al Cliente que es usado por el Cliente para encriptar el Key Exchange Message. Este paso es sólo necesario cuando el algoritmo de llave pública no permite encriptar el mensaje de Key Exchange del Cliente.

Figura 5.4.6 .Server Key Exchange

Server Hello Done: Se envía este mensaje para indicar que el servidor está a la espera de respuesta por parte del cliente.

Figura 5.4.7 .Server Hello Done

Client Key Exchange : El cliente utiliza los números random enviados por él y por el servidor para crear el premaster secret el cual encripta utilizando el certificado enviado por el servidor. En caso de que el servidor pueda desencriptar la información el cliente puede estar seguro de que se está comunicando con el dueño del certificado, del cual ya verificó corresponde al servidor con el que desea comunicarse.

Figura 5.4.7 .Client Key Exchange

Server ­ Client Change Cipher Spec: Mensaje que notifica que los mensajes siguientes van a estar encriptados con las llaves negociadas.

Figura 5.4.7 .Change Cipher Spec message

5.5. Mensajes de Application Data

Los mensajes de application data son mensajes que se encuentran encriptados de acuerdo a los parámetros que se establecieron durante el handshake. Se puede observar un ejemplo de un mensaje enviado desde el servidor hasta el cliente en la Figura 5.5.1 :

Figura 5.5.1 .Mensaje de Data Application

6. Preguntas

1. ¿Puede encontrarse información adicional sobre los servicios prestados en la topología usando la captura de paquetes? Por ejemplo, ¿sería posible encontrar la ubicación de los recursos de contenido? Explicar.

Utilizando la captura de paquetes se pueden generar análisis interesantes que permiten comprender mejor las comunicaciones que se establecen. Poder visualizar la estructura de cada uno de los mensajes de cada protocolo y el camino que siguen es información que permite entender los servicios que se prestan utilizando una determinada topología.

Tal y como se expone en la pregunta número 4 las capturas en Wireshark sólo permiten visualizar la información de la dirección MAC para los componentes de la misma red lo que impide ubicar físicamente a hosts o enrutadores que no pertenezcan a ésta. ¿Dentro de los paquetes capturados, hay frames cuya dirección IP no sea la dirección del cliente a la que corresponde la interfaz de red? Si es así, ¿Por qué sucede esto? Como se observa en la captura de la Figura 6.2.1 estos casos si se dan. Para el ejemplo mostrado en la captura la IP no correspondiente se debe a que se está llevando a cabo un proceso de Broadcast el cual la capa de red proporciona un servicio de entrega de un paquete enviado desde un nodo de origen a todos los otros nodos en la red (12) . En este caso se observa un proceso de multidifusión que utiliza un rango especial de direcciones IP que no identifican puntos dentro de una red sino redes como tal. En este caso la IP es 192.168.20.255 que no corresponde a la de la interfaz de red Usuario1 (192.168.20.6) sino a toda la red local.

Figura 6.2.1 IP no correspondite a la interfaz de res

2. Para capturas de un mismo protocolo, ¿hay diferencias significativas entre los paquetes respecto a su estructura? Explicar y mostrar capturas que respalden la respuestas.

El objetivo principal de un protocolo es establecer ciertas reglas y acuerdos para que la comunicación se pueda llevar a cabo. Es por esto que las estructuras correspondientes a los paquetes dentro de un mismo protocolo deben ser iguales pues siguen unos estándares previamente definidos para que se pueda comprender el mensaje. Es precisamente por esto que a lo largo del laboratorio no se incluyeron mensajes de los mismos protocolos, sino que se ejemplifico con un mensaje como era la estructura de uno de ellos. A continuación se ilustra esta idea desde los mensajes capturados en los diferentes pings.

Figura 6.3.1 Ping a un servidorDNS

Figura 6.3.2 Respuesta a ping desde un usuario.

En estos mensajes se puede ver que a pesar de que uno proviene de un usuario local y otra de un servidor y además uno es una respuesta y el otro unrequest. Se observa la misma estructura: tipo, código, un checksum, un identificador, un número de secuencia, y unos datos. 3. ¿Por qué Wireshark muestra la dirección MAC vigente del enrutador local, pero

no la dirección MAC vigente de los servidores remotos al realizar una comunicación directa a ellos?

Únicamente se puede averiguar la dirección MAC de los computadores que están la misma red y también la del enrutador local en la medida en la que existe una conexión con este último. Así WireShark puede mostrar la MAC del enrutador local. Pero cuando se atraviesa una enrutador como es el caso cuando se realiza una

comunicación con un servidor remoto no se puede averiguar tal dirección MAC porque no pertenece a la misma red. Para obtener una dirección MAC a partir de una IP se hace uso del protocolo ARP , pero este sólo puede traducir una IP en dirección MAC si ésta pertenece a un router o equipo que pertenezca a la misma red: desde allí también se explica porque no se muestra la dirección MAC de los servidores remotos aunque exista comunicación entre ellos.

Cuando se desea crear una comunicación con un servidor que no pertenece a la red el proceso es diferente. Al tener en cuenta que ARP sólo funciona en la misma red no se puede utilizar este para obtener la MAC. Para comprender el proceso que se lleva a cabo cuando se intenta crear comunicación con un servidor remoto es necesario comprender que los enrutadores tienen una IP , un módulo ARP y un adaptador para cada una de sus interfaces. Así los enrutadores pueden tener varias direcciones MAC en la medida en la que cada adaptador tiene una. Para poder enviar un mensaje se requiere que se le indique al adaptador una dirección MAC de destino. Sin embargo la MAC que se le debe indicar es la que corresponde a su enrutador local y esto si lo puede obtener a través de ARP. Una vez llega al enrutador este puede determinar la interfaz a la cual el datagrama debe dirigirse y esta lo pasa a su adaptador el cual lo encapsula y lo manda a la otra red. Allí la dirección MAC si es la del destino la cual ha sido obtenida por el enrutador de dicha red a través de ARP.

4. ¿Por qué el computador envía un mensaje de tipo ARP antes de enviar la primera solicitud de ping? Explique ¿cómo opera este protocolo con respecto a lo observado en las capturas realizadas?

El computador envía un mensaje tipo ARP antes de iniciar la primera solicitud de ping porque busca averiguar la dirección MAC del destinatario delping para poder enviar allí la solicitud esto en la medida en la que para enviar un datagrama la fuente necesita darle al adaptador no solo la dirección IP sino también la MAC. Cuando por el contrario el ping se dirige a un servidor remoto se solicita la MAC del enrutador local no del servidor al que lo envía como ya se especificó en la pregunta anterior. ARP es el protocolo que permite le brinda al host que desea comunicarse a la dirección MAC que necesita a partir de una IP. En este sentido es un protocolo que

se parece al DNS aunque este último siempre puede traducir el hostname en una dirección IP, mientras que en ARP sólo puede llevarse a cabo la traducción si la IP pertenece a una interfaz de host o enrutador que pertenezca a la misma red que la del sending host. El protocolo funciona de la siguiente manera: cada sistema final o enrutador tiene una tabla ARP en la memoria la cual contiene el mapeo entre direcciones IP y MAC aunque no necesariamente tiene un registro para todas las direcciones IP de su red. Esta tabla también contiene un valor TTL que indica cuándo se debe borrar un registro de la tabla. Así que cuando se desea enviar un datagrama dentro de la misma red lo que se en primera instancia es consultar la tabla; si el registro no existe se procede a utilizar el protocolo ARP. Se envía una petición que tiene como propósito consultar con todos los hosts y enrutadores que pertenecen a la red para determinar la dirección MAC que corresponde a la IP enviada como parte de la petición. Esta petición se envía haciendo uso de unbroadcast frame porque se busca que llegue a todos los adaptadores de la red para consultar si su dirección IP es la misma que la enviada en la petición. Cada adaptador pasa el paquete al módulo ARP para que verifique y envía la dirección MAC si coincide con la IP buscada. El computador envía un mensaje ARP sólo la primera vez porque como no encuentra el registro que está buscando en la tabla , en las siguientes ocasiones no es necesario hacerlo porque ya está dicho registro allí.

7. Bibliografía

1. J.Kurose & K.Ross, Computer networking. 6.Ed. United States: Pearson, 2013. 2. R. Gellens & C. Newman & L. Lundblade. Request for Comments: 2449. POP3 Extension

Mechanism. [En línea] [Citado el: 13 de Agosto de 2015.] https://www.ietf.org/rfc/rfc2449.txt.

3. M. Rose. Request for Comments: 1081 .Post Office Protocol ­ Version 3. [En línea] [Citado el: 13 de Agosto de 2015.] https://tools.ietf.org/html/rfc1081

4. R. Gellens & J. Klensin. Request for Comments: 2476 . Message Submission . [En línea] [Citado el: 13 de Agosto de 2015.] https://www.rfc­editor.org/rfc/rfc2476.txt

5. J. Klensin. Request for Comments: 2821 . Simple Mail Transfer Protocol. [En línea] [Citado el: 13 de Agosto de 2015.] https://www.ietf.org/rfc/rfc2821.txt

6. Wireshark Wiki. Internet Message Format (imf). [En línea] [Citado el: 13 de Agosto de 2015.] https://wiki.wireshark.org/IMF

7. A. Freier & A. Karlton & P. Kocher . Request for Comments: 6101. The Secure Sockets Layer (SSL) Protocol Version 3.0 [En línea] [Citado el: 16 de Agosto de 2015.] https://www.ietf.org/rfc/rfc2821.txt

8. The Chromium Project. QUIC, a multiplexed stream transport over UDP. [En línea] [Citado el: 16 de Agosto de 2015.] https://www.chromium.org/quic

9. T. Dierks & C.Allen.. Request for Comments: 2246. The TLS Protocol Version 1.0 [En línea] [Citado el: 16 de Agosto de 2015.] https://www.ietf.org/rfc/rfc2246.txt

10. R. Fielding & J. Gettys & J.Mogul & H. Frystyc & L.Masinter & P.Leach & T.Berners Leev. Request for Comments: 2616. Hypertext Transfer Protocol ­­ HTTP/1.1 [En línea] [Citado el: 16 de Agosto de 2015.] http://tools.ietf.org/html/rfc2616

11. Microsoft TechNet. SSL/TLS in Detail. [En línea] [Citado el: 16 de Agosto de 2015.] https://technet.microsoft.com/en­us/library/cc785811(v=ws.10).aspx

12. Kurose, J. & Ross, K. (2011) Broadcast and Multicast. En Computer Networking, a top­down approach (pp.230). Addison­Wesley, 6th Ed.