rfc3195.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 2,020 行 · 第 1/5 页

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
   document are to be interpreted as described in RFC 2119 [2].





































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


2. The Model

   The syslog service supports three roles of operation: device, relay,
   and collector.

   Devices and collectors act as sources and sinks, respectively, of
   syslog entries.  In the simplest case, only a device and collector
   are present.  E.g.,

     +--------+        +-----------+
     | Device | -----> | Collector |
     +--------+        +-----------+

   The relationship between devices and collectors is potentially many-
   to-many.  I.e., a device might communicate with many collectors;
   similarly, a collector might communicate with many devices.

   A relay operates in both modes, accepting syslog entries from devices
   and other relays and forwarding those entries to collectors and other
   relays.

   For example,

     +--------+      +-------+        +-------+      +-----------+
     | Device | ---> | Relay | -...-> | Relay | ---> | Collector |
     +--------+      +-------+        +-------+      +-----------+

   As shown, more than one relay may be present between any particular
   device and collector.

   A relay may be necessary for administrative reasons.  For example, a
   relay might run as an application proxy on a firewall.  Also, there
   might be one relay per company department, which authenticates all
   the devices in the department, and which in turn authenticates itself
   to a company-wide collector.

   A relay can also serve to filter messages.  For example, one relay
   may collect the syslog information from an entire web server farm,
   summarizing hit counts for report generation, forwarding "page not
   found" messages (indicating a possible broken link) to a collector
   that presents it to the webmaster, and sending more urgent messages
   (such as hardware failure reports) to a collector that gateways them
   to a pager.  A relay may also be used to convert formats from a
   device's output to a collector's input.

   It should be noted that a role of device, relay, or collector is
   relevant only to a particular BEEP channel (q.v., below).  A single
   server can serve as a device, a relay, and a collector, all at once,



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


   if so configured.  It can even serve as a relay and a collector to
   the same device at the same time using different BEEP channels over
   the same connection-oriented session; this might be useful to collect
   status yet relay urgent error messages.

   To provide reliable delivery when realizing the syslog protocol, this
   memo defines two BEEP profiles.  BEEP [3] is a generic application
   protocol framework for connection-oriented, asynchronous
   interactions.  Within BEEP, features such as authentication, privacy,
   and reliability through retransmission are provided.  There are two
   profiles defined in this memo:

   o  The RAW profile is designed to provide a high-performance, low-
      impact footprint, using essentially the same format as the
      existing UDP-based syslog service.

   o  The COOKED profile is designed to provide a structured entry
      format, in which individual entries are acknowledged (either
      positively or negatively).

   Note that both profiles run over BEEP.  BEEP defines "transport
   mappings," specifying how BEEP messages are carried over the
   underlying transport technologies.  At the time of this writing, only
   one such transport is defined, in [4], which specifies BEEP over TCP.
   All transport mappings are required to support enough reliability and
   sequencing to allow all BEEP messages on a given channel to be
   delivered reliably and in order.  Hence, both the RAW and COOKED
   profile provide reliable delivery of their messages.

   The choice of profile is independent of the operational roles
   discussed above.

   For example, in

     +--------+        +-------+        +-----------+
     | Device | -----> | Relay | -----> | Collector |
     +--------+        +-------+        +-----------+

   the device-to-relay link could be configured to use the RAW profile,
   while the relay-to-collector link could be configured to use the
   COOKED profile.  (For example, the relay may be parsing the RAW
   syslog messages from the device, knowing the details of their
   formats, before passing them to a more generic collector.) Indeed,
   the same device may use different profiles, depending on the
   collector to which it is sending entries.






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


   Devices and relays MAY discover relays and collectors via the DNS SRV
   algorithm [5].  If so configured, the service used is "syslog" and
   the protocol used is "tcp".  This allows for central administration
   of addressing, fallback for failed relays and collectors, and static
   load balancing.  Security policies and hardware configurations may be
   such that device configuration is more secure than the DNS server.
   Hardware devices may be of such limited resources that DNS SRV access
   is inappropriate.  Firewalls and other restrictive routing mechanisms
   may need to be dealt with before a reliable syslog connection can be
   established.  In these cases, DNS might not be the most appropriate
   configuration mechanism.








































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


3. The RAW Profile

3.1 RAW Profile Overview

   The RAW profile is designed for minimal implementation effort, high
   efficiency, and backwards compatibility.  It is appropriate
   especially in cases where legacy syslog processing will be applied.

   It should be noted that even though the RAW profile uses the same
   format for message payloads as the UDP version of syslog uses,
   delivery is reliable.  The RAW syslog profile is a profile of BEEP
   [3], and BEEP guarantees ordered reliable delivery of messages within
   each individual channel.

   When the profile is started, no piggyback data is supplied.  All BEEP
   messages in the RAW profile are specified as having a MIME Content-
   Type [6] of application/octet-stream.  Once the channel is open, the
   listener (not the initiator) sends a MSG message indicating it is
   ready to act as a syslog sink.  (Refer to [3]'s Section 2.1 for a
   discussion of roles that a BEEP peer may perform, including
   definitions of the terms "listener", "initiator", "client", and
   "server".)

   The initiator uses ANS replies to supply one or more syslog entries
   in the current UDP format, as specified in [1]'s Section 3.  When the
   initiator has no more entries to send, it finishes with a NUL reply
   and closes the channel.

   An example might appear as follows:

      L: <wait for incoming connection>
      I: <establish connection>
      L: RPY 0 0 . 0 201
      L: Content-type: application/beep+xml
      L:
      L: <greeting>
      L:   <profile
      L:     uri='http://xml.resource.org/profiles/syslog/COOKED' />
      L:   <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
      L: </greeting>
      L: END
      I: RPY 0 0 . 0 52
      I: Content-type: application/beep+xml
      I:
      I: <greeting />
      I: END
      I: MSG 0 1 . 52 133
      I: Content-type: application/beep+xml



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


      I:
      I: <start number='1'>
      I:   <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
      I: </start>
      I: END
      L: RPY 0 1 . 201 100