Resumen

  • RFC 3164 limita el paquete syslog heredado completo a 1.024 bytes y exige que el relay añada una fecha ausente; también recomienda agregar el nombre de host.
  • Si esos campos hacen que el paquete supere el límite, el relay debe truncarlo; el RFC advierte que podrían perderse datos importantes del final original.

La cabecera compite por el mismo presupuesto

Imaginemos un equipo que envía un paquete syslog casi lleno, pero sin una fecha válida. El relay comprueba PRI antes de reenviarlo. Según la sección 4.3.2 de RFC 3164, debe insertar su hora local actual después de PRI y debería añadir también el nombre de host si puede determinarlo. El resto del material recibido pasa a ser CONTENT del mensaje.

Ese enriquecimiento consume bytes. La sección 4.1 limita el paquete entero, no solo el texto del evento: PRI, HEADER y MSG comparten el máximo de 1.024 bytes. Si la fecha, el nombre y sus espacios hacen que el paquete reconstruido rebase el límite, el relay debe comprobar la longitud y truncarlo a 1.024 bytes. El RFC advierte expresamente que así pueden perderse datos vitales del final del paquete original.

El registro todavía puede parecer correcto. El colector recibe una prioridad y una cabecera legibles, aunque quizá falten los últimos bytes del evento: la explicación después de «porque», el resultado de un comando, un identificador de equipo o un valor de diagnóstico. Son ejemplos de lo que podría ocurrir, no incidentes que este artículo afirme que sucedieron. El protocolo hace vulnerable el final cuando los campos añadidos empujan una entrada larga por encima del límite común.

Una regla normativa no es un censo de implementaciones

RFC 3164 es un memorando Informational de agosto de 2001 que documenta el protocolo BSD syslog; no prueba que todos los relays aplicaran la regla. La sección 4.2 permite que el contenido UDP dirigido al puerto 514 sea cualquier mensaje syslog válido y recomienda que el emisor incluya PRI, HEADER y MSG para que el relay no tenga que modificarlo. La sección 6.1 exige que los receptores no fallen ante mensajes de más de 1.024 bytes y describe comportamientos distintos. Ninguna sección mide cuántos equipos enviaban mensajes largos, qué relays truncaban o qué guardaban los colectores.

El límite de mensaje tampoco equivale al MTU del camino. Fragmentación IP, tratamiento UDP y truncamiento de aplicación son mecanismos distintos. La hora insertada es la hora local actual del relay, no necesariamente el momento del evento. El nombre de host es como el relay conoce al dispositivo —o su dirección IP— y RFC 3164 no obliga a validar que corresponda al emisor.

Los formatos posteriores aclaran la diferencia, no prueban la migración

RFC 5424 sustituyó RFC 3164 con una cabecera más explícita y datos estructurados. RFC 6587 describe el encuadre sobre TCP y señala que el límite heredado de 1.024 octetos se amplió para syslog estandarizado. RFC 3195 usa otra contabilidad: su perfil RAW limita cada cuerpo de evento a 1.024 bytes, sin contar la sobrecarga de encuadre BEEP. La comparación ayuda a distinguir capas; no demuestra que emisores o relays antiguos desaparecieran al publicarse nuevos RFC.

La lección histórica es concreta: un relay puede gastar el mismo presupuesto finito que transporta al añadir contexto. Que un paquete llegue, se analice y se archive no demuestra que sobreviva todo el mensaje original. Para probarlo en un sistema real hacen falta los bytes del emisor, las entradas y salidas de cada relay, el análisis del colector y una lectura posterior.

Fuentes