.pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .ds LF Gerhards .ds RF FORMFEED[Page %] .ds CF .ds LH DRAFT .ds RH January 2003 .ds CH .hy 0 .ad l Loganalysis Mailing List R. Gerhards Request for Comments: DRAFT January 2003 .sp 2 .ce The Simple Event Log Protocol (SELP) .sp 2 .fi .ne 4 Status of this Memo .sp .in 3 This draft is being distributed to the members of the Loganalysis mailing list to detail an evolving transport protocol for event logging. .sp .in 0 .ne 4 Abstract .sp .in 3 .ne 4 This documents describes the evolving simple event log protocol which has been discussed on the loganalysis mailing list for quite a while. .sp Please note that the discussion focussed on a "syslog over tcp" protocol. I have renamed the protocol to "simple event log protocol" - or SELP for short - to avoid any confusion with the syslog standardization protocols going on at the IETF. SELP will likely never become an RFC. I am documenting it here because it looks like at least some Implementors would like to have such a simple, TCP-based, syslog-like protocol and will not move to [RFC3195] for the time being. .sp .in 0 .ne 4 1. Introduction .sp .in 3 The syslog protocol [1] presents a spectrum of service options for provisioning an event-based logging service over a network. The reliablke syslog protocol described in [2] provides reliable - and optional encrypted - delivery of network events via syslog protocol. It uses BEEP [3] to achieve this goal. .sp 1 While BEEP is acknowledged as a well-engineered protocol, there is a group of implementors who belief a simpler, tcp based protocol is needed for syslog-like event notification. This memo describes some slight additions to [1] that will enable syslog-like messages to travel over TCP connections. .sp 1 It was the effort of the group of implementors to keep the protocol as consistent with [1] as possible. To avoid confusion, the new syslog-like protocol over tcp has been named "simple event log protocol" (SELP). This shall make clear that it is not the actual syslog protocol. .sp 1 It is beyond the scope of this memo to argue for, or against, the use of SELP versus [RFC3195] for reliable delivery for syslog-like messages. .sp 1 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. .sp 1 I DO NOT INTEND TO DUPLICATE [RFC3164] HERE. As such, this memo lists only the differences to [RFC3164]. I am using the original chapter numbers to list them. .sp .in 0 .ne 4 2. Transport Layer Protocol .sp .in 3 SELP uses the transmission control protocol (TCP) as its underlying transport layer mechanism. There has no well-known port been assigned to SELP. It is recommended that a server listens to port 1514. The actual port should be a configurable entity in both the SELP client and server. .sp There may be multiple SELP messages within a single TCP stream. The messages are separated by proper TRAILERs as described in 4.1.4. SELP exclusively relies on TCP for handshaking. No handshaking takes place at the SELP layer and as such a sender will never receive any packet from the receiver. .sp .in 0 .ne 4 4.1 SELP Message Parts .sp .in 3 The full format of a SELP message seen on the wire has four discernable parts. The first part is called the PRI, the second part is the HEADER, and the third part is the MSG and the fourth part is the TRAILER. The total length of the message MUST be 65530 bytes or less. There is no minimum length of the SELP message although sending a SELP messagewith no contents is worthless and SHOULD NOT be transmitted. .sp .in 0 .ne 4 4.1.2 HEADER Part of a SELP Packet .sp .in 3 The HEADER part contains a timestamp and an indication of the hostname or IP address of the device. The HEADER part of the selp message MUST contain visible (printing) characters. The code set used MUST also be seven-bit ASCII in an eight-bit field like that used in the PRI part. In this code set, the only allowable characters are the ABNF VCHAR values (%d33-126) and spaces (SP value %d32). .sp The HEADER contains two fields called the TIMESTAMP and the HOSTNAME. The TIMESTAMP will immediately follow the trailing ">" from the PRI part and single space characters MUST follow each of the TIMESTAMP and HOSTNAME fields. HOSTNAME will contain the hostname, as it knows itself. If it does not have a hostname, then it will contain its own IP address. If a device has multiple IP addresses, it has usually been seen to use the IP address from which the message is transmitted. An alternative to this behavior has also been seen. In that case, a device may be configured to send all messages using a single source IP address regardless of the interface from which the message is sent. This will provide a single consistent HOSTNAME for all messages sent from a device. .sp The TIMESTAMP field is a RFC3339-TIMESTAMP. A sender MUST format the timestamp as a RFC3339-TIMESTAMP. A receiver MAY accept additional formats, for example an RFC3164-TIMESTAMP. When accepting additional timestamp formats, the receiver MUST ensure the most correct interpretation. It can use external configuration files to obtain a correct interpretation (e.g. a config file that stores sender's time zones). .sp 1 The RFC3339-TIMESTAMP is as specified in [RFC3339]: .sp 1 The following syntax MUST be used when using a RFC3339-TIMESTAMP. This is specified using the syntax description notation defined in [ABNF]. .sp .nf date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second ; rules time-secfrac = "." 1*DIGIT time-numoffset = ("+" / "-") time-hour ":" time-minute time-offset = "Z" / time-numoffset partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset date-time = full-date "T" full-time .sp 1 .fi Other than in RFC3339 .sp 1 - .in 5 the 'T' and 'Z' characters in this syntax MUST be upper case. .sp 1 .in 3 - .in 5 usage of the 'T' character is mandatory. It MUST NOT be replaced by any other character (like a space character). .sp 1 .in 3 - .in 5 the sender SHOULD include time-secfrac (fractional seconds) if its clock accuracy permits so .in 3 .sp 1 A sample of this format is: .sp 1 .in 9 1985-04-12T23:20:50.52Z .in 3 .sp 1 This represents 20 minutes and 50.52 seconds after the 23rd hour of April 12th, 1985 in UTC. .sp 1 For complete details and samples see RFC3339. .sp 2 A single space character MUST follow the TIMESTAMP field. .sp 1 The HOSTNAME field will contain only the hostname, the IPv4 address, or the IPv6 address of the originator of the message. The preferred value is the hostname. If the hostname is used, the HOSTNAME field MUST contain the hostname of the device as specified in STD 13 [4]. It should be noted that this MUST NOT contain any embedded spaces. The Domain Name MAY be included in the HOSTNAME field. If the IPv4 address is used, it MUST be shown as the dotted decimal notation as used in STD 13 [5]. If an IPv6 address is used, any valid representation used in RFC 2373 [6] MAY be used. A single space character MUST also follow the HOSTNAME field. .sp .in 0 .ne 4 4.1.3 MSG Part of a SELP Packet .sp .in 3 This needs probably some work regarding the character set... .sp .in 0 .ne 4 4.1.4 TRAILER Part of a SELP Packet .sp .in 3 The TRAILER MUST be CRLF. Each SELP message MUST be terminated by a valid trailer. Receivers MAY accept a single LF as a valid trailer. Recivers MAY accept a recived message without a trailer as valid if the TCP stream is closed without receiving a TRAILER. .sp .in 0 .ne 4 Author's Note: .sp .in 3 This is a very rough first draft intend to get discussion started. This draft is incomplete and most probably inconsistent. It should not serve as a reference for implementation. .sp .in 0 Security Considerations .sp .in 3 Security considerations ane not discussed in this memo. .sp .in 0 .ne 5 Acknowledgements .sp .in 3 The following people provided content feedback during the writing of this document: .sp 1 .in 9 Balazs Scheidler .br Darren Reed .br Andrew Ross .br Mikael Olsson (mikael.olsson@clavister.com) .br others to follow... Need to look up the mailing list ;) .sp 1 .in 3 Eric Allman is the original inventor and author of the syslog daemon and protocol. The author of this memo and the community at large would like to express their appreciation for this work and for the usefulness that it has provided over the years. .sp .in 0 .ne 5 References .sp .in 3 [1] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. .sp 1 .sp .in 0 .ne 5 Author's Address: .sp .in 3 .nf Rainer Gerhards Adiscon GmbH Mozartstrasse 21 97950 Grossrinderfeld Germany email: rgerhards@hq.adiscon.com phone: +49-9349-92880 .fi