Résumé

  • Le profil RAW de la RFC 3195 transporte les messages syslog habituels sur BEEP, qui garantit une livraison fiable et ordonnée sur chaque canal ; COOKED ajoute des entrées structurées avec une réponse positive ou négative pour chacune.
  • Ces reçus ne répondent pas à la même question. Une trame livrée ou un <ok/> ne prouve ni l’origine de l’événement, ni sa conservation durable, ni son indexation ou le déclenchement d’une action.

Le mot « fiable » paraît parfois plus large que la garantie réellement spécifiée. Publiée en novembre 2001 comme document de la voie Standards Track, la RFC 3195 associe syslog à BEEP, un cadre orienté connexion. Ses deux profils rendent visible un choix d’ingénierie. RAW privilégie la simplicité, le faible surcoût et la compatibilité ascendante : le contenu garde la forme syslog historique, tandis que BEEP assure une livraison fiable et ordonnée dans un canal donné. COOKED structure les opérations et autorise une réponse ok ou error à chaque entry. Cette réponse porte sur l’échange protocolaire, pas sur toutes les étapes ultérieures d’un système de journalisation. (RFC 3195 §§1, 3.1, 4.4.2)

Il faut distinguer les reçus. Un émetteur transmet un événement ; un pair BEEP reçoit un message complet ; un récepteur COOKED peut accepter ou refuser une entrée ; un collecteur peut ensuite l’analyser, l’écrire, l’indexer, la répliquer ou déclencher une alerte. Ce sont des changements d’état séparés. La RFC 3195 définit le transport et les échanges de profil, mais pas une transaction universelle de stockage. Même <ok/> ne dit pas si le collecteur a vidé ses tampons sur un support durable ni si les consommateurs en aval ont vu la ligne. Une réponse error peut traduire un refus administratif : elle prouve une décision de politique, pas l’inexistence de l’événement.

RAW montre cette limite de façon concrète. Dans BEEP, la marque de fin délimite le message et le transport assure fiabilité et ordre sur un canal individuel. Mais le premier message du récepteur RAW n’a pas de sémantique d’entrée syslog ; les réponses de l’initiateur contiennent les entrées. Le profil fixe aussi à 1 024 octets la taille du corps de chaque événement RAW, hors surcharge de cadrage BEEP. Cette borne concerne la charge utile, pas la conservation durable. Elle diffère du plafond de paquet et de la troncature au relais de la RFC 3164, qui relèvent d’un autre mécanisme. (RFC 3195 §3.3 ; RFC 3164)

La RFC 3195 énonce aussi clairement que BEEP peut protéger la communication sans garantir l’intégrité de l’objet message. Un appareil compromis peut émettre des événements erronés ; un relais ou un collecteur peut modifier, insérer ou supprimer des messages sans détection, sauf si d’autres techniques sont prévues. Le document traite l’authentification, la protection contre le rejeu, l’intégrité et la confidentialité comme des services à configurer séparément. Un canal protégé peut authentifier le pair d’un saut ; cette identité n’est pas automatiquement le nom d’hôte inscrit dans l’événement, ni une signature de bout en bout sur son contenu. (RFC 3195 §§5, 10 ; RFC 5425 §4)

Les travaux syslog ultérieurs rendent la frontière encore plus nette. La RFC 5848 décrit des blocs signés capables d’étayer l’authentification de l’origine, l’intégrité, la résistance au rejeu, l’ordre et le repérage de messages manquants. Elle avertit séparément qu’un transport fiable ne prévient pas les pertes au niveau applicatif, par exemple si le récepteur ferme une session TCP ou TLS. Cela ne prouve ni que RFC 3195 a été largement déployée ni que les signatures résolvent tout problème de conservation. Cela montre que livraison, authenticité et exhaustivité réclament des preuves différentes. (RFC 5848 §§1, 8.3–8.7)

La valeur durable de RFC 3195 tient à la précision de son périmètre. RAW peut répondre : « ce canal BEEP a-t-il livré le message dans l’ordre ? » COOKED ajoute : « le récepteur a-t-il répondu positivement ou négativement à cette entrée ? » Sans contrôles supplémentaires, aucun des deux ne répond à « l’événement est-il authentique ? », « a-t-il survécu à une panne de stockage ? » ou « un opérateur a-t-il agi ? ». Une enquête devrait donc conserver séparément l’état de session, les réponses par entrée, la validation des signatures, la persistance chez le collecteur et le traitement en aval.

La RFC décrit un protocole ; les sources examinées ne mesurent ni son adoption actuelle ni ses performances.

Sources : RFC 3195 ; notice actuelle de RFC 3195 ; texte RFC 3195 sur Datatracker ; RFC 3080, cœur de BEEP ; RFC 3081, BEEP sur TCP ; RFC 3164, protocole BSD Syslog ; RFC 5424, protocole Syslog ; RFC 5425, transport TLS de Syslog ; RFC 5426, transport UDP de Syslog ; RFC 5848, messages Syslog signés ; RFC 6587, Syslog sur TCP ; RFC 2782, DNS SRV ; RFC 2119, niveaux d’exigence.