Reliable Delivery for syslog
RFC 3195
| Document | Type | RFC - Proposed Standard (November 2001) | |
|---|---|---|---|
| Authors | Dr. Marshall T. Rose , Darren New | ||
| Last updated | 2013-03-02 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 3195
#x27;
C: linkprops='DLI'
C: pathID='24'>
C: </path></path></path></path>
C: END
S: RPY 2 2 . 1338 45
S: Content-type: application/beep+xml
S:
S: <ok/>
S: END
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 at
the firewall. The "path" attribute is rewritten, and it is forwarded
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+xml
C:
C: <entry 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: </entry>
C: END
S: RPY 2 3 . 1383 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
It is forwarded out the 134.130.74.56 interface:
C: MSG 7 9 . 9375 276
C: Content-Type: application/beep+xml
C:
C: <entry 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: </entry>
C: END
S: RPY 7 9 . 338 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
A discussion of the wisdom of configuring Lowry's machine to forward
such messages via Kurtzman's machine is beyond the scope of this
document.
New & Rose Standards Track [Page 24]
RFC 3195 Reliable Delivery for syslog November 2001
5. Additional Provisioning
In more advanced configurations, syslog devices, relays, and
collectors can be configured to support various delivery priorities.
Multiple channels running the same profile can be opened between two
peers, with higher priority syslog messages routed to a channel that
is given more bandwidth. Such provisioning is a local matter.
syslog [1] discusses a number of reasons why privacy and
authentication of syslog entry messages may be important in a
networked computing environment. The nature of BEEP allows for
convenient layering of authentication and privacy over any BEEP
channel.
5.1 Message Authenticity
Section 6.2 of [1] discusses the dangers of unauthenticated syslog
entries. To prevent inauthentic syslog event messages from being
accepted, configure syslog peers to require the use of a strong
authentication technology for the BEEP session.
If provisioned for message authentication, implementations SHOULD use
SASL mechanism DIGEST-MD5 [8] to provision this service.
5.2 Message Replay
Section 6.3.4 of [1] discusses the dangers of syslog message replay.
To prevent syslog event messages from being replayed, configure
syslog peers to require the use of a strong authentication technology
for the BEEP session.
If provisioned to detect message replay, implementations SHOULD use
SASL mechanism DIGEST-MD5 [8] to provision this service.
5.3 Message Integrity
Section 6.5 of [1] discusses the dangers of syslog event messages
being maliciously altered by an attacker. To prevent messages from
being altered, configure syslog peers to require the use of a strong
authentication technology for the BEEP session.
If provisioned to protect message integrity, implementations SHOULD
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 Observation
Section 6.6 of [1] discusses the dangers (and benefits) of syslog
messages being visible at intermediate points along the transmission
path between device and collector. To prevent messages from being
viewed by an attacker, configure syslog peers to require the use of a
transport security profile for the BEEP session. (However, other
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 this
service. The cipher algorithm used SHOULD be
TLS_RSA_WITH_3DES_EDE_CBC_SHA.
5.5 Summary of Recommended Practices
For the indicated protections, implementations SHOULD be configured
to use the indicated mechanisms:
Desired Protection SHOULD tune using
------------------ -----------------
Authentication http://iana.org/beep/SASL/DIGEST-MD5
+ Replay http://iana.org/beep/SASL/DIGEST-MD5
+ Integrity http://iana.org/beep/SASL/DIGEST-MD5
+ Observation http://iana.org/beep/TLS
BEEP peer identities used for authentication SHOULD correspond to the
FQDN of the initiating peer. That is, a relay running on
relay.example.com should use a "user ID" of "relay.example.com"
within the SASL authentication profiles, as well as in the FQDN of
the "iam" element.
New & Rose Standards Track [Page 26]
RFC 3195 Reliable Delivery for syslog November 2001
6. Initial Registrations
6.1 Registration: The RAW Profile
Profile Identification: http://xml.resource.org/profiles/syslog/RAW
Messages exchanged during Channel Creation: None
Messages starting one-to-one exchanges: Anything
Messages in positive replies: None
Messages in negative replies: None
Messages in one-to-many exchanges: Anything
Message Syntax: See Section 3.3
Message Semantics: See Section 3.4
Contact Information: See the "Authors' Addresses" section of this
memo
6.2 Registration: The COOKED Profile
Profile Identification:
http://xml.resource.org/profiles/syslog/COOKED
Messages exchanged during Channel Creation: iam
Messages starting one-to-one exchanges: iam, entry, path
Messages in positive replies: ok
Messages in negative replies: error
Messages in one-to-many exchanges: None
Message Syntax: See Section 4.3
Message Semantics: See Section 4.4
Contact Information: See the "Authors' Addresses" section of this
memo
New & Rose Standards Track [Page 27]
RFC 3195 Reliable Delivery for syslog November 2001
7. The syslog DTD
The following is the DTD defining the valid elements for the syslog
over BEEP mapping.
<!--
DTD for syslog over BEEP, as of 2000-10-10
Refer to this DTD as:
<!ENTITY % SYSLOG PUBLIC "-//Blocks//DTD SYSLOGRELIABLE//EN" "">
%SYSLOG;
-->
<!--
Contents
Overview
Includes
Profile Summaries
Entity Definitions
Operations
iam
entry
path
-->
<!--
Overview
Syslog packets delivered via BEEP
-->
<!-- Includes -->
<!ENTITY % BEEP PUBLIC "-//Blocks//DTD BEEP//EN"
"">
%BEEP;
New & Rose Standards Track [Page 28]
RFC 3195 Reliable Delivery for syslog November 2001
<!--
Profile summaries
BEEP profile SYSLOG-RAW
role MSG ANS ERR
==== === === ===
L text text text
BEEP profile SYSLOG-COOKED
role MSG RPY ERR
==== === === ===
I or L iam ok error
I or L entry ok error
I or L path ok error
-->
<!--
Entity Definitions
entity syntax/reference example
====== ================ =======
a fully qualified domain name
FQDN See [RFC-1034] www.example.com
a dotted-quad IP address
IP 1*3DIGIT "." 1*3DIGIT "."
1*3DIGIT "." 1*3DIGIT
10.0.0.27
a syslog facility
FACILITY See [1]
1*3DIGIT 80
a syslog severity
SEVERITY See [1]
DIGIT 4
a timestamp See [1] Jan 03 18:43:12
TIMESTAMP
an identifying integer
IDINT 1*DIGIT 1027
-->
New & Rose Standards Track [Page 29]
RFC 3195 Reliable Delivery for syslog November 2001
<!ENTITY % FQDN "CDATA">
<!ENTITY % IP "CDATA">
<!ENTITY % FACILITY "CDATA">
<!ENTITY % SEVERITY "CDATA">
<!ENTITY % TIMESTAMP "CDATA">
<!ENTITY % IDINT "CDATA">
<!--
The iam element declares the role and identity of the peer
issuing it. The contents of the element may include human-readable
informative text, such as the physical location of the computer
issuing the "iam".
-->
<!ELEMENT iam (#PCDATA)>
<!ATTLIST iam
fqdn %FQDN; #REQUIRED
ip %IP; #REQUIRED
type (device|relay|collector) #REQUIRED>
<!--
The entry element conveys a single syslog message.
-->
<!ELEMENT entry (#PCDATA)>
<!ATTLIST entry
xml:lang %LANG; "i-default"
facility %FACILITY; #REQUIRED
severity %SEVERITY; #REQUIRED
timestamp %TIMESTAMP; #IMPLIED
tag %ATEXT; #IMPLIED
deviceFQDN %FQDN; #IMPLIED
deviceIP %IP; #IMPLIED
pathID %IDINT; #IMPLIED>
New & Rose Standards Track [Page 30]
RFC 3195 Reliable Delivery for syslog November 2001
<!--
The path element conveys a list of relays through which
entries have passed.
-->
<!ELEMENT path (path?)>
<!ATTLIST path
pathID %IDINT; #REQUIRED
fromFQDN %FQDN; #IMPLIED
fromIP %IP; #REQUIRED
toFQDN %FQDN; #IMPLIED
toIP %IP; #REQUIRED
linkprops %ATEXT; #REQUIRED>
<!-- End of DTD -->
New & Rose Standards Track [Page 31]
RFC 3195 Reliable Delivery for syslog November 2001
8. Reply Codes
The following error codes are used in the protocol:
code meaning
==== =======
200 success
421 service not available
451 requested action aborted
(e.g., local error in processing)
454 temporary authentication failure
500 general syntax error
(e.g., poorly-formed XML)
501 syntax error in parameters
(e.g., non-valid XML)
504 parameter not implemented
530 authentication required
534 authentication mechanism insufficient
(e.g., too weak, sequence exhausted, etc.)
535 authentication failure
537 action not authorized for user
538 authentication mechanism requires encryption
550 requested action not taken
(e.g., no requested profiles are acceptable)
553 parameter invalid
554 transaction failed
(e.g., policy violation)
New & Rose Standards Track [Page 32]
RFC 3195 Reliable Delivery for syslog November 2001
9. IANA Considerations
9.1 Registration: BEEP Profiles
The IANA registers the profiles specified in Section 6, and selects
IANA-specific URIs "http://iana.org/beep/SYSLOG/RAW" and
"http://iana.org/beep/SYSLOG/COOKED".
9.2 Registration: The System (Well-Known) TCP port number for syslog-
conn
A single well-known port (601) is allocated to syslog-conn. In-band
negotiation determines whether COOKED or RAW syslog-conn is in use.
Protocol Number: TCP
Message Formats, Types, Opcodes, and Sequences: See Section 3.3 and
Section 4.4.
Functions: See Section 3.4 and Section 4.4.
Use of Broadcast/Multicast: none
Proposed Name: Reliable syslog service
Short name: syslog-conn
Contact Information: See the "Authors' Addresses" section of this
memo
New & Rose Standards Track [Page 33]
RFC 3195 Reliable Delivery for syslog November 2001
10. Security Considerations
Consult Section 6 of [1] for a discussion of security issues for the
syslog service. In addition, since the RAW and COOKED profiles are
defined using the BEEP framework, consult [3]'s Section 8 for a
discussion of BEEP-specific security issues.
BEEP is used to provide communication security but not object
integrity. In other words, the messages "on the wire" can be
protected, but a compromised device may undetectably generate
incorrect messages, and relays and collectors can modify, insert, or
delete messages undetectably. Other techniques must be used to
assure that such compromises are detectable.
11. Acknowledgements
The authors gratefully acknowledge the contributions of Christopher
Calabrese, Keith McCloghrie, Balazs Scheidler, and David Waitzman.
12. References
[1] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[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,
February 2000.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[7] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
[8] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
Mechanism", RFC 2831, May 2000.
New & Rose Standards Track [Page 34]
RFC 3195 Reliable Delivery for syslog November 2001
Authors' Addresses
Darren New
5390 Caminito Exquisito
San Diego, CA 92130
US
Phone: +1 858 350 9733
EMail: dnew@san.rr.com
Marshall T. Rose
Dover Beach Consulting, Inc.
POB 255268
Sacramento, CA 95865-5268
US
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
New & Rose Standards Track [Page 35]
RFC 3195 Reliable Delivery for syslog November 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
New & Rose Standards Track [Page 36]