Fundamentos de Redes y Arquitecturas
PEC3
Luis Mateo Sanchez
Ejercicio 1
El protocolo ICMP (Internet Control Message Protocol) trabaja junto con el protocolo IP para
detectar y notificar errores en la red sin corregirlos directamente. ICMP envía mensajes
como "Destination Unreachable" y "Time Exceeded" para informar de problemas,
encapsulando estos mensajes en paquetes IP que se dirigen al origen del paquete
problemático. La corrección de errores se deja a protocolos de transporte como TCP, que
maneja la retransmisión de paquetes, permitiendo que ICMP sea simple y eficiente en su
función de notificación.
Ejercicio 2
He analizado el tráfico de red con Wireshark y encontré un total de 13 paquetes ICMP. Estos
paquetes se dividen en dos grupos principales: enviados y recibidos. La IP del servidor al
que he realizado ping es [Link], y esta dirección la encontré en la columna
"Destination" de Wireshark. Esta dirección IP aparece en distintas columnas, como
"Source" y "Destination", dependiendo de la dirección del flujo del paquete: cuando el
paquete es enviado al servidor, la IP aparece en "Destination", y cuando el servidor
responde, la IP del servidor aparece en "Source". Esto refleja el intercambio bidireccional de
paquetes entre mi máquina y el servidor.
Ejercicio 3
3.1. La dirección IP del emisor es **[Link]**.
3.2. Los puertos de origen y destino son identificadores específicos de los protocolos de
transporte como TCP y UDP. El protocolo ICMP opera a nivel de red y no a nivel de transporte,
por lo que no utiliza puertos. En lugar de puertos, ICMP utiliza los campos de tipo y código
para definir su propósito y manejar el control de mensajes.
3.3.
• Type: 8 (Echo Request, utilizado para enviar una solicitud de ping)
• Code: 0 (Significa que no hay subcódigo adicional para el tipo de mensaje Echo
Request)
3.4. La identificación del número de protocolo en el encabezado IP para ICMP es 1. Este
número indica que el contenido del paquete es un mensaje ICMP, diferenciándolo de otros
protocolos de la capa de red, como TCP (número de protocolo 6) o UDP (número de
protocolo 17).
Ejercicio 4
He realizado un traceroute a [Link] y observé 18 saltos. Traceroute identifica cada
router intermedio utilizando el campo TTL (Time to Live) en los paquetes IP. Cada vez que un
paquete alcanza un router, este decrementa el TTL y si llega a 0, envía un mensaje ICMP
"Time Exceeded" de vuelta al origen, revelando la dirección IP del router.
Nodos de las ciudades: Miami, Ashburn y Unión Chocó.
Ejercicio 5
Realicé un traceroute a [Link] y observé que los paquetes dieron varios saltos
hasta llegar al destino, completándose exitosamente debido a la proximidad de
Norteamérica a mi ubicación en Latinoamérica. Comparando los tiempos de respuesta con
el traceroute anterior a [Link] (que no se completó), noté que los tiempos a
[Link] fueron significativamente más bajos, debido a la menor distancia y
menos routers intermedios.
La traza incompleta a [Link] probablemente se deba a restricciones de firewall,
redes privadas que bloquean paquetes ICMP, o la mayor cantidad de saltos y complejidad
de la ruta, lo que aumenta la probabilidad de encontrar nodos que no respondan a las
solicitudes ICMP. A continuación, adjunto una captura de pantalla de mi consola con el
resultado del traceroute a [Link].
Ejercicio 6
Además de las razones ya mencionadas, existen varios motivos adicionales por los cuales
un ping puede no recibir una respuesta. Muchas redes y dispositivos implementan firewalls
que bloquean paquetes ICMP para mejorar la seguridad, y algunos dispositivos están
configurados específicamente para no responder a solicitudes de ping. También, la
congestión de la red puede hacer que los paquetes ICMP excedan el tiempo de espera antes
de llegar a su destino. Problemas de conectividad, como interrupciones en la red o fallos en
los enlaces, también pueden impedir que los paquetes ICMP lleguen a su destino. Por
último, en algunas redes, las rutas asimétricas pueden causar problemas, ya que la ruta de
ida y vuelta de los paquetes puede ser diferente, y un problema en cualquiera de las rutas
puede impedir la respuesta.
Ejercicio 7
Protocolo Número de RFC Año de publicación Transporte Seguridad
HTTP/3 RFC 9114 2021 UDP TLS 1.3
Ejercicio 8
Al realizar capturas de tráfico en Wireshark, he notado que no se capturan paquetes cuando
uso el filtro http. Sin embargo, con el filtro tls, sí veo tráfico. A pesar de navegar a páginas
que utilizan solo HTTP (sin HTTPS), no aparece nada en la captura. Estoy utilizando la última
versión de Chrome y he verificado que estoy en la interfaz de red correcta, pero el problema
persiste.
Ejercicio 9
Al seguir los pasos establecidos en el ejercicio 8, no he logrado capturar paquetes HTTP
específicos en Wireshark. Sin embargo, si hubiera capturado un paquete HTTP, los detalles
de la cabecera IP que se podrían encontrar incluirían:
• Versión (Version): Indica la versión del protocolo IP, generalmente IPv4 o IPv6.
• Longitud de la Cabecera (Header Length): Especifica la longitud de la cabecera IP.
• Tipo de Servicio (Type of Service): Define la prioridad y la calidad del servicio del
paquete.
• Longitud Total (Total Length): La longitud total del paquete IP, incluyendo datos y
cabecera.
• Identificación (Identification): Identificador único del paquete IP, usado para la
reensamblaje de fragmentos.
• Flags: Banderas que controlan la fragmentación del paquete.
• Desplazamiento de Fragmentos (Fragment Ogset): La posición del fragmento en el
paquete original.
• Tiempo de Vida (TTL): Tiempo que el paquete puede existir en la red antes de ser
descartado.
• Protocolo (Protocol): Protocolo de la capa superior al que se entregará el paquete,
como TCP o UDP.
• Checksum de la Cabecera (Header Checksum): Verifica la integridad de la cabecera
IP.
• Dirección IP de Origen (Source Address): Dirección IP del emisor del paquete.
• Dirección IP de Destino (Destination Address): Dirección IP del receptor del paquete.
Ejercicio 10
Siguiendo el mismo procedimiento, no logré capturar paquetes HTTP en Wireshark. De
haberse capturado, los elementos de la cabecera TCP que se podrían analizar incluirían:
• Puerto de Origen (Source Port): Puerto del cual se envía el paquete.
• Puerto de Destino (Destination Port): Puerto al cual se envía el paquete.
• Número de Secuencia (Sequence Number): Número que identifica el orden de los
paquetes.
• Número de Acuse de Recibo (Acknowledgment Number): Número que confirma la
recepción de datos.
• Longitud de la Cabecera (Data Ogset): Tamaño de la cabecera TCP.
• Flags: Controlan diversas funciones de la conexión (SYN, ACK, FIN, etc.).
• Ventana de Recepción (Window): Tamaño de la ventana de recepción.
• Checksum: Verificación de errores en la cabecera y datos.
• Puntero Urgente (Urgent Pointer): Indica datos urgentes.
• Opciones (Options): Opciones adicionales de la cabecera.
Lamentablemente, no puedo proporcionar capturas de pantalla debido a la falta de
paquetes HTTP en la captura de Wireshark realizada.
Ejercicio 11
Lamentablemente, no he logrado capturar paquetes HTTP específicos en Wireshark
siguiendo los pasos establecidos en el ejercicio 8. Sin embargo, aquí está la información
que se podría encontrar:
1. Puerto Destino:
o HTTP: El puerto destino típico para conexiones HTTP es el puerto 80. Este
puerto se utiliza porque está reservado para el tráfico HTTP en los estándares
de red.
o HTTPS: Si la conexión fuera contra un servidor HTTPS, el puerto destino
cambiaría a 443, que es el puerto reservado para el tráfico HTTPS cifrado.
2. Puerto Origen:
o El puerto origen es asignado dinámicamente por el sistema operativo del
cliente y generalmente es un puerto efímero (números de puerto mayores a
1024). Este puerto puede variar cada vez que se cierra el navegador y se vuelve
a abrir para generar una nueva petición GET
Ejercicio 12
Aunque no capturé los paquetes necesarios para este ejercicio, el procedimiento del three-
way handshake en TCP es el siguiente:
1. SYN: El cliente envía un segmento TCP con la bandera SYN (Synchronize) para iniciar
la conexión.
2. SYN-ACK: El servidor responde con un segmento SYN-ACK (Synchronize-
Acknowledge), indicando que ha recibido el SYN del cliente y está listo para
establecer la conexión.
3. ACK: El cliente envía un segmento ACK (Acknowledge) al servidor, confirmando que
ha recibido el SYN-ACK del servidor. La conexión ahora está establecida.
Ejercicio 13
HTTPS (Protocolo de Transferencia de Hipertexto Seguro) fue desarrollado por Netscape
Communications en 1994 para el navegador Netscape Navigator, utilizando inicialmente el
cifrado SSL (Secure Sockets Layer). Con el tiempo, se descubrieron vulnerabilidades en SSL,
lo que llevó a la creación de TLS (Transport Layer Security), una versión mejorada y más
segura. TLS ofrece mayor seguridad y eficiencia en la transmisión de datos. Las principales
causas de la evolución de SSL a TLS incluyen las vulnerabilidades de seguridad encontradas
en SSL, la necesidad de mejorar la eficiencia, y la adopción de TLS como estándar por parte
de organizaciones como el IETF.
Ejercicio 14
Al capturar tráfico en Wireshark para la URL `[Link] observé paquetes
etiquetados como `TLSv1.2 Record Layer: Application Data Protocol: HyperText Transfer
Protocol 2`, lo que indica el uso del protocolo HTTPS. Esto significa que los datos
intercambiados entre el cliente y el servidor están cifrados. Aunque se puede ver que hay
tráfico de datos, no es posible obtener información específica sobre los mensajes o páginas
web debido al cifrado, lo que garantiza la privacidad y seguridad de la información
transmitida.
Ejercicio 15
En la captura de Wireshark, se puede observar cómo el navegador web y el servidor
intercambian información sobre el protocolo de cifrado y cómo mantendrán la conexión
segura. Durante el proceso de handshake TLS, el navegador envía un mensaje `ClientHello`
que incluye una lista de algoritmos de cifrado soportados. El servidor responde con un
mensaje `ServerHello` que selecciona el algoritmo de cifrado que se utilizará. Luego, el
servidor envía su certificado digital para que el navegador pueda verificar su autenticidad.
Una vez establecida la conexión segura, todos los datos intercambiados entre el navegador
y el servidor están cifrados utilizando el protocolo TLS, garantizando así la privacidad y
seguridad de la información.
En cuanto a HTTP/3, el primer borrador de esta versión se definió en 2018. HTTP/3 es una
mejora significativa sobre sus predecesores, ya que utiliza el protocolo QUIC en lugar de
TCP, lo que permite una conexión más rápida y eficiente, reduciendo la latencia y mejorando
la experiencia del usuario en la web.
Ejercicio 16
Al realizar una captura en Wireshark mientras visitas [Link] con un
navegador compatible con HTTP/3, se observa que los paquetes utilizan el protocolo QUIC.
QUIC es un protocolo de transporte desarrollado por Google que utiliza UDP en lugar de TCP,
mejorando la velocidad y la eficiencia en la transmisión de datos, especialmente en redes
con alta latencia. A diferencia de HTTP/2 que usa TLS sobre TCP, HTTP/3 integra la
encriptación TLS 1.3 directamente en QUIC, proporcionando conexiones más rápidas y
seguras al combinar transporte y encriptación en un solo protocolo.
Ejercicio 17
DNS (Domain Name System) es un sistema que traduce nombres de dominio en direcciones
IP, permitiendo que las computadoras se identifiquen y comuniquen en la red. La
herramienta `nslookup` se utiliza para consultar servidores DNS y obtener información
sobre nombres de dominio y direcciones IP, siendo útil para diagnosticar problemas de red
y verificar configuraciones DNS.
Un servidor DNS autoritativo proporciona respuestas definitivas y precisas sobre los
dominios que administra, mientras que un servidor no autoritativo ofrece respuestas
basadas en información en caché, que puede no ser completamente actual. La diferencia
clave radica en la fuente y la confiabilidad de la información proporcionada por estos
servidores.
Ejercicio 18
Las peticiones DNS y sus respuestas se envían generalmente mediante UDP por su rapidez
y eficiencia. Sin embargo, si la respuesta es demasiado grande o se requiere mayor
fiabilidad, se utiliza TCP. Las peticiones DNS utilizan el puerto de destino 53, mientras que
las respuestas suelen venir del puerto 53 en el servidor DNS, con el cliente usando un puerto
efímero. Esta configuración permite una resolución de nombres de dominio eficiente y
confiable.
Al capturar el tráfico DNS en Wireshark, es posible observar las peticiones y respuestas DNS
mediante el filtro `dns`. Las peticiones desde el cliente se originan en puertos efímeros y
se dirigen al puerto 53 del servidor DNS, y las respuestas vienen del puerto 53 del servidor.
Esto facilita la identificación y análisis de las consultas DNS en la red.
Ejercicio 19
La dirección IP de mi servidor DNS es `fe80::1%14`, que es una dirección IPv6 link-local
utilizada para comunicación en la red local. Esto se deduce de la salida de la herramienta
`nslookup`, que mostró que las respuestas provienen de un servidor local. La respuesta
"non-authoritative" indica que el servidor DNS respondió con información en caché en lugar
de directamente desde la fuente autoritativa del dominio.
Ejercicio 20
El servidor me devolvió la información sobre el autor en formato JSON. Además, en las
cabeceras de la respuesta que muestra Postman, puedo ver detalles como la fecha de la
respuesta, el tipo de codificación (content-encoding), y el servidor que procesó la solicitud.
Esta información me permite entender mejor cómo se ha gestionado la petición y la
respuesta.
Ejercicio 21
En la petición HTTP, puedo ver que se está utilizando la versión 1.1 del protocolo. Además,
es posible observar los datos de latitud y longitud en el mensaje HTTP. Sin embargo, no se
está utilizando encriptación, lo que tiene serias implicaciones para la seguridad. Sin
encriptación, la información sensible podría ser interceptada y leída por terceros, poniendo
en riesgo la privacidad y la integridad de los datos. Aquí te adjunto una captura de pantalla
de Wireshark para apoyar lo descrito.
Ejercicio 22
Al filtrar la captura para mostrar solo los paquetes intercambiados con el servidor de 7timer,
no puedo ver la versión del protocolo ni los datos de latitud y longitud en la petición original
que enviamos con Postman. A diferencia del ejercicio anterior, aquí toda la información
aparece cifrada, lo que impide identificar esos detalles específicos en la captura.
Esta diferencia se debe a la implementación de cifrado en la comunicación con el servidor
de 7timer, lo cual asegura que los datos sensibles no sean accesibles para terceros. Esto
resalta la importancia del uso de HTTPS y otros métodos de encriptación para proteger la
integridad y privacidad de la información transmitida. Adjunto una captura de pantalla de
Wireshark que muestra cómo la información aparece cifrada, apoyando lo descrito en este
ejercicio.