- La infraestructura de red está compuesta por switches, bridges, routers, balanceadores de carga, firewalls, etc.
- El sistema operativo controla la comunicación de red clasificando paquetes, colocándolos en colas y aplicando reglas de firewall, entre otras cosas.
- Entonces, ¿qué pasaría si se usa un protocolo de capa de transporte inexistente?
- ¿El OS lo permitiría? ¿Los paquetes realmente se entregarían? ¿El firewall los bloquearía?
- Se realizó un experimento directo para comprobarlo.
Resumen del protocolo de Internet
- Internet funciona mediante múltiples capas de protocolos que transportan los datos.
- Cuando una aplicación envía una solicitud, el OS la transmite encapsulándola con encabezados de varias capas de red.
- Capa de transporte (Transport Layer): aquí se encuentran protocolos como TCP (6) y UDP (17).
- ¿Qué pasaría si se modifica el campo
Protocol del encabezado IP para poner un número no utilizado?
Experimento #1: prueba directa en mi PC
Método del experimento
- Definición de HDP (protocolo falso): diseño de un nuevo protocolo de capa de transporte totalmente distinto de los existentes.
- Implementación de servidor y cliente: desarrollo de programas para enviar y recibir paquetes.
- Prueba de loopback: observación de cómo el OS procesa los paquetes internamente.
Proceso de ejecución
$ sudo cargo run --bin server # ejecutar servidor
$ fortune | cowsay | sudo cargo run --bin client 127.0.0.1 # ejecutar cliente
Resultado
- El OS procesó correctamente los paquetes HDP y los recibió de vuelta a través de la interfaz de loopback.
- Se realizaron pruebas adicionales cambiando el número de protocolo IP.
- 1 (ICMP), 2 (IGMP), 6 (TCP) → no se detectaron en el servidor
- 50, 51 (protocolos relacionados con IPSec) → el envío fue bloqueado desde el cliente
- 256 (fuera del rango de números de protocolo IP) → se produjo un error en la etapa de llamada a
socket()
Análisis de la causa
- Hay casos en los que el OS bloquea ciertos números de protocolo porque están reservados por el sistema.
- En Darwin (macOS basado en BSD), si se establece protocol=0 en la llamada a
socket(), algunos paquetes se filtran automáticamente.
- Es muy probable que los protocolos relacionados con IPSec se bloqueen por razones de seguridad.
- Como los números de protocolo IPv4 son de 8 bits, solo son válidos del 0 al 255.
Experimento #2: envío de paquetes por Internet
Plan del experimento
- Configuración de un VPS de DigitalOcean: se montó el entorno de prueba en un servidor en la nube ubicado en Frankfurt, Alemania.
- Envío de paquetes HDP: se enviaron paquetes desde mi PC (Arabia Saudita) al servidor de DigitalOcean.
- Análisis de la reacción del equipo de red: verificar si los paquetes llegan o si el firewall los bloquea.
Resultado esperado
- Los paquetes HDP podrían entregarse normalmente, o bien ser bloqueados por algún ISP o por el firewall de DigitalOcean.
Resultado real
- Solo se entregó el primer paquete y los siguientes fueron bloqueados
- Al verificar con
tcpdump:
- Los paquetes salieron correctamente desde mi PC
- En el servidor de DigitalOcean solo se detectó el primer paquete
- Los paquetes posteriores fueron bloqueados en algún punto (NAT, firewall, ISP, etc.)
Análisis de la causa
- DigitalOcean no soporta protocolos IP no estándar.
- Es muy probable que la causa principal sea la política de firewall del proveedor cloud.
- No está claro por qué solo llegó el primer paquete.
Nueva prueba en AWS
- El experimento se repitió en AWS usando dos instancias.
- Dentro del mismo datacenter, los paquetes HDP se enviaron y recibieron correctamente.
- Sin embargo, al transmitirlos por Internet, ocurrió el mismo problema que en DigitalOcean: solo llegó el primer paquete.
Problemas principales
- NAT (Network Address Translation): como opera con base en puertos TCP/UDP, no tiene forma de manejar un protocolo nuevo como HDP.
- Filtrado de red/firewall: la mayoría de los ISP y proveedores cloud bloquean protocolos IP no autorizados.
- Problemas de optimización en equipos de red: algunos dispositivos de red podrían descartar automáticamente paquetes no estándar.
Conclusión: lo mejor es usar TCP y UDP
- La implementación del stack de red difiere entre OS
- El comportamiento de
socket() varía entre Linux, macOS y Windows.
- Los firewalls y equipos NAT bloquean protocolos no estándar
- Aunque funcione en una red privada, en Internet es casi imposible.
- No hay mejora de rendimiento
- Ya existen alternativas probadas, como QUIC implementado sobre UDP.
- Usemos TCP/UDP
- Si se usan protocolos estándar, NAT basado en puertos, firewalls y enrutamiento reciben soporte automáticamente.
Material adicional
5 comentarios
Creo que también te puede servir leer https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/.
Recuerdo que en el viejo StarCraft, cuando jugábamos multijugador por Hamachi, estaba IPX, y en ese momento me acuerdo de que tenía mucha curiosidad por saber qué era eso.
Ahora que lo pienso, NAT terminaría bloqueando todo... Si IPv6 se adoptara por completo y NAT desapareciera (aunque no creo que eso pase), quizá también sería posible comunicarse usando un protocolo propio.
Oh, buen intento...
Estuvo bien intentar sacudir los cimientos de la red, pero todos los equipos de red de este mundo están especializados solo para TCP/UDP...
Parece que podría ser posible cuando no sabes que los equipos de red se fabrican en serie... pero una vez que lo entiendes, te das cuenta de que no se puede, a menos que te vaya tan bien que logres que todos usen tu protocolo...
Comentarios de Hacker News