RFC relevance of reliable

As per Relevance of the word reliable, 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