Resumen

  • El perfil RAW de la RFC 3195 lleva mensajes syslog conocidos sobre BEEP, que garantiza entrega fiable y ordenada en cada canal; COOKED añade entradas estructuradas con respuesta positiva o negativa para cada una.
  • Son recibos de alcance distinto: un marco entregado o un <ok/> no prueba por sí solo el origen del evento, su almacenamiento duradero, su indexación ni una respuesta operativa.

La palabra «fiable» puede sonar más amplia que la garantía del protocolo. Publicada en noviembre de 2001 como documento de la vía Standards Track, la RFC 3195 asignó syslog a BEEP, un marco orientado a conexión. Sus perfiles hacen visible una elección de diseño. RAW prioriza la sencillez, el bajo coste y la compatibilidad: conserva el formato histórico del mensaje y deja que BEEP aporte entrega fiable y ordenada dentro de cada canal. COOKED usa operaciones estructuradas y permite que cada entry reciba un ok o un error. Esa respuesta concierne al intercambio de protocolo, no a todas las fases posteriores de un sistema de registro. (RFC 3195 §§1, 3.1, 4.4.2)

Conviene separar los comprobantes. Un emisor envía un evento; un par BEEP recibe el mensaje completo; un receptor COOKED puede aceptar o rechazar una entrada; después, un colector puede analizarla, escribirla, indexarla, replicarla o generar una alerta. Son cambios de estado distintos. La RFC 3195 define el transporte y los intercambios de perfiles, no una transacción universal de almacenamiento. Ni siquiera <ok/> especifica si el colector volcó los datos a un soporte persistente o si los consumidores posteriores los recibieron. Un error puede reflejar un rechazo administrativo: acredita una decisión de política, no que el evento nunca existiera.

RAW muestra el límite con claridad. En BEEP, el marcador final delimita el mensaje y el transporte ofrece fiabilidad y orden en un canal individual. Pero el mensaje inicial del receptor RAW no tiene semántica de entrada syslog; las respuestas del iniciador llevan las entradas. El perfil fija además un máximo de 1.024 bytes para el cuerpo de cada evento RAW, excluida la sobrecarga de encuadre BEEP. Es un límite de carga útil, no una promesa de retención duradera. No debe confundirse con el límite de paquete y la posible truncación en retransmisiones de la RFC 3164: son mecanismos diferentes. (RFC 3195 §3.3; RFC 3164)

La RFC 3195 también distingue comunicación segura de integridad del objeto. Su sección de seguridad advierte que un dispositivo comprometido puede generar mensajes incorrectos y que relés o colectores pueden modificarlos, insertarlos o borrarlos sin detección, salvo que se añadan otras técnicas. El texto trata autenticación, resistencia a repetición, integridad y confidencialidad como servicios que deben configurarse por separado. Un canal protegido puede autenticar al par de un salto; esa identidad no coincide necesariamente con el nombre de host escrito en el evento ni constituye una firma de extremo a extremo sobre su contenido. (RFC 3195 §§5, 10; RFC 5425 §4)

El trabajo posterior sobre syslog aclara aún más la diferencia. La RFC 5848 define bloques firmados que pueden aportar autenticación del origen, integridad, resistencia a repetición, secuenciación y detección de mensajes ausentes. También señala que un transporte fiable no evita pérdidas en la capa de aplicación, por ejemplo cuando el receptor cierra una sesión TCP o TLS. Esto no prueba que RFC 3195 se adoptara ampliamente ni que las firmas resuelvan toda cuestión de retención; sí muestra que entrega, autenticidad e integridad de la secuencia exigen evidencias diferentes. (RFC 5848 §§1, 8.3–8.7)

El valor duradero del diseño está en delimitar su alcance. RAW puede responder: «¿este canal BEEP entregó el mensaje en orden?». COOKED añade: «¿el receptor contestó positiva o negativamente a esta entrada?». Sin controles adicionales, ninguno responde si el evento era auténtico, sobrevivió a un fallo de almacenamiento o provocó una intervención. Una investigación debería conservar por separado el estado de sesión, las respuestas por entrada, la verificación de firmas, la persistencia del colector y el procesamiento posterior.

La RFC especifica conductas de protocolo; las fuentes consultadas no establecen su prevalencia actual ni sus resultados operativos.

Fuentes: RFC 3195; registro actual de RFC 3195 en RFC Editor; texto de RFC 3195 en IETF Datatracker; RFC 3080, núcleo de BEEP; RFC 3081, BEEP sobre TCP; RFC 3164, protocolo BSD Syslog; RFC 5424, protocolo Syslog; RFC 5425, transporte TLS para Syslog; RFC 5426, transporte UDP para Syslog; RFC 5848, mensajes Syslog firmados; RFC 6587, Syslog sobre TCP; RFC 2782, DNS SRV; RFC 2119, niveles de requisitos.