Seminario de Redes TRABAJO PRACTICO Nº 3. UDP y TCP. deimos_azul@yahoo.com Padrón: gonzalojosa@hotmail.

Transcripción

1 Departamento de Electrónica Facultad de Ingeniería Seminario de Redes TRABAJO PRACTICO Nº 3 UDP y TCP. Grupo: NMNK Responsable a cargo: Integrantes: Guzmán Pegazzano, Ma. Azul deimos_azul@yahoo.com Padrón: Josa Scorza, Gonzalo gonzalojosa@hotmail.com Padrón: Rodríguez Palacios, Agustina apalaci@fi.uba.ar Padrón: 77677

2 Maqueta. Para el desarrollo de las pruebas se utilizará la siguiente maqueta. Dependiendo del escenario en cuestión, se utilizará una parte de la maqueta en especial, la cual será especificada en el escenario correspondiente, es decir, la siguiente es la maqueta más general utilizándose ciertos sectores de la misma en cada caso. FI.UBA SERVER ETH. A: / PC2 PC3 PC1 INTERNET + PC L14 MDM DNS Server Descripción de los equipos utilizados. PC1: Windows XP. Ethereal. PC2: Windows 98. Ethereal. PC3: Linux Red Hat 7.2 PCL14: Linux. 2

3 Escenario I. DHCP sobre UDP Objetivo: En este escenario se desea observar como se encapsulan los mensajes DHCP sobre el protocolo UDP. Desarrollo: Dentro de la red Ethernet A se configura la PC 1 como servidor DHCP y a la PC3 como cliente DHCP. Se sniffeará el tráfico en la LAN cuando el cliente DHCP negocia el arrendamiento de una dirección IP al bootearse. En particular, se analizarán los puertos utilizados por UDP. Ejecución: En esta trama se observa que el protocolo DHCP viaja sobre UDP, utilizando los puertos 67 y 68. En particular, el puerto que utiliza el servidor es el 67, y el que utiliza el cliente es el 68. En el header UDP no se manifiesta cual es el protocolo que está encapsulando. Conclusiones: Vemos que DHCP utiliza el protocolo UDP para encapsularse, usando los puertos reservados 67 y 68 tal como se manifestó anteriormente. Utiliza UDP y no TCP porque los diálogos que se establecen no son punto a punto sino del tipo broadcast, ya que en el proceso de arranque se desconoce la dirección IP del servidor DHCP a contactar, necesaria para establecer una conexión TCP. 3

4 Escenario II. Transacciones DHCP Objetivo: Se pretenden observar distintos mensajes DHCP que se intercambian en el arrendamiento de una dirección IP. Desarrollo: Este escenario, se desarrolla con la misma configuración anterior (la PC 1 como servidor DHCP y la PC3 como cliente DHCP), y se observarán los distintos mensajes que se ven involucrados en el momento de arrendar una dirección IP. Un host difunde un mensaje broadcast de nivel 2 (DHCP DISCOVER) a todos los servidores DHCP de la red LAN (en este caso la PC1) con el fin de obtener una dirección IP. El servidor responde a este pedido enviando un mensaje DHCP OFFER, sugiriendo una posible IP. El cliente selecciona la dirección IP y negocia el arrendamiento con el servidor enviándole un mensaje DHCP REQUEST avisando que va a aceptar la dirección IP propuesta. Por último el servidor le confirma el arrendamiento mediante un mensaje DHCP ACK. Ejecución: La secuencia de tramas obtenidas fue la siguiente: 4

5 El primer paquete, correspondiente al DHCP DISCOVER, posee los siguientes campos: Este es un mensaje del tipo Boot Request, lo cual se observa en el campo Message Type. A su vez, también se puede ver que es un mensaje de broadcast como se dijo anteriormente, lo cual se ve en la trama Ethernet. En el campo de opciones, se destaca que el tipo de mensaje DHCP es el de DHCP Discover. La trama correspondiente al paquete DHCP OFFER es: 5

