La ausencia de handshake no elimina el estado
Una aplicación puede enviar un datagrama UDP y recibir una respuesta sin abrir una conexión como la de TCP. Esa observación es correcta y, sin embargo, insuficiente para describir el sistema. UDP no garantiza entrega, orden ni protección frente a duplicados; el kernel mantiene sockets y colas, un NAT puede conservar una traducción con expiración, un firewall puede hacer seguimiento del flujo y la aplicación puede asociar una respuesta con un identificador de solicitud. «Sin sesión aparente» describe una interfaz o un protocolo de transporte, no la ausencia de estado en todos los niveles.
ICMP (Internet Control Message Protocol) parece distinto porque informa errores y ofrece diagnósticos, pero no es un canal de confirmación confiable ni una prueba de autenticidad. Un mensaje puede decir que un nodo descartó un datagrama, que una ruta no permite continuar o que un paquete excede la MTU (Maximum Transmission Unit). También puede no llegar, estar limitado por rate limiting o ser generado por un componente distinto del que la aplicación considera su servidor. La pregunta profesional es qué datagrama provocó el mensaje, dónde se generó, qué parte del original se citó y qué decisión puede cambiarse con esa evidencia.
Este capítulo construye un modelo operativo para UDP, ICMPv4 e ICMPv6. Separa la unidad que se demultiplexa, el control de integridad, el mensaje de error, el camino de PMTUD (Path MTU Discovery) y el estado que mantienen implementaciones o aplicaciones. El modelo sirve tanto para diagnosticar un timeout como para evaluar una política que permite, bloquea o inspecciona estos protocolos.
Source Quench está deprecado; no es un control moderno.
UDP: un datagrama, un puerto y una entrega mínima
El User Datagram Protocol (UDP) añade a los datos una cabecera con puerto origen, puerto destino, longitud y checksum. La longitud incluye cabecera y datos; el valor mínimo es ocho octetos. El puerto destino tiene significado en el contexto de la dirección IP de destino, no como un identificador global de producto o proceso. El puerto origen puede ser cero cuando no se usa, aunque una aplicación de solicitud y respuesta normalmente seleccionará uno para que la respuesta pueda dirigirse al emisor. RFC 768, «Fields»
RFC 768 define UDP como un servicio orientado a datagramas y transaccional: no garantiza entrega ni protección frente a duplicados. RFC 1122 lo resume como un servicio mínimo sobre IP: checksum y multiplexación por puerto; retransmisión, reensamblaje, control de flujo y evitación de congestión quedan a cargo de la aplicación si los necesita. Esto no significa que un datagrama jamás pueda llegar en orden o que un kernel nunca retransmita algo construido sobre UDP. Significa que esas propiedades no son garantías generales del protocolo UDP. RFC 1122, §4.1.1
Un socket UDP puede estar enlazado a una dirección y puerto locales, recibir datagramas de muchos pares y entregar cada uno según las reglas de demultiplexación de la implementación. Un socket llamado «connected» por una API de sistema puede fijar un par remoto y filtrar o seleccionar respuestas, pero esa operación local no convierte UDP en TCP. Del mismo modo, una biblioteca puede añadir número de solicitud, reintentos, expiración o autenticación de aplicación. Es estado de la API o de la aplicación, no fiabilidad proporcionada por UDP.
La demultiplexación permite formular una afirmación acotada: «el kernel entregó este datagrama a un socket que coincidía con la dirección y el puerto observados». No permite afirmar que un proceso concreto lo escribió, que el propietario de la IP lo autorizó o que la lógica de negocio aceptó la operación. En un host pueden existir varios procesos, balanceo local, reutilización de puertos o un proxy que recibe el datagrama y crea otro. Un puerto 53 es una convención útil para localizar DNS, no una prueba de que el receptor sea un resolvedor ni de que la respuesta sea legítima.
Ejemplo de unidad y demultiplexación
Supongamos que un cliente 192.0.2.10:53000 envía 24 octetos a 198.51.100.53:53 sobre IPv4. La longitud UDP es 32 (8 de cabecera más 24 de datos). El datagrama contiene el puerto destino que ayuda a localizar el socket del receptor; IP selecciona el destino y UDP entrega la unidad si pasa las comprobaciones aplicables. Un NAT de salida puede sustituir la dirección y el puerto origen y conservar una asociación temporal para que la respuesta vuelva al cliente. Una captura antes del NAT y otra después pueden mostrar cuatro valores distintos sin que exista una contradicción.
Un control positivo sería observar, en un punto bajo autoridad del servicio, un datagrama válido con ese identificador de solicitud y un log de aplicación que lo correlacione. Un control negativo puede dirigir el mismo formato a un puerto controlado que no tiene receptor. Si aparece ICMP Port Unreachable, la señal acota una decisión de entrega en ese punto; si no aparece, siguen siendo posibles un filtro, pérdida, rate limiting o una implementación que no genera el error. Ninguno de los dos controles prueba por sí solo autenticidad del cliente o disponibilidad de una operación de negocio.
Checksum: integridad acotada, no autenticación
El checksum UDP es una suma complemento a uno de 16 bits calculada sobre la cabecera UDP, los datos y un pseudoheader tomado de IP. En IPv4, el pseudoheader incluye las direcciones origen y destino de 32 bits, un octeto cero, el número de protocolo UDP (17) y la longitud UDP. El propósito es detectar, entre otras cosas, una entrega al destino o protocolo equivocados. El resultado cero se transmite como todos unos; un cero transmitido significa que el emisor no generó checksum según la especificación histórica. RFC 768, «Checksum»
La política de host de RFC 1122 exige que UDP pueda generar y validar checksums y que el envío los active por defecto; un checksum no nulo inválido debe provocar descarte silencioso. El texto histórico permite casos configurables de checksum ausente, por lo que la captura de un cero debe interpretarse con la versión, familia de direcciones y modalidad de transporte a la vista. Un checksum válido sólo sostiene que los campos cubiertos coinciden con la operación aritmética en ese punto. No protege contra un emisor autorizado de forma incorrecta, no firma el contenido y no demuestra intención. RFC 1122, §4.1.3.4
IPv6 cambia una suposición importante. Su pseudoheader usa direcciones IPv6 de 128 bits, la longitud de la unidad superior y el valor Next Header que identifica UDP. Por defecto, un nodo IPv6 debe calcular un checksum UDP y el receptor debe descartar un checksum cero; existen excepciones específicas para ciertos túneles UDP bajo RFC 6936. Además, ICMPv6 usa un pseudoheader, mientras ICMPv4 no lo usa. La comparación correcta es «IPv4 permite la modalidad de checksum ausente según sus reglas; IPv6 exige checksum salvo una excepción normativa», no «IPv6 siempre es más seguro». RFC 8200, §8.1
La diferencia entre familias importa para la observabilidad. Una tarjeta o una pila puede calcular el checksum mediante offload y mostrar en una captura local un valor pendiente o aparentemente incorrecto antes de que el hardware lo complete. Esa es una consideración de implementación, no una licencia para ignorar la verificación en el receptor. Para adjudicar un candidato, compare el punto de captura con la interfaz de recepción, la configuración de offload y una segunda observación controlada. Un fallo de checksum también puede ser un síntoma de decodificación incorrecta, truncamiento o desalineación, no necesariamente de corrupción intencional.
¿Dónde existe el estado?
La palabra «sesión» reúne estados diferentes. Conviene registrarlos por plano:
Desliza horizontalmente para consultar todas las columnas.
Una misma comunicación puede tener estado en los cuatro planos y seguir usando datagramas independientes. También puede no haber una entrada NAT para un datagrama entrante o haber expirado el mapeo mientras la aplicación considera abierta una transacción. El diagnóstico debe preguntar qué estado esperaba cada componente, qué clave usó y cuánto tiempo era válido.
API, PMTU y NAT no son garantías del protocolo UDP.
Estos planos tienen fuentes diferentes. RFC 768/1122 describen UDP y su interfaz; RFC 8201 describe caché PMTU; RFC 4787 define requisitos de mapping, filtering y temporización para NAT UDP unicast. Un firewall o conntrack concreto necesita además documentación y versión de esa implementación. No debe usarse la palabra «estado UDP» para atribuir al protocolo lo que pertenece a un NAT, una API o una aplicación. RFC 4787, §§4–6
ICMP no es «un error de UDP»
ICMPv4 viaja dentro de IP y sirve para control, diagnóstico y reporte de errores; no convierte IP en un transporte confiable. RFC 792 recalca que ni el datagrama original ni el mensaje ICMP tienen una entrega garantizada. RFC 1122 agrupa ICMPv4 en errores —Destination Unreachable, Redirect, Time Exceeded y Parameter Problem, entre otros— y consultas como Echo. Un mensaje desconocido se descarta silenciosamente. RFC 792, «Introduction»; RFC 1122, §3.2.2
Un error ICMPv4 incluye la cabecera IP original y, como mínimo, los primeros ocho octetos de sus datos; puede incluir más. Esa porción permite extraer el protocolo y, cuando están presentes, los puertos para localizar la operación que provocó el error. Es una asociación, no una firma: una dirección fuente o un puerto citado pueden ser falsificados; el contenido citado puede ser truncado; y el mensaje puede haber sido generado por un router distinto del destino que la aplicación esperaba. RFC 1122, §3.2.2
ICMPv6 es parte integral de IPv6: todo nodo IPv6 debe implementar los mensajes y comportamientos base de RFC 4443. Define mensajes de error —Destination Unreachable, Packet Too Big, Time Exceeded y Parameter Problem— y mensajes informativos Echo. Los errores incluyen tanto del paquete invocante como sea posible sin superar la MTU mínima de IPv6. El protocolo superior se extrae de ese paquete citado para entregar la notificación al proceso adecuado cuando puede identificarse. RFC 4443, §§1–2.4
Las reglas de entrega limitan deliberadamente la propagación. Un nodo no debe generar un error ICMPv6 por recibir otro error, un Redirect, un paquete destinado a multicast —salvo excepciones normativas de Packet Too Big y cierto Parameter Problem—, un multicast de enlace, un broadcast de enlace o un paquete cuya dirección origen no identifica un único nodo. ICMPv4 tiene restricciones análogas para errores ante errores, broadcasts, multicasts, fragmentos no iniciales y fuentes no unívocas. Estas reglas evitan bucles y tormentas de respuesta; también explican por qué la ausencia de un error no prueba que no hubo descarte. RFC 4443, §2.4(e); RFC 1122, §3.2.2
El envío de errores puede estar limitado por tasa, pero la obligación no es idéntica entre familias ni mensajes. RFC 4443 §2.4(f) exige limitar la tasa de errores ICMPv6 originados y propone mecanismos capaces de tolerar ráfagas. Para IPv4, RFC 1812 §4.3.2.8 exigía capacidad de limitar Source Quench y recomendaba que el router pudiera limitar otros errores como Destination Unreachable, Redirect, Time Exceeded y Parameter Problem; RFC 6633 deprecó después Source Quench y exige no originarlo ni reaccionar a él. Por tanto, no existe una regla correcta que diga «todo ICMPv4 debe limitarse igual». Un sensor puede ver un error para el primer datagrama y ninguno para los siguientes sin que la ruta haya cambiado. La telemetría debe registrar familia, contador, ventana, tipo, código, configuración y punto de generación antes de convertir la ausencia en una conclusión. RFC 1812, §4.3.2.8; RFC 6633, §§2–3
PMTUD: la red informa una restricción, no entrega el paquete
En IPv4, el descubrimiento de MTU de camino puede usar un datagrama con DF (Don’t Fragment). Un router que no puede reenviarlo debe informar al origen con ICMP Destination Unreachable, código «fragmentation needed and DF set», cuando esa capacidad y política están presentes. En IPv6 un router intermedio no fragmenta: si el paquete excede la MTU del siguiente enlace, lo descarta y origina ICMPv6 Packet Too Big cuando se cumplen las reglas de generación; excepciones y limitación de tasa impiden esperar el mensaje en todos los casos. Si el origen recibe y valida la notificación, reduce su estimación de PMTU y el protocolo que paquetiza —TCP o una aplicación sobre UDP— debe producir unidades menores. RFC 1122, §§3.3.3 y 3.3.8; RFC 8200, §§4.5–5; RFC 8201, §§3–4; RFC 4443, §§2.4 y 3.2
El paquete citado es esencial: el origen necesita identificar qué flujo y qué unidad fueron rechazados. RFC 8201 exige validar que el contenido de Packet Too Big corresponde a tráfico transmitido y no bajar la PMTU por debajo de la mínima IPv6. Un Packet Too Big falsificado o descontextualizado podría forzar tamaños innecesariamente pequeños; por eso el control no consiste en aceptar ciegamente cualquier ICMP, sino en validar relación, ruta, familia, tamaño y estado local. Al mismo tiempo, bloquear indiscriminadamente ICMP puede producir un black hole de PMTUD: los datagramas grandes se pierden sin que el emisor aprenda la restricción.
Caso conductor: Atlas y una respuesta que deja de llegar
Atlas es un servicio sintético que consulta por UDP desde un cliente dual-stack. Con respuestas pequeñas, el cliente recibe una respuesta y la aplicación correlaciona el identificador de solicitud. Tras añadir un túnel, las respuestas grandes fallan sólo por IPv6. En el cliente se observa el envío UDP; en el gateway del túnel aparece una reducción de MTU; el origen recibe algunas solicitudes, pero no termina de entregar la respuesta grande.
Hay al menos dos hipótesis compatibles: el camino genera Packet Too Big y ese mensaje no llega o no se asocia al socket UDP; o un filtro descarta fragmentos/cabeceras IPv6 o impide el retorno. Un control positivo conserva el mismo identificador de aplicación y varía el tamaño por debajo de la MTU efectiva; otro compara una captura en ambos extremos del túnel y la caché PMTU. Un control negativo usa un tamaño deliberadamente mayor y comprueba si aparece un Packet Too Big válido y limitado por tasa. Capturar sólo el primer fragmento no prueba que el conjunto se reensamblara ni que UDP pasara checksum y demultiplexación.
Si se recibe ICMP Port Unreachable, la conclusión acotada es que un componente decidió no entregar ese datagrama a un puerto UDP en el alcance indicado. Si no se recibe, no se sigue que el puerto exista ni que el host esté caído: un filtro, un NAT expirado, un error de checksum, una ruta asimétrica, la pérdida del mensaje o el rate limiting siguen siendo posibilidades. La respuesta de aplicación, además, podría venir de un proxy y no del proceso que el cliente imagina.
Spoofing, reflexión y amplificación bajo precondiciones
UDP facilita enviar unidades sin handshake de transporte. Eso reduce latencia y sirve para multicast, consultas y protocolos que implementan su propio control, pero también permite que un emisor alcance servicios que responden a una solicitud sin crear una conexión previa. Una reflexión requiere, como mínimo, un servicio accesible que responda y una forma de dirigir la respuesta hacia otra víctima —habitualmente una fuente falsificada aceptada por la ruta—. La amplificación añade una relación de tamaño o tasa observada: una solicitud pequeña provoca una respuesta mayor o más costosa. RFC 5358 documenta esas precondiciones para resolvers DNS recursivos abiertos; no convierte a todo UDP en amplificador. El protocolo y despliegue concretos deben demostrar exposición, respuesta y factor. RFC 5358, §§1–3
BCP 38 recomienda filtrado de ingreso para impedir que una red emita paquetes con fuentes que no son plausibles para su interfaz; RFC 2827 describe el control y sus límites. RFC 3704 analiza variantes como strict y loose reverse-path filtering y advierte que rutas asimétricas, multihoming y excepciones pueden cambiar el resultado. El control reduce la posibilidad de falsificar direcciones, pero no demuestra que una dirección permitida sea una identidad ni elimina ataques desde un origen legítimo comprometido. RFC 2827, §§1–3; RFC 3704, §§2–4
Las restricciones de ICMP sobre broadcast, multicast y fuentes ambiguas buscan precisamente limitar tormentas; no son una garantía global contra reflexión. Un servidor que responde Echo o un servicio UDP que devuelve más datos debe aplicar autenticación de aplicación cuando la operación lo requiera, límites de tasa y respuestas proporcionales. Un mensaje de respuesta recibido desde la IP esperada no prueba autenticidad: UDP no aporta una firma y ICMPv6 sólo añade checksum y reglas de integridad de campos, no autenticación del origen. RFC 4443 señala que autenticación y confidencialidad requieren mecanismos como IPsec cuando ese es el objetivo. RFC 4443, §5.1
Observabilidad y errores comunes
Un diagnóstico debe preservar la ubicación y el tiempo de cada observación:
- En el proceso, registrar solicitud, identificador, timeout y error devuelto, sin asumir que un timeout identifica pérdida de red.
- En el socket/kernel, comprobar bind, cola, checksum reportado y error asíncrono; RFC 1122 exige que los errores ICMP pertinentes puedan subir hacia la capa de transporte, pero la API y la entrega concreta dependen de la implementación. RFC 1122, §§3.4 y 4.1.3.3
- En la interfaz, fijar familia, dirección, puerto, filtro, offload y ventana de captura. La ausencia es «no observado aquí», no «no enviado».
- En NAT, firewall o túnel, correlacionar la traducción, el timeout, la política y la interfaz de salida. El paquete citado por ICMP puede pertenecer al tramo externo o interno según dónde se generó.
- En el receptor, separar llegada IP, validación UDP, demultiplexación al socket y decisión de aplicación. Un log de aplicación es evidencia de parsing/decisión, no de todos los saltos previos.
Errores frecuentes:
«UDP no tiene estado». UDP no ofrece una sesión fiable general; kernel, aplicación, NAT, firewall y PMTUD sí pueden mantener estado.
«El puerto identifica la aplicación». Identifica un destino de demultiplexación bajo una dirección y política locales. No identifica producto, proceso legítimo o usuario.
«El checksum autentica». Detecta ciertas alteraciones o desvíos en los campos cubiertos; no es MAC, firma ni prueba de origen.
«ICMP es opcional y se puede bloquear sin consecuencias». Su soporte, mensajes y efectos dependen de la familia y del rol, pero ICMP participa en errores, diagnóstico y PMTUD. Un filtro amplio puede romper descubrimiento o dejar black holes; una política debe distinguir mensajes necesarios, validación, tasa y exposición.
«Una respuesta prueba que el servidor es quien dice ser». Sólo prueba que una respuesta llegó al punto observador desde una dirección y puerto en una ventana. La autenticidad requiere un mecanismo y una verificación de aplicación o de canal.
«Un ICMP Port Unreachable prueba que el host está caído». El código puede informar una decisión local de entrega; la ausencia o presencia está limitada por ruta, filtro, generación y rate limiting.
Transferencia profesional: del paquete al claim
Un informe sobre UDP o ICMP debe escribir por separado observación, inferencia, impacto y límite. Por ejemplo:
Durante la ventana T, el cliente C envió datagramas UDP IPv6 de 1420 octetos hacia S a través del túnel G. En C se observaron los envíos; en G se observó una MTU menor; no se observó un Packet Too Big válido en C. El resultado es compatible con una PMTU aprendida de forma incompleta o con filtrado del mensaje, pero no permite atribuir la causa a S sin evidencia del tramo G–S. El control positivo con 1200 octetos sí obtuvo respuesta; el negativo con 1500 reprodujo la pérdida.
El claim no dice que ICMP «causó» el fallo ni que el túnel esté comprometido. Declara una diferencia de tamaño, los puntos de observación y la hipótesis que la evidencia todavía no separa. Para un hallazgo de reflexión, el informe debe fijar precondiciones: dirección falsificable o ruta de retorno, endpoint que responde, factor de respuesta observado, controles de tasa, autenticación, filtrado de ingreso y destinatarios afectados. Para una remediación, «permitir ICMP» es demasiado amplio: especificar familia, tipos/códigos, dirección, estado de PMTUD, validación del paquete citado, límites de tasa y prueba de regresión.
La observación acota impacto; no prueba autenticidad ni causa única.
Síntesis
UDP ofrece datagramas con puertos, longitud y checksum, pero no una garantía general de entrega, orden, unicidad o congestión. El checksum protege una relación aritmética acotada; el pseudoheader cambia entre IPv4 e IPv6 y no sustituye autenticación. Los puertos demultiplexan bajo un contexto local; no nombran por sí solos una aplicación.
ICMPv4 e ICMPv6 son mecanismos de control y error integrados con IP. Sus mensajes pueden citar el paquete original para que el receptor asocie una causa con una operación; no son confirmaciones confiables ni pruebas de autoría. Las reglas contra respuestas recursivas, broadcasts, multicasts y fuentes ambiguas, junto con el rate limiting, son límites de seguridad y de observabilidad. PMTUD depende de interpretar esos mensajes: bloquearlos sin evaluar el mecanismo puede convertir una restricción legítima de MTU en una pérdida silenciosa.
La conclusión transferible es sencilla pero exigente: fijar la unidad, la familia IP, la clave de demultiplexación, el punto de observación, el estado de cada intermediario y la evidencia que vincula un error con su datagrama. Sólo entonces una respuesta UDP o ICMP puede cambiar una decisión profesional.
Fuentes de referencia
- RFC 768 — User Datagram Protocol, «Introduction», «Fields», «Checksum» y «User Interface».
- RFC 1122 — Requirements for Internet Hosts, §§3.2.2, 3.3.3, 3.3.8, 3.4, 4.1.1, 4.1.3.1–4.1.3.4.
- RFC 792 — Internet Control Message Protocol, «Introduction», «Message Formats» y «Destination Unreachable».
- RFC 8200 — IPv6 Specification, §§4.5, 5 y 8.1.
- RFC 8201 — Path MTU Discovery for IPv6, §§3–5.
- RFC 4443 — ICMPv6, §§1–2.4, 3 y 5.
- RFC 1812 — Requirements for IP Version 4 Routers, §§4.3.2.7–4.3.2.8.
- RFC 2827 — Network Ingress Filtering, §§1–3; RFC 3704 — Ingress Filtering, §§2–4.