|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SYSLOGwg
##
|
|
|
|
|
|
|
|
|
Last Update: May 12, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SYSLOGwg
##
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SYSLOGwg
|
|
|
|
|
|
| The charter of the SYSLOG working group
is reported below.
|
|
|
|
Syslog is a de-facto standard for logging system events. However, the
protocol component of this event logging system has not been formally
documented. While the protocol has been very useful and scalable, it
has some known security problems which were documented in the
INFORMATIONAL RFC 3164.
The goal of this working group is to address the security and integrity
problems, and to standardize the syslog protocol, transport, and a
select set of mechanisms in a manner that considers the ease of
migration between and the co-existence of existing versions and the
standard.
Reviews have shown that there are very few similarities between the
message formats generated by heterogeneous systems. In fact, the only
consistent commonality between messages is that all of them contain
the <PRI> at the start. Additional testing has shown that as long as
the <PRI> is present in a syslog message, all tested receivers will
accept any generated message as a valid syslog message. In designing a
standard syslog message format, this Working Group will retain the
<PRI> at the start of the message and will introduce protocol
versioning. Along these same lines, many different charsets have been
used in syslog messages observed in the wild but no indication of the
charset has been given in any message. The Working Group also feels
that multiple charsets will not be beneficial to the community;
much code would be needed to distinguish and interpret different
charsets. For compatibility with existing implementations, the Working
Group will allow that messages may still be sent that do not indicate
the charset used. However, the Working Group will recommend that
messages contain a way to identify the charset used for the message,
and will also recommend a single default charset.
syslog has traditionally been transported over UDP and this WG has
already defined RFC 3195 for the reliable transport for the syslog
messages. The WG will separate the UDP transport from the protocol so
that others may define additional transports in the future.
The threats that this WG will primarily address are modification,
disclosure, and masquerading. A secondary threat is message stream
modification. Threats that will not be addressed by this WG are DoS and
traffic analysis. The primary attacks may be thwarted by a secure
transport. However, it must be remembered that a great deal of the
success of syslog has been attributed to its ease of implementation and
relatively low maintenance level. The Working Group will consider those
factors, as well as current implementations, when deciding upon a
secure transport. The secondary threat of message stream modification
can be addressed by a mechanism that will verify the end-to-end
integrity and sequence of messages. The Working Group feels that these
aspects may be addressed by a dissociated signature upon sent messages.
|
|
| - |
A document will be produced that describes a standardized syslog
protocol. A mechanism will also be defined in this document that will
provide a means to convey structured data.
|
| - |
A document will be produced that describes a standardized UDP
transport for syslog.
|
| - |
A document will be produced that requires a secure transport for the
delivery of syslog messages.
|
| - |
A document will be produced to describe the MIB for syslog entities.
|
| - |
A document will be produced that describes a standardized mechanism
to sign syslog messages to provide integrity checking and source
authentication.
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SYSLOGwg
##
|
|
|
|
|
|
|
|
|
|
| | |
RFC3164
08/2001
(29 p.)
[html]
[pdf(2)] |
C. Lonvick |
|
The BSD syslog Protocol |
|
This document describes the observed behavior of the syslog protocol.
This protocol has been used for the transmission of event
notification messages across networks for many years. While this
protocol was originally developed on the University of California
Berkeley Software Distribution (BSD) TCP/IP system implementations,
its value to operations and management has led it to be ported to
many other operating systems as well as being embedded into many
other networked devices.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3195
11/2001
(36 p.)
[html]
[pdf(2)] |
D. New
M. Rose |
|
Reliable Delivery for syslog |
|
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.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SYSLOGwg
##
|
|
|
|
|
|
|
|
|
|
| | |
syslog-protocol-23
RFC Ed Queue (09/07)
Sep 5, 2007
(39 p.)
[pdf(2)]
[html]
|
R. Gerhards |
|
The syslog Protocol |
This document describes the syslog protocol, which is used to convey
event notification messages. This protocol utilizes a layered
architecture, which allows the use of any number of transport
protocols for transmission of syslog messages. It also provides a
message format that allows vendor-specific extensions to be provided
in a structured way.
This document has been written with the original design goals for
traditional syslog in mind. The reason for a new layered
specification has arisen because standardization efforts for reliable
and secure syslog extensions suffer from the lack of a standards-
track and transport independent RFC. Without this document, each
other standard needs to define its own syslog packet format and
transport mechanism, which over time will introduce subtle
compatibility issues. This document tries to provide a foundation
that syslog extensions can build on. This layered architecture
approach also provides a solid basis that allows code to be written
once for each syslog feature rather than once for each transport.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SYSLOGwg
##
|
|
|
|
|
|
|
|
|
|
| | |
syslog-sign-23
Publication Requested
Sep 28, 2007
(36 p.)
[pdf(2)]
[html]
|
J. Kelsey
J. Callas
A. Clemm |
|
Signed syslog Messages |
|
This document describes a mechanism to add origin authentication,
message integrity, replay resistance, message sequencing, and
detection of missing messages to the transmitted syslog messages.
This specification is intended to be used in conjunction with the
work defined in RFC xxxx, "The syslog Protocol".
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SYSLOGwg
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
syslog-
rfc3195bis-00
ID Exists
(Recently Expired)
Nov 8, 2007
(21 p.)
[pdf(2)]
[html]
|
D. New
M. Rose
E. Lear |
|
Reliable Delivery for syslog |
|
The syslog protocol describes a number of service options related to
propagating event messages. This memo describes a mapping of the
syslog protocol to TCP connections, useful for reliable delivery of
event messages through the use of a BEEP profile. The earlier RAW
and COOKED BEEP syslog profiles are deprecated. The use of syslog
over BEEP provides 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.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## SYSLOGwg
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