6 En esta trama se observan todos los parámetros que debe tener el cliente para arrendar una dirección IP, tales como el tiempo de arrendamiento (opción 59), tiempo de reasignación (opción 58), y el tiempo de expiración (opción 51). A su vez se envía información adicional como las direcciones IP del gateway y del DNS server asociado a la LAN. Se observa que este mensaje también es un broadcast de nivel 2. La trama correspondiente al paquete DHCP Request es: 6

7 En este paquete se observa en el campo option 50, cual es la dirección IP elegida que es la La trama correspondiente al paquete DHCP ACK es: En este paquete, el servidor DHCP le confirma al host que puede comenzar a utilizar esa dirección IP a partir de ese momento. Con esta trama termina la transacción. 7

8 Conclusiones: Como primer observación, notamos que el servidor envía mensajes ARP intercalados antes de enviar el mensaje DHCP OFFER, y antes del mensaje DHCP ACK. Suponemos que el servidor realiza consultas ARP con el fin de verificar que la IP propuesta al cliente no esté siendo utilizada por ningún host dentro de la misma LAN. Notamos también que el host, luego de haber recibido la confirmación de su dirección IP, envía un mensaje ARP broadcast, consultando a la red para confirmar que nadie la esté utilizando. Todos los mensajes DHCP observados son del tipo broadcast. Creemos que es así con el fin de que todos los hosts de la red sean informados acerca de la existencia de una nueva dirección IP en la red. 8

9 Escenario III: TFTP sobre UDP Objetivo: Desarrollo: El objetivo de este escenario es ver como se encapsula TFTP en UDP. Para lograr este escenario se realizó un TFTP desde la PC1 hacia la PC3 dado que en este caso la PC3 actuaba como servidor TFTP (dado que el servidor TFTP que teníamos corría sobre Windows 98). TFTP se diseñó para aplicaciones que no necesiten interacciones complejas entre cliente-servidor. TFTP no necesita un transporte de flujo confiable por lo que no es necesario que viaje sobre TCP; razón por la cual se utiliza UDP. Ejecución: Se realizó la siguiente captura: En esta captura se puede observar que TFTP utiliza el puerto 69 de UDP como puerto destino y un puerto efímero como puerto origen (puerto 3222 en este caso). La trama 107 es la primer trama de la aplicación TFTP, la cual indica el tipo de mensaje que interviene (en este ejemplo se realiza un pedido de lectura). Conclusiones: TFTP utiliza como protocolo de transporte UDP ya que no necesita interacciones complejas entre servidor-cliente ni un transporte de flujo confiable. 9

10 Escenario IV: TFTP Objetivo: Se desean analizar los distintos mensajes de TFTP y el funcionamiento de esta aplicación. Desarrollo: Para realizar este escenario realizamos diferentes transferencias TFTP con 2 tipos de mensajes: Read Request y Write Request. En estas transferencias también se involucran los mensaje de datos, acknowledge y error. Ejecución: Para la operación de lectura se capturó la siguiente trama: Este primer mensaje es generado por el cliente, quien utiliza un puerto efímero (3222). El puerto contra el cual se establece la conexión en el servidor es el puerto 69 de UDP. En la operación de lectura el primer mensaje es del tipo Read Request, lo cual se observa en el campo opcode con valor igual a 1. En el header de TFTP también se muestra el archivo sobre el cual se desea realizar la operación (readme.txt). 10

11 Los paquetes subsiguientes son del tipo de mensaje datos con sus correspondientes acknowledges : En la trama de datos, se observa que el opcode tiene valor 3 y que el tamaño de los paquetes es 512 bytes (máximo tamaño de datos que permite UDP). El último paquete de datos es el siguiente: En éste se observa que la cantidad de datos es de 61 bytes. TFTP interpreta esto como que éste es el último paquete de datos ya que todos los paquetes de datos poseen un tamaño de 512 bytes con excepción del último. Cuando se recibe un paquete de tamaño inferior, se infiere que la transferencia de datos ha terminado. 11

