< draft-ietf-syslog-reliable-11.txt   draft-ietf-syslog-reliable-12.txt >
Network Working Group D. New Network Working Group D. New
Internet-Draft M. Rose Internet-Draft M. Rose
Expires: January 14, 2002 Invisible Worlds, Inc. Expires: January 22, 2002 Invisible Worlds, Inc.
July 16, 2001 July 24, 2001
Reliable Delivery for syslog Reliable Delivery for syslog
draft-ietf-syslog-reliable-11 draft-ietf-syslog-reliable-12.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2002. This Internet-Draft will expire on January 22, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
The syslog protocol [1] describes a number of service options related The syslog protocol [1] describes a number of service options related
to propagating event messages. This memo describes two mappings of to propagating event messages. This memo describes two mappings of
the syslog protocol to TCP connections, both useful for reliable the syslog protocol to TCP connections, both useful for reliable
skipping to change at page 2, line 9 skipping to change at page 2, line 9
maximizing backward compatibility. The second provides a more maximizing backward compatibility. The second provides a more
complete mapping. Both provide a degree of robustness and security complete mapping. Both provide a degree of robustness and security
in message delivery that is unavailable to the usual UDP-based syslog in message delivery that is unavailable to the usual UDP-based syslog
protocol, by providing encryption and authentication over a protocol, by providing encryption and authentication over a
connection-oriented protocol. connection-oriented protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Model . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The RAW Profile . . . . . . . . . . . . . . . . . . . . . . 6 3. The RAW Profile . . . . . . . . . . . . . . . . . . . . . . 7
3.1 RAW Profile Overview . . . . . . . . . . . . . . . . . . . . 6 3.1 RAW Profile Overview . . . . . . . . . . . . . . . . . . . . 7
3.2 RAW Profile Identification and Initialization . . . . . . . 8 3.2 RAW Profile Identification and Initialization . . . . . . . 9
3.3 RAW Profile Message Syntax . . . . . . . . . . . . . . . . . 9 3.3 RAW Profile Message Syntax . . . . . . . . . . . . . . . . . 10
3.4 RAW Profile Message Semantics . . . . . . . . . . . . . . . 9 3.4 RAW Profile Message Semantics . . . . . . . . . . . . . . . 10
4. The COOKED Profile . . . . . . . . . . . . . . . . . . . . . 10 4. The COOKED Profile . . . . . . . . . . . . . . . . . . . . . 11
4.1 COOKED Profile Overview . . . . . . . . . . . . . . . . . . 10 4.1 COOKED Profile Overview . . . . . . . . . . . . . . . . . . 11
4.2 COOKED Profile Identification and Initialization . . . . . . 10 4.2 COOKED Profile Identification and Initialization . . . . . . 11
4.3 COOKED Profile Message Syntax . . . . . . . . . . . . . . . 10 4.3 COOKED Profile Message Syntax . . . . . . . . . . . . . . . 11
4.4 COOKED Profile Message Semantics . . . . . . . . . . . . . . 11 4.4 COOKED Profile Message Semantics . . . . . . . . . . . . . . 12
4.4.1 The IAM Element . . . . . . . . . . . . . . . . . . . . . . 11 4.4.1 The IAM Element . . . . . . . . . . . . . . . . . . . . . . 12
4.4.2 The ENTRY Element . . . . . . . . . . . . . . . . . . . . . 13 4.4.2 The ENTRY Element . . . . . . . . . . . . . . . . . . . . . 14
4.4.3 The PATH Element . . . . . . . . . . . . . . . . . . . . . . 18 4.4.3 The PATH Element . . . . . . . . . . . . . . . . . . . . . . 19
5. Additional Provisioning . . . . . . . . . . . . . . . . . . 24 5. Additional Provisioning . . . . . . . . . . . . . . . . . . 25
5.1 Message Authenticity . . . . . . . . . . . . . . . . . . . . 24 5.1 Message Authenticity . . . . . . . . . . . . . . . . . . . . 25
5.2 Message Replay . . . . . . . . . . . . . . . . . . . . . . . 24 5.2 Message Replay . . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Message Integrity . . . . . . . . . . . . . . . . . . . . . 24 5.3 Message Integrity . . . . . . . . . . . . . . . . . . . . . 25
5.4 Message Observation . . . . . . . . . . . . . . . . . . . . 25 5.4 Message Observation . . . . . . . . . . . . . . . . . . . . 26
5.5 Summary of Recommended Practices . . . . . . . . . . . . . . 25 5.5 Summary of Recommended Practices . . . . . . . . . . . . . . 26
6. Initial Registrations . . . . . . . . . . . . . . . . . . . 26 6. Initial Registrations . . . . . . . . . . . . . . . . . . . 27
6.1 Registration: The RAW Profile . . . . . . . . . . . . . . . 26 6.1 Registration: The RAW Profile . . . . . . . . . . . . . . . 27
6.2 Registration: The COOKED Profile . . . . . . . . . . . . . . 26 6.2 Registration: The COOKED Profile . . . . . . . . . . . . . . 27
7. The syslog DTD . . . . . . . . . . . . . . . . . . . . . . . 27 7. The syslog DTD . . . . . . . . . . . . . . . . . . . . . . . 28
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
9.1 Registration: BEEP Profiles . . . . . . . . . . . . . . . . 32 9.1 Registration: BEEP Profiles . . . . . . . . . . . . . . . . 33
9.2 Registration: The System (Well-Known) TCP port number for 9.2 Registration: The System (Well-Known) TCP port number for
syslog-reliable . . . . . . . . . . . . . . . . . . . . . . 32 syslog-reliable . . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . 34
References . . . . . . . . . . . . . . . . . . . . . . . . . 34 References . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
Full Copyright Statement . . . . . . . . . . . . . . . . . . 37 Full Copyright Statement . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The syslog protocol [1] presents a spectrum of service options for The syslog protocol [1] presents a spectrum of service options for
provisioning an event-based logging service over a network. Each provisioning an event-based logging service over a network. Each
option has associated benefits and costs. Accordingly, the choice as option has associated benefits and costs. Accordingly, the choice as
to what combination of options is provisioned is both an engineering to what combination of options is provisioned is both an engineering
and administrative decision. This memo describes how to realize the and administrative decision. This memo describes how to realize the
syslog protocol when reliable delivery is selected as a required syslog protocol when reliable delivery is selected as a required
service. It is beyond the scope of this memo to argue for, or service. It is beyond the scope of this memo to argue for, or
skipping to change at page 5, line 24 skipping to change at page 5, line 24
profiles defined in this memo: profiles defined in this memo:
o The RAW profile is designed to provide a high-performance, low- o The RAW profile is designed to provide a high-performance, low-
impact footprint, using essentially the same format as the impact footprint, using essentially the same format as the
existing UDP-based syslog service. existing UDP-based syslog service.
o The COOKED profile is designed to provide a structured entry o The COOKED profile is designed to provide a structured entry
format, in which individual entries are acknowledged (either format, in which individual entries are acknowledged (either
positively or negatively). positively or negatively).
Note that both profiles run over BEEP. BEEP defines "transport
mappings," specifying how BEEP messages are carried over the
underlying transport technologies. At the time of this writing, only
one such transport is defined, in [4], which specifies BEEP over TCP.
All transport mappings are required to support enough reliability and
sequencing to allow all BEEP messages on a given channel to be
delivered reliably and in order. Hence, both the RAW and COOKED
profile provide reliable delivery of their messages.
The choice of profile is independent of the operational roles The choice of profile is independent of the operational roles
discussed above. discussed above.
For example, in For example, in
+--------+ +-------+ +-----------+ +--------+ +-------+ +-----------+
| Device | -----> | Relay | -----> | Collector | | Device | -----> | Relay | -----> | Collector |
+--------+ +-------+ +-----------+ +--------+ +-------+ +-----------+
the device-to-relay link could be configured to use the RAW profile, the device-to-relay link could be configured to use the RAW profile,
while the relay-to-collector link could be configured to use the while the relay-to-collector link could be configured to use the
COOKED profile. (For example, the relay may be parsing the RAW COOKED profile. (For example, the relay may be parsing the RAW
syslog messages from the device, knowing the details of their syslog messages from the device, knowing the details of their
formats, before passing them to a more generic collector.) Indeed, formats, before passing them to a more generic collector.) Indeed,
the same device may use different profiles, depending on the the same device may use different profiles, depending on the
collector to which it is sending entries. collector to which it is sending entries.
Devices and relays MAY discover relays and collectors via the DNS SRV Devices and relays MAY discover relays and collectors via the DNS SRV
algorithm [4]. If so configured, the service used is "syslog" and algorithm [5]. If so configured, the service used is "syslog" and
the protocol used is "tcp". This allows for central administration the protocol used is "tcp". This allows for central administration
of addressing, fallback for failed relays and collectors, and static of addressing, fallback for failed relays and collectors, and static
load balancing. Security policies and hardware configurations may be load balancing. Security policies and hardware configurations may be
such that device configuration is more secure than the DNS server. such that device configuration is more secure than the DNS server.
Hardware devices may be of such limited resources that DNS SRV access Hardware devices may be of such limited resources that DNS SRV access
is inappropriate. Firewalls and other restrictive routing mechanisms is inappropriate. Firewalls and other restrictive routing mechanisms
may need to be dealt with before a reliable syslog connection can be may need to be dealt with before a reliable syslog connection can be
established. In these cases, DNS might not be the most appropriate established. In these cases, DNS might not be the most appropriate
configuration mechanism. configuration mechanism.
3. The RAW Profile 3. The RAW Profile
3.1 RAW Profile Overview 3.1 RAW Profile Overview
The RAW profile is designed for minimal implementation effort, high The RAW profile is designed for minimal implementation effort, high
efficiency, and backwards compatibility. It is appropriate efficiency, and backwards compatibility. It is appropriate
especially in cases where legacy syslog processing will be applied. especially in cases where legacy syslog processing will be applied.
It should be noted that even though the RAW profile uses the same
format for message payloads as the UDP version of syslog uses,
delivery is reliable. The RAW syslog profile is a profile of BEEP
[3], and BEEP guarantees ordered reliable delivery of messages within
each individual channel.
When the profile is started, no piggyback data is supplied. All BEEP When the profile is started, no piggyback data is supplied. All BEEP
messages in the RAW profile are specified as having a MIME Content- messages in the RAW profile are specified as having a MIME Content-
Type [5] of application/octet-stream. Once the channel is open, the Type [6] of application/octet-stream. Once the channel is open, the
listener (not the initiator) sends a MSG message indicating it is listener (not the initiator) sends a MSG message indicating it is
ready to act as a syslog sink. (Refer to [3]'s Section 2.1 for a ready to act as a syslog sink. (Refer to [3]'s Section 2.1 for a
discussion of roles that a BEEP peer may perform, including discussion of roles that a BEEP peer may perform, including
definitions of the terms "listener", "initiator", "client", and definitions of the terms "listener", "initiator", "client", and
"server".) "server".)
The initiator uses ANS replies to supply one or more syslog entries The initiator uses ANS replies to supply one or more syslog entries
in the current UDP format, as specified in [1]'s Section 3. When the in the current UDP format, as specified in [1]'s Section 3. When the
initiator has no more entries to send, it finishes with a NUL reply initiator has no more entries to send, it finishes with a NUL reply
and closes the channel. and closes the channel.
skipping to change at page 10, line 46 skipping to change at page 11, line 46
creation is successful, then before sending the corresponding reply, creation is successful, then before sending the corresponding reply,
the BEEP peer processes the "iam" element and includes the resulting the BEEP peer processes the "iam" element and includes the resulting
response in the reply. This response will be an "ok" element or an response in the reply. This response will be an "ok" element or an
"error" element. The choice of which element is returned is "error" element. The choice of which element is returned is
dependant on local provisioning of the recipient. Including an "iam" dependant on local provisioning of the recipient. Including an "iam"
in the initial "start" element has exactly the same semantics as in the initial "start" element has exactly the same semantics as
passing it as the first MSG message on the channel. passing it as the first MSG message on the channel.
4.3 COOKED Profile Message Syntax 4.3 COOKED Profile Message Syntax
All BEEP messages in this profile have a MIME Content-Type [5] of All BEEP messages in this profile have a MIME Content-Type [6] of
application/beep+xml. The syntax of the individual elements is application/beep+xml. The syntax of the individual elements is
specified in Section 7. specified in Section 7.
4.4 COOKED Profile Message Semantics 4.4 COOKED Profile Message Semantics
Initiators issue two elements: "iam" and "entry", each using a "MSG" Initiators issue two elements: "iam" and "entry", each using a "MSG"
message. The listener issues "ok" in "RPY" messages and "error" in message. The listener issues "ok" in "RPY" messages and "error" in
"ERR" messages. (See [3]'s Section 2.3.1 for the definitions of the "ERR" messages. (See [3]'s Section 2.3.1 for the definitions of the
"error" and "ok" elements.) "error" and "ok" elements.)
skipping to change at page 16, line 27 skipping to change at page 17, line 27
S: Content-Type: application/beep+xml S: Content-Type: application/beep+xml
S: S:
S: <ok/> S: <ok/>
S: END S: END
In this case, the tag is detected and the timestamp represents the In this case, the tag is detected and the timestamp represents the
message generation time rather than the message reception time. message generation time rather than the message reception time.
Finally, the "entry" element may also contain an "xml:lang" Finally, the "entry" element may also contain an "xml:lang"
attribute, indicating the language in which the CDATA content of the attribute, indicating the language in which the CDATA content of the
tag is presented, as described in [6]. tag is presented, as described in [7].
The "entry" element is answered with either an empty "ok" element if The "entry" element is answered with either an empty "ok" element if
everything was successful, or a standard "error" element if there was everything was successful, or a standard "error" element if there was
a problem. An "entry" element can be rejected if no "iam" element a problem. An "entry" element can be rejected if no "iam" element
has been accepted by the listener. It can also be rejected if the has been accepted by the listener. It can also be rejected if the
user authenticated on the BEEP session (if any) does not have the user authenticated on the BEEP session (if any) does not have the
authority to generate (as a device) or relay that entry. An error is authority to generate (as a device) or relay that entry. An error is
also possible if the "pathID" attribute refers to an unknown (or also possible if the "pathID" attribute refers to an unknown (or
rejected) "path" element. rejected) "path" element.
skipping to change at page 24, line 27 skipping to change at page 25, line 27
channel. channel.
5.1 Message Authenticity 5.1 Message Authenticity
Section 6.2 of [1] discusses the dangers of unauthenticated syslog Section 6.2 of [1] discusses the dangers of unauthenticated syslog
entries. To prevent inauthentic syslog event messages from being entries. To prevent inauthentic syslog event messages from being
accepted, configure syslog peers to require the use of a strong accepted, configure syslog peers to require the use of a strong
authentication technology for the BEEP session. authentication technology for the BEEP session.
If provisioned for message authentication, implementations SHOULD use If provisioned for message authentication, implementations SHOULD use
SASL mechanism DIGEST-MD5 [7] to provision this service. SASL mechanism DIGEST-MD5 [8] to provision this service.
5.2 Message Replay 5.2 Message Replay
Section 6.3.4 of [1] discusses the dangers of syslog message replay. Section 6.3.4 of [1] discusses the dangers of syslog message replay.
To prevent syslog event messages from being replayed, configure To prevent syslog event messages from being replayed, configure
syslog peers to require the use of a strong authentication technology syslog peers to require the use of a strong authentication technology
for the BEEP session. for the BEEP session.
If provisioned to detect message replay, implementations SHOULD use If provisioned to detect message replay, implementations SHOULD use
SASL mechanism DIGEST-MD5 [7] to provision this service. SASL mechanism DIGEST-MD5 [8] to provision this service.
5.3 Message Integrity 5.3 Message Integrity
Section 6.5 of [1] discusses the dangers of syslog event messages Section 6.5 of [1] discusses the dangers of syslog event messages
being maliciously altered by an attacker. To prevent messages from being maliciously altered by an attacker. To prevent messages from
being altered, configure syslog peers to require the use of a strong being altered, configure syslog peers to require the use of a strong
authentication technology for the BEEP session. authentication technology for the BEEP session.
If provisioned to protect message integrity, implementations SHOULD If provisioned to protect message integrity, implementations SHOULD
use SASL mechanism DIGEST-MD5 [7] to provision this service. use SASL mechanism DIGEST-MD5 [8] to provision this service.
5.4 Message Observation 5.4 Message Observation
Section 6.6 of [1] discusses the dangers (and benefits) of syslog Section 6.6 of [1] discusses the dangers (and benefits) of syslog
messages being visible at intermediate points along the transmission messages being visible at intermediate points along the transmission
path between device and collector. To prevent messages from being path between device and collector. To prevent messages from being
viewed by an attacker, configure syslog peers to require the use of a viewed by an attacker, configure syslog peers to require the use of a
transport security profile for the BEEP session. (However, other transport security profile for the BEEP session. (However, other
traffic characteristics, e.g., volume and timing of transmissions, traffic characteristics, e.g., volume and timing of transmissions,
remain observable.) remain observable.)
skipping to change at page 28, line 12 skipping to change at page 29, line 12
""> "">
%BEEP; %BEEP;
<!-- <!--
Profile summaries Profile summaries
BEEP profile SYSLOG-RAW BEEP profile SYSLOG-RAW
role MSG ANS ERR role MSG ANS ERR
==== === === === ==== === === ===
L text text text L text text text
BEEP profile SYSLOG-COOKED BEEP profile SYSLOG-COOKED
role MSG RPY ERR role MSG RPY ERR
==== === === === ==== === === ===
I or L iam ok error I or L iam ok error
I or L entry ok error I or L entry ok error
I or L path ok error I or L path ok error
--> -->
skipping to change at page 34, line 16 skipping to change at page 35, line 16
[1] Lonvick, C., "The BSD Syslog Protocol", draft-ietf-syslog- [1] Lonvick, C., "The BSD Syslog Protocol", draft-ietf-syslog-
syslog-12 (work in progress), May 2001. syslog-12 (work in progress), May 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC [3] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001. 3080, March 2001.
[4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [4] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
2001.
[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996. 1996.
[6] Alvestrand, H., "Tags for the Identification of Languages", RFC [7] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995. 1766, March 1995.
[7] Leach, P. and C. Newman, "Using Digest Authentication as a SASL [8] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
Mechanism", RFC 2831, May 2000. Mechanism", RFC 2831, May 2000.
Authors' Addresses Authors' Addresses
Darren New Darren New
Invisible Worlds, Inc. Invisible Worlds, Inc.
131 Stony Circle 131 Stony Circle
Suite 500 Suite 500
Santa Rosa, CA 95401 Santa Rosa, CA 95401
US US
 End of changes. 20 change blocks. 
49 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/