Resumen

  • Message ID pertenece a la mecánica del mensaje CoAP sobre UDP: duplicados, ACK, Reset y vida del intercambio. Token pertenece a la conversación solicitud-respuesta y se interpreta junto con el extremo correspondiente.
  • Ni el Token ni el Message ID acreditan por sí mismos quién está detrás del extremo, qué permisos tiene, si la representación sigue vigente o si la acción de la aplicación terminó.

En los sistemas pequeños, la escasez de bytes obliga a nombrar bien. CoAP no dispone de espacio para un identificador universal que represente a la vez el paquete, la solicitud, el usuario, la sesión, la autorización y el resultado. La RFC 7252 tomó una decisión más saludable: usar campos distintos y dar a cada uno un alcance corto.

Carsten Bormann figura como coautor de esa RFC junto con Zach Shelby y Klaus Hartke. También encabeza la lista de autores de RFC 8323, que adapta CoAP a TCP, TLS y WebSockets. Leídas juntas, las dos especificaciones permiten observar el diseño en movimiento. Cuando el transporte fiable asume retransmisión y deduplicación, CoAP elimina Message ID. No elimina Token.

La permanencia del segundo campo revela el error de muchas plataformas de telemetría: no existe un único «ID de transacción» en el cable. Hay evidencias parciales que deben conservar su procedencia.

Una copia repetida no es una orden repetida

En UDP, un mensaje Confirmable se retransmite si su ACK no llega. El receptor puede ver de nuevo el mismo Message ID desde el mismo extremo. RFC 7252 recomienda responder a cada copia con el ACK o Reset correspondiente, pero procesar una sola vez la solicitud o respuesta contenida, salvo las excepciones previstas para operaciones idempotentes.

Message ID también enlaza un ACK o Reset con el mensaje Confirmable o Non-confirmable al que responde. El valor tiene 16 bits y no puede reutilizarse con el mismo extremo dentro de EXCHANGE_LIFETIME. La clave práctica no es el número aislado, sino número, extremo y ventana temporal.

Esto evita un salto lógico frecuente. Dos datagramas iguales pueden ser una retransmisión de una sola intención. Dos solicitudes de aplicación diferentes pueden, en otro momento o con otro extremo, reutilizar el mismo número. El contador de paquetes no equivale al contador de operaciones de negocio.

Un sistema de control que ejecuta de nuevo una acción física cada vez que recibe una copia no puede culpar al Message ID. La capa CoAP puede reconocer el duplicado; la aplicación todavía debe diseñar su propia idempotencia, su registro de compromiso y su prueba de efecto.

El Token recupera una espera local

Cada solicitud lleva un Token generado por el cliente. El servidor debe repetirlo sin cambios en la respuesta resultante. El cliente lo usa, junto con la información del extremo correspondiente, para localizar la solicitud que estaba esperando. La propia RFC dice que podría haberse llamado «request ID».

Su unicidad también es local: los Tokens activos deben distinguirse para una pareja de extremos origen-destino. La misma secuencia puede usarse con extremos distintos. Si no hay concurrencia, un Token de longitud cero puede ser correcto. Quien recibe un Token que no generó debe tratarlo como opaco y no deducir estructura ni contenido.

Por eso el servidor no está emitiendo una credencial cuando devuelve el valor. Está devolviendo un asa que el cliente entiende dentro de su propia tabla. Incluso si el cliente codifica información en ella, esa interpretación no se convierte automáticamente en una afirmación compartida.

En una respuesta piggybacked, el ACK comparte Message ID con la solicitud Confirmable y la respuesta comparte Token con la solicitud. En una respuesta separada, el Token sigue enlazando la semántica, mientras el nuevo mensaje usa otro Message ID y su propia confirmación. Guardar sólo uno de los campos vuelve imposible distinguir ambos recorridos.

El experimento TCP

RFC 8323 retira Type y Message ID porque TCP ya ofrece transmisión fiable y elimina duplicados del flujo. CoAP añade longitud para separar sus mensajes, conserva Code, opciones, carga y Token, y deja que la conexión gestione lo que antes gestionaba la capa de mensajes UDP.

La consecuencia sirve como prueba diferencial. Si una biblioteca pierde respuestas concurrentes tanto por UDP como por TCP, el sospechoso común no es Message ID: es la tabla de solicitudes, el Token, el enlace al extremo o conexión, un proxy o el procesamiento superior. Si el fallo aparece sólo por UDP, entonces sí conviene revisar temporizadores, reutilización de Message ID, cache de duplicados y ACK.

También aclara la seguridad. Una conexión TLS puede autenticar un par según su configuración. El Token continúa siendo el enlace de la solicitud. El par autenticado puede cambiar al renovar la sesión, y la solicitud pendiente puede expirar antes. Mezclar ambas evidencias en una sola etiqueta impide aplicar sus vidas útiles correctas.

Aleatoriedad contra respuestas a ciegas

Cuando no hay seguridad de transporte, RFC 7252 recomienda que el Token sea aleatorio y no trivial. Para un cliente conectado a Internet, aconseja al menos 32 bits de aleatoriedad. El objetivo es dificultar que un atacante fuera del camino adivine el valor de una solicitud pendiente e inyecte una respuesta falsa.