12 En un mensaje del tipo acknowledge el campo de opcode posee un valor igual a 4. Por cada paquete de datos recibido se manda un mensaje de acknowledge. Hasta que éste no se recibe no se envía el siguiente mensaje de datos. Es interesante observar dentro del paquete TFTP el campo block indica el segmento al cual se refiere el acknowledge en cuestión. El campo block tanto en el mensaje de datos como en el acknowledge indica la correspondencia que existe entre estos. El campo block indica la posición relativa del segmento de datos dentro del archivo total a transmitir. Para la operación de escritura se capturó la siguiente trama: En esta trama el tipo de mensaje es de Write Request. Esto se observa en el campo opcode con valor igual a 2. A diferencia del mensaje Read Request, este mensaje tiene un campo de Destination File, el cual indica el archivo que se desea escribir (readme.txt). 12

13 En una operación de escritura, las tramas de datos poseen el mismo formato que en la operación de lectura. Conclusiones: TFTP establece la conexión con el puerto 69 de UDP. Una vez que se ha establecido la conexión este puerto queda liberado y el servidor cambia a un puerto efímero cualquiera, de manera de dejar disponible este puerto para otras conexiones sucesivas TFTP. En este caso se observa que el puerto efímero que utiliza el destino es el Las tramas de datos poseen igual formato tanto para las operaciones de lectura y escritura. Para saber cuando finaliza la transferencia de datos, TFTP analiza el tamaño de los paquetes de datos. Cuando recibe un paquete de tamaño menor al máximo aceptado por UDP (512 bytes), determina que es el último paquete de datos, dando por finalizada la transferencia. 13

14 Escenario V: Establecimiento de la conexión en TCP. Objetivo: El objetivo de este escenario es ver cómo realiza TCP el establecimiento de una conexión. Desarrollo: Dado que TCP es un protocolo orientado a la conexión, antes de el envío de datos, debe establecerse una conexión. En un segmento TCP existen los siguientes flags: Flag Abreviación Observación S SYN Sincroniza el número de secuencia F FIN Quien lo envía deja de enviar datos. R RESET Reseteo de la conexión P PUSH Empuja los datos hacia el proceso de recepción lo antes posible. A ACK Acknowledge de segmentos recibidos. U URG Indica datos Urgentes. Cuando el flag push se encuentra activado, esto es una notificación del emisor al receptor para que éste pase todos los datos que tiene en la cola al proceso de recepción. Los datos que se transfieren al proceso de recepción son todos aquellos que se encuentren en la cola más los que llegan con el flag push activado. En el inicio de la conexión, el primer paquete contiene el falg SYN activado, especificándose el número de puerto del servidor al cual se quiere conectar junto con el número de secuencia inicial del cliente. El servidor responde también con su bit de SYN activado, el cual contiene su número de secuencia inicial. El servidor también realiza el ACK del SYN del cliente enviándole el número de secuencia del cliente más uno (ISN cliente + 1). El cliente debe a su vez, hacer un ACK del SYN del servidor transmitiéndole el numero de secuencia del servidor más uno (ISN servidor + 1). Con este último paquete finaliza el establecimiento de la conexión. Esta recibe el nombre de Threeway handshake. Quien envía el primer SYN realiza la apertura activa y el otro la apertura pasiva. El valor del ISN debe cambiar a lo largo del tiempo para que cada conexión tenga un valor de ISN distinto. En el establecimiento de la conexión también se negocia el máximo tamaño de segmento permitido en bytes (MSS: Maximum Segment Size). El emisor no desea recibir segmentos TCP mayores al valor indicado por este parámetro. Este valor se elige con el fin de evitar la fragmentación en TCP. El tamaño del MSS es en general de 1460 bytes, ya que se tiene en cuenta una MTU de 1500 bytes, 20 bytes de encabezado de IP y 20 bytes de encabezado TCP. El campo window size indica el tamaño de la ventana de datos disponible que se puede recibir. Tanto quien realiza la apertura activa, como quien realiza la apertura pasiva envían tamaños máximos de ventana en el inicio de la conexión; ambos tamaños son independientes entre sí. Los mismos pueden ir variando a lo largo de la conexión, según sea la congestión existente en el enlace. 14

