This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 4, 2004.
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document describes the syslog protocol. The syslog protocol has been used throughout the years to convey event notifications. This documents describes a layered architecture for an easily extensible syslog protocol.
2. Definitions and Architecture
3. Transport Layer Protocol
4. Required syslog Format
4.1 HEADER Part
5. Structured Data
5.2 MSG with just Structured Data
6.1 SD-ID fragment
6.2 Cryptographically signing fragmented Messages
6.3 Fragmentation Examples
7. Security Considerations
7.1 Packet Parameters
7.2 Message Authenticity
7.3 Authentication Problems
7.4 Message Forgery
7.5 Sequenced Delivery
7.5.1 Single Source to a Destination
7.5.2 Multiple Sources to a Destination
7.5.3 Multiple Sources to Multiple Destinations
7.7 Reliable Delivery
7.8 Message Integrity
7.9 Message Observation
7.10 Message Prioritization and Differentiation
7.12 Forwarding Loop
7.13 Load Considerations
7.14 Denial of Service
7.15 Covert Channels
8. IANA Considerations
9. Authors and Working Group Chair
§ Author's Address
§ Intellectual Property and Copyright Statements
The informational document RFC 3164 describes a general format of syslog messages as they have been seen on the wire, and as the original author intended. Over time that format has been modified and extended in several ways, usually to meet new requirements. This document describes the semantics of the syslog protocol and provides a standard format for all syslog messages, that adheres to the original intent of the message format but also contains enhancements that are consistent with many of the innovations put forth through the years. Some components have been adjusted in this document to allow for backwards compatibility. However, the greatest benefit to automated log message parsers and people reading the log messages will come from adherence to the newly defined fields laid out in this document. The adherence of syslog messages to the format defined in this document may present problems to older syslog message receivers even though efforts were made to keep the message format similar to the format described in RFC 3164. People deploying devices that generate messages following the protocol described here should verify that they don't present problems to their existing syslog receivers.
The following definitions will be used in this document.
A machine that can generate a message will be called a "device".
A machine that can receive the message and forward it to another machine will be called a "relay".
A machine that receives the message and does not relay it to any other machines will be called a "collector". This has been commonly known as a "syslog server".
Any device or relay will be known as the "sender" when it sends a message.
Any relay or collector will be known as the "receiver" when it receives the message.
There are machines that both receive messages and forward them to another machine AND generate syslog messages themselfs. An example for this may be an application that operates as a syslog relay as one service while at the same time running other services. These services may be monitored by the same application, generating new syslog messages. Such a machine acts both as a relay AND a device. This case is specifically mentioned as the role a machine plays has special significance, for example on formatting. A machine as described here may thus have two separate configurations for each of the machine's operations modes.
The architecture of the devices may be summarized as follows:
Senders send messages to relays or collectors with no knowledge of whether it is a collector or relay.
Senders may be configured to send the same message to multiple receivers.
Relays may send all or some of the messages that they receive to a subsequent relay or collector. In the case where they do not forward all of their messages, they are acting as both a collector and a relay. In the following diagram, these devices will be designated as relays.
Relays may also generate their own messages and send them on to subsequent relays or collectors. In that case it is acting as a device. These devices will also be designated as a relay in the following diagram.
The following architectures shown in Diagram 1 are valid while the first one has been known to be the most prevalent. Other arrangements of these examples are also acceptable. As noted above, in the following diagram relays may pass along all or some of the messages that they receive along with passing along messages that they internally generate.
+------+ +---------+ |Device|---->----|Collector| +------+ +---------+ +------+ +-----+ +---------+ |Device|---->----|Relay|---->----|Collector| +------+ +-----+ +---------+ +------+ +-----+ +-----+ +---------+ |Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector| +------+ +-----+ +-----+ +---------+ +------+ +-----+ +---------+ |Device|---->----|Relay|---->----|Collector| | |-\ +-----+ +---------+ +------+ \ \ +-----+ +---------+ \-->--|Relay|---->----|Collector| +-----+ +---------+ +------+ +---------+ |Device|---->----|Collector| | |-\ +---------+ +------+ \ \ +-----+ +---------+ \-->--|Relay|---->----|Collector| +-----+ +---------+ +------+ +-----+ +---------+ |Device|---->----|Relay|---->-------|Collector| | |-\ +-----+ /--| | +------+ \ / +---------+ \ +-----+ / \-->--|Relay|-->--/ +-----+ +------+ +-----+ +---------+ |Device|---->-----|Relay|---->----------|Collector| | |-\ +-----+ /--| | +------+ \ / +---------+ \ +--------+ / \ |+------+| / \-->-||Relay ||->---/ |+------|| / ||Device||->-/ |+------+| +--------+
Diagram 1. Some Possible syslog Architectures
This document DOES NOT specify or enforce a specific transport layer protocol. Instead, it describes the format of a syslog message in a transport layer independent way.
As long as there are no transport mappings defined, the relevant parts of RFC 3164 should be used for UDP-based transport and the relevant parts of RFC 3195 should be used for TCP-based transport.
Transport mappings being defined MUST ensure that a message formatted according to this document can be transported unaltered over the mapping. If the mapping needs to perform temporary transformations, it must be guaranteed that the message received at the final destination is an exact copy of the message sent from the initial originator. This is vital because otherwise cryptographic verifiers (like signatures) would be broken.
The traditional format of a syslog message is defined in RFC 3164. There is a concept in that document that anything delivered to UDP port 514 will be accepted as a valid syslog message. However, this document REQUIRES a defined format for syslog messages.
The full format of a syslog message seen on the wire has three discernable parts. The first part is called the PRI, the second part is the HEADER, and the third part is the MSG. The total length of the packet MUST be 1024 bytes or less. There is no minimum length of the syslog message although sending a syslog packet with no contents is worthless and SHOULD NOT be transmitted.
The definitions of the fields are slightly changed in this document from RFC 3164. While the format described in RFC 3164 is correct for packet formation, the Working Group evaluating this work determined that it would be better if the TAG field were to become a part of the HEADER part rather than the CONTENT part. While IETF documentation does not allow the specification of an API, people developing code to adhere to this specification have found it helpful to think about the parts in this format.
The syslog message has the following ABNF definition:
; The general syslog message format SYSLOG-MSG = HEADER MSG TRAILER HEADER = "V" VERSION SP enterpriseID SP FACILITY SP SEVERITY SP TIMESTAMP SP HOSTNAME SP TAG SP TRAILER = LF VERSION = 1*3DIGIT enterpriseID = 1*10DIGIT ; range 0..2147483648 FACILITY = 1*10DIGIT ; range 0..2147483648 SEVERITY = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" HOSTNAME = 1*255PRINTUSASCII ; a FQDN TAG = static-id [full-dyn-id] [":"] ; 64 chars max static-id = 1*VISUAL full-dyn-id = "[" proc-id [thread-sep thread-id] "]" proc-id = 1*ALFANUM ; recommended: number thread-sep = VISUAL / %d58 ; recommended: ",", or ':', or '.' thread-id = 1*ALFANUM ; recommended: number VISUAL = (%d33-57/%d59-126) ; all but SP and ":" TIMESTAMP = full-date "T" full-time 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*6DIGIT time-offset = "Z" / time-numoffset time-numoffset = ("+" / "-") time-hour ":" time-minute partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset MSG = *((%d32-126) / (%d128-254)) ; VALID UTF-8 String of PRINTABLE characters LF = %d10 CR = %d13 SP = %d32 PRINTUSASCII = %d33-126 ALFANUM = %d48..57 / %d65..90 / %d97..122
The header MUST contain the token identifying the message as a syslog message complying with this specification, the version of the specification it complies to, the enterpriseID of the original sender, the facility, the severity, the timestamp, the hostname and the tag. Each of this fields MUST be present and MUST be of correct syntax. The code set used in the HEADER MUST be seven-bit ASCII in an eight- bit field as described in RFC 2234. These are the ASCII codes as defined in "USA Standard Code for Information Interchange" ANSI.X3-4.1968.
If the header is not syntactically correct, the receiver MUST NOT try to sub-parse some of the header fields in order to find a "good" interpretation. However, the receiver MAY assume it is a RFC3164 compliant message and MAY decide to process it as such. In this case, RFC3164 semantics MUST be used.
As a note to implementors, the "V" token at the very beginning of the message MAY be used as a rough indication whether or not the message complies to this document. However, it is not sufficient to assume it complies to this document just because the first character is a "V". As written above, the full header MUST be validated to assume this.
The HEADER contains three fields called the TIMESTAMP, the HOSTNAME, and the TAG fields. The TIMESTAMP immediately follows the trailing ">" from the PRI part and single space characters MUST follow each of the TIMESTAMP and HOSTNAME fields. HOSTNAME contains the hostname, as it knows itself. If it does not have a hostname, then it contains 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 provides a single consistent HOSTNAME for all messages sent from a device.
The Version field denotes the version of the syslog protcol specification the message is formatted to. It is used to uniquely identify the message format should later versions of the syslog protocol specification change it.
Note well: this document is the first to specify this format, including the VERSION in the header. Any previous syslog specification had a different header. As outlined under HEADER above, an invalid HEADER will automatically tell the receiver that the message is NOT compliant to this specification. As such, all version information is well defined (absence of version information means legacy syslog by the fact that the header is invalid).
The VERSION MUST be a numerical value. It MUST be one of the IANA assigned valid VERSION numbers. It starts at 1, which means the format specified in this document. The VERSION number MUST be incremented for each new syslog protocol specification that changes the format. If MUST NOT be incremented if a new syslog protocol specification does not change the syntax and semantics of the message format.
The sender of the syslog message MUST specify the VERSION of the format that the message was formatted to.
The receiver MUST check the VERSION. If the VERSION is within the set of format versions supported by the receiver, the receiver MUST parse the message according to the correct syslog protcol specification. A receiver MUST NOT parse a previous version with some parsing rules from a later specification.
If the receiver does not support the specified VERSION, it SHOULD log a diagnostic message. It SHOULD NOT parse beyond the VERSION field. This is because the header format may have changed in a newer version. It SHOULD NOT try to process the message, but I MAY try this if the administrator has configured the receiver to do so. In the later case, the results may be undefined. If the administrator has instructed the receiver to parse non-supported version, it SHOULD assume that these messages are legacy syslog messages and parse and process them in respect to RFC 3164. Again, the administrator MAY configure the receiver to use a different algorithm.
To be precise, a receiver receiving an unknown VERSION number, MUST, by default, ignore it. The administrator may configure it to not ignore it. Then, the receiver MUST, by default, parse it according to RFC 3164. The administrator may again override this setting. In this case, the receiver MAY use whatever method the administor has choosen. In this case, the receiver MUST ensure that no application reliability issues occur. If there is a chance for this, it MUST NOT allow the administrator to select an insecure mode.
The spirit of this behaviour is that the administrator may sometime need the power to allow overriding of version-specific parsing, but this should be done in the most secure and reliable way. Therefore, the receiver MUST use the appropriate defaults specified above. This document is so specific on the defaults and modes because it is common experience that parsing unknown formats often leads to security issues.
The enterprise ID unquily identifies the vender whom's software or device created the message. This is to support log-parsers sub-parsing vendor-specifc information from the message part.
The enterprise ID is an integer. It MUST be the enterprise ID assigned by IANA to the vendor whoms software or device created the syslog message.
The facility is primarily a way to filter messages at the receiver. It is a numerical value. There exist some traditional facility code semantics for the codes in the range from 0 to 23. These semantics are not closely followed by all vendors, softwares and devices. Therefore, no specifc semantics for facility codes are implied in this document.
FACILITY is just a sender-supplied numerical identifier that can be used for filtering by the receiver. The facility in itself does not have any semantics. Semantics MUST be applied by site configuration (through the site's administrator).
Any implementation of this document MUST support free configuration of the FACILITY on the sender.
The SEVERITY field is used to indicate the severity that the sender of the message assgined to it. It is a numerical value with just few values. The traditional syslog severity values are reused, because they have prooven to be useful and sufficient in reality.
SEVERITY is a numerical field, which MUST contain one of the digits from 0 to 7. Any other value is invalid and MUST NOT be used.
Each of the numerical codes has been assigned the follwing semantics:
Numerical Severity Code 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages
All implementations SHOULD try to assign the most appropriate severity to their message. Most importantly, test aid like messages or programm debugging information SHOULD be assiged severity 7. Severity 0 SHOULD be reserved for high-priviledge core processes of very high importance (like serious hardware failures or a very soon power failure). An implementation MAY use severities 0 and 7 for other purposes if this is configured by the administrator.
In general, a receiver should abide to the fact that severities are often very subjective. As such, a receiver MUST not assume that all senders have the same sense of severities.
The TIMESTAMP field is a formalized timestamp as taken from RFC 3339.
Note well: RFC 3339 makes allowances for multiple syntaxes for a timestamp to be used in various cases. This document mandates a restricted set of syntaxes. The primary characteristics of TIMESTAMP used in this document are as follows.
Please also note that RFC 3339 permits the value "60" in the second part to indicate a leap second. This must not be misinterpreted. As a suggestion for application developer, it is advised to replace the value "60" if seen in the header, with the value "59" if it otherwise can not be processed, e.g. stored to a database. It SHOULD NOT be converted to the first second of the next minute.
Two samples of this format are:
The first represents 20 minutes and 50.52 seconds after the 23rd hour of April 12th, 1985 in UTC. The second represents the same time but expressed in the Eastern US timezone (daylight savings time being observed).
A single space character MUST follow the TIMESTAMP field.
The HOSTNAME field contains the original creator of the syslog message.
The HOSTNAME field SHOULD contain the host name and the domain name of the originator in the format specified in STD 13. This format will be referred to in this document as HOSTNAME-STD13.
If the HOSTNAME-STD13 is not known to the orginator, it MUST use either its IPv4 address or its IPv6 address.
If the IPv4 address is used, it MUST be shown as the dotted decimal notation as used in STD 13, and will be referred to as HOSTNAME-IPV4. If an IPv6 address is used, any valid textual representation used in RFC 2373, section 2 MAY be used and will be referred to as HOSTNAME-IPV6.
If a device has multiple IP addresses, it SHOULD use a consistent value in the HOSTNAME field. This consistent value MUST be one of its actual IP addresses. As an alternative, it MAY use the IP address of the interface that is used to send the message.
A single space character MUST follow the HOSTNAME field.
The TAG is a string of visible (printing) characters excluding SP, that MUST NOT exceed 64 characters in length. The first occurrence of a SP (space) will terminate the TAG field, but is not part of it.
Note well: the colon (":") is no special character inside the TAG. It may occur anywhere within it and may occur muliple times. The TAG is terminated by the first SP, NOT the colon character.
The TAG is used to denote the sender of the message. It MUST be in the syntax shown in the ABNF above.
A typical example of a TAG is: (without the quotes)
Another example with a dynamic id may be:
Another example (from VMS) is: (without the quotes)
Please note that in this example, "DKA0:[MYDIR.SUBDIR1.SUBDIR2]MYFILE.TXT;1" is the static-id while "[123,456]" is still the full-dyn-id. This shows that a receiver must be prepared for special characters like '[' and ':' to be present inside the static part.
As a note to implementors: the beginning of the full-dyn-id is not the first but the LAST occurrence of '[' inside the tag and this ONLY if the tag ends in either "]" or "]". If these conditions are not met, the '[' is part of the static-id.
Systems that use both process-ID's and thead-IDs, SHOULD fill both the proc-id and the thread-part. For other systems it is RECOMMENDED to use the proc-id only.
No specific format inside the tag is required. However, a sender SHOULD use a consistent tag value.
The MSG part contains the details of the message. This has traditionally been a freeform message that gives some detailed information of the event. It MAY also contain structured data as described in Structured Data below.
The MSG part of the syslog packet MUST contain visible (printing) characters. The code set used must be UNICODE. It MUST be encoded in UTF-8 as specified in RFC 2279. Only non-control characters and spaces MUST be used inside the MSG part. Specifically, ABNF values %d00..31 are NOT permitted inside the MSG part.
The trailer is an optional part that is being introduced to preserve compatibility to legacy syslog implementations. It is observed behavior that some emitors send a trailer after the MSG part. Their syslog-message is otherwise well-formed. In order to provide backwards compatibility, receivers MUST accept messages with trailers as valid syslog messages. A relay receiving a trailer MUST NOT reformat the message to remove the trailer. An emitor SHOULD NOT include the trailer inside the syslog message. It MAY be configured to include it, if the receiver it is sending to requires a trailer (which is unlikely).
The following examples are given.
V1 0 888 4 2003-10-11T22:14:15.003Z mymachine.example.com su: 'su root' failed for lonvick on /dev/pts/8
In this example, the VERSION is 1 (formatted according this document), the enterprise ID is 0 (IETF), the FACILITY has the value of 888 (whatever this means is up to the sender and recipient). The message was created The timestamp is in UTC. on October, 11th 2003 at 10:14:15pm, 3 milliseconds into the next second. Please note that the sender had millisecond resolution. The sender may have actually had a better resolution, but by providing just three digits for the fractional settings, he does not tell us this. The message orignated from a host that calls itself "mymachine.example.com". The TAG is "su:". Note that the colon is part of the tag. The MSG is "'su root failed for lonvick...". Please note that the SP after the TAG is NOT part of the MSG - it is the seperator between TAG and MSG.
As a note to implementors: please note that the sender had millisecond time resolution in this example. A common coding bug is that leading zeros are not written for fractional seconds. Very often, the above timestamp is errornously being written as: "2003-10-11T22:13:14.3". This would indicate 300 milliseconds instead of the 3 milliseconds that are actually meant. Please make sure that an implementation handles this correctly.
V1 0 20 6 2003-08-24T05:14:15.000003-09:00 10.1.1.1 myproc:%% It's time to make the do-nuts. %% Ingredients: Mix=OK, Jelly=OK # Devices: Mixer=OK, Jelly_Injector=OK, Frier=OK # Transport: Conveyer1=OK, Conveyer2=OK # %%
In this example, the VERSION is again 1 and the enterprise ID 0. The FACILITY is within the legacy syslog range (20), as such we assume the user has specifically configure the sender to use this FACILITY. The severity is 6 ("Notice" semantics). The timestamp now has microsecond resolution, indicated by the additional digits in the fractional seconds. The sender indicates that its local time is -9 hours from UTC. Given the date stamp, we can assume the sender is in the US Pacific time zone during daylight savings time. The HOSTNAME is "10.1.1.1", so the sender did not know its host- and domainname and used the V4 IP address instead. The TAG is "myproc:%%" - we can speculate that the sender actually wanted the tag to be "myproc:", but because there was no SP following it, the TAG continues until the first SP. The message is "It's time to make the do-nuts......".
Example 3 - An Invalid Message
V1 0 20 6 2003-08-24T05:14:15.000000003-09:00 10.1.1.1 myproc:%% It's time to make the do-nuts. %% Ingredients: Mix=OK, Jelly=OK # Devices: Mixer=OK, Jelly_Injector=OK, Frier=OK # Transport: Conveyer1=OK, Conveyer2=OK # %%
This example just just like Example 2, but this time the sender is overdoing with the clock resolution. It is supplying nanosecond resolution. This will result in the TIME-SECFRAC part to be longer than the allowed 6 digits, which invalidates the header and thus the message. A receiver MUST NOT try to "fix" this error. It MUST detect this as an invalid message and SHOULD log a diagnostic entry. If the receiver is capable of processing legacy syslog messages, it MUST assume that this message is legacy syslog and act accordingly.
While syslog traditionally contains freeform data, there may be structured data present in the MSG part of a syslog message. Structured data are special, well defined data elements designed to be easily computer-parsable. They may transport meta data for the syslog protocol as well as application-defined information (like traffic counters, IP addresses and other well-defined elements).
There is a certain set of structured data that is under IANA control. These structured data elements are described in this and other RFCs. A second set of structured data elements is not under IANA-control. This set MUST be used for experimental or vendor-specific elements.
A syslog message may contain none, one or multiple structured data elements.
Structured data can be present anywhere within the MSG part and follows this ABNF:
; Format of structured data element STRUCTURED-DATA = "[@#" SD-ID 0*(1*SP SD-PARAM) *SP "]" SD-ID = SD-ID-IANA / SD-ID-EXPERI SD-ID-IANA = 1*1ID-CHAR [1*1ID-CHARNOSLASH [1*62ID-CHAR]] SD-ID-EXPERI = %d120 "-" 1*62ID-CHAR ; "x-" (lower case 'x'!) ID-CHAR = %d32-33 / %d35-60 / %d62-92 / %d94-126 / %d128-254 ; all US-ASCII but '"' (%d34), '=' (%d61), ']' ; (%d93) ID-CHARNOSLASH = %d32-33 / %d35-44 / %d46-60 / %d62-92 / %d94-126 / %d128-254 ; same as ID-CHAR but without '-' (%d45) SD-PARAM = PARAM-ID "=%d34" PARAM-VALUE "%d34" PARAM-ID = 1*64ID-CHAR PARAM-VALUE = *(SAFE-CHAR / ESCAPED-CHAR) SAFE-CHAR = *((%d32-33) / (%d35-46) / (%d48-92) / (%d94-126) / (%d128-254)) ESCAPED-CHAR = ("\\" / %d47.34 / "]") ; 47.34 is \"
Each structured data element MUST begin with the token "[@#". This designates it as a special entity. This three-character sequence is highly likely not to be confused with traditional syslog message patterns.
The beginning token MUST immediatly be followed by the ID of the structured data element. No space is allowed between the beginning token and the SD-ID. The SD-ID uniquely identifies the type and purpose of the element.
IANA controls ALL SD-IDs without a hyphen '-' in the second character position. Experimental or vendor-specific SD-IDs MUST start with "x-". Values with a hypen on the second character position and the first character position not being a lower case "x" are undfined and SHOULD NOT be used. Receivers MAY accept them.
If a receiver receives a well-formed but unknown SD-ID, the receiver SHOULD ignore this element. It MUST NOT malfunction because of this unknown SD-ID.
The SD-ID is followed by none, one or many optional parameter/value pairs. Each of them MUST start with the parameter name, MUST be followed by an equal sign and quote sign. There MUST NOT be any space between the SD-ID, the equal and the quote sign. This is followed by the parameter value and then another quote sign.
The parameter value may contain any character, but the three special characters '"', '\' and ']' MUST be escaped. This is neccessary to avoid parsing errors. Please note that escaping ']' would actually not be necessary but is required in order to avoid parser implementation errors. Each of these three characters MUST be escaped as '\"', '\\' and '\]' respectively. If a receiver receives an invalid
A backslash ('\') followed by none of the three described characters is considered an invalid escape sequence. Upon reception of such an invalid message, the receiver MUST replace the two-character sequence with just the second character received. It is recommended that the receivers logs a diagnostic message in this case. The receiver MUST otherwise ignore the invalid escape sequence.
Parameter/Value pairs MUST be separated by at least one SP character.
The structured data element MUST be terminated by the character ']', the ending token. This MUST follow the last parameter/value pair. There SHOULD be no SP in front of the ending token, but there MAY be one or multiple SP in front of it.
If multiple structured data elements are written, it is RECOMMENDED that they are all sequentially written and no SP be written between those elements. However, they MAY occur at any position inside MSG.
The order of structured data elements inside the MSG is irrelevant, except for IANA-assigned SD-IDs which specifically require a certain order. The same SD-ID MAY exist more than once inside a MSG if this is permitted by the SD-ID type.
Any syslog MSG may contain structured as well as traditional free form data. The free form (or unstructured) part of the syslog MSG is obtained by omiting all the structured data elements from the MSG.
The resulting free from part of the MSG may consist purely of one or more SPs. This is considered as a MSG with just structured data elements.
As far as this specification goes, there is no implied special action to be taken on messages without a free form content in the MSG field. This case is just defined so that it may be used for implementation-specifc (and probably user-configurable) actions.
All examples show the MSG part of the syslog message only. All examples should be considered to be on one line. They are wrapped on multiple lines for readabily purposes, only.
[@#x-adiscon-iut iut="3" EventSource="Application" EventID="1011"]This is event 1011
This example is a MSG with an experimental SD-ID of type "x-adiscon-iut" which has two parameters. This is followed by the free form text "This is event 1011".
[@#x-adiscon-iut iut="3" EventSource="Application" EventID="1011"]This is event 1011 [@#x-adiscon-priority class="high"]
This is the same example, but with a second structured data element. Please note that the structured data element does not immediately follow the first one. Also note that the free form message is different from the example 1. It now is "This is event 1011>SP<" - notice the extra space character at the end.
This is event[@#x-adiscon-priority class="high"] 1 [@#x-adiscon-iut iut="3" EventSource="Application "EventID="1011"]011<SP>
In this example, <SP> is actually a single space character. Although all elements are re-odered and the free form message is intermixed with structured data, it is still exactly the same message as in example 2. The message formatting shown in example three SHOULD be avoided by syslog senders. However, receivers MUST accept messages formatted in that way.
[ @#x-adiscon-iut iut="3" EventSource="Application" EventID="1011"]This is event 1011
Example four looks very much like example one. However, it is totally different because example four does NOT contain any structured data element at all. This is because there is a SP between the bracket and the rest of the beginning token "@#". As such, the three-character beginning token is not identifiable and not parsed as such. Receivers receiving this format MUST NOT assume structured data. This is especially important as legacy syslog data may very well contain a sequence as shown above which actually is no structured data.
[@#sigSig Ver="1" RSID="1234" ... Signature="......"]
Example 5 is not a full example. It shows how a hypothetical IANA assigned SD-ID may be used inside an otherwise empty message. Please note that the dots denote missing fields, which have been left out for brevity.
Fragmentation is an optional feature. It may be used if the amount of syslog data to be transported is larger than the maximum of 1024 characters allowed. Fragmentation is implemented using STRUCTURED-DATA elements.
A syslog message that is fragemented is split into a number of fragments that will be transmitted as separate messages via syslog. If fragmentation is used, special processing needs to take place. In order to avoid complexity, the receiver MUST reassemble the orginal message before parsing the message content. This original message MUST NOT contain the fragmentation structured data elements.
It is RECOMMENDED that fragmentation is only be used if the full message does not fit into a single syslog message. If it does, fragmentatin SHOULD NOT be used. However, a sender may still choose to use it in this case. Thus, a receiver MUST accept a fragmented message with just a single fragment.
Fragmentation is done via the IANA-reserved "fragment" SD-ID.
The "fragment" SD-ID is a structured data element with 3 parameters. It describes a single fragment of a fragmented syslog message. It MUST begin immediately after the HEADER of the syslog message. The fragment of the original message immediatly begins AFTER the closing token (']') of the fragment SD-ID. The MUST NOT be any SP or other character between the closing token and the begin of the fragment.
The receiver of a fragment MUST NOT try to parse structured data elements inside a single fragment. This MUST only be done on the fully re-assembled message. The reason for this is that a single fragment may be missing important tokens that will lead to misdetection of structured data elements.
The "fragement" SD-ID has three parameters: msgid, fragnum, fragcount. Each of them is described in detail in the following sections.
All fragments of a single syslog message MUST have the exact same syslog message header, most importantly the exact same timestamp. It is RECOMMENDED that a sender implementing fragementation uses TIMESTAMP and provides better-than-second time-resolution inside it.
The parameter "msgid" is an integer value in the range 0..2147483648. It MUST uniquely identify a message for a given TIMESTAMP. It SHOULD at least uniquely identify a message between two reboots of the syslog sender.
It is RECOMMENDED that an incrementing value is used, which MAY be reset to 0 at the time of the syslog sender's startup. If the value is incremented and the maximum value is reached, than it is RECOMMENDED to reset the msgid to 0.
Two otherwise identical msgid received in different fragments with different TIMESTAMP in the header MUST be considered to be two different msgid.
The parameter "fragnum" is an integer value in the range 1..2147483648. This value MUST start at one for the first message fragment and MUST be incremented by one for each subsequent fragments.
The "fragnum" counter MUST be processed on a per-message basis. That is, when the next full syslog message is to be fragemented, its first fragment again starts with "fragnum" set to 1.
The "fragnum" counter MUST never be greater than "fragcount". If it ever is greater, all message fragments MUST be considered invalid. It is RECOMMENDED that a diagnostic message is logged in that case.
If the "fragnum" is outside the defined range, all message fragments MUST be considered invalid. It is RECOMMENDED that a diagnostic message is logged in that case.
The parameter "fragcount" is an integer value in the range 1..2147483648. It specifies into how many fragments the message has been split into.
The "fragcount" parameter must remain the same for all fragments of a fragmented message. If "fragcount" is not the same in all message fragments, all fragments MUST be considered invalid. It is RECOMMENDED that a diagnostic message is logged in that case.
If the "fragcount" is outside the defined range, all message fragments MUST be considered invalid. It is RECOMMENDED that a diagnostic message is logged in that case.
While the author of this draft does not intend to specify how messages can be signed, he would like to offer a suggestion on the implications of fragmented messages.
Fragmented messages need to be transmitted in fragmented form and need to be reassmebled to be processed. During reassembly, parts of the fragment's message text are stripped from the message. This poses a problem to cryptographically signing the messages.
An obvious solution to keeping the message signature intact is that only the original, full-size message is signed. Then, the individual fragments are transmitted without a specifc signature attached to them. Only the re-assembled message will then be used for verifying the signature.
This mode will probably be very efficient, as the ultimate goal is to guarantee the integrity of the original message. Any modification to the fragments will either result in a protocol error or a modification of the signed original message. Both of this will be detected by verifying the signature in the original, reassembled, message.
One problem, however, may be caused to signature verifiers who work on raw logs. Raw logs will most probably include only the individual fragments. If this is an issue, it may be worth thinking about a signature protocol which both signs the original message as well as each individual fragments. So the message would effectively be signed twice.
The author of this draft thinks it is NOT advisable to only sign the individual message fragments. While this would guarantee the authenticy of the individual fragments, no authentic signature could be provided for the reassembled message. This may cause serious issues with higher-level signature verifiers.
Again, these are just thoughts about implementing signatures. Depending on the signature specification used, there may be different solutions. It is RECOMMENDED that authors of signature specifications specifically describe how their specification deals with fragmented messages.
To conserve some space, we use an abbreviated sample, where not all data is shown:
<34>2004-01-19T22:14:15.002 mymachine mwagent: [@#x-adiscon-iut iut="3" EventSource="Application" (some lenghty params) EventID="1011"][@#x-adiscon-priority class="high"]This is event 1011. (lengthy data) This is the end.
We assume that the lengthy data is longer than does fit into a single syslog message. As such, it needs to be fragmented. To keep it simple, we assume that "(some lengthy paramters)" and "(lenghty data)" are the lengthy parts and that their length forces us to create three fragments.
The initial fragment will just contain structured data, the second fragment some structured data and some free form data and the last part only free form data. This is how they look:
Example Fragment One
<34>2004-01-19T22:14:15.002 mymachine mwagent: [@#fragment msgid="12" fragcount="3" fragnum="1"] [@#x-adiscon-iut iut="3" EventSource="Application" (some lenghty params) EventID="1011"][@#x-adiscon-prior
Example Fragment Two
<34>2004-01-19T22:14:15.002 mymachine mwagent: [@#fragment msgid="12" fragnum="2" fragcount="3"] ity class="high"]This is event 1011. (lengthy data) This i
Example Fragment Three
<34>2004-01-19T22:14:15.002 mymachine mwagent: [@#fragment msgid="12" fragnum="3" fragcount="3"]s the end.
There are some things worth noting when looking at the examples:
This section is to be updated once the rest of the document has been confirmed. The current content is incomplete and potentially not in sync with the rest of the draft.
Many security considerations were described in the informational RFC 3164 and are repeated here for completeness. Additional considerations are also included in this section.
The message length must not exceed 1024 bytes. Various problems may result if a device sends out messages with a length greater than 1024 bytes. In this case, as with all others, it is best to be conservative with what you send but liberal in what you receive, and accept more than 1024 bytes.
Similarly, the fragmentation features introduced in this document may be misused to overrun a receiver or a log analyzer with a gigantic message. Any process reassembling fragmented messages MUST properly check the maximum re-assembled message size it supports. Oversize data SHOULD be dropped.
Similarly, senders must rigidly enforce the correctness of the message body. It is hoped that all devices adopt the newly defined HOSTNAME-STD13 and TIMESTAMP formats. However, until that happens, receivers may become upset at the receipt of messages with these fields. Knowledgeable humans should review the senders and receivers to ensure that no problems arise from this.
Finally, receivers must not malfunction if they receive syslog messages containing characters other than those specified in this document.
The syslog delivery mechanism does not strongly associate the message with the message sender. The receiver of that packet will not be able to ascertain that the message was indeed sent from the reported sender, or if the packet was sent from another device. It should be noted here that the message receiver does not need to verify that the HOSTNAME in the HEADER part match the name of the IP address contained in the Source Address field of the IP packet.
One possible consequence of this behavior is that a misconfigured machine may send syslog messages to a collector representing itself as another machine. The administrative staff may become confused that the status of the supposed sender of the messages may not be accurately reflected in the received messages. The administrators may not be able to readily discern that there are two or more machines representing themselves as the same machine.
It should also be noted that some cases of filling the HOSTNAME field in the HEADER part might only have local significance and that may only be ephemeral. If the device had obtained an IP address from a DHCP pool, then any association between an identifier and an actual source would not always hold true. The inclusion of a fully qualified domain name in the CONTENT may give the administrators the best chance of identifying the source of each message if it can always be associated with an IP address or if it can always be associated with a unique machine.
Malicious exploits of this behavior have also been noted. An attacker may transmit syslog messages (either from the machine from which the messages are purportedly sent or from any other machine) to a collector. In one case, an attacker may hide the true nature of an attack amidst many other messages. As an example, an attacker may start generating forged messages indicating a problem on some machine. This may get the attention of the system administrators who will spend their time investigating the alleged problem. During this time, the attacker may be able to compromise a different machine, or a different process on the same machine. Additionally, an attacker may generate false syslog messages to give untrue indications of status or of events. As an example, an attacker may stop a critical process on a machine, which may generate a notification of exit. The attacker may subsequently generate a forged notification that the process had been restarted. The system administrators may accept that misinformation and not verify that the process had indeed been restarted.
As a general rule, the forensics of a network anomaly rely upon reconstructing the sequence of events. In a perfect world, the messages would be received on the syslog collector in the order of their generation from the other devices and anyone looking at these records would have an accurate picture of the sequence of events. Unfortunately, the syslog process and protocol do not ensure ordered delivery. This section details some of the problems that may be encountered from this.
Strict adherence to the use of TIMESTAMP will help administrators to place received messages in their proper order.
The syslog records are usually presented (placed in a file, displayed on the console, etc.) in the order in which they are received. This is not always in accordance with the sequence in which they were generated. As they are transported across an IP network, some out of order receipt should be expected. This may lead to some confusion a messages may be received that would indicate that a process has stopped before it was started. This may be somewhat rectified if the originating process had timestamped or numbered each of the messages before transmission. In this, the sending device should utilize an authoritative time source. It should be remembered, however, that not all devices are capable of receiving time updates, and not all devices can timestamp their messages.
In syslog, there is no concept of unified event numbering. Single devices are free to include a sequence number within the CONTENT but that can hardly be coordinated between multiple devices. In such cases, multiple devices may report that each one is sending message number one. Again, this may be rectified somewhat if the sending devices utilize a timestamp from an authoritative source in their messages. As has been noted, however, even messages from a single device to a single collector may be received out of order. This situation is compounded when there are several devices configured to send their syslog messages to a single collector. Messages from one device may be delayed so the collector receives messages from another device first even though the messages from the first device were generated before the messages from the second. If there is no timestamp or coordinated sequence number, then the messages may be presented in the order in which they were received which may give an inaccurate view of the sequence of actual events.
The plethora of configuration options available to the network administrators may further skew the perception of the order of events. It is possible to configure a group of devices to send the status messages -or other informative messages- to one collector, while sending messages of relatively higher importance to another collector. Additionally, the messages may be sent to different files on the same collector. If the messages do not contain timestamps from the source, it may be difficult to order the messages if they are kept in different places. An administrator may not be able to determine if a record in one file occurred before or after a record in a different file. This may be somewhat alleviated by placing marking messages with a timestamp into all destination files. If these have coordinated timestamps, then there will be some indication of the time of receipt of the individual messages.
Without any sequence indication or timestamp, messages may be recorded and replayed at a later time. An attacker may record a set of messages that indicate normal activity of a machine. At a later time, that attacker may remove that machine from the network and replay the syslog messages to the collector. Even with a TIMESTAMP field in the HEADER part, an attacker may record the packets and could simply modify them to reflect the current time before retransmitting them. The administrators may find nothing unusual in the received messages and their receipt would falsely indicate normal activity of the machine.
As there is no mechanism within either the syslog process or the protocol to ensure delivery, and since the underlying transport is UDP, some messages may be lost. They may either be dropped through network congestion, or they may be maliciously intercepted and discarded. The consequences of the drop of one or more syslog messages cannot be determined. If the messages are simple status updates, then their non-receipt may either not be noticed, or it may cause an annoyance for the system operators. On the other hand, if the messages are more critical, then the administrators may not become aware of a developing and potentially serious problem. Messages may also be intercepted and discarded by an attacker as a way to hide unauthorized activities.
RFC 3195 may be used for the reliable delivery of all syslog messages.
Besides being discarded, syslog messages may be damaged in transit, or an attacker may maliciously modify them. In the case of a packet containing a syslog message being damaged, there are various mechanisms built into the link layer as well as into the IP  and UDP protocols which may detect the damage. An intermediary router may discard a damaged IP packet . Damage to a UDP packet may be detected by the receiving UDP module, which may silently discard it. In any case, the original contents of the message will not be delivered to the collector. Additionally, if an attacker is positioned between the sender and collector of syslog messages, they may be able to intercept and modify those messages while in-transit to hide unauthorized activities.
While there are no strict guidelines pertaining to the event message format, most syslog messages are generated in human readable form with the assumption that capable administrators should be able to read them and understand their meaning. Neither the syslog protocol nor the syslog application have mechanisms to provide confidentiality of the messages in transit. In most cases passing clear-text messages is a benefit to the operations staff if they are sniffing the packets off of the wire. The operations staff may be able to read the messages and associate them with other events seen from other packets crossing the wire to track down and correct problems. Unfortunately, an attacker may also be able to observe the human- readable contents of syslog messages. The attacker may then use the knowledge gained from those messages to compromise a machine or do other damage.
While the processes that create the messages may signify the importance of the events through the use of the message Priority value, there is no distinct association between this value and the importance of delivery of the packet. As an example of this, consider an application that generates two event messages. The first is a normal status message but the second could be an important message denoting a problem with the process. This second message would have an appropriately higher Severity value associated with the importance of that event. If the operators had configured that both of these messages be transported to a syslog collector then they would, in turn, be given to UDP for transmission. Under normal conditions, no distinction would be made between them and they would be transmitted in their order.
Again, under normal circumstances, the receiver would accept syslog messages as they are received. If many devices are transmitting normal status messages, but one is transmitting an important event message, there is no inherent mechanism within the syslog protocol to prioritize the important message over the other messages.
On a case-by-case basis, device operators may find some way to associate the different levels with the quality of service identifiers. As an example, the operators may elect to define some linkage between syslog messages that have a specific Priority value with a specific value to be used in the IPv4 Precedence field , the IPv6 Traffic Class octet , or the Differentiated Services field . In the above example, the operators may have the ability to associate the status message with normal delivery while associating the message indicating a problem with a high reliability, low latency queue as it goes through the network. This would have the affect of prioritizing the essential messages before the normal status messages. Even with this hop-by-hop prioritization, this queuing mechanism could still lead to head of line blocking on the transmitting device as well as buffer starvation on the receiving device if there are many near-simultaneous messages being sent or received. This behavior is not unique to syslog but is endemic to all operations that transmit messages serially.
There are security concerns for this behavior. Head of line blocking of the transmission of important event messages may relegate the conveyance of important messages behind less important messages. If the queue is cleared appropriately, this may only add seconds to the transmission of the important message. On the other hand, if the queue is not cleared, then important messages may not be transmitted. Also at the receiving side, if the syslog receiver is suffering from buffer starvation due to large numbers of messages being received near-simultaneously, important messages may be dropped indiscriminately along with other messages. While these are problems with the devices and their capacities, the protocol security concern is that there is no prioritization of the relatively more important messages over the less important messages.
Since there is no control information distributed about any messages or configurations, it is wholly the responsibility of the network administrator to ensure that the messages are actually going to the intended recipient. Cases have been noted where devices were inadvertently configured to send syslog messages to the wrong receiver. In many cases, the inadvertent receiver may not be configured to receive syslog messages and it will probably discard them. In certain other cases, the receipt of syslog messages has been known to cause problems for the unintended recipient . If messages are not going to the intended recipient, then they cannot be reviewed or processed.
As it is shown in Figure 1, machines may be configured to relay syslog messages to subsequent relays before reaching a collector. In one particular case, an administrator found that he had mistakenly configured two relays to forward messages with certain Priority values to each other. When either of these machines either received or generated that type of message, it would forward it to the other relay. That relay would, in turn, forward it back. This cycle did cause degradation to the intervening network as well as to the processing availability on the two devices. Network administrators must take care to not cause such a death spiral.
Network administrators must take the time to estimate the appropriate size of the syslog receivers. An attacker may perform a Denial of Service attack by filling the disk of the collector with false messages. Placing the records in a circular file may alleviate this but that has the consequence of not ensuring that an administrator will be able to review the records in the future. Along this line, a receiver or collector must have a network interface capable of receiving all messages sent to it.
Administrators and network planners must also critically review the network paths between the devices, the relays, and the collectors. Generated syslog messages should not overwhelm any of the network links.
As with any system, an attacker may just overwhelm a receiver by sending more messages to it than can be handled by the infrastructure or the device itself. Implementors should attempt to provide features that minimize this threat. Such as only receiving syslog messages from known IP addresses.
Nothing in this protocol attempts to eliminate covert channels. Indeed, the unformatted message syntax in the packets could be very amenable to sending embedded secret messages. In fact, just about every aspect of syslog messages lends itself to the conveyance of covert signals. For example, a collusionist could send odd and even PRI values to indicate Morse Code dashes and dots.
This document also upholds the Facilities and Severities listed in RFC 3164. Those values range from 0 to 191. This document also instructs the IANA to reserve all other possible values of the Severities and Facilities above the value of 191 and to distribute them via the consensus process as defined in RFC 2434.
IANA must also maintain a registry of cookie values.
The working group can be contacted via the mailing list:
The current Chair of the Working Group may be contacted at:
Chris Lonvick Cisco Systems Email: firstname.lastname@example.org
The author of this draft is:
Rainer Gerhards Email: email@example.com Phone: +49-9349-92880 Fax: +49-9349-928820 Adiscon GmbH Mozartstrasse 21 97950 Grossrinderfeld Germany
The authors wish to thank Chris Lonvick, Jon Callas, Andrew Ross, Albert Mietus, Anton Okmianski, Tina Bird, David Harrington and all other people who commented on various versions of this proposal.
|||National Institute of Standards and Technology, "Digital Signature Standard", FIPS PUB 186-1, December 1998.|
|||National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995.|
|||American National Standards Institute, "USA Code for Information Interchange", ANSI X3.4, 1968.|
|||Menezes, A., van Oorschot, P. and S. Vanstone, ""Handbook of Applied Cryptography", CRC Press", 1996.|
|||Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.|
|||Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.|
|||Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.|
|||Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996.|
|||Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.|
|||Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", RFC 2085, February 1997.|
|||Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.|
|||Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).|
|||Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.|
|||Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.|
|||Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998 (TXT, HTML, XML).|
|||Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 (TXT, HTML, XML).|
|||Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998 (TXT, HTML, XML).|
|||Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.|
|||Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.|
|||New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001 (TXT, HTML, XML).|
|||Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.|
|||Schneier, B., "Applied Cryptography Second Edition: protocols, algorithms, and source code in C", 1996.|
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Copyright (C) The Internet Society (2004). 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 assignees.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.