요약

  • RFC 3195의 RAW 프로필은 기존에 익숙한 syslog 메시지를 BEEP 위에서 전달하며, BEEP 채널은 신뢰할 수 있고 순서가 보장된 메시지 전달을 약속합니다. COOKED는 구조화된 엔트리와 각 엔트리에 대한 긍정 또는 부정 응답을 추가합니다.
  • 이 메커니즘들은 서로 다른 질문에 답합니다. 전달된 프레임이나<ok/>는 그 자체로 이벤트의 출처, 내구성 있는 저장, 색인화 또는 운영 대응을 증명하지 못합니다.

"신뢰할 수 있다"는 말은 프로토콜이 실제로 보장하는 것보다 넓게 들릴 수 있습니다. 2001년 11월에 Standards Track 문서로 공개된 RFC 3195는 syslog를 연결 지향 프레임워크인 BEEP 위에 사상합니다. 두 프로필은 유용한 설계 선택을 보여줍니다. RAW는 낮은 오버헤드와 하위 호환성을 우선합니다. 페이로드는 기존 syslog 형식을 그대로 유지하며, BEEP가 개별 채널 안에서 신뢰할 수 있고 순서가 보장된 전달을 제공합니다. COOKED는 구조화된 연산을 사용하며 각entry가ok또는error를 받을 수 있게 합니다. 이는 해당 엔트리에 대한 프로토콜적 답변일 뿐, 로깅 시스템의 이후 모든 단계에 대한 영수증이 아닙니다. (RFC 3195 §§1, 3.1, 4.4.2)

증거 사슬을 생각해 보십시오. 발신자가 이벤트를 내보내고, BEEP 피어가 완전한 메시지를 수신하고, COOKED 리스너가 엔트리를 수락하거나 거부하고, 수집기가 이를 파싱하고, 기록하고, 색인화하고, 복제하거나 경보를 만들 수 있습니다. 이들은 별개의 상태 변화입니다. RFC 3195는 첫 번째 전송 및 프로필 교환을 정의할 뿐, 일반적인 저장 트랜잭션을 정의하지 않습니다. 심지어<ok/>도 수집기가 내구성 있는 미디어에 플러시했는지, 하위 소비자가 레코드를 보았는지를 명시하지 않습니다.error는 정책 결정의 증거인 관리상 거부일 수 있으며, 이벤트가 존재하지 않았다는 증거가 아닙니다.

이 구분은 RAW에서 잘 드러납니다. BEEP의 프레임 트레일러는 메시지의 끝을 표시하고, 그 사상은 채널 안에서 신뢰할 수 있는 순서 보장 전달을 정의합니다. 그러나 RAW의 리스너 여는 메시지에는 syslog 엔트리 의미가 없으며, 개시자의 답변이 하나 이상의 엔트리를 담습니다. 문서는 또한 RAW 이벤트 본문마다 1,024바이트 상한을 두고, BEEP 프레이밍 오버헤드는 명시적으로 제외합니다. 이는 페이로드 경계이지 내구성 있는 보존에 대한 약속이 아닙니다. 이것은 RFC 3164의 전체 패킷 한도와 릴레이 잘림 문제와는 별개의 메커니즘입니다. (RFC 3195 §3.3;RFC 3164)

RFC 3195는 또 다른 공백에 대해 이례적으로 솔직합니다. BEEP는 메시지 객체 자체를 보호하지 않고 통신을 보호할 수 있습니다. 보안 절은 침해된 기기가 잘못된 메시지를 생성할 수 있으며, 다른 기법이 사용되지 않으면 릴레이나 수집기가 이를 탐지 불가능하게 수정, 삽입, 삭제할 수 있다고 말합니다. 이 문서는 인증, 재생 방지, 무결성, 기밀성을 별도로 프로비저닝되는 서비스로 다룹니다. 보안 채널은 한 홉에서 피어를 인증할 수 있지만, 그 신원이 자동으로 이벤트에 기록된 호스트명과 동일하거나 이벤트 자체에 대한 종단간 서명인 것은 아닙니다. (RFC 3195 §§5, 10;RFC 5425 §4)

이후의 syslog 작업은 이 구분을 더욱 분명하게 합니다. RFC 5848은 출처 인증, 무결성, 재생 저항, 시퀀싱, 누락 메시지 탐지를 지원할 수 있는 서명 메시지 블록을 정의합니다. 아울러 신뢰할 수 있는 전송도 응용 계층 손실은 막지 못한다고 경고합니다. 예컨대 수신자가 TCP 또는 TLS 세션을 닫는 경우입니다. 이것은 RFC 3195가 널리 배포되었다거나 서명이 모든 보존 문제를 해결한다는 증거가 아닙니다. 전달, 진위성, 완전성은 서로 다른 증거를 요구한다는 점을 보여줄 뿐입니다. (RFC 5848 §§1, 8.3–8.7)

이 설계의 지속적 가치는 범위에 대한 정확성입니다. RAW는 "이 BEEP 채널이 메시지를 순서대로 신뢰할 수 있게 전달했는가?"라는 질문에 답할 수 있습니다. COOKED는 "이 리스너가 이 엔트리에 긍정 또는 부정으로 응답했는가?"를 추가로 답할 수 있습니다. 그러나 다른 통제 없이는 "이벤트가 진짜였는가?", "저장 장애에서 살아남았는가?", "운영자가 대응했는가?"에는 답할 수 없습니다. 사고 조사에서는 감사 기록이 전송/세션 상태, 엔트리별 응답, 서명 검증, 수집기의 영속화, 하위 처리를 서로 다른 영수증으로 보존해야 합니다. RFC 3195는 프로토콜 동작을 규정합니다. 현재 구현 보급률이나 성능은 사용 가능한 자료가 확립하지 않습니다.

출처:RFC 3195;RFC 3195 현재 RFC Editor 기록;RFC 3195 IETF Datatracker 텍스트;RFC 3080, The BEEP Core;RFC 3081, BEEP over TCP;RFC 3164, The BSD Syslog Protocol;RFC 5424, The Syslog Protocol;RFC 5425, TLS Transport Mapping for Syslog;RFC 5426, Syslog UDP Transport;RFC 5848, Signed Syslog Messages;RFC 6587, Transmission of Syslog Messages over TCP;RFC 2782, DNS SRV;RFC 2119, Requirement-Level Keywords.