Reliable Delivery for syslog
RFC 3195

Document Type RFC - Proposed Standard (November 2001; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3195 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                             D. New
Request for Comments: 3195                                       M. Rose
Category: Standards Track                   Dover Beach Consulting, Inc.
                                                           November 2001

                      Reliable Delivery for syslog

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   The BSD Syslog Protocol describes a number of service options related
   to propagating event messages.  This memo describes two mappings of
   the syslog protocol to TCP connections, both useful for reliable
   delivery of event messages.  The first provides a trivial mapping
   maximizing backward compatibility.  The second provides a more
   complete mapping.  Both provide a degree of robustness and security
   in message delivery that is unavailable to the usual UDP-based syslog
   protocol, by providing encryption and authentication over a
   connection-oriented protocol.

New & Rose                  Standards Track                     [Page 1]
RFC 3195              Reliable Delivery for syslog         November 2001

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    The Model  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.    The RAW Profile  . . . . . . . . . . . . . . . . . . . . . .  7
   3.1   RAW Profile Overview . . . . . . . . . . . . . . . . . . . .  7
   3.2   RAW Profile Identification and Initialization  . . . . . . .  9
   3.3   RAW Profile Message Syntax . . . . . . . . . . . . . . . . . 10
   3.4   RAW Profile Message Semantics  . . . . . . . . . . . . . . . 10
   4.    The COOKED Profile . . . . . . . . . . . . . . . . . . . . . 11
   4.1   COOKED Profile Overview  . . . . . . . . . . . . . . . . . . 11
   4.2   COOKED Profile Identification and Initialization . . . . . . 11
   4.3   COOKED Profile Message Syntax  . . . . . . . . . . . . . . . 11
   4.4   COOKED Profile Message Semantics . . . . . . . . . . . . . . 12
   4.4.1 The IAM Element  . . . . . . . . . . . . . . . . . . . . . . 12
   4.4.2 The ENTRY Element  . . . . . . . . . . . . . . . . . . . . . 14
   4.4.3 The PATH Element . . . . . . . . . . . . . . . . . . . . . . 19
   5.    Additional Provisioning  . . . . . . . . . . . . . . . . . . 25
   5.1   Message Authenticity . . . . . . . . . . . . . . . . . . . . 25
   5.2   Message Replay . . . . . . . . . . . . . . . . . . . . . . . 25
   5.3   Message Integrity  . . . . . . . . . . . . . . . . . . . . . 25
   5.4   Message Observation  . . . . . . . . . . . . . . . . . . . . 26
   5.5   Summary of Recommended Practices . . . . . . . . . . . . . . 26
   6.    Initial Registrations  . . . . . . . . . . . . . . . . . . . 27
   6.1   Registration: The RAW Profile  . . . . . . . . . . . . . . . 27
   6.2   Registration: The COOKED Profile . . . . . . . . . . . . . . 27
   7.    The syslog DTD . . . . . . . . . . . . . . . . . . . . . . . 28
   8.    Reply Codes  . . . . . . . . . . . . . . . . . . . . . . . . 32
   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 33
   9.1   Registration: BEEP Profiles  . . . . . . . . . . . . . . . . 33
   9.2   Registration: The System (Well-Known) TCP port number for
            syslog-conn . . . . . . . . . . . . . . . . . . . . . . . 33
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 34
   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36

New & Rose                  Standards Track                     [Page 2]
RFC 3195              Reliable Delivery for syslog         November 2001

1. Introduction

   The syslog protocol [1] presents a spectrum of service options for
   provisioning an event-based logging service over a network.  Each
   option has associated benefits and costs.  Accordingly, the choice as
   to what combination of options is provisioned is both an engineering
   and administrative decision.  This memo describes how to realize the
   syslog protocol when reliable delivery is selected as a required
   service.  It is beyond the scope of this memo to argue for, or
   against, the use of reliable delivery for the syslog protocol.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Show full document text