As per Relevance of the word delivery, we have this rfc below:
Network Working Group D.
Request for Comments: 3195 M.
Category: Standards Track Dover Beach Consulting, Inc
November 2001
Reliable Delivery for
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
The BSD Syslog Protocol describes a number of service options
to propagating event messages. This memo describes two mappings
the syslog protocol to TCP connections, both useful for
delivery of event messages. The first provides a trivial
maximizing backward compatibility. The second provides a
complete mapping. Both provide a degree of robustness and
in message delivery that is unavailable to the usual UDP-based
protocol, by providing encryption and authentication over
connection-oriented protocol
New & Rose Standards Track [Page 1]
RFC 3195 Reliable Delivery for syslog November 2001
Table of
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
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.
The syslog protocol [1] presents a spectrum of service options
provisioning an event-based logging service over a network.
option has associated benefits and costs. Accordingly, the choice
to what combination of options is provisioned is both an
and administrative decision. This memo describes how to realize
syslog protocol when reliable delivery is selected as a
service. It is beyond the scope of this memo to argue for,
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
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
The syslog service supports three roles of operation: device, relay
and collector
Devices and collectors act as sources and sinks, respectively,
syslog entries. In the simplest case, only a device and
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
and other relays and forwarding those entries to collectors and
relays
For example
+--------+ +-------+ +-------+ +-----------+
| Device | ---> | Relay | -...-> | Relay | ---> | Collector |
+--------+ +-------+ +-------+ +-----------+
As shown, more than one relay may be present between any
device and collector
A relay may be necessary for administrative reasons. For example,
relay might run as an application proxy on a firewall. Also,
might be one relay per company department, which authenticates
the devices in the department, and which in turn authenticates
to a company-wide collector
A relay can also serve to filter messages. For example, one
may collect the syslog information from an entire web server farm
summarizing hit counts for report generation, forwarding "page
found" messages (indicating a possible broken link) to a
that presents it to the webmaster, and sending more urgent
(such as hardware failure reports) to a collector that gateways
to a pager. A relay may also be used to convert formats from
device's output to a collector's input
It should be noted that a role of device, relay, or collector
relevant only to a particular BEEP channel (q.v., below). A
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
the same device at the same time using different BEEP channels
the same connection-oriented session; this might be useful to
status yet relay urgent error messages
To provide reliable delivery when realizing the syslog protocol,
memo defines two BEEP profiles. BEEP [3] is a generic
protocol framework for connection-oriented,
interactions. Within BEEP, features such as authentication, privacy
and reliability through retransmission are provided. There are
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
existing UDP-based syslog service
o The COOKED profile is designed to provide a structured
format, in which individual entries are acknowledged (
positively or negatively).
Note that both profiles run over BEEP. BEEP defines "
mappings," specifying how BEEP messages are carried over
underlying transport technologies. At the time of this writing,
one such transport is defined, in [4], which specifies BEEP over TCP
All transport mappings are required to support enough reliability
sequencing to allow all BEEP messages on a given channel to
delivered reliably and in order. Hence, both the RAW and
profile provide reliable delivery of their messages
The choice of profile is independent of the operational
discussed above
For example,
+--------+ +-------+ +-----------+
| 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
COOKED profile. (For example, the relay may be parsing the
syslog messages from the device, knowing the details of
formats, before passing them to a more generic collector.) Indeed
the same device may use different profiles, depending on
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
algorithm [5]. If so configured, the service used is "syslog"
the protocol used is "tcp". This allows for central
of addressing, fallback for failed relays and collectors, and
load balancing. Security policies and hardware configurations may
such that device configuration is more secure than the DNS server
Hardware devices may be of such limited resources that DNS SRV
is inappropriate. Firewalls and other restrictive routing
may need to be dealt with before a reliable syslog connection can
established. In these cases, DNS might not be the most
configuration mechanism
New & Rose Standards Track [Page 6]
RFC 3195 Reliable Delivery for syslog November 2001
3. The RAW
3.1 RAW Profile
The RAW profile is designed for minimal implementation effort,
efficiency, and backwards compatibility. It is
especially in cases where legacy syslog processing will be applied
It should be noted that even though the RAW profile uses the
format for message payloads as the UDP version of syslog uses
delivery is reliable. The RAW syslog profile is a profile of
[3], and BEEP guarantees ordered reliable delivery of messages
each individual channel
When the profile is started, no piggyback data is supplied. All
messages in the RAW profile are specified as having a MIME Content
Type [6] of application/octet-stream. Once the channel is open,
listener (not the initiator) sends a MSG message indicating it
ready to act as a syslog sink. (Refer to [3]'s Section 2.1 for
discussion of roles that a BEEP peer may perform,
definitions of the terms "listener", "initiator", "client",
"server".)
The initiator uses ANS replies to supply one or more syslog
in the current UDP format, as specified in [1]'s Section 3. When
initiator has no more entries to send, it finishes with a NUL
and closes the channel
An example might appear as follows
L: incoming connection
I: <establish connection
L: RPY 0 0 . 0 201
L: Content-type: application/beep+
L
L:
L: <
L: uri='http://xml.resource.org/profiles/syslog/COOKED' />
L:
L:
L:
I: RPY 0 0 . 0 52
I: Content-type: application/beep+
I
I:
I:
I: MSG 0 1 . 52 133
I: Content-type: application/beep+
New & Rose Standards Track [Page 7]
RFC 3195 Reliable Delivery for syslog November 2001
I
I:
I:
I:
I:
L: RPY 0 1 . 201 100
L: Content-type: application/beep+
L
L:
L:
L: MSG 1 0 . 0 50
L
L: Central Services. This has not been a recording
L:
I: ANS 1 0 . 0 61 0
I
I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.
I: ANS 1 0 . 61 58 1
I
I: <29>Oct 27 13:22:15 ductwork imxpd[141]: Contact Tuttle.
I: NUL 1 0 . 119 0
I:
L: MSG 0 3 . 301 70
L: Content-Type: application/beep+
L
L:
L:
I: RPY 0 3 . 185 46
I: Content-Type: application/beep+
I
I:
I:
I: MSG 0 4 . 231 72
I: Content-Type: application/beep+
I
I:
I:
L: RPY 0 4 . 371 46
L: Content-type: application/beep+
L
L:
L:
L: connection
I: connection
L: connection
New & Rose Standards Track [Page 8]
RFC 3195 Reliable Delivery for syslog November 2001
Here we see a BEEP session established, followed by the use of
RAW profile. The initiator is a device, while the listener is
collector. The initiator opens the channel, but the listener
the first MSG. This allows the initiator to send any number of
replies carrying syslog event messages. The initiator sends a
reply to indicate it is finished. Upon receiving the NUL,
listener closes the RAW channel. The initiator has the choice
closing the entire BEEP session or opening a new syslog channel (
or COOKED) for more transfers. In this example, the
chooses to close the entire BEEP session
The overhead for one ANS frame is about thirty octets, once
initial handshakes have been exchanged. If this overhead is
high, then messages are likely being generated at a high rate.
this case, multiple syslog messages can be aggregated into a
ANS frame, each separated by a CRLF sequence from the preceding.
final message still MUST NOT end with a CRLF
For example
L: MSG 1 0 . 0 50
L
L: Central Services. This has not been a recording
L:
I: ANS 1 0 . 0 119 0
I
I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency
I: <29>Oct 27 13:21:09 ductwork imxpd[141]: Contact Tuttle.
I: NUL 1 0 . 119 0
I:
3.2 RAW Profile Identification and
The RAW syslog profile is identified
http://xml.resource.org/profiles/syslog/
in the BEEP "profile" element during channel creation
No data is piggybacked during channel creation
New & Rose Standards Track [Page 9]
RFC 3195 Reliable Delivery for syslog November 2001
3.3 RAW Profile Message
All BEEP messages in this profile have a MIME content-type
application/octet-stream. The listener's first BEEP message
ignored and indeed may be empty except for headers; hence, any
is acceptable
The ANS replies the initiator sends in response MUST be
according to Section 4 of [1]. In particular, If the receiver
acting as a relay, then it MUST follow the rules as laid out
Section 4.2.2 of [1].
If multiple syslog messages are included in a single ANS reply,
is separated from the preceding with a CRLF. There is no
delimiter, but each syslog event message body length MUST be 1024
bytes or less, excluding BEEP framing overhead. Note that there
NOT be a CRLF between the text of the final syslog event message
the "END" marking the trailer of the BEEP frame
3.4 RAW Profile Message
The listener's opening BEEP MSG message has no semantics. (It is
good place to put in an identifying greeting.) The initiator's
replies MUST specify a facility, severity, and textual message,
described in [1].
New & Rose Standards Track [Page 10]
RFC 3195 Reliable Delivery for syslog November 2001
4. The COOKED
4.1 COOKED Profile
The COOKED profile is designed for new implementations of
protocol handlers. It provides a much finer grain of
tagging, allowing a better degree of automation in processing
Naturally, it includes more overhead as well in support of this
The COOKED profile supports three elements of interest
o The "iam" element identifies the sender to the receiver,
each peer to name itself for the other, and specifying the
(device, relay, or collector) each is taking on
o The "entry" element provides a parsed version of the syslog entry
with the various fields of interest broken out
o The "path" element identifies a list of relays through which
tagged collection of "entry" elements has passed, along with a
of flags indicating what assurances of security have been
effect throughout its delivery
4.2 COOKED Profile Identification and
The COOKED syslog profile is identified
http://xml.resource.org/profiles/syslog/
in the BEEP "profile" element during channel creation
During channel creation, the corresponding "profile" element in
BEEP "start" element may contain an "iam" element. If
creation is successful, then before sending the corresponding reply
the BEEP peer processes the "iam" element and includes the
response in the reply. This response will be an "ok" element or
"error" element. The choice of which element is returned
dependent on local provisioning of the recipient. Including an "iam
in the initial "start" element has exactly the same semantics
passing it as the first MSG message on the channel
4.3 COOKED Profile Message
All BEEP messages in this profile have a MIME Content-Type [6]
application/beep+xml. The syntax of the individual elements
specified in Section 7.
New & Rose Standards Track [Page 11]
RFC 3195 Reliable Delivery for syslog November 2001
4.4 COOKED Profile Message
Initiators issue two elements: "iam" and "entry", each using a "MSG
message. The listener issues "ok" in "RPY" messages and "error"
"ERR" messages. (See [3]'s Section 2.3.1 for the definitions of
"error" and "ok" elements.)
4.4.1 The IAM
The "iam" element serves to identify a device, relay, or collector
one end of the BEEP channel to the device, relay, or collector at
other end of the channel. The "iam" element includes the type
peer (device, relay, or collector), the fully qualified domain
of the peer, and an IP address of the peer. (The IP address
SHOULD be the IP address associated with the underlying
protocol carrying the channel.) The character data of the element
free-form human-readable text. It may be used to further
the peer, such as by describing the physical location of the machine
An "iam" element may be sent by the initiator of the channel at
time. The listener responds to an "iam" element with an "ok
(indicating acceptance), or an "error" (indicating rejection).
identity and role in effect is specified by the most recent "iam
answered with an "ok".
An "iam" could be rejected (with an "error" element) by the
if the privacy or authentication that has been negotiated
inadequate or if the authenticated user does not have
to serve in the specified role. It is expected that
installations will require an "iam" from the peer before
any "entry" messages
New & Rose Standards Track [Page 12]
RFC 3195 Reliable Delivery for syslog November 2001
For example, a successful creation might look like this
I: MSG 0 10 . 1832 259
I: Content-type: application/beep+
I
I:
I: <
I: uri='http://xml.resource.org/profiles/syslog/COOKED'>
I:
I: type='device'/> ]]>
I:
I:
L:
L: RPY 0 10 . 704 138
L: Content-type: application/beep+
L
L:
L: ]]>
L:
L:
A creation with an embedded "iam" that fails might look like this
C: MSG 0 12 . 1832 259
C: Content-type: application/beep+
C
C:
C: <
C: uri='http://xml.resource.org/profiles/syslog/COOKED'>
C:
C: type='relay'/> ]]>
C:
C:
C:
S: RPY 0 12 . 704 241
S: Content-type: application/beep+
S
S:
S:
S: User 'buttle.example.com' not
S: to "iam" for 'tuttle.example.com' ]]>
S:
S:
In this case, the error code indicates that the
"buttle.example.com" has logged in via some SASL profile, but
syslog COOKED profile implementation is claiming to
"tuttle.example.com", a mismatch that the server is disallowing
New & Rose Standards Track [Page 13]
RFC 3195 Reliable Delivery for syslog November 2001
4.4.2 The ENTRY
The "entry" element carries the details of a single syslog entry.
attributes of an "entry" element include "facility", "severity",
"timestamp", "hostname", and "tag". "Facility" and "severity"
the semantics defined in [1]'s 4.1. The other attributes have
semantics as in Sections 4.2.1 and 4.2.3 of [1]. An "entry"
can also contain a "pathID" attribute, described below
If the client is a relay, the "entry" SHOULD also contain
attributes "deviceFQDN" and "deviceIP", specifying the FQDN and
address of the device that originally created the entry.
attributes may be added by either the relay or the
device. If possible, the device SHOULD add these entries,
to the interface most closely associated with the syslog entry
Before a relay forwards an entry from a device that does not
these attributes, it SHOULD add them based on the "iam" element
has received from the device, or based on the underlying
connection address. A relay MUST NOT add these fields if they
missing and an "iam" element on the channel has indicated
messages are coming from another relay
The "pathID" attribute indicates the path over which this entry
travelled, from device through relays to the final collector
Syntactically, its value is a string of digits that must match
"pathID" attribute of a "path" element sent earlier over the
channel. Semantically, it indicates that the list of relays
flags indicated in that earlier "path" element apply to this "entry
element
The character data for the element is the unstructured syslog
message being logged. If the original device delivers the
for the first time via the COOKED profile, it may have any
inside the CDATA. However, for maximum compatibility, the
SHOULD format the CDATA of the message in accordance with
4.2.1 through 4.2.3 of [1].
New & Rose Standards Track [Page 14]
RFC 3195 Reliable Delivery for syslog November 2001
In the message is being relayed, "tag" SHOULD be those of
original device generating the entry (unless the device cannot
a tag). The "timestamp" SHOULD be that of the original
generation time, rather than the time the entry was passed
from the relay. The "hostname" SHOULD be the host name or IP
by which the device knows itself; this MUST follow the
established in Sections 4.2.1 through 4.2.3 of [1]. The
contents of the syslog message MUST be preserved in the CDATA of
"entry" element; this includes preservation of exact content
translation from the UDP or RAW formats. In particular,
timestamps MUST NOT be rewritten in the CDATA of the "entry" element
the tag MUST NOT be removed from the CDATA even if presented in
"entry" attributes as well, and so on
To be consistent with the spirit of [1], a relay receiving a
that does not contain a valid priority, timestamp or hostname
follow the same general rules as described in section 4.2.2 of [1]
while including the exact contents of the received syslog packet
the CDATA. The values of the facility and severity will be
to be 8 and 6 respectively and will be placed into the
attributes of the "entry" element. The hostname will be the name
the device as it is known to the relay and will also be inserted
the "entry" element's attributes. The timestamp would be set to
received time, inserted only into the attributes of the "entry
element. As an example, consider this message received on UDP
514 and interpreted as a traditional syslog message, assuming
underlying IP source address is that of the "pipeworks" machine
<.....eeeek
To be relayed, it must be modified as follows
C: MSG 1 0 . 2079 156
C: Content-Type: application/beep+
C
C: facility='8' severity='6'
C: hostname='pipeworks
C: timestamp='Oct 31 23:59:59'
C: ><.....eeeek!
C:
S: RPY 1 0 . 933 45
S: Content-Type: application/beep+
S
S:
S:
New & Rose Standards Track [Page 15]
RFC 3195 Reliable Delivery for syslog November 2001
As another example, consider a message being received that does
properly adhere to the conventions described in Section 4.2.2 of [1].
In particular, the timestamp has a year, making it a
format
<166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM
This would be relayed as follows
C: MSG 1 0 . 2235 242
C: Content-Type: application/beep+
C
C: facility='160' severity='6'
C: hostname='bomb
C: deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
C: timestamp='Oct 22 01:00:04'
C: ><166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!
C:
S: RPY 1 0 . 978 45
S: Content-Type: application/beep+
S
S:
S:
Note that the tag value was not readily apparent from the
message (due to the failed parsing of the timestamp), so it was
included in the "entry" element
It is explicitly permitted for a relay to parse raw messages in
more sophisticated way, but all implementations MUST be able to
messages presented in the format described in [1]. A
sophisticated relay could have recognized the year and
parsed out the correct time, tag, and hostname, but such
parsing capability is OPTIONAL
Consider the following example, in contrast
<166> Oct 22 01:00:00 bomb tick[0]: BOOM
New & Rose Standards Track [Page 16]
RFC 3195 Reliable Delivery for syslog November 2001
This conformant message would be relayed as follows
C: MSG 1 0 . 2477 248
C: Content-Type: application/beep+
C
C: facility='160' severity='6'
C: hostname='bomb
C: deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
C: timestamp='Oct 22 01:00:00' tag='tick
C: ><166> Oct 22 01:00:00 bomb tick[0]: BOOM!
C:
S: RPY 1 0 . 1023 45
S: Content-Type: application/beep+
S
S:
S:
In this case, the tag is detected and the timestamp represents
message generation time rather than the message reception time
Finally, the "entry" element may also contain an "xml:lang
attribute, indicating the language in which the CDATA content of
tag is presented, as described in [7].
The "entry" element is answered with either an empty "ok" element
everything was successful, or a standard "error" element if there
a problem. An "entry" element can be rejected if no "iam"
has been accepted by the listener. It can also be rejected if
user authenticated on the BEEP session (if any) does not have
authority to generate (as a device) or relay that entry. An error
also possible if the "pathID" attribute refers to an unknown (
rejected) "path" element
New & Rose Standards Track [Page 17]
RFC 3195 Reliable Delivery for syslog November 2001
A successful exchange of an "entry" element may look like this
C: MSG 1 0 . 2725 173
C: Content-Type: application/beep+
C
C: facility='24' severity='5'
C: timestamp='Jan 26 15:16:17'
C: hostname='pipework' tag='imxp'>
C: No 27B/6 available
C:
S: RPY 1 0 . 1068 45
S: Content-Type: application/beep+
S
S:
S:
Here, the device IP address and FQDN are taken from the "iam
element, if any, or from the underlying connection information
An example where an "entry" element is rejected with an "error
element
C: MSG 1 2 . 2898 223
C: Content-Type: application/beep+
C
C: facility='24' severity='5' timestamp='Jan 02 13:22:15'
C: deviceFQDN='jack.example.net' deviceIP='10.0.0.83'
C: tag='imxpd'>
C: Replacement device found in nostril
C:
C:
S: ERR 1 2 . 1113 111
S: Content-Type: application/beep+
S
S: Not allowed to relay
S: jack.example.net
S:
Here, the client attempts to relay an entry on behalf
jack.example.com, but the entry is refused by the collector
administrative reasons. This may occur, for example,
lowry.example.com is in a different department than jack.example.com
New & Rose Standards Track [Page 18]
RFC 3195 Reliable Delivery for syslog November 2001
4.4.3 The PATH
The "path" element serves to describe a list of the relays
which that element has passed, along with a set of flags
indicate the properties that all links from the device to the
have shared in common. Each "path" element contains either
"path" element or is empty. An empty "path" element identifies
device, while a "path" element with a nested "path"
identifies a relay. Each "path" element names a FQDN and IP
of the interface that sent the element. Each "path" element
names a FQDN and IP address for the interface that received
element. Each "path" element also carries a "linkprops" attribute
specifying the properties of the link it describes
Each "path" element has a "pathID" attribute which must be unique
all "path" elements sent on this channel since its inception
Syntactically, the "pathID" attribute is a string of digits
Semantically, it serves to identify one "path" element out of many
and it serves to link a "path" element with one or more "entry
elements. Any "pathID" attribute is unrelated to any "pathID
attribute in nested "path" elements or on other channels
Each "path" element has a "fromFQDN" attribute and an "fromIP
attribute. The "fromFQDN" attribute SHOULD be the fully
domain name of the interface over which the "path" element was sent
(The "fromFQDN" can be omitted if that interface has no DNS entry.)
Similarly, the "fromIP" attribute MUST be the IP address of
interface over which the "path" element was sent
Each "path" element has a "toFQDN" attribute and an "toIP" attribute
The "toFQDN" attribute SHOULD be the fully qualified domain name
the interface over which the "path" element was received. (
"toFQDN" can be omitted if that interface has no DNS entry.)
Similarly, the "toIP" attribute MUST be the IP address of
interface over which the "path" element was received
Finally, each "path" element carries a "linkprops" attribute.
is syntactically a string of individual characters, each
one property of the channel over which this "path" element is
carried. Note that outer "path" elements may have
guarantees than inner "path" elements; care should be taken in
interpretation of flags. The semantics of each possible character
this string are as follows
New & Rose Standards Track [Page 19]
RFC 3195 Reliable Delivery for syslog November 2001
o: When present, "o" (lower-case letter "o") indicates that
privacy has been negotiated over this link, weakly protecting
observation the content of entries associated with this "path
element. (Weak privacy is encryption with less than 80 bits
key.)
O: When present, "O" (upper-case letter "O") indicates that
privacy has been negotiated over this link, strongly
from observation the content of entries associated with
"path" element. (Strong privacy is encryption with 80 bits
more of key, or a transfer mechanism that is otherwise
to eavesdrop upon.)
U: When present, "U" indicates that a valid user has
authenticated (via SASL or TLS) and an "iam" element has
accepted
A: When present, "A" indicates that this link has been protected
an authentication layer, authenticating the source of
"entry" associated with this path
R: When present, "R" indicates that this link has been
against message replay
I: When present, "I" indicates that this link has been
against modifications of messages in passing. ("I" stands
message Integrity.)
L: When present, "L" indicates that this link has been
against loss of messages. That is, this is a reliable
link
D: When present, "D" indicates that the "from" side of this link is
device. If this is not present on the innermost "path" element
"entry" elements associated with this path have not been
by the COOKED profile for their entire lifetime
Upon receiving a "path" element, the peer MUST perform the
checks
o The "fromFQDN" and "fromIP" must match the underlying
connection
o The flags in the "linkprops" attribute must match the
of the session
o The "toFQDN" and "toIP" must match the underlying
connection
New & Rose Standards Track [Page 20]
RFC 3195 Reliable Delivery for syslog November 2001
o The "pathID" attribute must be unique with respect to all
"path" elements received on this channel
If all these checks pass, the "path" element is accepted with an "ok
element. Otherwise, an "error" element is generated with
appropriate code. In addition, if any of the nested "path"
refer to the machine receiving the element, it may indicate a
loop in the configuration for the so-identified path, and
measures should be taken
If the peer receiving an "entry" element is receiving it
from a device via either syslog-conn profile, and the device has
generated a "path" element, the receiver may itself generate
appropriate "path" element, either to be recorded in the logs (
this peer is a collector) or passed to the next peer (if this peer
a relay). If a peer receives a syslog message via UDP, it
optionally generate an appropriate "peer" element based on
cryptographic information provided in the message itself
When a peer receives a "path" element, it remembers it for
use. A collector will store it in the log for later reference.
relay will remember it. When an "entry" arrives referencing
received "path" element, and that entry needs to be forwarded
another relay or collector, and no appropriate "path" element
already been generated, an appropriate "path" element is
and sent over the outbound channel before the entry is forwarded.
appropriate "path" element is created by taking the received "path
element, wrapping it in a new "path" element with the
attributes, and assigning it a new "pathID" attribute. When
"entry" elements arrive with the same incoming "pathID" attribute
and they need to be forwarded to a channel over which an
"pathID" attribute has already been sent, only the "pathID"
of the "entry" element needs to be rewritten to refer to the "path
element on the outgoing channel
It should be noted that the majority of the complexity in
"path" elements arises only in relays. In particular, devices
need to generate "path" elements and collectors need only
them, log them, and possibly use them in displays and reports
Collectors do not need to generate "path" elements or rewrite "entry
elements. Hence, only in complex configurations (where they are
useful) do complex "path" configurations occur
New & Rose Standards Track [Page 21]
RFC 3195 Reliable Delivery for syslog November 2001
For example, here is a path element sent
lowry.records.example.com to kurtzman.records.example.com.
indicates that entries from lowry to kurtzman tagged
pathID='173' originated from screen.lowry.records.example.com.
indicates that screen.lowry.records.example.com is believed
lowry.records.example.com to be the originating device, and
entries over this path are delivered without loss and
modification, although messages might be replayed or observed.
link between lowry and kurtzman, however, avoids replay attacks,
messages, and modifications to messages.
screen.lowry.records.example.com has not authenticated itself
lowry.records.example.com, lowry claims to have authenticated
to kurtzman
C: MSG 2 1 . 3121 426
C: Content-type: application/beep+
C
C:
C: toFQDN='kurtzman.records.example.com
C: toIP='10.0.0.51'
C: linkprops='ULRI
C: pathID='173'>
C:
C: toFQDN='lowry.records.example.com
C: toIP='10.0.0.50'
C: linkprops='DLI
C: pathID='24'>
C:
C:
C:
S: ERR 2 1 . 1224 114
S: Content-type: application/beep+
S
S: linkprops includes 'U
S: but no 'iam' received
S:
However, kurtzman.records.example.com rejects the "path" element
since the "linkprops" attribute claims that lowry has
itself, but kurtzman disagrees, not having received an "iam" element
New & Rose Standards Track [Page 22]
RFC 3195 Reliable Delivery for syslog November 2001
In a second example, this "path" element
collector.example.com that the records department's firewall will
forwarding "entry" elements with a "pathID" attribute whose value
"17". These "entry" elements will be coming in on the "10.0.0.2"
interface of the firewall, to be forwarded out the "134.130.74.56"
interface of the firewall. The final hop has all
guarantees, although the entries transferred within the
department (behind the firewall) may have been observed in passing
C: MSG 2 2 . 3547 813
C: Content-type: application/beep+
C
C:
C: toFQDN='collector.example.com
C: toIP='134.130.74.12'
C: linkprops='OUARIL
C: pathID='17'>
C:
C: toFQDN='fwall.records.example.com
C: toIP='10.0.0.2'
C: linkprops='ULRI
C: pathID='120'>
C:
C: toFQDN='kurtzman.records.example.com
C: toIP='10.0.0.51'
C: linkprops='ULRI
C: pathID='173'>
C:
C: toFQDN='lowry.records.example.com
C: toIP='10.0.0.50'
C: linkprops='DLI
C: pathID='24'>
C:
C:
S: RPY 2 2 . 1338 45
S: Content-type: application/beep+
S
S:
S:
New & Rose Standards Track [Page 23]
RFC 3195 Reliable Delivery for syslog November 2001
As a final example, an "entry" element from Lowry's screen arrives
the firewall. The "path" attribute is rewritten, and it is
on to the collector
The entry arrives on the 10.0.0.2 interface
C: MSG 2 3 . 4360 250
C: Content-Type: application/beep+
C
C: facility='24' severity='5'
C: timestamp='Oct 27 13:24:12'
C: deviceFQDN='screen.lowry.records.example.com
C: deviceIP='10.0.0.47'
C: pathID='173'
C: tag='dvd'>
C: Job paused - Boss watching
C:
C:
S: RPY 2 3 . 1383 45
S: Content-Type: application/beep+
S
S:
S:
It is forwarded out the 134.130.74.56 interface
C: MSG 7 9 . 9375 276
C: Content-Type: application/beep+
C
C: facility='24' severity='5'
C: timestamp='Oct 27 13:24:12'
C: deviceFQDN='screen.lowry.records.example.com
C: deviceIP='10.0.0.47'
C: pathID='17'
C: tag='dvd'>
C: Job paused - Boss watching
C:
C:
S: RPY 7 9 . 338 45
S: Content-Type: application/beep+
S
S:
S:
A discussion of the wisdom of configuring Lowry's machine to
such messages via Kurtzman's machine is beyond the scope of
document
New & Rose Standards Track [Page 24]
RFC 3195 Reliable Delivery for syslog November 2001
5. Additional
In more advanced configurations, syslog devices, relays,
collectors can be configured to support various delivery priorities
Multiple channels running the same profile can be opened between
peers, with higher priority syslog messages routed to a channel
is given more bandwidth. Such provisioning is a local matter
syslog [1] discusses a number of reasons why privacy
authentication of syslog entry messages may be important in
networked computing environment. The nature of BEEP allows
convenient layering of authentication and privacy over any
channel
5.1 Message
Section 6.2 of [1] discusses the dangers of unauthenticated
entries. To prevent inauthentic syslog event messages from
accepted, configure syslog peers to require the use of a
authentication technology for the BEEP session
If provisioned for message authentication, implementations SHOULD
SASL mechanism DIGEST-MD5 [8] to provision this service
5.2 Message
Section 6.3.4 of [1] discusses the dangers of syslog message replay
To prevent syslog event messages from being replayed,
syslog peers to require the use of a strong authentication
for the BEEP session
If provisioned to detect message replay, implementations SHOULD
SASL mechanism DIGEST-MD5 [8] to provision this service
5.3 Message
Section 6.5 of [1] discusses the dangers of syslog event
being maliciously altered by an attacker. To prevent messages
being altered, configure syslog peers to require the use of a
authentication technology for the BEEP session
If provisioned to protect message integrity, implementations
use SASL mechanism DIGEST-MD5 [8] to provision this service
New & Rose Standards Track [Page 25]
RFC 3195 Reliable Delivery for syslog November 2001
5.4 Message
Section 6.6 of [1] discusses the dangers (and benefits) of
messages being visible at intermediate points along the
path between device and collector. To prevent messages from
viewed by an attacker, configure syslog peers to require the use of
transport security profile for the BEEP session. (However,
traffic characteristics, e.g., volume and timing of transmissions
remain observable.)
If provisioned to secure messages against unauthorized observation
implementations SHOULD use the TLS profile [3] to provision
service. The cipher algorithm used SHOULD
TLS_RSA_WITH_3DES_EDE_CBC_SHA
5.5 Summary of Recommended
For the indicated protections, implementations SHOULD be
to use the indicated mechanisms
Desired Protection SHOULD tune
------------------ -----------------
Authentication http://iana.org/beep/SASL/DIGEST-MD
+ Replay http://iana.org/beep/SASL/DIGEST-MD
+ Integrity http://iana.org/beep/SASL/DIGEST-MD
+ Observation http://iana.org/beep/
BEEP peer identities used for authentication SHOULD correspond to
FQDN of the initiating peer. That is, a relay running
relay.example.com should use a "user ID" of "relay.example.com
within the SASL authentication profiles, as well as in the FQDN
the "iam" element
New & Rose Standards Track [Page 26]
RFC 3195 Reliable Delivery for syslog November 2001
6. Initial
6.1 Registration: The RAW
Profile Identification: http://xml.resource.org/profiles/syslog/
Messages exchanged during Channel Creation:
Messages starting one-to-one exchanges:
Messages in positive replies:
Messages in negative replies:
Messages in one-to-many exchanges:
Message Syntax: See Section 3.3
Message Semantics: See Section 3.4
Contact Information: See the "Authors' Addresses" section of
6.2 Registration: The COOKED
Profile Identification
http://xml.resource.org/profiles/syslog/
Messages exchanged during Channel Creation:
Messages starting one-to-one exchanges: iam, entry,
Messages in positive replies:
Messages in negative replies:
Messages in one-to-many exchanges:
Message Syntax: See Section 4.3
Message Semantics: See Section 4.4
Contact Information: See the "Authors' Addresses" section of
New & Rose Standards Track [Page 27]
RFC 3195 Reliable Delivery for syslog November 2001
7. The syslog
The following is the DTD defining the valid elements for the
over BEEP mapping
"">
%BEEP
New & Rose Standards Track [Page 28]
RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 29]
RFC 3195 Reliable Delivery for syslog November 2001
FACILITY "CDATA">
TIMESTAMP "CDATA">
fqdn %FQDN; #
ip %IP; #
type (device|relay|collector) #REQUIRED
xml:lang %LANG; "i-default
facility %FACILITY; #
severity %SEVERITY; #
timestamp %TIMESTAMP; #
tag %ATEXT; #
deviceFQDN %FQDN; #
deviceIP %IP; #
pathID %IDINT; #IMPLIED
New & Rose Standards Track [Page 30]
RFC 3195 Reliable Delivery for syslog November 2001
pathID %IDINT; #
fromFQDN %FQDN; #
fromIP %IP; #
toFQDN %FQDN; #
toIP %IP; #
linkprops %ATEXT; #REQUIRED
New & Rose Standards Track [Page 31]
RFC 3195 Reliable Delivery for syslog November 2001
8. Reply
The following error codes are used in the protocol
code
==== =======
200
421 service not
451 requested action
(e.g., local error in processing
454 temporary authentication
500 general syntax
(e.g., poorly-formed XML
501 syntax error in
(e.g., non-valid XML
504 parameter not
530 authentication
534 authentication mechanism
(e.g., too weak, sequence exhausted, etc.)
535 authentication
537 action not authorized for
538 authentication mechanism requires
550 requested action not
(e.g., no requested profiles are acceptable
553 parameter
554 transaction
(e.g., policy violation
New & Rose Standards Track [Page 32]
RFC 3195 Reliable Delivery for syslog November 2001
9. IANA
9.1 Registration: BEEP
The IANA registers the profiles specified in Section 6, and
IANA-specific URIs "http://iana.org/beep/SYSLOG/RAW"
"http://iana.org/beep/SYSLOG/COOKED".
9.2 Registration: The System (Well-Known) TCP port number for syslog
A single well-known port (601) is allocated to syslog-conn. In-
negotiation determines whether COOKED or RAW syslog-conn is in use
Protocol Number:
Message Formats, Types, Opcodes, and Sequences: See Section 3.3
Section 4.4.
Functions: See Section 3.4 and Section 4.4.
Use of Broadcast/Multicast:
Proposed Name: Reliable syslog
Short name: syslog-
Contact Information: See the "Authors' Addresses" section of
New & Rose Standards Track [Page 33]
RFC 3195 Reliable Delivery for syslog November 2001
10. Security
Consult Section 6 of [1] for a discussion of security issues for
syslog service. In addition, since the RAW and COOKED profiles
defined using the BEEP framework, consult [3]'s Section 8 for
discussion of BEEP-specific security issues
BEEP is used to provide communication security but not
integrity. In other words, the messages "on the wire" can
protected, but a compromised device may undetectably
incorrect messages, and relays and collectors can modify, insert,
delete messages undetectably. Other techniques must be used
assure that such compromises are detectable
11.
The authors gratefully acknowledge the contributions of
Calabrese, Keith McCloghrie, Balazs Scheidler, and David Waitzman
12.
[1] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[3] Rose, M., "The Blocks Extensible Exchange Protocol Core",
3080, March 2001.
[4] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081,
2001.
[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part Two: Media Types", RFC 2046,
1996.
[7] Alvestrand, H., "Tags for the Identification of Languages",
47, RFC 3066, January 2001.
[8] Leach, P. and C. Newman, "Using Digest Authentication as a
Mechanism", RFC 2831, May 2000.
New & Rose Standards Track [Page 34]
RFC 3195 Reliable Delivery for syslog November 2001
Authors'
Darren
5390 Caminito
San Diego, CA 92130
Phone: +1 858 350 9733
EMail: dnew@san.rr.
Marshall T.
Dover Beach Consulting, Inc
POB 255268
Sacramento, CA 95865-5268
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.
New & Rose Standards Track [Page 35]
RFC 3195 Reliable Delivery for syslog November 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
New & Rose Standards Track [Page 36]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