15 Para poder observar lo arriba expuesto realizaremos una conexión TELNET entre la PC1 y la PC2. Ejecución: Se capturaron las siguientes tramas: En el segmento señalado se observan lo siguiente: el bit de SYN activado, ya que éste es el primer segmento de una conexión TCP establecida el número de secuencia inicial ( ) el tamaño de window size (16384) el MSS (1460) Se observa que en este caso, el número de puerto al cual se quiere conectar el cliente es el 23; es decir Telnet, ya que la aplicación que utilizamos era ésta. En el siguiente segmento el servidor inicia la conexión en el sentido opuesto, observándose los siguientes bytes: 15

16 el bit de SYN está activado el número de secuencia inicial correspondiente a ese sentido de la transmisión el ACK del segmento SYN recibido el window size del servidor el mismo MSS Se observa que el número de puerto destino en este paquete, corresponde al mismo número de puerto de origen del paquete anterior. Por último, vemos el tercer paquete involucrado en el establecimiento de la conexión: 16

17 Notamos que el ACK es igual al número de secuencia anterior, más uno, y que el número de secuencia de este paquete es superior en uno, con respecto al número de secuencia del primer paquete ( = ). Se ve que en este paquete el tamaño de la ventana aumentó con respecto al primer paquete (de pasó a 17520). Conclusiones: Se puede concluir que al establecerse una conexión TCP se utiliza un socket pair, es decir; cada extremo de la conexión reserva un puerto para la conexión, manteniéndolo durante el transcurso de la misma. El hecho de que exista un número de secuencia para cada sentido de la conexión se debe a que la misma es full-duplex. El MSS se determina en los dos primeros paquetes intercambiados, por lo tanto, este dato no aparece en el resto de la conexión. El tamaño de la ventana aumenta en los paquetes sucesivos, debido a que TCP no detectó congestión en el enlace y por lo tanto puede aumentarlo. 17

18 Escenario VI: Finalización de la conexión en TCP. Objetivo: El objetivo de este escenario es ver cómo realiza TCP la finalización de una conexión. Desarrollo: En la finalización de la conexión intervienen 4 paquetes debido a que la conexión TCP es full-duplex y por lo tanto cada extremo debe finalizar su conexión. Cualquiera de los extremos que no quiera enviar mas datos, enviará una segmento con el flag FIN activado. El receptor realiza una acknowledge de éste segmento dando por finalizada la conexión en es sentido. A partir de este momento la conexión se vuelve half-duplex es decir, el extremo que cerró su conexión solo enviará mensajes de acknowledge hacia el otro extremo. Cuando éste último desea finalizar por completo la conexión, envía un FIN esperando recibir el ACK correspondiente. Quien envía el primer FIN realiza lo que se llama finalización activa y quien responde realiza la finalización pasiva. Ejecución: Durante la finalización de la conexión anterior se capturaron las siguientes tramas: En esta trama se puede observar que tanto el flag de ack y el flag de fin están activados. Esto se debe a que para no generar tráfico de más se aprovecha el mensaje de acknowledge de datos para enviar a su vez el anuncio de fin. 18

19 El mensaje de acknowledge para la trama anterior es el siguiente: En esta trama se observa que el bit de FIN no está activado; esto se debe a que en este caso se esta finalizando la conexión en un solo sentido. Conclusiones: TCP permite enviar el flag de FIN junto con el acknowledge de un paquete de datos con el fin de no generar tráfico extra en el enlace. La conexión puede finalizarse en un solo sentido permitiendo al otro extremo continuar con la suya. Por ello, el extremo que finaliza su transmisión de datos, no libera el puerto que estaba utilizando para la misma. El socket-pair es liberado solo cuando la conexión termina por completo, luego de transcurrido un tiempo de 2MSL (tiempo de espera para liberar el socket-pair). 19