Message ID aporta poco a esa defensa porque suele asignarse secuencialmente y una respuesta separada puede usar su propio intercambio. El Token aleatorio funciona como desafío de correlación. No demuestra que el emisor sea una persona, una empresa o el dispositivo esperado.

El alcance del adversario importa. Quien observa el tráfico puede copiar el Token. Un proxy legítimo conoce el Token de su salto. Un generador defectuoso puede repetirlo. Una tabla antigua puede aceptar un retorno retrasado. Por eso un evento de coincidencia necesita indicar longitud, política de generación, extremo, tiempo de vida, modo de seguridad y punto de observación.

Llamarlo «auth token» en un esquema de datos no modifica la amenaza. Sólo oculta que la autenticación vive en otra capa.

Los saltos rompen la fantasía de un identificador extremo a extremo

Un intermediario normalmente conserva el Token y la dirección de transporte del cliente, luego crea otra solicitud hacia el origen con un Token propio. Cuando vuelve la respuesta, consulta su mapeo y responde en el salto inferior. Tokens iguales en dos saltos no son necesarios; Tokens distintos no indican una avería.

Para reconstruir un incidente hacen falta dos registros y una unión local del intermediario. El registro debe decir qué interfaz o conexión observó cada valor, cuándo se creó el mapeo, cuándo expiró y qué versión del proxy lo produjo. Sin eso, el Token del lado servidor no puede atribuirse al cliente original.

Si una plataforma añade después un UUID global, ese UUID puede ser útil. Pero es un objeto creado por la plataforma. Su confiabilidad depende del código de mapeo y de la custodia del log, no de una propiedad end-to-end de CoAP.

Este límite protege también la privacidad. No es necesario publicar Tokens crudos para todo análisis. Un resumen con clave o un identificador de unión interno puede conservar la relación sin transformar una señal transitoria en identificador durable del dispositivo.

El cliente «sin estado» conserva varios estados

RFC 8974, escrita por Klaus Hartke y Michael Richardson, permite serializar parte del estado de una solicitud dentro del Token y recuperarlo al volver la respuesta. No es obra de Bormann; aquí importa como extensión posterior de los campos definidos en RFC 7252 y RFC 8323.

La especificación advierte que «stateless» simplifica demasiado. Siguen existiendo estado por servidor, generación de Tokens y control de congestión. Los mensajes Confirmable por UDP requieren además su estado de intercambio. Si el cliente necesita Tokens extendidos, primero debe descubrir su soporte de forma stateful, salvo que el entorno lo garantice por otro medio fiable.

Mover el estado al cable añade obligaciones. La integridad evita que alguien lo modifique. La protección contra replay y la frescura evitan que un estado válido pero viejo se acepte como actual. El cifrado protege detalles privados. Los cambios de formato deben separarse. Los Tokens grandes pueden agotar la memoria de servidores restringidos, y una cadena de intermediarios puede hacerlos crecer salto a salto.

El servidor devuelve bytes opacos. No certifica el estado interno que el cliente recupera. La técnica reduce una tabla local por solicitud a cambio de más tamaño y más criptografía; no elimina la responsabilidad.

Nueve filas para una conclusión prudente

Una investigación debería conservar al menos nueve filas relacionadas. La primera identifica punto de captura y tiempo. La segunda describe UDP, TCP, TLS o WebSocket y el extremo o conexión. La tercera guarda la asociación de seguridad y la afirmación de par autenticado.

La cuarta conserva Type y Message ID cuando existen. La quinta conserva Token, longitud, política de generación y alcance de reutilización. La sexta describe método, URI/opciones y solicitud pendiente. La séptima registra retransmisión, ACK/Reset y veredicto de duplicado. La octava registra código, versión o frescura de la representación. La novena pertenece a autorización y resultado de la aplicación o actuador.

Cada fila tiene propietario y caducidad distintos. Una actualización de firmware puede invalidar la deduplicación sin cambiar certificados. Una renovación TLS puede cambiar la identidad de par sin cambiar el algoritmo de Token. Una respuesta correcta puede preceder a un fallo de la transacción física.

Una sola columna «success» elimina justo la información necesaria para asignar responsabilidad.

El lugar documentado de Bormann

El perfil actual del IETF, revisado el 30 de agosto de 2026, enumera 65 RFC y cargos como la presidencia de CoRE y de Thing-to-Thing Research Group. Es contexto temporal. La atribución técnica más sólida está en los documentos: coautor de RFC 7252 y primer autor listado de RFC 8323.

Ambas RFC son productos colectivos del IETF. Describen la condición común que permite interoperar; no obligan a una implementación concreta a demostrar conformidad ni sustituyen la decisión de un operador. La captura, el estado del proceso, la configuración y el resultado real hacen esa segunda demostración.

Esta separación entre contribución y mandato repite la separación entre Token e identidad. Reconocer exactamente el aporte no lo disminuye. Evita que la reputación de un autor se utilice como prueba de un sistema que él no opera.

CoAP ahorró bytes sin ahorrar distinciones. La observabilidad debería hacer lo mismo.

Fuentes