20 Escenario VII: FTP sobre TCP. Objetivo: Desarrollo: El objetivo de este escenario es observar como funciona FTP sobre TCP. Se realizó una transacción FTP (get) desde la PC1 hacia la PC 2, donde está instalado un servidor FTP. Cuando el cliente en la PC1 establece la conexión con el servidor en la PC2, el cliente utiliza un número de puerto aleatorio y se pone en contacto con el puerto 21 del servidor. Este par de números de puertos son los que se utilizan para la conexión de control. Para realizar la transferencia de datos se utiliza un par de puertos diferentes, en particular el puerto 20 en el servidor y un puerto efímero en el cliente. El cliente utiliza el canal de control para comunicarle al servidor el puerto efímero por el cual debe establecer la conexión de datos. En caso de que el cliente no le comunique esto, el servidor establece la conexión de datos con el mismo puerto con el cual tiene establecida la conexión de control. 20

21 Ejecución: En estas primeras tramas se puede observar como se establece la conexión TCP entre la PC1 y la PC2: 21

22 En estas tramas se observa que la conexión se establece entre el puerto efímero 3017 del cliente y el puerto 21 (reservado para FTP) del servidor. En la trama siguiente se puede observar cuando el cliente le envía al servidor el puerto efímero con el cual debe establecer la conexión de datos: 22

23 En la última línea del campo FTP, el cliente envía el puerto que debe utilizar el servidor para transmitirle datos. Este puerto se coloca a continuación de la dirección IP del cliente de la siguiente manera: donde: dirección IP del cliente: puerto efímero a conectar (en base 256): El valor del puerto es entonces (11.203) 256 = 3019 A continuación se observa la trama en la cual se pide el archivo setuplog.txt : Dentro de la trama de FTP se encuentra el campo de request arg, donde se escribe el archivo que se desea obtener (setuplog.txt). 23

24 En las siguientes tramas se observa el establecimiento de la conexión para el tráfico de datos: 24

25 En esta trama se puede observar que la conexión se estableció contra el puerto 3019 del cliente. Con respecto a la finalización de la conexión: Se observa que cuando la PC2 (ana.mshome.net) finaliza la transferencia de datos, ésta realiza el cierre activo de la conexión enviando un FIN a la PC1 (hppav.mshome.net) junto con el acknowledge de los últimos datos recibidos. 25

26 La trama anterior es el ACK al FIN enviado por la PC2. La trama siguiente es la correspondiente a la finalización pasiva que realiza la PC1. La misma envía una trama con el bit FIN activado hacia la PC2. 26

27 Luego, la PC2 responde con un ACK correspondiente: Las tramas anteriores representan la finalización de la conexión de datos. Como la conexión de datos es independiente de la conexión de control, ésta también necesita su finalización. En este caso es la PC1 quien realiza la finalización activa de la conexión de control: 27

28 La PC2 envía el ACK correspondiente: La PC2 realiza la finalización pasiva de la conexión de control: 28

29 En el momento de la finalización de la conexión de datos y de control, se libera el socket-pair utilizado en la conexión. Conclusiones: Cuando se utiliza el protocolo FTP, se observa que en lugar de una sola conexión TCP, se obtienen dos conexiones completamente independientes entre sí. La primera conexión se realiza para los comandos de control y se establece entre el puerto 21 del servidor y un puerto efímero cualquiera del cliente. La segunda conexión se establece entre el puerto 20 del servidor y otro puerto efímero del cliente, el cual es comunicado al servidor a través de la primera conexión. En caso que el cliente no le especifique otro puerto efímero, la conexión de datos se establece en el mismo puerto que la primera; debiendo éste multiplexar la información que le llegue. Pese a que cuando finaliza la transmisión de datos el puerto 20 del servidor y el puerto efímero correspondiente quedan liberados; la conexión de control se mantiene en caso de que se quiera realizar otra operación. La conexión de control finaliza cuando se tipea el comando bye, indicando que se desea terminar la aplicación. 29

30 Escenario VIII: Conexiones de datos sucesivas en FTP. Objetivo: El objetivo de este escenario es observar como se establecen 2 conexiones de datos sucesivas bajo la misma sesión de FTP; analizando si se utiliza el mismo puerto efímero del cliente en ambas conexiones. Desarrollo: Para lograr el objetivo se inició una sesión FTP de la PC1 a la PC2 para obtener dos archivos diferentes blue.txt y bluedot.txt que se encontraban en la PC2. Ejecución: A continuación se destacan las tramas que involucran el establecimiento de las transmisiones de datos. En primer lugar se muestra la transferencia de datos del primer archivo; luego la del segundo archivo, obtenidos de la PC2 mediante la operación get. 30

31 Conclusiones: A partir de el sniffeo de los paquetes podemos observar que al ejecutar dos transacciones get en una misma sesión FTP; al finalizar una, y comenzar otra los puertos asignados por el cliente para recibir los datos son diferentes. 31

32 Escenario IX: Aplicación de TCP según el sistema operativo. Objetivo: Determinar las diferencias de la implementación de TCP sobre distintos sistemas operativos. Desarrollo: Se realizó una sesión de TELNET entre la PC1 con sistema operativo Windows XP y la PC3 con Linux y una conexión FTP entre la PC1 y la PC2 con Windows 98. Una vez capturado el tráfico de ambas conexiones se analizarán las diferencias en la implementación de TCP. Ejecución: Las tramas correspondientes a la conexión TELNET son las siguientes: El primer segmento corresponde al enviado desde la PC1 con Windows XP hacia la PC3 con Linux; mientras que el segundo es la respuesta al primero. 32

33 Se realizó una nueva captura, pero en este caso se corrió la aplicación FTP desde la PC1 a la PC2, y se analizaron los paquetes intercambiados en las dos direcciones: Conclusiones: Vemos que la única diferencia que existe al variar las plataformas en donde se implementa TCP, es el tamaño de la ventana. Los demás parámetros no varían ya que están dados por factores externos al sistema operativo en curso. Es el caso de el valor del MSS, que está dado por la interfaz de capa 2 (Ethernet), o el caso de la asignación de los puertos TCP utilizados, que sólo están dados en función de la aplicación que se corre. El mayor tamaño de ventana se observa en la PC1 en donde corre el sistema operativo Windows XP. Luego sigue el tamaño de ventana de Windows 98, y por último el de Linux. 33

34 Escenario X: Congestionamiento del enlace. Objetivo: Desarrollo: El objetivo de este escenario es observar el congestionamiento del enlace. Se realizará una transacción FTP entre la PC2 y el servidor FTP ftp.fi.debian.org. A la vez se realizarán transacciones FTP desde la PC1 con el servidor remoto para cargar el enlace y se trazará la curva de congestión correspondiente. En un principio se negociará un tamaño de ventana dado. Cuando se realicen las nuevas conexiones FTP que comparten el enlace, se deberá negociar un nuevo tamaño de ventana ya que todas compartirán el mismo ancho de banda, aumentando los tiempos de tránsito de los paquetes en la red. Este aumento influye en la determinación del tamaño de la ventana, ya que éste se calcula a partir de los tiempos. Ejecución: FTP. La operación realizada fue un get transfiriéndose un archivo desde el servidor Los paquetes en los cuales se observa el bit de CWR seteado son los siguientes: 34

35 Estos paquetes corresponden a la inicialización de la conexión de datos. Una vez capturado todo el tráfico de la transferencia de datos original se realizó el gráfico que representa el intercambio de paquetes de dicha conexión en función del tiempo. time 35

36 Conclusiones: Las variaciones de pendientes en el gráfico representan los cambios en la tasa de transferencia denotando que el enlace se encuentra congestionado. Al principio se observa que la pendiente es máxima ya que en el enlace sólo está presente la transferencia de datos original. A medida que comienzan a establecerse nuevas conexiones, la pendiente va disminuyendo debido a que el enlace comienza a ser compartido por todas las sesiones. Las variaciones de pendiente que aparecen en la mitad de la curva corresponden a la finalización e inicio de las sesiones FTP utilizadas para cargar el enlace. 36