From syslog-bounces@lists.ietf.org Sun Nov 06 12:49:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYoeU-0000if-1w; Sun, 06 Nov 2005 12:49:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYoeS-0000ia-0P for syslog@megatron.ietf.org; Sun, 06 Nov 2005 12:49:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11108 for ; Sun, 6 Nov 2005 12:49:30 -0500 (EST) Received: from pp109-223.bctel.ca ([209.52.109.223] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYots-0000Gl-Tf for syslog@ietf.org; Sun, 06 Nov 2005 13:05:54 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5EB53E006C; Sun, 6 Nov 2005 12:50:02 -0500 (EST) To: syslog@ietf.org From: Sam Hartman Date: Sat, 05 Nov 2005 20:02:13 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Syslog] Comments on syslog udp transport 05 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi. Here are my AD review comments on version 05 of the syslog udp transport document. These comments need to be addressed before the document can be published. I noticed that you use the term bytes in this document . Please use octet instead. Section 4: bytes in size. This limit stems from the maximum supported UDP payload of 65536 kilobytes specified in the RFC 768 [1]. Is it 65536 or 65535? Also it's octets not kb. Please either remove section 13 or indicate that it should be stripped on RFC publication. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Nov 06 12:50:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYofG-0000y2-Qd; Sun, 06 Nov 2005 12:50:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYofG-0000xx-16 for syslog@megatron.ietf.org; Sun, 06 Nov 2005 12:50:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11139 for ; Sun, 6 Nov 2005 12:50:20 -0500 (EST) Received: from pp109-223.bctel.ca ([209.52.109.223] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYoug-0000He-Pe for syslog@ietf.org; Sun, 06 Nov 2005 13:06:44 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 72CC5E006C; Sun, 6 Nov 2005 12:50:52 -0500 (EST) To: syslog@ietf.org From: Sam hartman Message-Id: <20051106004541.29F4AE006E@carter-zimmerman.mit.edu> Date: Sat, 5 Nov 2005 19:45:41 -0500 (EST) User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.0 (+++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Syslog] Still waiting to hear back on protocol document X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org A few weeks ago I asked the WG if it believes that the new version of syslog-protocol represents WG consensus and addresses comments in AD review. I have received no response to that question; the document will not progress until I get a response from the chair on this issue. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Nov 06 22:28:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYxgm-0003ez-Ov; Sun, 06 Nov 2005 22:28:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYxgl-0003dG-55 for syslog@megatron.ietf.org; Sun, 06 Nov 2005 22:28:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08697 for ; Sun, 6 Nov 2005 22:28:30 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYxwH-0005Ej-Sr for syslog@ietf.org; Sun, 06 Nov 2005 22:44:58 -0500 Received: from djyxpy41 (pp105-206.bctel.ca[209.52.105.206]) by comcast.net (sccrmhc12) with SMTP id <2005110703284101200m0jjae>; Mon, 7 Nov 2005 03:28:42 +0000 From: "David B Harrington" To: Date: Sun, 6 Nov 2005 19:28:25 -0800 Message-ID: <000501c5e34b$571d0860$ce6934d1@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXjP5yeINE/Ghf/Q6mQB17oxWM3xQAC3cZQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: Subject: [Syslog] FW: Agenda for the Ops & Mgmt Open Area Meeting IETF64 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, I requested that the netconf/isms discussion be moved to the first half of the OPS open meeting so syslog personnel could attend. I will be presenting a slide show that includes discussion of syslog/netconf/snmp commonalities. dbh -----Original Message----- From: owner-ops-area@ops.ietf.org [mailto:owner-ops-area@ops.ietf.org] On Behalf Of David Kessens Sent: Sunday, November 06, 2005 5:49 PM To: Operations and Management Area Subject: Agenda for the Ops & Mgmt Open Area Meeting IETF64 Please see below for the agenda of the Operations & Management Open Area meeting. We have rearranged the agenda somewhat to accomodate the various speakers. David Kessens & Bert Wijnen --- Agenda for the Ops & Mgmt Open Area Meeting IETF64 When: 1740-1950, MONDAY, November 7, 2005 Where: Salon 2/3 A. Administrative stuff - appointment of scribe - blue sheets - agenda bashing (David Kessens, Bert Wijnen) B. Area news and updates (Bert Wijnen, David Kessens) 10 minutes for agenda item A&B C. SNMP/ISMS issues: - Overlap between SNMP+ISMS/NETCONF (David Harrington & Simon Leinen - 20 minutes) Some people see potential in evolving NETCONF - which currently focuses on configuration management - into a more general network management protocol, which would subsume much of what SNMP was designed for. At the same time, the ISMS (Integrated Security Mechanisms for SNMP) WG is converging towards the same connection-oriented underlying transport (SSH) as NETCONF. Now seems to be a good time to think about the overlap between SNMP+ISMS and NETCONF, and whether an effort should be made in the IETF at unifying the two. Discussion (20 minutes) D. Proposed working groups - MAVS BOF proposal (Martin Halstead - 10 minutes) - AAA Maintenance (John Loughney - 10 minutes during mini break) Second Hour - o Diffserv Control Plane Elements (DCPEl) (Kathleen Nichols, Scott Bradner - 18 minutes) mailing list: dcpel@ietf.org archive: https://www1.ietf.org/mailman/listinfo/dcpel o Existing diffserv control plane work on nsis, NGN and ETSI (Hannes Tschofenig - tentative, 12 minutes) Discussion (20 minutes) Y. Open Mike Z. AOB --- _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 07 02:14:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ1DO-0003bC-Op; Mon, 07 Nov 2005 02:14:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ1DN-0003aw-Vu for syslog@megatron.ietf.org; Mon, 07 Nov 2005 02:14:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20335 for ; Mon, 7 Nov 2005 02:14:22 -0500 (EST) Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ1Sv-0002L4-81 for syslog@ietf.org; Mon, 07 Nov 2005 02:30:53 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jA77EUnR013679 for ; Mon, 7 Nov 2005 16:14:30 +0900 (JST) Received: from [127.0.0.1] (bert.priv.cysol.co.jp [192.168.0.254]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jA77ETIc012177 for ; Mon, 7 Nov 2005 16:14:30 +0900 (JST) Message-ID: <436EFED5.3030606@cysols.com> Date: Mon, 07 Nov 2005 16:14:29 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: syslog@ietf.org X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Cc: Subject: [Syslog] Re: I-D ACTION:draft-ietf-syslog-protocol-15.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, A few small points that I noticed while reviewing the latest 15.txt draft are given below. Apologies for noticing some of these so late in the day. Cheers Glenn +=============================================================================+ Comments a. page 7 Section 4 Basic Principles The significance of the second clause is not clear. Is it essential that senders not know whether the receiver is a collector or a relay? To me it seems that Senders MAY or MAY NOT know ... b. page 11 Section 6.1 the term "payload" is used only once in the document. It is not defined anywhere. I suggest s/payload/message/. c. page 12 Section 6.2.2 Probably there has been prior discussion on this- but, a sentence that indicates that the present FACILITY codes as in RFC 3164 are (?) reserved, would be helpful. New FACILITY code definitions MUST not override the RFC 3164 FACILITY codes. d. page 14 Section 6.2.4 Value Meaning 00 There has been no truncation needs to be added. e. page 15 Section 6.2.5 The semantics of the TIMESTAMP field is not obvious. It would be nice to have something like The TIMESTAMP field gives the time at which the syslog message was generated at the sender. or. something more appropriate. f. page 17 Section 6.2.7 It would be nice to add that the APP-NAME is the sender's name. g. page 17 Section 6.2.8 The text says The PROCID field SHOULD be used to provide the sender's process name or process ID The difference between APP-NAME and PROCID is not clear. In the example that is given in the following paragraph the PROCID could be "syslogd" or "NNNN" But, if PROCID is "syslogd" then the point of the example will not hold. We will not be able to detect restarts of the syslog! I would think that APP-NAME should be "syslogd" and PROCID should be NNNN. Am I missing something ? +-------------------------------------------------------------------------+ Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. > > Title : The syslog Protocol > Author(s) : R. Gerhards > Filename : draft-ietf-syslog-protocol-15.txt > Pages : 48 > Date : 2005-10-21 > > This document describes the syslog protocol, which is used to convey > event notification messages. This protocol utilizes a layered > architecture, which allows the use of any number of transport > protocols for transmission of syslog messages. It also provides a > message format that allows vendor-specific extensions to be provided > in a structured way. > > This document has been written with the spirit of traditional syslog > in mind. The reason for a new layered specification has arisen > because standardization efforts for reliable, and secure syslog > extensions suffer from the lack of a standards-track and transport > independent RFC. Without this document, each other standard needs to > define its own syslog packet format and transport mechanism, which > over time will introduce subtle compatibility issues. This document > tries to provide a foundation that syslog extensions can build on. > The layered architecture also provides a solid basis that allows code > to be written once instead of multiple times, once for each syslog > feature. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-15.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-syslog-protocol-15.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-syslog-protocol-15.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 07 02:21:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ1JQ-0004tM-G1; Mon, 07 Nov 2005 02:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ1JP-0004tH-3T for syslog@megatron.ietf.org; Mon, 07 Nov 2005 02:21:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20768 for ; Mon, 7 Nov 2005 02:20:36 -0500 (EST) Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ1Yx-0002Y5-1c for syslog@ietf.org; Mon, 07 Nov 2005 02:37:07 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jA77L0nR013714 for ; Mon, 7 Nov 2005 16:21:00 +0900 (JST) Received: from [127.0.0.1] (bert.priv.cysol.co.jp [192.168.0.254]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jA77KxIc012280 for ; Mon, 7 Nov 2005 16:21:00 +0900 (JST) Message-ID: <436F005B.7050902@cysols.com> Date: Mon, 07 Nov 2005 16:20:59 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: syslog@ietf.org X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: Subject: [Syslog] Re: I-D ACTION:draft-ietf-syslog-transport-udp-05.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Folks, A few minor comments on draft-ietf-syslog-transport-udp-05 a. Page 10.1 the text says "This transport does not provide for strong sender authentication". That sort of seems to imply that "weak sender authentication" is provided for. Is that the intent ? To me it appears that no authentication is provided for. The remaining comments are editorial in nature: b. I would prefer the format of the document to be more hierarchically structured. Specifically group Sections 3-8 into a single section. That section defines the syslog-udp-transport. c. page 5 section 8 s/The Note/Note/ Glenn Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. > > Title : Transmission of syslog messages over UDP > Author(s) : A. Okmianski > Filename : draft-ietf-syslog-transport-udp-05.txt > Pages : 10 > Date : 2005-7-15 > > This document describes the transport for syslog messages over UDP/ > IPv4 or UDP/IPv6. The syslog protocol layered architecture provides > for support of any number of transport mappings. However, for > interoperability purposes, syslog protocol implementors are required > to support this transport protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-05.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-syslog-transport-udp-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-syslog-transport-udp-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 07 10:53:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ9JO-0007em-97; Mon, 07 Nov 2005 10:53:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ9JN-0007eh-9D for syslog@megatron.ietf.org; Mon, 07 Nov 2005 10:53:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18764 for ; Mon, 7 Nov 2005 10:53:08 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ9Yw-0007zg-Lq for syslog@ietf.org; Mon, 07 Nov 2005 11:09:40 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2005 07:53:15 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA7FrBNm004165; Mon, 7 Nov 2005 07:53:14 -0800 (PST) Date: Mon, 7 Nov 2005 07:53:11 -0800 (PST) From: Chris Lonvick To: Sam hartman Subject: Re: [Syslog] Still waiting to hear back on protocol document In-Reply-To: <20051106004541.29F4AE006E@carter-zimmerman.mit.edu> Message-ID: References: <20051106004541.29F4AE006E@carter-zimmerman.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Sam, We are finalizing our positions on the last few things during our meeting this afternoon. We are also concerned about implementations and plan to discuss that today as well. Thanks, Chris On Sat, 5 Nov 2005, Sam hartman wrote: > > > A few weeks ago I asked the WG if it believes that the new version of > syslog-protocol represents WG consensus and addresses comments in AD > review. > > I have received no response to that question; the document will not > progress until I get a response from the chair on this issue. > > --Sam > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 07 12:15:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZAaR-0007JZ-Bo; Mon, 07 Nov 2005 12:15:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZAaP-0007JU-Af for syslog@megatron.ietf.org; Mon, 07 Nov 2005 12:15:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23326 for ; Mon, 7 Nov 2005 12:14:47 -0500 (EST) Received: from pp106-155.bctel.ca ([209.52.106.155] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZAq0-0001mc-Ks for syslog@ietf.org; Mon, 07 Nov 2005 12:31:23 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D1FEAE0070; Mon, 7 Nov 2005 11:15:04 -0500 (EST) To: syslog@ietf.org From: Sam Hartman Date: Mon, 07 Nov 2005 11:15:04 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 X-Spam-Score: 2.6 (++) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [Syslog] Responses to AD review comments X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1258849831==" Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org --===============1258849831== Content-Type: multipart/digest; boundary="=-=-=" --=-=-= Content-Type: text/plain I think these messages may never have made it to the wg. --=-=-= Subject: Topics MIME-Version: 1.0 Topics: Re: Prefix - was: RE: [Syslog-sec] AD Review for Re: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Re: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 --=-=-= Date: Thu, 29 Sep 2005 14:18:50 -0400 From: Sam Hartman To: "Rainer Gerhards" Cc: "Chris Lonvick" , Subject: Re: Prefix - was: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3B0A@grfint2.intern.adiscon.com> MIME-Version: 1.0 The ssh ids are in the rfc editor queue and have been there for months, so waiting on them is not an issue. However I believe copying the text is fine. --=-=-= Date: Thu, 29 Sep 2005 14:31:05 -0400 From: Sam Hartman To: "Rainer Gerhards" Cc: Subject: Re: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> MIME-Version: 1.0 Hi. Sorry about the delay. Your proposed directions seem reasonable. However based on your comments on operator input I'm going to request explicit review from the ops directorate. I'd like to give some proposed constraints on the solutions for the sd-ids and parameters. 1) It seems like it should be relatively easy to add vendor extensions. Mechanisms for doing this include a liberal IANA policy, vendor prefixes or vendor suffixes (like ssh). 2) It may be desirable to have a way to extend sd-ids with vendor-specific parameters. However if such a mechanism exists, there also needs to be a way to extend sd-ids with standards track parameters. I.E. it seems silly for it to be more inconvenient for the IETF to extend something than a vendor. Possible ways of handling this are to allow standards track specifications to update the list of sd-params for sd-id, creating a special notation for after-the-fact extensions (a special prefix, @ietf.org suffix, etc), or removing the mechanism for vendor extensions to sd-params completely. 3) Namespace uniqueness should be considered. How important this is depends on how difficult it is to get a name registered. For example with a liberal IANA policy like first-come-first-serve or specification required, x- may be a fine prefix for sd-ids. A vendor concerned by namespace conflicts can just register an extension. However if the iANA policy is going to be more restrictive, then mechanisms such as those discussed on the list become more important. It is likely that with a liberal IANA policy mechanisms for vendor-specific sd-parameters may still be important. Your original proposal as well as the ssh-style proposal do meet these constraints. However there may be options that better meet your desires to make messages small. For this reason, I've tried to explicitly enumerate what I consider the constraints to be. --Sam --=-=-= Date: Fri, 30 Sep 2005 12:23:23 -0400 From: Sam Hartman To: "Rainer Gerhards" Subject: Re: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3B10@grfint2.intern.adiscon.com> MIME-Version: 1.0 >>>>> "Rainer" == Rainer Gerhards writes: Rainer> Sam, sorry to bother you, but I simply do not know about Rainer> this: >> I'm going to request explicit review from the ops directorate. Rainer> Is this something I must initiate. If so, do you have a Rainer> pointer how to do that? No, I will deal with it. --=-=-=-- --===============1258849831== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --===============1258849831==-- From syslog-bounces@lists.ietf.org Mon Nov 07 17:27:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFSd-00008K-VO; Mon, 07 Nov 2005 17:27:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFSc-00008C-56 for syslog@megatron.ietf.org; Mon, 07 Nov 2005 17:27:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12221 for ; Mon, 7 Nov 2005 17:27:04 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZFiH-0002O4-TW for syslog@ietf.org; Mon, 07 Nov 2005 17:43:43 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 07 Nov 2005 14:27:19 -0800 X-IronPort-AV: i="3.97,301,1125903600"; d="scan'208"; a="361965970:sNHT20242532" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA7MQeKm017630 for ; Mon, 7 Nov 2005 14:27:18 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 14:27:12 -0800 Received: from wwwin-cons.cisco.com ([171.71.118.52]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 14:27:12 -0800 Date: Mon, 7 Nov 2005 14:27:11 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Nov 2005 22:27:12.0188 (UTC) FILETIME=[65EE0FC0:01C5E3EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Syslog] Volunteers needed for jabber and scribe X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Please let me know if you can do either. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 08 21:03:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfJb-0004oG-7g; Tue, 08 Nov 2005 21:03:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfJZ-0004o4-Fm for syslog@megatron.ietf.org; Tue, 08 Nov 2005 21:03:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03353 for ; Tue, 8 Nov 2005 21:03:26 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfZT-0003vU-PO for syslog@ietf.org; Tue, 08 Nov 2005 21:20:21 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Nov 2005 18:03:43 -0800 X-IronPort-AV: i="3.97,306,1125903600"; d="scan'208"; a="362586911:sNHT24364764" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA923ebh009383; Tue, 8 Nov 2005 18:03:40 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 21:03:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Comments on syslog udp transport 05 Date: Tue, 8 Nov 2005 21:03:38 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122B915A0@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Comments on syslog udp transport 05 Thread-Index: AcXi+qQRO/GsuVRtRbyFtkSHnb8tGwB1O+iA From: "Anton Okmianski \(aokmians\)" To: "Sam Hartman" , X-OriginalArrivalTime: 09 Nov 2005 02:03:39.0896 (UTC) FILETIME=[CD9EC780:01C5E4D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sam: > Hi. Here are my AD review comments on version 05 of the=20 > syslog udp transport document. These comments need to be=20 > addressed before the document can be published. >=20 >=20 > I noticed that you use the term bytes in this document . =20 > Please use octet instead. Section 2 on Terms has this: "The words 'byte' and 'octet' are used interchangeably in this = document.". =20 I can change it to: "The words 'byte' and 'octet' are used interchangeably in this document = to refer to an octet.". Is this sufficient? I'd prefer to stick to byte (after properly defining it as octet) since = this is what most engineers use and how most product documentation is = written. If you insist, I can switch.=20 > Section 4: >=20 > bytes in size. This limit stems from the maximum supported UDP > payload of 65536 kilobytes specified in the RFC 768 [1]. >=20 > Is it 65536 or 65535? Also it's octets not kb. Ah, good catch - sloppy error. Fixed both.=20 > Please either remove section 13 or indicate that it should=20 > be stripped on RFC publication. Removed.=20 Once I hear on octet vs. byte from you, I will send another draft to the = editor. Thanks, Anton. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 08 21:11:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfQy-0007hI-HH; Tue, 08 Nov 2005 21:11:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfQx-0007hD-TQ for syslog@megatron.ietf.org; Tue, 08 Nov 2005 21:11:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03801 for ; Tue, 8 Nov 2005 21:11:04 -0500 (EST) Received: from pp106-87.bctel.ca ([209.52.106.87] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfgt-00046x-CN for syslog@ietf.org; Tue, 08 Nov 2005 21:27:59 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 52E53E0070; Tue, 8 Nov 2005 21:11:23 -0500 (EST) To: "Anton Okmianski (aokmians)" Subject: Re: [Syslog] Comments on syslog udp transport 05 References: <98AE08B66FAD1742BED6CB9522B73122B915A0@xmb-rtp-20d.amer.cisco.com> From: Sam Hartman Date: Tue, 08 Nov 2005 21:11:22 -0500 In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122B915A0@xmb-rtp-20d.amer.cisco.com> (Anton Okmianski's message of "Tue, 8 Nov 2005 21:03:38 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 2.6 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Anton" == Anton Okmianski (aokmians) writes: Anton> Section 2 on Terms has this: Anton> "The words 'byte' and 'octet' are used interchangeably in Anton> this document.". I did see that. Anton> I can change it to: Anton> "The words 'byte' and 'octet' are used interchangeably in Anton> this document to refer to an octet.". Anton> Is this sufficient? No, I'm not really happy with that. The IETf tends to use octet in specs we publish. Anton> I'd prefer to stick to byte (after properly defining it as Anton> octet) since this is what most engineers use and how most Anton> product documentation is written. If you insist, I can Anton> switch. I'm not sure I quite insist, but I'd strongly request at least. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 08 21:19:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfYQ-0000ZF-T0; Tue, 08 Nov 2005 21:19:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfYQ-0000ZA-1S for syslog@megatron.ietf.org; Tue, 08 Nov 2005 21:19:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04112 for ; Tue, 8 Nov 2005 21:18:46 -0500 (EST) Received: from pp106-87.bctel.ca ([209.52.106.87] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZfoL-0004Gr-JR for syslog@ietf.org; Tue, 08 Nov 2005 21:35:41 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B32A7E0070; Tue, 8 Nov 2005 21:19:10 -0500 (EST) To: syslog@ietf.org From: Sam Hartman Message-Id: <20051109021910.B32A7E0070@carter-zimmerman.mit.edu> Date: Tue, 8 Nov 2005 21:19:10 -0500 (EST) X-Spam-Score: 2.6 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Syslog] Returning your documents X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi. At the meeting yesterday it was fairly obvious that the working group is interested in considering significant modifications to draft-ietf-syslog-protocol- . The level of modifications being seriously discussed make it clear to me that the working group does not currently have sufficient consensus to publish the protocol document at this time. I'm returning the protocol and udp document to the working group until such time as the working group reaches rough consensus to publish the documents. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 08 21:44:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfxI-0002Mi-Ms; Tue, 08 Nov 2005 21:44:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfxF-0002MV-TF for syslog@megatron.ietf.org; Tue, 08 Nov 2005 21:44:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06255 for ; Tue, 8 Nov 2005 21:44:26 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZgDB-00055A-Cn for syslog@ietf.org; Tue, 08 Nov 2005 22:01:21 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Nov 2005 18:44:45 -0800 X-IronPort-AV: i="3.97,306,1125903600"; d="scan'208"; a="362602010:sNHT90107314" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA92ibbj000979; Tue, 8 Nov 2005 18:44:41 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 21:44:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Syslog] Re: I-D ACTION:draft-ietf-syslog-transport-udp-05.txt Date: Tue, 8 Nov 2005 21:44:37 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122B915B1@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Re: I-D ACTION:draft-ietf-syslog-transport-udp-05.txt Thread-Index: AcXjbAOeYDoCOzFZRDWMJfz+F9l8agBalCSQ From: "Anton Okmianski \(aokmians\)" To: "Glenn Mansfield Keeni" , X-OriginalArrivalTime: 09 Nov 2005 02:44:38.0521 (UTC) FILETIME=[87132E90:01C5E4D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Glenn: > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn > Mansfield Keeni > Sent: Monday, November 07, 2005 2:21 AM > To: syslog@ietf.org > Subject: [Syslog] Re: I-D > ACTION:draft-ietf-syslog-transport-udp-05.txt > > > Folks, > A few minor comments on draft-ietf-syslog-transport-udp-05 > > a. Page 10.1 > the text says > "This transport does not provide for strong sender > authentication". > That sort of seems to imply that "weak sender > authentication" is provided > for. Is that the intent ? > To me it appears that no authentication is provided for. It was the intent. The source IP is a "soft" authentication. It identifies the sender. Not to be confused with originator of the message on which we say this: "The source IP address of the UDP datagrams SHOULD NOT be interpreted as the identifier for the host that originated the syslog message. The entity sending the syslog message may be merely a relay. The syslog message itself contains the identifier of the originator of the message." I can change this to "no authentication" if you still feel it is misleading. > The remaining comments are editorial in nature: > > b. I would prefer the format of the document to be more hierarchically > structured. Specifically group Sections 3-8 into a single section. > That section defines the syslog-udp-transport. Good point -- done. > c. page 5 section 8 > s/The Note/Note/ > Thanks! Anton > Glenn > > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the Security Issues in Network > Event Logging Working Group of the IETF. > > > > Title : Transmission of syslog messages over UDP > > Author(s) : A. Okmianski > > Filename : draft-ietf-syslog-transport-udp-05.txt > > Pages : 10 > > Date : 2005-7-15 > > > > This document describes the transport for syslog messages over UDP/ > > IPv4 or UDP/IPv6. The syslog protocol layered > architecture provides > > for support of any number of transport mappings. However, for > > interoperability purposes, syslog protocol implementors > are required > > to support this transport protocol. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-05 > > .txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-syslog-transport-udp-05.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-syslog-transport-udp-05.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > -------------------------------------------------------------- > ---------- > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 08 21:47:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfzZ-0002lR-NA; Tue, 08 Nov 2005 21:47:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfzX-0002lJ-Ta for syslog@megatron.ietf.org; Tue, 08 Nov 2005 21:47:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06380 for ; Tue, 8 Nov 2005 21:46:48 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZgFS-00058b-MA for syslog@ietf.org; Tue, 08 Nov 2005 22:03:43 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2005 18:46:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,306,1125903600"; d="scan'208"; a="14772638:sNHT22649048" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA92knmi003490; Tue, 8 Nov 2005 21:46:49 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 21:46:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Comments on syslog udp transport 05 Date: Tue, 8 Nov 2005 21:46:48 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122B915B3@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Comments on syslog udp transport 05 Thread-Index: AcXk0vSmYeRvLFFORPu/VVccndFpPAABNfTg From: "Anton Okmianski \(aokmians\)" To: "Sam Hartman" X-OriginalArrivalTime: 09 Nov 2005 02:46:49.0365 (UTC) FILETIME=[D5106450:01C5E4D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Ok, changed to octets. Anton.=20 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Tuesday, November 08, 2005 9:11 PM > To: Anton Okmianski (aokmians) > Cc: syslog@ietf.org > Subject: Re: [Syslog] Comments on syslog udp transport 05 >=20 > >>>>> "Anton" =3D=3D Anton Okmianski (aokmians)=20 > writes: >=20 > Anton> Section 2 on Terms has this: >=20 > Anton> "The words 'byte' and 'octet' are used interchangeably in > Anton> this document.". >=20 > I did see that. >=20 > Anton> I can change it to: >=20 > Anton> "The words 'byte' and 'octet' are used interchangeably in > Anton> this document to refer to an octet.". >=20 > Anton> Is this sufficient? >=20 > No, I'm not really happy with that. The IETf tends to use=20 > octet in specs we publish. >=20 > Anton> I'd prefer to stick to byte (after properly defining it as > Anton> octet) since this is what most engineers use and how most > Anton> product documentation is written. If you insist, I can > Anton> switch. >=20 > I'm not sure I quite insist, but I'd strongly request at least. >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 10 14:38:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIG7-0001Ex-Gt; Thu, 10 Nov 2005 14:38:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIG6-0001Ec-3Y for syslog@megatron.ietf.org; Thu, 10 Nov 2005 14:38:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29053 for ; Thu, 10 Nov 2005 14:38:26 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaIWM-0005vi-9H for syslog@ietf.org; Thu, 10 Nov 2005 14:55:43 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2005 11:38:41 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAAJccbi016446; Thu, 10 Nov 2005 11:38:38 -0800 (PST) Date: Thu, 10 Nov 2005 11:38:38 -0800 (PST) From: Chris Lonvick To: Russ Housley , hartmans-ietf@mit.edu, syslog@ietf.org In-Reply-To: <7.0.0.10.2.20051107123337.05c27a30@vigilsec.com> <6.2.1.2.2.20050804045943.05d48890@mail.binhost.com> Message-ID: References: <7.0.0.10.2.20051107123337.05c27a30@vigilsec.com> <6.2.1.2.2.20050804045943.05d48890@mail.binhost.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Syslog] syslog WG Session Summary X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Everyone, During the syslog WG meeting, we discussed implementation of the proposed syslog-protocol. It became apparent that the proposed protocol was not going to be implemented in a widespread manner any time soon. The WG agreed that widespread adoption will probably only occur if we stick with the observed syslog protocol. Action items: - Sam has asked Chris and the WG to better define the charter of the WG. This will entail getting consensus on either defining the 'standard' syslog protocol, or by just allowing any proposals that the WG will make will just be features in the payload of current syslog messages. A new charter needs to be established by the end of the year and will include realistic milestones. Overall, the ideas already developed in the Working Group are good. The use of Structured Data is sound and should progress as the basis for signing syslog messages. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 10 15:50:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaJNj-0007IZ-Qm; Thu, 10 Nov 2005 15:50:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaJN0-000773-Ih; Thu, 10 Nov 2005 15:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03679; Thu, 10 Nov 2005 15:49:37 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaJdE-0008Da-Rt; Thu, 10 Nov 2005 16:06:54 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EaJMw-00087s-AV; Thu, 10 Nov 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 10 Nov 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-udp-06.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Transmission of syslog messages over UDP Author(s) : A. Okmianski Filename : draft-ietf-syslog-transport-udp-06.txt Pages : 11 Date : 2005-11-10 This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementors are required to support this transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-transport-udp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-transport-udp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-10113921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-udp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-udp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-10113921.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Mon Nov 14 10:16:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebg4X-0003Ud-6W; Mon, 14 Nov 2005 10:16:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebg4V-0003UY-H4 for syslog@megatron.ietf.org; Mon, 14 Nov 2005 10:16:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28452 for ; Mon, 14 Nov 2005 10:16:07 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbgLY-0008D2-Q5 for syslog@ietf.org; Mon, 14 Nov 2005 10:34:17 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 14 Nov 2005 07:16:28 -0800 X-IronPort-AV: i="3.97,328,1125903600"; d="txt'?scan'208"; a="674683044:sNHT31116588" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAEFGQ3q013788 for ; Mon, 14 Nov 2005 07:16:26 -0800 (PST) Date: Mon, 14 Nov 2005 07:16:26 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="----=_NextPart_000_024A_01C5E3DD.3DA37FD0" Content-ID: X-Spam-Score: 0.9 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: Subject: [Syslog] Proposed syslog meeting notes X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ------=_NextPart_000_024A_01C5E3DD.3DA37FD0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-ID: Hi Folks, Hector Trevino took notes. I'll post these to the repository if no one has any comments. Thanks, Chris ------=_NextPart_000_024A_01C5E3DD.3DA37FD0 Content-Type: TEXT/PLAIN; name=syslog-meeting-notes-Nov.txt Content-ID: Content-Description: Content-Disposition: attachment; filename=syslog-meeting-notes-Nov.txt Content-Transfer-Encoding: QUOTED-PRINTABLE Syslog meeting notes ------------------- Chris went over various outstanding issues/updates - use of unicode (see presented slide) - SD-IDs (see presented slide) - Will it be implemented? -- Angle brackets w/PRI inside or new = header... * Sharon Chisholm - concerned about doing a complete re-do of = syslog which may change in the near future. Too many changes may be dangerous since it may go on for a while. * Proposal is to update the draft to put back angle brackets around = PRI - no one objected * Put updated timestamp * Steve Chang - he feels that keeping the angle brackets will help = speed up=20 implementations. It also helps as a delimiter for multiple syslog = packets/messages * Sam - these changes are significant and they should not be made = now. The document should be withdrawn from last call, updated, and re-submitted if = the changes need to be made - agreed * Richard G. - looking at multiple dimensions (better use of field, = security,=20 will it be implemented). Seems the WG is defining a new protocol. = Want to be able to separate the issues. Want to use syslog in a management = framework for another standard outside the IETF but needed security.=20 * Proposal - separate various issues into multiple docs.=20 Question to mailing list: should a new doc be generated to = include angle bracket, new time stamp, and SD-ID * Darrin - should have a syslog receiver compliance doc (accept old = format - 3164 and over time accept new one). Capture evolution of = protocol/implementations. The protocol doc does not appear to be good enough for capturing this.=20 * Steve - Truncate indicator seems to be necessary. Chris - perhaps = move it from the header to the SD-ID * Sam - WG is behind on many milestones. Various concerns about = decisions the WG is making at this late stage. CHris - the WG will establish new = milestones Alex Clemm - update on signed syslog (syslog-sign) Brief re-cap of what the current draft specifies =20 sylsog/BEEP - anyone implemented it? Cisco=20 SSH and TLS - should do this in conjunction w/other WGs (NETCONF, = ISMS) Split decision on use of SSH & TLS - take it to the mailing list =20 ------=_NextPart_000_024A_01C5E3DD.3DA37FD0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ------=_NextPart_000_024A_01C5E3DD.3DA37FD0-- From syslog-bounces@lists.ietf.org Mon Nov 14 12:34:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbiDY-00035G-9I; Mon, 14 Nov 2005 12:34:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbiDW-00034i-NF for syslog@megatron.ietf.org; Mon, 14 Nov 2005 12:34:06 -0500 Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07358 for ; Mon, 14 Nov 2005 12:33:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 1226027C028 for ; Mon, 14 Nov 2005 18:30:37 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18700-10 for ; Mon, 14 Nov 2005 18:30:36 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 6EB5627C018 for ; Mon, 14 Nov 2005 18:30:36 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 18:33:27 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Charter revision - why is there so a big difference between list concensus and meeting concensus? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2005 18:33:21 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3E29@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog] Charter revision - why is there so a big difference between list concensus and meeting concensus? Thread-Index: AcXpP2OeK1fOdpT7TUGrFLxjVCiHSwAAI9xA From: "Rainer Gerhards" To: X-OriginalArrivalTime: 14 Nov 2005 17:33:27.0585 (UTC) FILETIME=[85BD5110:01C5E941] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, I will reply to your actual questions with a later message. But I have a concern that is far prior to even the questions. We have been working 2+ years on syslog-protocol and syslog-transport-udp. We had hard discussions. It looked we reached concensus on the mailing list. Then, in the meeting, non-concensus was found. It looks like we have a big discrepancy between what is said on the mailing list and what is said in meetings. I think we need to tackle that *issue* first. Why are we pushing for more and more changes on the mailing list, just to abandon things when they come close to being finished. To get me right: I have no really bad feelings about the way things have evolved (though I have to admit that it is hard to accept that 2+ years of work are being abandoned in 30 minutes - but that is life and it is better to abandon things than to create things that nobody uses [hint: rfc 3195;)]. I only fear that we will work another 2+ years, just to arrive where we are right now. If we do not solve the discrepancy between on-list and off-list concensus, anything we do can strongly be questioned. So my big question is: how did this come? Was there a totally different set of people in the meeting (I noticed some quite uninformed comments in the notes)? Were these folks on the list and just not speaking up? What can we do to prevent this in the future? Please speak up NOW if you are just lurking ;) If we can not solve the discrepancy, it may be worth considering doing only one change at a time on-list, then wait for the next meeting, then do the next change. This might take us three years to complete whatever we like to complete - but if we had started that initially, we would only be some months away from finishing now. So the slow approach might be the right one. Again, this is no bashing - I am just deeply concerned on the way things have evolved and how we can prevent this in the future. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > Sent: Monday, November 14, 2005 6:17 PM > To: syslog@ietf.org > Subject: [Syslog] Charter revision >=20 > Hi Folks, >=20 > I'd like to start the discussion of revising our charter. We=20 > will need to=20 > address various parts of this. >=20 > 1 - At the meeting, it was clear that many people thought=20 > that we should > be building on the accepted syslog header. >=20 > A) Should the WG accept that the observed syslog header=20 > format is good=20 > enough and we should build on top of that? (We can RECOMMEND=20 > a better=20 > timestamp and a few other features but we will not REQUIRE anything.) >=20 > B) Should the WG define a standard header still based upon=20 > Timestamp... ? >=20 >=20 >=20 > 2 - Sam recommended that the WG consider a secure transport -=20 > or have an > explanation of why we don't have one. One option would=20 > be to allow > syslog-tranport-udp to progress at this point while we=20 > decide upon > (1) above. >=20 > Yes/No ) Should the WG let syslog-transport-udp progress without=20 > syslog-protocol at this time? >=20 > Yes/No ) Should the WG consider another secure substrate (in=20 > addition to=20 > RFC3195)? [Any of SSH, SSL, dtls, etc.] >=20 >=20 >=20 > Please respond to this. Additional comment will be=20 > appreciated. Based=20 > upon what I hear back, I'll start drafting a revised charter. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 14 13:20:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbiwF-0005lO-T4; Mon, 14 Nov 2005 13:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbiwE-0005kd-0g for syslog@megatron.ietf.org; Mon, 14 Nov 2005 13:20:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11231 for ; Mon, 14 Nov 2005 13:19:45 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbjDF-0006IR-7A for syslog@ietf.org; Mon, 14 Nov 2005 13:37:55 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAEIJkok026354; Tue, 15 Nov 2005 05:19:46 +1100 (EST) From: Darren Reed Message-Id: <200511141819.jAEIJfbD027223@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Charter revision - why is there so a big difference between list concensus and meeting concensus? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3E29@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Tue, 15 Nov 2005 05:19:41 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Chris, > > We have been working 2+ years on syslog-protocol and > syslog-transport-udp. We had hard discussions. It looked we reached > concensus on the mailing list. Then, in the meeting, non-concensus was > found. It looks like we have a big discrepancy between what is said on > the mailing list and what is said in meetings. I think we need to tackle > that *issue* first. Well, if more people from the list showed up in meetings, that might not be such a problem. > Why are we pushing for more and more changes on the mailing list, just > to abandon things when they come close to being finished. To get me > right: I have no really bad feelings about the way things have evolved > (though I have to admit that it is hard to accept that 2+ years of work > are being abandoned in 30 minutes - but that is life and it is better to > abandon things than to create things that nobody uses [hint: rfc > 3195;)]. I only fear that we will work another 2+ years, just to arrive > where we are right now. If we do not solve the discrepancy between > on-list and off-list concensus, anything we do can strongly be > questioned. First problem: RFC 3195 looks incredibly complex, so rather than try and understand it, people ignore it. I think that people, as a result, tend to be less interested in getting involved, looking at that. What happened here was a lack of good protocol engineering. What the group attempted to do was solve "world hunger" and as a result, we gave birth to something that few people see any benefit in and it is easier for them to do their own thing since that RFC seems to be largely irrelevant. So, I think going forward, this group needs to be more cogniscent of what the world *really* wants and find a way to deliver that rather than something we think they need and in actuality, don't want. > So my big question is: how did this come? Was there a totally different > set of people in the meeting (I noticed some quite uninformed comments > in the notes)? Were these folks on the list and just not speaking up? Probably :) > What can we do to prevent this in the future? Please speak up NOW if you > are just lurking ;) Get better and more critical reviews on what the group is doing and do not pass on documents that do not have this. I suspect the problem here is finding interested and qualified people who have the time. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 15 17:55:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec9iY-0003Ig-SS; Tue, 15 Nov 2005 17:55:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec9iX-0003IM-2t for syslog@megatron.ietf.org; Tue, 15 Nov 2005 17:55:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03482 for ; Tue, 15 Nov 2005 17:55:21 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec9zn-0006vo-2t for syslog@ietf.org; Tue, 15 Nov 2005 18:13:49 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAFMta54008536; Wed, 16 Nov 2005 09:55:36 +1100 (EST) From: Darren Reed Message-Id: <200511152255.jAFMtBnm010569@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Charter revision In-Reply-To: To: Chris Lonvick Date: Wed, 16 Nov 2005 09:55:11 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, What I'd like to see happen is for 3195 to be broken up into 2 or more new RFCs, one (or more) which cover the protocol and one which defines their use over BEEP. i.e. One which covers the COOKED profile, one which covers a RAW profile and one which covers one or both of these over BEEP. We may also choose to add a BSD profile (which is syslog-protocol or an enhanced version of 3164.) That nails down the protocol. Next we move on to defining how the protocol is used. So we describe syslog (COOKED/RAW/BSD) over BEEP/ssh/TLS/UDP/TCP. I think if we evolve that way there is a much better chance of aligning ourselves with what people are doing and want to do without rendering what we've done to the scrap heap completely. It may also be worth taking input from those who have developed or deployed 3195 to understand if there are components of it that did/didn't work. When we get close to getting all of that documentation done, I'd be for advocating that 3195 be moved to "experimental" status, rather than obsolete. For example, chosing this path gives us a syslog-BSD/tcp that should be close enough to what people are doing today with this, bringing together most of these implementations as being RFC compliant. I expect work will be required on both sides to evolve it a little to get there, but I think there's considerable advantage for us and developers if a little work on the part of each party results in RFC compliant software. Sam, do you have any comments on taking this approach with the syslog protocols by the working group ? Cheers, Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 15 17:59:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec9lw-00046C-FZ; Tue, 15 Nov 2005 17:59:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec9lv-000456-92 for syslog@megatron.ietf.org; Tue, 15 Nov 2005 17:59:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03719 for ; Tue, 15 Nov 2005 17:58:53 -0500 (EST) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcA3F-00073o-6v for syslog@ietf.org; Tue, 15 Nov 2005 18:17:21 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3B47DE0073; Tue, 15 Nov 2005 17:59:22 -0500 (EST) To: Darren Reed Subject: Re: [Syslog] Charter revision References: <200511152255.jAFMtBnm010569@firewall.reed.wattle.id.au> From: Sam Hartman Date: Tue, 15 Nov 2005 17:59:22 -0500 In-Reply-To: <200511152255.jAFMtBnm010569@firewall.reed.wattle.id.au> (Darren Reed's message of "Wed, 16 Nov 2005 09:55:11 +1100 (EST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This proposal confuses me greatly. IT seems to be mixing message formats and over the wire protocol. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 16 03:54:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcJ3N-0004rz-4u; Wed, 16 Nov 2005 03:54:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcJ3K-0004pp-R5 for syslog@megatron.ietf.org; Wed, 16 Nov 2005 03:54:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10699 for ; Wed, 16 Nov 2005 03:53:30 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcJKj-0000Sn-J4 for syslog@ietf.org; Wed, 16 Nov 2005 04:12:02 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 7F2699C00C; Wed, 16 Nov 2005 10:01:21 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26128-07; Wed, 16 Nov 2005 10:01:16 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id D29659C00B; Wed, 16 Nov 2005 10:01:16 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] Charter revision / WG obsolete? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2005 09:53:30 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3E4C@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog] Charter revision / WG obsolete? Thread-Index: AcXqOC1dDSgD911USjWt0H6zeBuREAATXeZw From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi all, =20 Darren's post clearly shows what is wrong with this WG: we are re-iterating everything. If I get the essence in Darren's message right, what he is proposing is to create a layered architecture for syslog. If you look at my presentation from two years ago (!), you will see that this was the primary driving force behind syslog-protocol. It is available on Chris' site at http://www.employees.org/~lonvick/attachments/syslog-protocol.pdf The primary difference is that we did the layers starting form RFC 3164 and not from the already-proven-to-be-not-accepted RFC 3195. With syslog-protocol and -transport-udp we initially tried to do just the bare necessities. What Darren recommend is an even broader approach. Please face it: on the WG mailing list, we are pressing for ever and ever change. More and more new things. At least in the last meeting, we are trying to conserve as much as possible (which I personally like). This won't go together. In a previous post, Darren said that the mailing list participants probably do not participate enough in the meetings. And that those in the meetings mostly do not care about the mailing list. I have the feeling that this analysis is correct. Obviously, I am not participating in the meetings for a reason: I simply can not justify traveling around the world for a 30 minute time slot even without a strong business case. I thought that personal participance is not a absolute must in IETF work (though I clearly understand its importance). If that is wrong, we should state that and accept the fact that at least I-D authors MUST participate. That can save a lot of time ;) I begin to feel really concerned about this WG: - the discrepancy about on-list and off-list comments seems to be huge - look at the mailing list archive: we are re-iterating many things ever and ever again - there is very low feedback on the list - we ignore running code and rough consenus existing in practice (syslog/tcp) - the syslog community is not at all interested in the work of this WG (may be a result and not a reason) So please let me ask if we really need a new charter. Or do we need to obsolete the WG? Does it really make sense to put effort into something where only very few participate and even fewer implement? I begin to feel it is more useful if some implementors talk to each other and define what they actually need. That would eventually become running code and maybe later we could turn that into an I-D. The advantage, of course, would be that it actually works and is accepted. On the other hand, the rough consensus and running code on syslog/plain tcp has so far violently been rejected by this WG on many occasions (but thanks to Darren for bringing it up again in his post). So maybe that doesn't make sense, too? Please do not misunderstand me: of course, I am a bit frustrated about the outcome of the last meeting. But that is NOT my driving force. In fact, I like the suggestions from the meeting. But I very strongly fear that this WG has fundamental problems. I personally doubt it makes sense to continue without solving them. One last evidence: if we follow the advise from the last meeting, we could revert back to an earlier version (maybe -02, -03 or so) of syslog-protocol and would have addressed many of the concerns (see http://www.syslog.cc/ietf/protocol.html). Isn't that indication of a serious problem? Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Tuesday, November 15, 2005 11:55 PM > To: Chris Lonvick > Cc: syslog@ietf.org; hartmans-ietf@mit.edu > Subject: Re: [Syslog] Charter revision >=20 > Chris, >=20 > What I'd like to see happen is for 3195 to be broken up into 2 or > more new RFCs, one (or more) which cover the protocol and one which > defines their use over BEEP. >=20 > i.e. One which covers the COOKED profile, one which covers a RAW > profile and one which covers one or both of these over BEEP. > We may also choose to add a BSD profile (which is syslog-protocol > or an enhanced version of 3164.) >=20 > That nails down the protocol. >=20 > Next we move on to defining how the protocol is used. >=20 > So we describe syslog (COOKED/RAW/BSD) over BEEP/ssh/TLS/UDP/TCP. >=20 > I think if we evolve that way there is a much better chance of > aligning ourselves with what people are doing and want to do > without rendering what we've done to the scrap heap completely. >=20 > It may also be worth taking input from those who have developed > or deployed 3195 to understand if there are components of it that > did/didn't work. >=20 > When we get close to getting all of that documentation done, I'd > be for advocating that 3195 be moved to "experimental" status, > rather than obsolete. >=20 > For example, chosing this path gives us a syslog-BSD/tcp that > should be close enough to what people are doing today with this, > bringing together most of these implementations as being RFC > compliant. I expect work will be required on both sides to evolve > it a little to get there, but I think there's considerable advantage > for us and developers if a little work on the part of each party > results in RFC compliant software. >=20 > Sam, do you have any comments on taking this approach with the > syslog protocols by the working group ? >=20 > Cheers, > Darren >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 16 07:25:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMLd-0004eK-Ky; Wed, 16 Nov 2005 07:25:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMLb-0004e0-M5 for syslog@megatron.ietf.org; Wed, 16 Nov 2005 07:25:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21111 for ; Wed, 16 Nov 2005 07:24:32 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcMcz-0005zu-LA for syslog@ietf.org; Wed, 16 Nov 2005 07:43:07 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAGCOfPv015164; Wed, 16 Nov 2005 23:24:41 +1100 (EST) From: Darren Reed Message-Id: <200511161224.jAGCOCpC007411@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Charter revision / WG obsolete? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3E4C@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Wed, 16 Nov 2005 23:24:12 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi all, > If I get the essence in Darren's message right, > what he is proposing is to create a layered architecture for syslog. Yes, by using what's gone before us as the way to start doing that. > Please face it: on the WG mailing list, we are pressing for ever and > ever change. More and more new things. At least in the last meeting, we > are trying to conserve as much as possible (which I personally like). > This won't go together. What I think the WG is lacking is a good long term focus of objectives. I believe this is largely because the group has been meandering along. I think we need to refocus by looking at where people are going with developing syslog protocols and evolve what exists today to meet that. > Obviously, I am not participating > in the meetings for a reason: I simply can not justify traveling around > the world for a 30 minute time slot even without a strong business case. > I thought that personal participance is not a absolute must in IETF work > (though I clearly understand its importance). Which is why those who attend the meetings are often involved in more than a single WG. .. > - we ignore running code and rough consenus existing in practice > (syslog/tcp) My hope is that if we pursue a layered approach will allow us to easily document a protocol that covers the existing practice in this area as well as provide a path for future design. > Please do not misunderstand me: of course, I am a bit frustrated about > that this WG has fundamental problems. I personally doubt it makes sense > to continue without solving them. Where I think we've gone wrong and I hear indications of "going wrong" are with people who want to solve their own pet problem - we've lost sight of the big picture. For example, the different message format to allow bit-banging for indicate this or that has happened to the message. For most people, it does nothing. As too with XML - I'm sure there is a large contingent of developers out there who balk at any document that mentions XML, even if its optional. I think the WG should remain and has a purpose. At the meeting Sam Hartman mentioned that we were going nowhere fast and in danger of being shut down. Apparently this isn't uncommon but I think that although there problems that they aren't beyond fixing. I think the key to achieving a good result has got to be thinking that it is ok to have lots of small documents rather than just one big document. If nothing else, it should make the work required to produce a single one down and therefore more attractive. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 16 08:51:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNgk-0006tG-TS; Wed, 16 Nov 2005 08:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNgj-0006tB-EC for syslog@megatron.ietf.org; Wed, 16 Nov 2005 08:51:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25883 for ; Wed, 16 Nov 2005 08:50:28 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcNy8-0008UH-MR for syslog@ietf.org; Wed, 16 Nov 2005 09:09:03 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 099889C00C; Wed, 16 Nov 2005 14:58:36 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26584-07; Wed, 16 Nov 2005 14:58:27 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id D4B229C00B; Wed, 16 Nov 2005 14:58:27 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] Charter revision / WG obsolete? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2005 14:50:45 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3E58@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog] Charter revision / WG obsolete? Thread-Index: AcXqqMJiIkvCoBlYRVS0WuInDPLiFgABlqpA From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, I mostly agree, but my main point is that all this has been discussed. My presentation from 2 years ago covers exactly these issues. For example... 22 Jan 2004 - talking about backwards compatibility and its importance http://www.syslog.cc/ietf/autoarc/msg00000.html 3 Feb 2004 - talking about transport ignorance and the need for a TCP mapping: http://www.syslog.cc/ietf/autoarc/msg01038.html =20 24 Feb 2004 - asking for a seperate doc on relay (to keep docs smaller) http://www.syslog.cc/ietf/autoarc/msg01155.html If I searched a little more through the archives, I would probably find another myriad of postings where others and I cautioned against changing too much. However, the consensus (then and on-list) was that we should add all these bells and whistles. I would definitely appreciate if the WG would result in a (series of) usable document(s). The plain fact, however, is that syslog is working quite well in practice. I have implemented complex syslog senders, relays and clients on Windows and Linux for several years now. My softwares support syslog/udp, syslog/plain tcp, even RFC3195/RAW and partial RFC3195/COOKED. I've written articles on how to encrypt syslog traffic and advised on how to ensure client authentication. I am about to implement native ssl-encryption and authentication in my softwares. I know stock syslogd code on Linux and BSD quite well. I know neither of them does syslog in the way RFC 3164 describes. Most importantly, I've implemented lots of code to tackle all this differences. Of course, my implementations are interoperable with the major other syslogs, like stock syslogd, kiwi syslog on windows and syslog-ng on *nix - both in plain and encrypted modes. I've done extremely simple code as well as high-performance multi-threaded ones (which will show you some weaknesses in the specs you don't see if you only do the simple stuff). And, yes, my software handles DBCS character sets and is able to process very large messages, should there be a need (and there sometimes is a need, even if the WG tends to object this). BTW: I implemented a RFC 3164 mode, and we needed to turn it off by default because almost nothing is compatible with that. I've tried to promote RFC 3195, even written a free-for-all-uses, open-sourced library for that and seen that nobody in the syslog community is interested in any of that. I know that a totally reliable (and thus blocking) transport is not desirable in all cases - it might cause denial of service (just like PIX stalls if it is set to tcp syslog and the syslogd dies - similar fatal cases exist if the *nix system logger stalls). So I have the tendency to think I know at least a little what is needed in syslog. And, yes, I agree that we do not urgently need the truncation bit and some other stuff. BUT... as long as these things are violently requested on the mailing list AND it is concensus that they are needed - how can I keep them out of a WG draft? I'd told Chris in private mail that I would be willing to change syslog-protocol so that it could life within the constraints of RFC 3164 (which does NOT describe what the majority of implementations does!). However, any such effort only makes sense when there is a chance that we get a real discusssion on the list. And especially one that is consistent with the discussion in the meetings. And I begin to strongly doubt that... Rainer > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Wednesday, November 16, 2005 1:24 PM > To: Rainer Gerhards > Cc: syslog@ietf.org; hartmans-ietf@mit.edu > Subject: Re: [Syslog] Charter revision / WG obsolete? >=20 > Hi all, >=20 > > If I get the essence in Darren's message right, > > what he is proposing is to create a layered architecture for syslog. >=20 > Yes, by using what's gone before us as the way to start doing that. >=20 > > Please face it: on the WG mailing list, we are pressing for ever and > > ever change. More and more new things. At least in the last=20 > meeting, we > > are trying to conserve as much as possible (which I=20 > personally like). > > This won't go together. >=20 > What I think the WG is lacking is a good long term focus of=20 > objectives. >=20 > I believe this is largely because the group has been meandering along. >=20 > I think we need to refocus by looking at where people are going with > developing syslog protocols and evolve what exists today to meet that. >=20 > > Obviously, I am not participating > > in the meetings for a reason: I simply can not justify=20 > traveling around > > the world for a 30 minute time slot even without a strong=20 > business case. > > I thought that personal participance is not a absolute must=20 > in IETF work > > (though I clearly understand its importance). >=20 > Which is why those who attend the meetings are often involved in more > than a single WG. >=20 > .. > > - we ignore running code and rough consenus existing in practice > > (syslog/tcp) >=20 > My hope is that if we pursue a layered approach will allow us to > easily document a protocol that covers the existing practice in > this area as well as provide a path for future design. >=20 > > Please do not misunderstand me: of course, I am a bit=20 > frustrated about > > that this WG has fundamental problems. I personally doubt=20 > it makes sense > > to continue without solving them. >=20 > Where I think we've gone wrong and I hear indications of "going wrong" > are with people who want to solve their own pet problem - we've lost > sight of the big picture. For example, the different message format > to allow bit-banging for indicate this or that has happened=20 > to the message. > For most people, it does nothing. As too with XML - I'm sure there is > a large contingent of developers out there who balk at any document > that mentions XML, even if its optional. >=20 > I think the WG should remain and has a purpose. At the meeting > Sam Hartman mentioned that we were going nowhere fast and in danger > of being shut down. Apparently this isn't uncommon but I think that > although there problems that they aren't beyond fixing. >=20 > I think the key to achieving a good result has got to be thinking > that it is ok to have lots of small documents rather than just one > big document. If nothing else, it should make the work required > to produce a single one down and therefore more attractive. >=20 > Darren >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 16 13:17:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcRr0-0004SY-73; Wed, 16 Nov 2005 13:17:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcRqy-0004SS-8Y for syslog@megatron.ietf.org; Wed, 16 Nov 2005 13:17:52 -0500 Received: from usscmail7.hds.com (usscmail7.hds.com [63.74.235.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14823 for ; Wed, 16 Nov 2005 13:17:16 -0500 (EST) Received: from mail.hds.com (usscmail9 [10.1.6.230]) by usscmail7.hds.com (8.11.7p1+Sun/8.11.5) with ESMTP id jAGIHHG29978 for ; Wed, 16 Nov 2005 10:17:17 -0800 (PST) Received: from usscceb102.corp.hds.com (USSCCNETSLB08-VLAN4.hds.com [10.1.6.68]) by mail.hds.com (8.11.5-p0-rfc19719/8.11.5) with ESMTP id jAGIHTb10540 for ; Wed, 16 Nov 2005 10:17:30 -0800 (PST) Received: from USSCCEVS102.corp.hds.com ([10.1.52.225]) by usscceb102.corp.hds.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 10:17:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Syslog] Charter revision / WG obsolete? Date: Wed, 16 Nov 2005 10:17:16 -0800 Message-ID: <45D4D9EBC6EF8D418F584D3D3F6AFC1C9290B8@USSCCEVS102.corp.hds.com> Thread-Topic: RE: [Syslog] Charter revision / WG obsolete? Thread-Index: AcXq2fkFNBc9+StyR0qiqj+JoavEDQ== From: "Eric Hibbard" To: X-OriginalArrivalTime: 16 Nov 2005 18:17:16.0919 (UTC) FILETIME=[F9C55870:01C5EAD9] Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1311179868==" Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1311179868== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EAD9.F94A6FF4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EAD9.F94A6FF4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As one of the many lurkers on this list, I have been monitoring this WG's activities and I'm a bit concerned with the recent posts. I had high hopes that some form of logging standardization might materialize, but that now seems to be in question. =20 Recent regulations within the U.S. (e.g., SOX, HIPAA, SEC, FDA, etc.) and other countries are forcing organizations to implement "accountability" measures. Audit logging (as well as authentication and authorization) is a critical element of these accountability measures. Seems to me that this WG might want to step up and standardize the way this gets handled. If nothing else, it could give the WG a little more focus. =20 -Eric =20 Eric A. Hibbard, CISSP, ISSAP, ISSMP, ISSEP Senior Director, Data Networking Technology Chair, SNIA Security Technical Work Group =20 Office of the CTO HITACHI DATA SYSTEMS 750 Central Expressway, MS 3407 Santa Clara, CA 95050-2627 P 408.970.7979/ F 408.562.5477 eric.hibbard@hds.com =20 =20 ------_=_NextPart_001_01C5EAD9.F94A6FF4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As one = of the many=20 lurkers on this list, I have been monitoring this WG's activities and = I'm a bit=20 concerned with the recent posts. I had high hopes that some form of = logging=20 standardization might materialize, but that now seems to be in=20 question.
 
Recent = regulations=20 within the U.S. (e.g., SOX, HIPAA, SEC, FDA, etc.) and other countries = are=20 forcing organizations to implement "accountability" measures. Audit = logging (as=20 well as authentication and authorization) is a critical element of these = accountability measures. Seems to me that this WG might want to step up = and=20 standardize the way this gets handled. If nothing else, it could give = the WG a=20 little more focus.
 
-Eric
 
Eric A. Hibbard, CISSP, ISSAP, ISSMP,=20 ISSEP
Senior = Director,=20 Data Networking Technology
Chair, SNIA Security Technical = Work=20 Group
 
Office of the = CTO
HITACHI DATA=20 SYSTEMS
750 Central = Expressway, MS=20 3407
Santa=20 Clara, CA 95050-2627
P 408.970.7979/ F = 408.562.5477
eric.hibbard@hds.com
 
------_=_NextPart_001_01C5EAD9.F94A6FF4-- --===============1311179868== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --===============1311179868==-- From syslog-bounces@lists.ietf.org Wed Nov 16 14:12:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSiF-0003TA-I5; Wed, 16 Nov 2005 14:12:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSiD-0003Rd-O1 for syslog@megatron.ietf.org; Wed, 16 Nov 2005 14:12:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18024 for ; Wed, 16 Nov 2005 14:12:19 -0500 (EST) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcSzf-00050F-Fg for syslog@ietf.org; Wed, 16 Nov 2005 14:30:58 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0126FE0074; Wed, 16 Nov 2005 14:12:40 -0500 (EST) To: syslog@ietf.org From: Sam Hartman Date: Wed, 16 Nov 2005 14:12:40 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: housley@vigilsec.com Subject: [Syslog] formal Consultation prior to concluding the working group X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Greetings. I'd like to draw yo;ur attention to section 4 of RFC 2418. This section requires area directors to consult with a working group prior to concluding that working group. At the meeting in Vancouver I started such a consultation by noting that once the next set of milestones is approved I would conclude the working group if these milestones are missed. However Rainer Gerhards's messages call into question whether we can even come to sufficient consensus to proceed at all. As such, I'm formally requesting input on the following questions: 1) Is there sufficient consensus on the direction of the work that this working group can continue? 2) Is there another charter under which the working group would better be able to make progress? Please Submit comments to me and preferably also to the list by December 1, 2005. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 16 14:15:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSkg-0003vv-CH; Wed, 16 Nov 2005 14:15:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSke-0003vk-CC for syslog@megatron.ietf.org; Wed, 16 Nov 2005 14:15:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18137 for ; Wed, 16 Nov 2005 14:14:46 -0500 (EST) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcT24-00055t-E1 for syslog@ietf.org; Wed, 16 Nov 2005 14:33:25 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1C35FE0074; Wed, 16 Nov 2005 14:15:14 -0500 (EST) To: syslog@ietf.org From: Sam Hartman Date: Wed, 16 Nov 2005 14:15:14 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Syslog] lists and meetings X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi. Participants who attend the meetings are expected to also join the list. It is the consensus on the list that should be driving the working group, not what decisions are being made in meetings. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 16 15:10:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTcJ-0001k7-Q4; Wed, 16 Nov 2005 15:10:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTcI-0001k2-KV for syslog@megatron.ietf.org; Wed, 16 Nov 2005 15:10:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20945 for ; Wed, 16 Nov 2005 15:10:17 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcTtm-0006ts-Q8 for syslog@ietf.org; Wed, 16 Nov 2005 15:28:56 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 16 Nov 2005 12:10:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,338,1125903600"; d="scan'208"; a="15336303:sNHT21681924" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAGKAIe7020872; Wed, 16 Nov 2005 15:10:37 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 15:10:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] lists and meetings Date: Wed, 16 Nov 2005 15:10:26 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122BDA51A@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] lists and meetings Thread-Index: AcXq4kaA9sZdqDKnSWOOhXTNupoPagABWR2Q From: "Anton Okmianski \(aokmians\)" To: "Sam Hartman" , X-OriginalArrivalTime: 16 Nov 2005 20:10:26.0976 (UTC) FILETIME=[C8F5D200:01C5EAE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Good to have that clear!=20 I also second Rainer that we had consensus on the list on everything = that is in syslog-protocol now. The consensus was built over 2 years, 15 = revisions, and is well-documented in list archives and Rainer's web site = http://www.syslog.cc/ietf. But I won't object to revisiting certain = issues if there is such desire on the part of new list members or to = making clear statements about the charter such that people get better = perspective about the work we undertook. =20 I will respond to other emails soon regarding details of charter and = address specific proposed draft changes. Consulting some additional = people. But in short, I don't think any drastic measures would be needed = which would nullify the effort by a number of people over 2 years to = create something really useful. Even with proposed changes (if there is = consensus on them) we are 95% there IMO. =20 I do agree with Rainer that we need a process that does not result in a = perpetual cycle of consensus on list and disagreement during the = meetings. This is a pre-requisite to successfully completing this work. = =20 Thanks, Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Sam Hartman > Sent: Wednesday, November 16, 2005 2:15 PM > To: syslog@ietf.org > Subject: [Syslog] lists and meetings >=20 >=20 >=20 > Hi. >=20 > Participants who attend the meetings are expected to also=20 > join the list. It is the consensus on the list that should=20 > be driving the working group, not what decisions are being=20 > made in meetings. >=20 > --Sam >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 16 15:17:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTj8-0002lD-LO; Wed, 16 Nov 2005 15:17:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTj6-0002kw-LF for syslog@megatron.ietf.org; Wed, 16 Nov 2005 15:17:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21322 for ; Wed, 16 Nov 2005 15:17:19 -0500 (EST) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcU0a-00079j-Rt for syslog@ietf.org; Wed, 16 Nov 2005 15:35:58 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 98496E0070; Wed, 16 Nov 2005 15:17:41 -0500 (EST) To: "Anton Okmianski (aokmians)" References: <98AE08B66FAD1742BED6CB9522B73122BDA51A@xmb-rtp-20d.amer.cisco.com> From: Sam Hartman Date: Wed, 16 Nov 2005 15:17:41 -0500 In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122BDA51A@xmb-rtp-20d.amer.cisco.com> (Anton Okmianski's message of "Wed, 16 Nov 2005 15:10:26 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: syslog@ietf.org Subject: [Syslog] Re: protocol direction X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Anton" == Anton Okmianski (aokmians) writes: Anton> Good to have that clear! I also second Rainer that we had Anton> consensus on the list on everything that is in Anton> syslog-protocol now. The consensus was built over 2 years, There are several questions then: 1) Do you still have that consensus (an item for the chair) 2) Can the chair say that he personally believes syslog-protocol is the right direction/a document he will request publication of. 3) Does the IETF as a whole share your consensus? 4) Will it be implementede. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 17 05:34:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ech6H-0000lA-Ni; Thu, 17 Nov 2005 05:34:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ech6F-0000iv-Ld for syslog@megatron.ietf.org; Thu, 17 Nov 2005 05:34:39 -0500 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12437 for ; Thu, 17 Nov 2005 05:34:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 88BBD9C00C for ; Thu, 17 Nov 2005 11:41:56 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27596-01 for ; Thu, 17 Nov 2005 11:41:51 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id B3F369C00B for ; Thu, 17 Nov 2005 11:41:51 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] formal Consultation prior to concluding the working group MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2005 11:33:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3E67@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] formal Consultation prior to concluding the working group Thread-Index: AcXq4fjsZmI2b4PZTGG8MMY/OVe5LAAgANhQ From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi WG, in order to provide feedback to Sam, I would like to know what you current view of syslog-protocol is. I am asking especially those people that objected it in the meeting. Please share your concerns with us, because only this allows us to drive that thing forward. I have absolutely no problem with changes, but we need to know that people think there is need to change. So, please let the WG know any concerns you might have with syslog-protocol and/or the work we have carried out so far. Many thanks, Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Sam Hartman > Sent: Wednesday, November 16, 2005 8:13 PM > To: syslog@ietf.org > Cc: housley@vigilsec.com > Subject: [Syslog] formal Consultation prior to concluding the=20 > working group >=20 >=20 >=20 > Greetings. I'd like to draw yo;ur attention to section 4 of RFC 2418. >=20 > This section requires area directors to consult with a working group > prior to concluding that working group. At the meeting in Vancouver I > started such a consultation by noting that once the next set of > milestones is approved I would conclude the working group if these > milestones are missed. >=20 > However Rainer Gerhards's messages call into question whether we can > even come to sufficient consensus to proceed at all. >=20 > As such, I'm formally requesting input on the following questions: >=20 > 1) Is there sufficient consensus on the direction of the work=20 > that this working group can continue? >=20 > 2) Is there another charter under which the working group would better > be able to make progress? >=20 >=20 > Please Submit comments to me and preferably also to the list by > December 1, 2005. >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 17 08:07:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcjUS-0000wF-6E; Thu, 17 Nov 2005 08:07:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcjUQ-0000wA-MK for syslog@megatron.ietf.org; Thu, 17 Nov 2005 08:07:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21989 for ; Thu, 17 Nov 2005 08:07:09 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecjly-0000zs-Nj for syslog@ietf.org; Thu, 17 Nov 2005 08:25:58 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAHD7NpB019540; Fri, 18 Nov 2005 00:07:23 +1100 (EST) From: Darren Reed Message-Id: <200511171307.jAHD72Sp016650@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Charter revision / WG obsolete? In-Reply-To: <45D4D9EBC6EF8D418F584D3D3F6AFC1C9290B8@USSCCEVS102.corp.hds.com> To: Eric Hibbard Date: Fri, 18 Nov 2005 00:07:02 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > As one of the many lurkers on this list, I have been monitoring this > WG's activities and I'm a bit concerned with the recent posts. I had > high hopes that some form of logging standardization might materialize, > but that now seems to be in question. That is outside the scope of this WG. We're trying to concentrate on the protocol used to convey log information - that's all. > Recent regulations within the U.S. (e.g., SOX, HIPAA, SEC, FDA, etc.) > and other countries are forcing organizations to implement > "accountability" measures. Audit logging (as well as authentication and > authorization) is a critical element of these accountability measures. > Seems to me that this WG might want to step up and standardize the way > this gets handled. If nothing else, it could give the WG a little more > focus. That information _may_ be placed in syslog messages but the scope of what you're talking about includes much more than just sending data between daemons. For now, we have other more basic problems to solve and as tempting as it is to try and solve these too, it would just be a distraction and stop the WG from achieving what it needs to achieve. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 17 08:46:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eck61-000656-8X; Thu, 17 Nov 2005 08:46:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eck60-00064u-60 for syslog@megatron.ietf.org; Thu, 17 Nov 2005 08:46:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24541 for ; Thu, 17 Nov 2005 08:46:01 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EckNc-0002Sn-Ov for syslog@ietf.org; Thu, 17 Nov 2005 09:04:50 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAHDkE8E012229; Fri, 18 Nov 2005 00:46:14 +1100 (EST) From: Darren Reed Message-Id: <200511171345.jAHDjtA1022011@firewall.reed.wattle.id.au> Subject: Re: [Syslog] formal Consultation prior to concluding the working group In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3E67@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Fri, 18 Nov 2005 00:45:55 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Hi WG, > > in order to provide feedback to Sam, I would like to know what you > current view of syslog-protocol is. I am asking especially those people > that objected it in the meeting. Please share your concerns with us, > because only this allows us to drive that thing forward. I have > absolutely no problem with changes, but we need to know that people > think there is need to change. > > So, please let the WG know any concerns you might have with > syslog-protocol and/or the work we have carried out so far. I've been asleep on here and not reading the drafts for too long. syslog-protocol is trying to do bit-banging it text, a-la "RAW" from 3195. This leads me to believe that the protocol is badly designed. Looking at it, it seems to be a cross between COOKED and RAW mode from 3195. Maybe the fault of this is this "structured data" that seems to be pervasive in the IETF at present. What you might call a poor man's XML. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 17 08:56:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckFD-0000le-0J; Thu, 17 Nov 2005 08:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckFA-0000lX-Ny for syslog@megatron.ietf.org; Thu, 17 Nov 2005 08:56:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24897 for ; Thu, 17 Nov 2005 08:55:29 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EckWo-0002hP-Ie for syslog@ietf.org; Thu, 17 Nov 2005 09:14:19 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAHDu0F3019006; Fri, 18 Nov 2005 00:56:00 +1100 (EST) From: Darren Reed Message-Id: <200511171355.jAHDtiwO019390@firewall.reed.wattle.id.au> Subject: Re: [Syslog] formal Consultation prior to concluding the working group In-Reply-To: To: Sam Hartman Date: Fri, 18 Nov 2005 00:55:44 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, housley@vigilsec.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > 2) Is there another charter under which the working group would better > be able to make progress? I believe the answer to this is yes. There is very relevant work this group could do and should do. If you look at what the community at large has done with implementing syslog in recent years, the only conclusion that you can draw is that what it has been doing, apart from 3164, has been quite distant from what this should have been doing. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 17 11:33:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcmhB-000295-C6; Thu, 17 Nov 2005 11:33:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecmh9-00027Y-EO for syslog@megatron.ietf.org; Thu, 17 Nov 2005 11:33:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04540 for ; Thu, 17 Nov 2005 11:32:33 -0500 (EST) Received: from usscmail7.hds.com ([63.74.235.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecmyn-0008Qr-4c for syslog@ietf.org; Thu, 17 Nov 2005 11:51:23 -0500 Received: from mail.hds.com (usscmail9 [10.1.6.230]) by usscmail7.hds.com (8.11.7p1+Sun/8.11.5) with ESMTP id jAHGWgG25632; Thu, 17 Nov 2005 08:32:42 -0800 (PST) Received: from usscceb102.corp.hds.com (USSCCNETSLB08-VLAN4.hds.com [10.1.6.68]) by mail.hds.com (8.11.5-p0-rfc19719/8.11.5) with ESMTP id jAHGWtb19001; Thu, 17 Nov 2005 08:32:55 -0800 (PST) Received: from USSCCEVS102.corp.hds.com ([10.1.52.225]) by usscceb102.corp.hds.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 08:32:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Charter revision / WG obsolete? Date: Thu, 17 Nov 2005 08:32:41 -0800 Message-ID: <45D4D9EBC6EF8D418F584D3D3F6AFC1C9290C6@USSCCEVS102.corp.hds.com> Thread-Topic: [Syslog] Charter revision / WG obsolete? Thread-Index: AcXrd94HOh9Ks4VERZKRMFRtmgH80AAG0agg From: "Eric Hibbard" To: "Darren Reed" X-OriginalArrivalTime: 17 Nov 2005 16:32:42.0591 (UTC) FILETIME=[88649EF0:01C5EB94] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org My mistake. I mis-interpreted the WG description, "...At a minimum this group will address providing authenticity, integrity and confidentiality of Syslog messages as they traverse the network." I guess I'll shift this discussion to INCITS/CS1. Thanks for the bandwidth. -Eric=20 -----Original Message----- From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 Sent: Thursday, November 17, 2005 5:07 AM To: Eric Hibbard Cc: syslog@ietf.org Subject: Re: [Syslog] Charter revision / WG obsolete? > As one of the many lurkers on this list, I have been monitoring this > WG's activities and I'm a bit concerned with the recent posts. I had > high hopes that some form of logging standardization might materialize, > but that now seems to be in question. That is outside the scope of this WG. We're trying to concentrate on the protocol used to convey log information - that's all. > Recent regulations within the U.S. (e.g., SOX, HIPAA, SEC, FDA, etc.) > and other countries are forcing organizations to implement > "accountability" measures. Audit logging (as well as authentication and > authorization) is a critical element of these accountability measures. > Seems to me that this WG might want to step up and standardize the way > this gets handled. If nothing else, it could give the WG a little more > focus. That information _may_ be placed in syslog messages but the scope of what you're talking about includes much more than just sending data between daemons. For now, we have other more basic problems to solve and as tempting as it is to try and solve these too, it would just be a distraction and stop the WG from achieving what it needs to achieve. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 17 15:21:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqGC-0002JL-80; Thu, 17 Nov 2005 15:21:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqGB-0002JA-3H for syslog@megatron.ietf.org; Thu, 17 Nov 2005 15:21:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17516 for ; Thu, 17 Nov 2005 15:20:55 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqXr-0007R2-Sx for syslog@ietf.org; Thu, 17 Nov 2005 15:39:49 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ecn3Q-0006qf-0T for syslog@ietf.org; Thu, 17 Nov 2005 11:56:08 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B6865E0073; Thu, 17 Nov 2005 11:55:29 -0500 (EST) To: Darren Reed Subject: Re: [Syslog] formal Consultation prior to concluding the working group References: <200511171355.jAHDtiwO019390@firewall.reed.wattle.id.au> From: Sam Hartman Date: Thu, 17 Nov 2005 11:55:29 -0500 In-Reply-To: <200511171355.jAHDtiwO019390@firewall.reed.wattle.id.au> (Darren Reed's message of "Fri, 18 Nov 2005 00:55:44 +1100 (EST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: syslog@ietf.org, housley@vigilsec.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >>>>> "Darren" == Darren Reed writes: >> 2) Is there another charter under which the working group >> would better be able to make progress? Darren> I believe the answer to this is yes. Darren> There is very relevant work this group could do and should Darren> do. In that case I'd recommend that you see if you can get consensus on such a charter. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 17 15:40:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqYY-0002Jr-8J; Thu, 17 Nov 2005 15:40:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqYW-0002Je-Tc for syslog@megatron.ietf.org; Thu, 17 Nov 2005 15:40:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19370 for ; Thu, 17 Nov 2005 15:39:53 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqqD-0008HP-Sx for syslog@ietf.org; Thu, 17 Nov 2005 15:58:47 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 17 Nov 2005 12:40:18 -0800 X-IronPort-AV: i="3.97,343,1125903600"; d="scan'208"; a="676298463:sNHT22985416" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAHKeGeT006772; Thu, 17 Nov 2005 12:40:16 -0800 (PST) Date: Thu, 17 Nov 2005 12:40:15 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Subject: Re: [Syslog] formal Consultation prior to concluding the working group In-Reply-To: Message-ID: References: <200511171355.jAHDtiwO019390@firewall.reed.wattle.id.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: hartmans-ietf@mit.edu, housley@vigilsec.com, Darren Reed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Apologies for the silence. I'm busy with the day job today and tomorrow. Very briefly, I'd suggest that we can work towards a charter that formalizes syslog but does not break existing syslog recievers. Once there, we can add in the Structured Data parts that can be used for higher level functions such as signing the messages. Does that approach make sense? If so, I can start working out a draft charter that says that we will do just that. I would like to hear from more people on this. Thanks, Chris On Thu, 17 Nov 2005, Sam Hartman wrote: >>>>>> "Darren" == Darren Reed writes: > > >> 2) Is there another charter under which the working group > >> would better be able to make progress? > > Darren> I believe the answer to this is yes. > > Darren> There is very relevant work this group could do and should > Darren> do. > > In that case I'd recommend that you see if you can get consensus on > such a charter. > > --Sam > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 17 15:51:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqjP-0007YE-6Y; Thu, 17 Nov 2005 15:51:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqjO-0007Y9-BH for syslog@megatron.ietf.org; Thu, 17 Nov 2005 15:51:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19918 for ; Thu, 17 Nov 2005 15:51:06 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecr16-0000JB-Di for syslog@ietf.org; Thu, 17 Nov 2005 16:10:00 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2005 12:51:33 -0800 X-IronPort-AV: i="3.97,343,1125903600"; d="scan'208"; a="366887887:sNHT27618588" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAHKpUeT012097; Thu, 17 Nov 2005 12:51:31 -0800 (PST) Date: Thu, 17 Nov 2005 12:51:30 -0800 (PST) From: Chris Lonvick To: Eric Hibbard Subject: RE: [Syslog] Charter revision / WG obsolete? In-Reply-To: <45D4D9EBC6EF8D418F584D3D3F6AFC1C9290C6@USSCCEVS102.corp.hds.com> Message-ID: References: <45D4D9EBC6EF8D418F584D3D3F6AFC1C9290C6@USSCCEVS102.corp.hds.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: syslog@ietf.org, Darren Reed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, I believe that we will still provide the attributes you list below in our work. We will be narrowly focused and we will not discuss how syslog can be used other than to say that it will transport event messages. After we finish our work, you may find that syslog can provide "accountability reporting" as you describe. Thanks, Chris On Thu, 17 Nov 2005, Eric Hibbard wrote: > My mistake. I mis-interpreted the WG description, "...At a minimum this > group will address providing authenticity, integrity and confidentiality > of Syslog messages as they traverse the network." I guess I'll shift > this discussion to INCITS/CS1. > > Thanks for the bandwidth. > > -Eric > > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au] > Sent: Thursday, November 17, 2005 5:07 AM > To: Eric Hibbard > Cc: syslog@ietf.org > Subject: Re: [Syslog] Charter revision / WG obsolete? > >> As one of the many lurkers on this list, I have been monitoring this >> WG's activities and I'm a bit concerned with the recent posts. I had >> high hopes that some form of logging standardization might > materialize, >> but that now seems to be in question. > > That is outside the scope of this WG. We're trying to concentrate on > the protocol used to convey log information - that's all. > >> Recent regulations within the U.S. (e.g., SOX, HIPAA, SEC, FDA, etc.) >> and other countries are forcing organizations to implement >> "accountability" measures. Audit logging (as well as authentication > and >> authorization) is a critical element of these accountability measures. >> Seems to me that this WG might want to step up and standardize the way >> this gets handled. If nothing else, it could give the WG a little more >> focus. > > That information _may_ be placed in syslog messages but the scope > of what you're talking about includes much more than just sending > data between daemons. For now, we have other more basic problems > to solve and as tempting as it is to try and solve these too, it > would just be a distraction and stop the WG from achieving what > it needs to achieve. > > Darren > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 18 04:01:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed27W-0007Ng-L8; Fri, 18 Nov 2005 04:01:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed27V-0007Lm-4I for syslog@megatron.ietf.org; Fri, 18 Nov 2005 04:01:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02365 for ; Fri, 18 Nov 2005 04:00:45 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed2PI-0007gY-Lp for syslog@ietf.org; Fri, 18 Nov 2005 04:19:45 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 45DA09C00C; Fri, 18 Nov 2005 10:08:54 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28577-04; Fri, 18 Nov 2005 10:08:47 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 6CE849C00B; Fri, 18 Nov 2005 10:08:47 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] formal Consultation prior to concluding the working group MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2005 10:00:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3E75@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] formal Consultation prior to concluding the working group Thread-Index: AcXrtz/FQD0PhQ+MQKG4Tdfa7IcGDQAWPdmw From: "Rainer Gerhards" To: , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Content-Transfer-Encoding: quoted-printable Cc: housley@vigilsec.com, Darren Reed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sam & WG: This is a long mail. It is both my answer to Sam's formal request for input on the future of the WG as well my suggestion for rechartering and mile stones. I consider it to be important. I know that reading long mails sometimes is annoying. I also know that people (including me) tend to not read long mails in detail. However, I have taken considerable effort in creating it and would appreciate if it were actually read thouroughly. I am telling this bluntly because out of past experience I know that postings, especially larger ones, are not always handled properly (which might be one of the causes for our current dilemma). I think it is unavoidable to sometimes post a longer message. My proposal in regard to the charter is based on the meeting minutes and the discussion with Darren and Chris on this list (sorry, nobody else is discussing...). The "list consensus" (that is between Darren, Chris and me ;)) seems to be - syslog-protocol in its current form is objected because we fear it won't be implemented (though we don't have any=20 "hard facts" on that) - syslog is important and it should be standardized - it is better to do small steps than a single big one - having a layered approach for syslog (with transport mappings, protocol description and application-layer add-ons) seems to be benefitial - in order to gain acceptance, the protocol format document should be backwards compatible to existing syslogds - *once* we have achieved creating initial transport mappings and format specification, *then* we can look at things like structured data - a secure transport is needed (no consensus so far on SSL/TLS, SSH or whatever else) It is questionable if there is consensus on the following (though I wouldn't outrule it): - plain tcp syslog as currently being widely implemented and deployed should no longer be ignored by the WG These bullet points could probably be used to create a new charter. The main issue they boil down to is that whatever we do should not break existing receivers. There are some subleties involved with that. Syslog-protocol-15 solved them by deliberately changing the header so that a previous syslogd would not try to interpret it. This tool has been rejected and is no loger available. On closer look at existing code bases, I also have to admit that it might not have worked as designed. We now head toward keeping the header and looking like old-style syslog. So we need to be very careful that we do not break existing, deployed technology. I would like to outline a few of the issues (those I know out of my head), so that they can become part of our decision process. This list is not necessarily complete. - PRI MUST stay as it is currently defined. Adding more facilities causes considerable problems to many existing/widely-deployed syslogd implementation. - MSG MUST NOT allow NUL octets. This would breaks almost all syslogd implementations I know (because of the C/C++ string terminator) - it is questionable if UTF-8 can be used inside MSG, because many syslogds do not expect this neither can they handle it. UTF-7 might be an alternative (this is no proposal!). - in real-world syslogds, the US-ASCII requirement specified in RFC 3164 for MSG is NOT honored, not even known. Actually, I have not yet seen a single code base that restricts the character set in MSG. In Asia, syslog messages routinely contain DBCS character sets, like shift-JIS or EUC. This might imply that NUL characters are currently part of MSG, even though I have not yet noticed it. In Europe, MSG routinely contains octets with values between 128 and 255. So if we want to keep consistent with deployed syslog technology, we can not place any further requirement on MSG as that it might contain any octet value (I know this contradicts with the non-NUL requirement I made immediately above - this would be a topic for discussion). Most importantly, we MUST not require anything in regard to internationalization (this might be the topic of a follow-up, small, other document). - while real-world syslogds default to 1K message size, they can be configured to larger message sizes. This ability MUST be retained in a spec. - real-world syslogds already accept and emit FQDNs (as well as hostname-only) in the HOSTNAME field. - BUT: not all real-world syslogds support HOSTNAME at all. If we standardize a header, we must provide instructions on how to detect if there is a HOSTNAME in the message or not (it's doable, I and=20 others have done it in our implementations). It remains as a problem that an older syslogd not expecting a HOSTNAME will misinterpret it as a TAG. This can cause major problems in existing analysis scripts. That problem can probably only be solved by adding an additional hostname field inside the current MSG part. - a similar issue exists for the TIMESTAMP. Many existing syslogds check if the punctuation inside the TIMESTAMP matches their expectations. If so, it is accepted as valid TIMESTAMP, if not it isn't. So we can NOT create the much asked-for TIMESTAMP with year (and timezone) in it without loosing backwards compatibility=20 (note that it does NOT help to keep the current format and just add the year). Again, the only workable solution might be to add an extra TIMESTAMP field inside MSG. In my point of view, the thoughest issues are HOSTNAME and TIMESTAMP. If we relax the backwards compatibility needs and accept that an older syslogd misinterprets the header, we could solve them. Please keep in mind that with current technology header misintrepretation is a common problem, so we would not add any new evil. But it will definitely be a big issue for sites in the migration process. Currently, a site typically goes for a single syslog implementation and has put workarounds for the few non-conforming senders. Similar workarounds would be needed during a migration. This might be an acceptable extra effort - or not (to be discussed). Duplicating TIMESTAMP and HEADER comes at the cost of being chatty and I also think it looks silly and - by doing so - discourages their acceptance. If we discuss this issue seriously, we might also come up with another solution. If we re-charter, the charter should specify the priority in regard to backwards compatibility, so that we can base the needed though decision on charter priorities. On the issue whether we should standardize the header or just recommend it, I am of the strong position that we must standardize it. If we just recommend things, we can simply promote RFC 3164 to standard, because it already tells us that a syslog message is a syslog message no matter what it contains. The only requirement it must fullfil is that it is sent to a syslog listener. I do not find this definition useful. But if we keep with that spirit, there is no need for any further work. Just recommending a new header, probably one that does not solve the backward-compatibility issues that raised this discussion, does NOT do any good. It just creates a fake impression of having solved the problem while in practice it complicates things (old receivers will still not be able to understand the format and would not have a proper way of handling it). So if we take that route, I suggest we conclude this WG because it has no power to find useful solutions above what is already published. Besides these comments in regard to the charter, I am still deeply concerned about the ability of this WG to do any representative work at all. From those voices in the meeting minutes, only Darren has said *anything* at all in the current discussion. I think I am not exaggerating if I say that this discussion is extremely important for the work and future of the WG. Still no voices heared. How can we achieve any stable consensus if nobody cares? I don't find it productive if a handful people ew discuss about a draft, then go to the meeting, where another handful few object it. I find some valuable wisdom in the outcome of the last meeting. This, together with the need to standardize logging, is my primary motivation for carrying on. However, it is neither productive, nor justifiable, to continue working on the issue if there is such a large des-interest in the WG. Eventually, the IETF is the wrong forum for syslog standardization. For example, there already is a industry-standard on plain tcp syslog, which is supported by most major implementations. This is in place for several years now. If the current rate of feedback continues, I strongly suggest to conclude this WG. This is independent from the point if we could find another charter. I simply do not find it acceptable to put any more considerable effort into an activity whose outcome has prooven to be very questionable. When thinking about this, please also keep in mind that the current state of charter discussion roughly resembles what was discussed for syslog-protocol in 2003 and the begining of 2004 (see mailing list archive if you do not believe me - I already posted some pointers;)). A compromise might be to re-charter with a *very* restrictive charter and *very challenging* mile stones and conclude the WG as soon as the first milestone is missed. In my point of view, that first mile stone should be for an I-D specifying the protocol format (together with Anton's -transport-UDP draft). I propose we do not start any new work but change syslog-protocol in the spirit of the new charter. What should be reached is - achived consensus (both on-list AND off-list!) - successful last call - AD review - AD acceptance of publishing this I-D This mile stone should be reached at the next IETF meeting. The WG should meet at it. The AD should participate in that meeting and decide on concluding the WG or moving the draft forward for publishing shortly after the meeting. I know this milestone is challenging. Anyhow, it should be doable (thinking about all the discussions we had). If we really need to sort out just minor issues, we can handle it. I object any later mile stone. The reason is that we would invest too much effort into something that still is very questionable. We have been working on this (if I look at the pre-protocol discussion on -sign and -interntional) since roughly 3 years now. If we can't finish it in another 5 months, we have no right to remain active. Of course, that was the compromise suggestion. I am still thinking it might be more appropriate to conclude the WG immediately. As a side-note to Sam, I am not sure if the inability to specify Unicode inside MSG (outlined in my bullet points at the top) would prevent an I-D from becoming a standards-track RFC. If so, we can not recharter in the spirit of the last meeting. I this case, I recommend immediate termination of the WG. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > Sent: Thursday, November 17, 2005 9:40 PM > To: syslog@ietf.org > Cc: hartmans-ietf@mit.edu; housley@vigilsec.com; Darren Reed > Subject: Re: [Syslog] formal Consultation prior to concluding=20 > the working group >=20 > Hi, >=20 > Apologies for the silence. I'm busy with the day job today=20 > and tomorrow. >=20 > Very briefly, I'd suggest that we can work towards a charter that=20 > formalizes syslog but does not break existing syslog recievers. Once=20 > there, we can add in the Structured Data parts that can be=20 > used for higher=20 > level functions such as signing the messages. >=20 > Does that approach make sense? If so, I can start working=20 > out a draft=20 > charter that says that we will do just that. >=20 > I would like to hear from more people on this. >=20 > Thanks, > Chris >=20 > On Thu, 17 Nov 2005, Sam Hartman wrote: >=20 > >>>>>> "Darren" =3D=3D Darren Reed writes: > > > > >> 2) Is there another charter under which the working group > > >> would better be able to make progress? > > > > Darren> I believe the answer to this is yes. > > > > Darren> There is very relevant work this group could do=20 > and should > > Darren> do. > > > > In that case I'd recommend that you see if you can get consensus on > > such a charter. > > > > --Sam > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 18 11:35:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9Cq-0003Bk-2G; Fri, 18 Nov 2005 11:35:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9Cn-0002vf-2z for syslog@megatron.ietf.org; Fri, 18 Nov 2005 11:35:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27550 for ; Fri, 18 Nov 2005 11:34:42 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9Ue-0005fi-Hk for syslog@ietf.org; Fri, 18 Nov 2005 11:53:45 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4C232E0075; Fri, 18 Nov 2005 11:35:07 -0500 (EST) To: "Rainer Gerhards" Subject: Re: [Syslog] formal Consultation prior to concluding the working group References: <577465F99B41C842AAFBE9ED71E70ABA0E3E75@grfint2.intern.adiscon.com> From: Sam Hartman Date: Fri, 18 Nov 2005 11:35:07 -0500 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3E75@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Fri, 18 Nov 2005 10:00:50 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: syslog@ietf.org, housley@vigilsec.com, Darren Reed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi. I did read your message in full and appreciate it greatly. I'd like to make a few points. The first is that if meetings aren't working for you and in particular if they produce different consensus that your list, don't meet. You don't need to meet. If you decide to ignore the input of the last meeting--particularly because the comments seem not to be appearing on the list--then you should make some effort to give participants who can be easily identified a heads up that the list failed to support the consensus of the meeting. However several things become harder if you don't meet. The one that I'm most worried about is making sure there are enough people in the WG who have agreed to write text and enough people in the WG who are reviewing text. If it's just three or four active people, you don't have a working group. I can ask about the internationalization issue. My suspicion is that no one will be happy but that we can make forward progress if that's the only issue. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 18 12:02:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9dM-0006zk-Ir; Fri, 18 Nov 2005 12:02:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9dH-0006ia-RS for syslog@megatron.ietf.org; Fri, 18 Nov 2005 12:02:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28900 for ; Fri, 18 Nov 2005 12:02:05 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9v9-0006Ms-FM for syslog@ietf.org; Fri, 18 Nov 2005 12:21:08 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 068279C00C; Fri, 18 Nov 2005 18:10:27 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29002-05; Fri, 18 Nov 2005 18:10:23 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 323139C00B; Fri, 18 Nov 2005 18:10:23 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] formal Consultation prior to concluding the working group MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2005 18:02:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3E90@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] formal Consultation prior to concluding the working group Thread-Index: AcXsYQUydziCZD2MR02K6DIPD6U4SQAADcVQ From: "Rainer Gerhards" To: "Sam Hartman" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, housley@vigilsec.com, Darren Reed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sam, > However several things become harder if you don't meet. The one that > I'm most worried about is making sure there are enough people in the > WG who have agreed to write text and enough people in the WG who are > reviewing text. If it's just three or four active people, you don't > have a working group. This is my primary concern at this time - and most probably the root cause of all the trouble. I do not know how to solve this. We've tried to promote more participation, but obviously failed at that... If we can not generate more interest, we can probably not succeed, no matter if we meet or not. If you have any idea on how we could change that, I would deeply appreciate it. But maybe we simply need to accept the fact that there is not sufficient interest in syslog to justify any efforts (I am saying this based on disappointment, but in order to face reality). Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 18 13:02:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAYu-0004ta-Is; Fri, 18 Nov 2005 13:02:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAYs-0004pX-KD for syslog@megatron.ietf.org; Fri, 18 Nov 2005 13:02:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02041 for ; Fri, 18 Nov 2005 13:01:35 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdAql-0007s4-OX for syslog@ietf.org; Fri, 18 Nov 2005 13:20:40 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 18 Nov 2005 10:02:01 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAII1N6u012913; Fri, 18 Nov 2005 10:01:57 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 13:01:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] formal Consultation prior to concluding the working group Date: Fri, 18 Nov 2005 13:01:36 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C282CA@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] formal Consultation prior to concluding the working group Thread-Index: AcXsYQUydziCZD2MR02K6DIPD6U4SQAADcVQAAGI1DA= From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , "Sam Hartman" X-OriginalArrivalTime: 18 Nov 2005 18:01:37.0817 (UTC) FILETIME=[1ED94090:01C5EC6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, housley@vigilsec.com, Darren Reed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer, Sam and all: I know that Cisco, for one, has great interest in this work. I agree WG = participation is weak, but I think a lot of people are lurking and only = voicing opinions when they see issues that really matter to them. Truth = is, a lot of the issues are probably not significant enough for people = to bother to voice preferences. But that does not mean that there is = lack of interest in a syslog standard, or that it is not important. =20 I have been involved in logging standardization (internal and public) = for 4 years now. And it is always hard to get people excited about = logging, even thought many people realize it is important. Very few = people specialize on logging problems or care to think about them for = more than 1 minute. So, I'd venture to say that what we observe in this = WG is not unique. Low participation, in this case, does not diminish the = value of the work produced by a few people who specialize on the = problem.=20 We just need a process that allows work to come to fruition. To this = end, I will try to propose very specific clarifications for charter next = week. Thanks, Anton.=20 =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Friday, November 18, 2005 12:02 PM > To: Sam Hartman > Cc: syslog@ietf.org; housley@vigilsec.com; Darren Reed > Subject: RE: [Syslog] formal Consultation prior to concluding=20 > the working group >=20 > Sam, >=20 > > However several things become harder if you don't meet. =20 > The one that=20 > > I'm most worried about is making sure there are enough=20 > people in the=20 > > WG who have agreed to write text and enough people in the=20 > WG who are=20 > > reviewing text. If it's just three or four active people,=20 > you don't=20 > > have a working group. >=20 > This is my primary concern at this time - and most probably=20 > the root cause of all the trouble. I do not know how to solve=20 > this. We've tried to promote more participation, but=20 > obviously failed at that... If we can not generate more=20 > interest, we can probably not succeed, no matter if we meet=20 > or not. If you have any idea on how we could change that, I=20 > would deeply appreciate it. But maybe we simply need to=20 > accept the fact that there is not sufficient interest in=20 > syslog to justify any efforts (I am saying this based on=20 > disappointment, but in order to face reality). >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 18 13:27:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAxB-0002Eg-PJ; Fri, 18 Nov 2005 13:27:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdAxA-000257-2K for syslog@megatron.ietf.org; Fri, 18 Nov 2005 13:27:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03149 for ; Fri, 18 Nov 2005 13:26:40 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdBF1-0008Qk-VT for syslog@ietf.org; Fri, 18 Nov 2005 13:45:45 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 18 Nov 2005 10:26:49 -0800 X-IronPort-AV: i="3.97,347,1125903600"; d="scan'208"; a="676619635:sNHT577575594" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAIIQGeq021657; Fri, 18 Nov 2005 10:26:47 -0800 (PST) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 10:26:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] formal Consultation prior to concluding the working group Date: Fri, 18 Nov 2005 10:26:38 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FBE9D683@xmb-sjc-236.amer.cisco.com> Thread-Topic: [Syslog] formal Consultation prior to concluding the working group Thread-Index: AcXsYQUydziCZD2MR02K6DIPD6U4SQAADcVQAAGI1DAAAUiW4A== From: "Alexander Clemm \(alex\)" To: "Anton Okmianski \(aokmians\)" , "Rainer Gerhards" , "Sam Hartman" X-OriginalArrivalTime: 18 Nov 2005 18:26:38.0934 (UTC) FILETIME=[9D958760:01C5EC6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, housley@vigilsec.com, Darren Reed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org To add on to Anton: I can confirm that from our side, at least, there is a lot of interest in this work, and we strongly believe that the working group should continue. As Anton mentions, we will be posting a consolidated response to many of the issues next week. =20 --- Alex =20 -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton Okmianski (aokmians) Sent: Friday, November 18, 2005 10:02 AM To: Rainer Gerhards; Sam Hartman Cc: syslog@ietf.org; housley@vigilsec.com; Darren Reed Subject: RE: [Syslog] formal Consultation prior to concluding the working group Rainer, Sam and all: I know that Cisco, for one, has great interest in this work. I agree WG participation is weak, but I think a lot of people are lurking and only voicing opinions when they see issues that really matter to them. Truth is, a lot of the issues are probably not significant enough for people to bother to voice preferences. But that does not mean that there is lack of interest in a syslog standard, or that it is not important. =20 I have been involved in logging standardization (internal and public) for 4 years now. And it is always hard to get people excited about logging, even thought many people realize it is important. Very few people specialize on logging problems or care to think about them for more than 1 minute. So, I'd venture to say that what we observe in this WG is not unique. Low participation, in this case, does not diminish the value of the work produced by a few people who specialize on the problem.=20 We just need a process that allows work to come to fruition. To this end, I will try to propose very specific clarifications for charter next week. Thanks, Anton.=20 =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Friday, November 18, 2005 12:02 PM > To: Sam Hartman > Cc: syslog@ietf.org; housley@vigilsec.com; Darren Reed > Subject: RE: [Syslog] formal Consultation prior to concluding the=20 > working group >=20 > Sam, >=20 > > However several things become harder if you don't meet. =20 > The one that > > I'm most worried about is making sure there are enough > people in the > > WG who have agreed to write text and enough people in the > WG who are > > reviewing text. If it's just three or four active people, > you don't > > have a working group. >=20 > This is my primary concern at this time - and most probably the root=20 > cause of all the trouble. I do not know how to solve this. We've tried > to promote more participation, but obviously failed at that... If we=20 > can not generate more interest, we can probably not succeed, no matter > if we meet or not. If you have any idea on how we could change that, I > would deeply appreciate it. But maybe we simply need to accept the=20 > fact that there is not sufficient interest in syslog to justify any=20 > efforts (I am saying this based on disappointment, but in order to=20 > face reality). >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 07:04:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeAPX-0004zL-4o; Mon, 21 Nov 2005 07:04:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeAPV-0004yo-O5 for syslog@megatron.ietf.org; Mon, 21 Nov 2005 07:04:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23672 for ; Mon, 21 Nov 2005 07:03:59 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeAhw-0000AN-AQ for syslog@ietf.org; Mon, 21 Nov 2005 07:23:41 -0500 Received: from pc6 (1Cust70.tnt14.lnd4.gbr.da.uu.net [62.188.143.70]) by blaster.systems.pipex.net (Postfix) with SMTP id 59A24E0001DA; Mon, 21 Nov 2005 12:04:19 +0000 (GMT) Message-ID: <00d801c5ee8b$10ea9100$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" References: <577465F99B41C842AAFBE9ED71E70ABA0E3E75@grfint2.intern.adiscon.com> Subject: Re: [Syslog] formal Consultation prior to concluding the working group Date: Mon, 21 Nov 2005 11:16:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris I am sitting here wondering what is going on. To quote from your session summary, "It became apparent that the proposed protocol was not going to be implemented in a widespread manner any time soon. The WG agreed that widespread adoption will probably only occur if we stick with the observed syslog protocol" This seems to say that the WG is the meeting and that what happens on the list is of lesser account. Your statement is probably correct but is so important that I think you MUST confirm this on the list, asking people whether or not they are going to implement the protocol as currently defined, inviting them to reply offlist (if they want to) and then telling us the results of this. Shutting down a WG on the basis of what persons unknown may or may not have said of which there is no record does not instill faith in the IETF process. The later minutes record as an issue "Will it be implemented? -- Angle brackets w/PRI inside or new " but give me no idea as to who if any gave what if any as answer to this question. (I continue to be surprised by IETF implementation reports that list just how many organisations, often ones I have not knowingly heard of, have implemented a particular protocol, which makes the work of the IETF worthwhile even when the 700lb gorillas are not taking part). The minutes further confuse me when they say Question to mailing list: should a new doc be generated to include angle bracket, new time stamp, and SD-ID I see no such question to the list nor do I understand what might be asked. I take angle bracket to be a reference to re-instating PRI in order to give greater backward compatability but what is "new time stamp" and so what about "SD-ID"? What are you on about? Rainer helps when he flags internationalisation (something the meeting seems not to have noticed), HOSTNAME and timestamp as the key issues but for me, places too much emphasis on backward compatability. Great to have, especially with an easy migration path to pastures new, but sometimes we do have to take a leap that leaves some behind; the issue is, how many? Back to implementations. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 07:56:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeBDL-0004bs-Rc; Mon, 21 Nov 2005 07:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeBDJ-0004ac-0Q for syslog@megatron.ietf.org; Mon, 21 Nov 2005 07:56:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27121 for ; Mon, 21 Nov 2005 07:55:26 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeBVj-0001pB-91 for syslog@ietf.org; Mon, 21 Nov 2005 08:15:09 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2005 04:55:53 -0800 X-IronPort-AV: i="3.97,356,1125903600"; d="scan'208"; a="232765418:sNHT27586658" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jALCtrCK002745; Mon, 21 Nov 2005 04:55:53 -0800 (PST) Date: Mon, 21 Nov 2005 04:55:53 -0800 (PST) From: Chris Lonvick To: Tom Petch Subject: Re: [Syslog] formal Consultation prior to concluding the working group In-Reply-To: <00d801c5ee8b$10ea9100$0601a8c0@pc6> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3E75@grfint2.intern.adiscon.com> <00d801c5ee8b$10ea9100$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 2.2 (++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: syslog@ietf.org, Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Tom, On Mon, 21 Nov 2005, Tom Petch wrote: > Chris > > I am sitting here wondering what is going on. To quote from your session > summary, > > "It became apparent that the proposed protocol was not > going to be implemented in a widespread manner any time soon. The WG > agreed that widespread adoption will probably only occur if we stick with > the observed syslog protocol" > > This seems to say that the WG is the meeting and that what happens on the list > is of lesser account. Your statement is probably correct but is so important > that I think you MUST confirm this on the list, asking people whether or not > they are going to implement the protocol as currently defined, inviting them to > reply offlist (if they want to) and then telling us the results of this. > Shutting down a WG on the basis of what persons unknown may or may not have said > of which there is no record does not instill faith in the IETF process. Please check the archives. I asked the list who would be implementing syslog-protocol during the last call. There were very few positive responses. (One came from a 700lb gorilla.) You are correct that the list has grown silent on the topic. I'm mostly caught up on the day stuff and I'll be active in the time Sam has given us to refocus. Everyone: Please get your comments in to the list on our rechartering discussion. > > The later minutes record as an issue > > "Will it be implemented? -- Angle brackets w/PRI inside or new " > > but give me no idea as to who if any gave what if any as answer to this > question. > > (I continue to be surprised by IETF implementation reports that list just how > many organisations, often ones I have not knowingly heard of, have implemented a > particular protocol, which makes the work of the IETF worthwhile even when the > 700lb gorillas are not taking part). > > The minutes further confuse me when they say > > Question to mailing list: should a new doc be generated to include angle > bracket, > new time stamp, and SD-ID > > I see no such question to the list nor do I understand what might be asked. I > take angle bracket to be a reference to re-instating PRI in order to give > greater backward compatability but what is "new time stamp" and so what about > "SD-ID"? What are you on about? That was me saying that I'd bring this up to the mailing list. I'm getting ready to do that now. The "new time stamp" and the "SD-ID"s are the good things that we have gotten acceptance upon in Rainer's syslog-protocol ID. We also have acceptance in that ID that the hostname should be replaced by the FQDN. > > Rainer helps when he flags internationalisation (something the meeting seems not > to have noticed), HOSTNAME and timestamp as the key issues but for me, places > too much emphasis on backward compatability. Great to have, especially with an > easy migration path to pastures new, but sometimes we do have to take a leap > that leaves some behind; the issue is, how many? Back to implementations. I will be asking for consensus on these issues so we can recharter and refocus. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 14:12:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeH5H-0002GG-R4; Mon, 21 Nov 2005 14:12:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeH5F-0002G8-JN for syslog@megatron.ietf.org; Mon, 21 Nov 2005 14:12:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25007 for ; Mon, 21 Nov 2005 14:11:30 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeHNk-0004wh-Gx for syslog@ietf.org; Mon, 21 Nov 2005 14:31:16 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2005 11:12:00 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jALJBxCK012118 for ; Mon, 21 Nov 2005 11:11:59 -0800 (PST) Date: Mon, 21 Nov 2005 11:11:59 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Subject: [Syslog] New direction and proposed charter X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Folks, I'd like for us to come to closure on some things. I'm going to be a bit direct on these questions so we can focus quicker. We really need for people to send in responses to see who's listening and involved. >From the meeting, it sounds like we will get many more implementations if we continue to use ... at the start of syslog messages. This will allow current receivers to continue to receive messages and put them in the right bins. Does anyone disagree with this? The WG has agreed to use the timestamp Rainer has in the current syslog-protocol. Using the FQDN and numeric notations for IPv4 and IPv6 addresses has been agreed to. Putting in the Structured Data still seems like a great evolutionary step for syslog. I'd like to see that go into the new syslog-protocol. Does anyone disagree with this? Should we continue to have the MSGID in the header, or should that become an SD-ID element? We've had slow-downs in our prior discussions about truncation and message length. To complete this work without revisiting those discussions, and in the spirit of backwards compliance with traditional syslog, I propose that we accept the length as Rainer has proposed in syslog-protocol, and disallow any device to truncate the messages. At some future time, someone can augment the syslog-protocol standard and define a mechanism and signalling that will allow truncation. Does anyone disagree with this? Encoding has been discussed and we have agreed upon US-ASCII and UTF-8 in appropriate places. Could we add a language tag as an element in an SD-ID to indicate the language of the MSG? We need a version. Should that be in the header (after ), or as an element in an SD-ID? One possibility would be to assemble a syslog message as: TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG If we can agree to this then I suspect that we can have a working document within Rainer's timeframe. I'll propose the following charter to keep us focused. -------- Proposed Charter -------------- Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in RFC 3164. The goal of this working group is to address the security and integrity problems of the existing syslog mechanism while not breaking backwards compatibility. The most obvious problems that need to be addressed in the syslog protocol are the timestamp, which has not formally included a means to indicate the year, and the identification of the source which has been a hostname without a qualified domain name. Additionally, a version, some type of message indicator, and a means to convey structured data will be included in the protocol. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. - A standard will be produced that formally documents the syslog protocol. A mechanism will also be defined in this specification that will provide a means to convey structured data. - A standard will be produced that documents the UDP transport for syslog. - A standard will be produced that documents a mechanism to sign syslog messages to provide integrity checking and source authentication. - A MIB definition for syslog will be produced. ------------------------------------------- PLEASE review this and respond. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 14:50:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeHgT-0002MG-FZ; Mon, 21 Nov 2005 14:50:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeHgS-0002M8-44 for syslog@megatron.ietf.org; Mon, 21 Nov 2005 14:50:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00468 for ; Mon, 21 Nov 2005 14:49:57 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeHyx-0006XJ-6b for syslog@ietf.org; Mon, 21 Nov 2005 15:09:44 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2005 11:50:24 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jALJndf4004492 for ; Mon, 21 Nov 2005 11:50:22 -0800 (PST) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 11:49:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Mon, 21 Nov 2005 11:49:51 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FBE9DAFA@xmb-sjc-236.amer.cisco.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu0Dhk1cG4enAnTqGgNu2JZ0COcAAAtywA From: "Alexander Clemm \(alex\)" To: "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 21 Nov 2005 19:49:52.0481 (UTC) FILETIME=[BD359510:01C5EED4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hello Chris, your proposal sounds good. I don't disagree with any of your items (which means, I agree with alll of them:-) =20 Concerning the particular questions that you raise: =20 "Should we continue to have the MSGID in the header, or should that become=20 an SD-ID element?" =20 I believe it will be preferrable to have it in the header, not require an SD-ID for that. =20 "Could we add a language tag as an element in an=20 SD-ID to indicate the language of the MSG?" I believe SD-ID would be the right place to put this one. A corresponding SDE could be defined at a later point in time. =20 "We need a version. Should that be in the header (after ), or as an=20 element in an SD-ID?" I believe it is preferrable to have it in the header, not require an SD-ID for that. --- Alex -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick (clonvick) Sent: Monday, November 21, 2005 11:12 AM To: syslog@ietf.org Subject: [Syslog] New direction and proposed charter Hi Folks, I'd like for us to come to closure on some things. I'm going to be a bit direct on these questions so we can focus quicker. We really need for people to send in responses to see who's listening and involved. >From the meeting, it sounds like we will get many more implementations=20 >if we continue to use ... at the start of syslog messages. This will allow current receivers to continue to receive messages and put them in the right bins. Does anyone disagree with this? The WG has agreed to use the timestamp Rainer has in the current syslog-protocol. Using the FQDN and numeric notations for IPv4 and IPv6 addresses has been=20 agreed to. Putting in the Structured Data still seems like a great evolutionary step=20 for syslog. I'd like to see that go into the new syslog-protocol. Does anyone disagree with this? Should we continue to have the MSGID in the header, or should that become=20 an SD-ID element? We've had slow-downs in our prior discussions about truncation and message=20 length. To complete this work without revisiting those discussions, and in the spirit of backwards compliance with traditional syslog, I propose that we accept the length as Rainer has proposed in syslog-protocol, and disallow any device to truncate the messages. At some future time,=20 someone can augment the syslog-protocol standard and define a mechanism=20 and signalling that will allow truncation. Does anyone disagree with=20 this? Encoding has been discussed and we have agreed upon US-ASCII and UTF-8 in=20 appropriate places. Could we add a language tag as an element in an=20 SD-ID to indicate the language of the MSG? We need a version. Should that be in the header (after ), or as an element in an SD-ID? One possibility would be to assemble a syslog message as: TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG If we can agree to this then I suspect that we can have a working document=20 within Rainer's timeframe. I'll propose the following charter to keep us=20 focused. -------- Proposed Charter -------------- Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in RFC 3164. The goal of this working group is to address the security and integrity problems of the existing syslog mechanism while not breaking backwards compatibility. The most obvious problems that need to be addressed in the syslog protocol are the timestamp, which has not formally included a means to indicate the year, and the identification of the source which has been a hostname without a qualified domain name. Additionally, a version, some type of message indicator, and a=20 means to convey structured data will be included in the protocol. syslog has traditionally been transported over UDP and this WG has=20 already defined RFC 3195 for the reliable transport for the syslog=20 messages. The WG will separate the UDP transport from the protocol so=20 that others may define additional transports in the future. - A standard will be produced that formally documents the syslog protocol. A mechanism will also be defined in this specification that will provide a means to convey structured data. - A standard will be produced that documents the UDP transport for syslog. - A standard will be produced that documents a mechanism to sign syslog messages to provide integrity checking and source authentication. - A MIB definition for syslog will be produced. ------------------------------------------- PLEASE review this and respond. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 14:51:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeHgx-0002Rl-Lx; Mon, 21 Nov 2005 14:51:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeHgw-0002Re-FC for syslog@megatron.ietf.org; Mon, 21 Nov 2005 14:51:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00583 for ; Mon, 21 Nov 2005 14:50:27 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeHzQ-0006ZZ-5A for syslog@ietf.org; Mon, 21 Nov 2005 15:10:14 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 21 Nov 2005 11:50:53 -0800 X-IronPort-AV: i="3.97,357,1125903600"; d="txt'?scan'208"; a="368331096:sNHT36546180" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jALJokeW005060 for ; Mon, 21 Nov 2005 11:50:51 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 14:50:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5EED4.CE200B58" Subject: RE: [Syslog] New direction and proposed charter Date: Mon, 21 Nov 2005 14:50:20 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C2884D@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: yes Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu0Duz4iKjuWHPQ3KUUvwArcnbpwAAe1mQ From: "Anton Okmianski \(aokmians\)" To: "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 21 Nov 2005 19:50:20.0974 (UTC) FILETIME=[CE3144E0:01C5EED4] X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EED4.CE200B58 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chris and all: So, to sum up the only change to the syslog-protocol that is proposed is = adding field for backwards compatibility and removing truncation. = Maybe a few other minor changes needed to incorporate the field = back in, like eliminating redundant SEVERITY field and deciding on = whether FACILITY becomes EXTENDED_FACILITY or gets eliminated. =20 I drafted a few statements on possible charter, which are pretty much = aligned with what you described. See attached. =20 So, I agree with the charter you proposed and think we are very close to = fulfilling it.=20 Answers to specific questions below.=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris=20 > Lonvick (clonvick) > Sent: Monday, November 21, 2005 2:12 PM > To: syslog@ietf.org > Subject: [Syslog] New direction and proposed charter >=20 > Hi Folks, >=20 > I'd like for us to come to closure on some things. I'm going=20 > to be a bit direct on these questions so we can focus=20 > quicker. We really need for people to send in responses to=20 > see who's listening and involved. >=20 >=20 >=20 > >From the meeting, it sounds like we will get many more=20 > implementations=20 > >if > we continue to use ... at the start of syslog messages. =20 > This will allow current receivers to continue to receive=20 > messages and put them in the right bins. Does anyone=20 > disagree with this? >=20 >=20 > The WG has agreed to use the timestamp Rainer has in the=20 > current syslog-protocol. >=20 >=20 > Using the FQDN and numeric notations for IPv4 and IPv6=20 > addresses has been=20 > agreed to. >=20 >=20 > Putting in the Structured Data still seems like a great=20 > evolutionary step=20 > for syslog. I'd like to see that go into the new=20 > syslog-protocol. Does=20 > anyone disagree with this? No disagreement - violent support.=20 > Should we continue to have the MSGID in the header, or should=20 > that become=20 > an SD-ID element? Support for separate field for MSGID as defined now.=20 > We've had slow-downs in our prior discussions about=20 > truncation and message=20 > length. To complete this work without revisiting those=20 > discussions, and=20 > in the spirit of backwards compliance with traditional=20 > syslog, I propose=20 > that we accept the length as Rainer has proposed in=20 > syslog-protocol, and=20 > disallow any device to truncate the messages. At some future time,=20 > someone can augment the syslog-protocol standard and define a=20 > mechanism=20 > and signalling that will allow truncation. Does anyone disagree with=20 > this? I agree with this approach. Something like a message signature, for = example, can indicate message integrity, including the fact that message = was truncated. =20 > Encoding has been discussed and we have agreed upon US-ASCII=20 > and UTF-8 in=20 > appropriate places. Could we add a language tag as an element in an=20 > SD-ID to indicate the language of the MSG? No problem with that. However, if we get into a rat-hole regarding = various standard tags, we could easily strip that whole setion into a = separate document. I would hope we could standardize some very essential = fields in syslog-protocol, as current draft attempted to do. =20 > We need a version. Should that be in the header (after=20 > ), or as an=20 > element in an SD-ID? >=20 >=20 > One possibility would be to assemble a syslog message as: >=20 > TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG This works for me. But if we agree that we are breaking timestamp = compatability anyway, I would suggest the version be put as a first = field. The key factors for me would ease of parsing and eliminating = false-positives. =20 > If we can agree to this then I suspect that we can have a=20 > working document=20 > within Rainer's timeframe. =20 What is timeframe? Thanks, Anton.=20 > I'll propose the following=20 > charter to keep us=20 > focused. >=20 > -------- Proposed Charter -------------- >=20 > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it > has some known security problems which were documented in RFC 3164. >=20 > The goal of this working group is to address the security and > integrity problems of the existing syslog mechanism while not breaking > backwards compatibility. The most obvious problems that need to be > addressed in the syslog protocol are the timestamp, which has not > formally included a means to indicate the year, and the identification > of the source which has been a hostname without a qualified domain > name. Additionally, a version, some type of message indicator, and a=20 > means to convey structured data will be included in the protocol. >=20 > syslog has traditionally been transported over UDP and this WG has=20 > already defined RFC 3195 for the reliable transport for the syslog=20 > messages. The WG will separate the UDP transport from the=20 > protocol so=20 > that others may define additional transports in the future. >=20 > - A standard will be produced that formally documents the syslog > protocol. A mechanism will also be defined in this specification > that will provide a means to convey structured data. >=20 > - A standard will be produced that documents the UDP transport for > syslog. >=20 > - A standard will be produced that documents a mechanism to sign > syslog messages to provide integrity checking and source > authentication. >=20 > - A MIB definition for syslog will be produced. >=20 > ------------------------------------------- >=20 >=20 > PLEASE review this and respond. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 ------_=_NextPart_001_01C5EED4.CE200B58 Content-Type: text/plain; name="syslog-protocol-charter.txt" Content-Description: syslog-protocol-charter.txt Content-Disposition: attachment; filename="syslog-protocol-charter.txt" Content-Transfer-Encoding: base64 VGhlIGZvbGxvd2luZyBjbGFyaWZpY2F0aW9ucyB0byB0aGUgV0cgY2hhcnRlciBhcmUgcHJvcG9z ZWQ6DQoNCjEuIFN5c2xvZy1wcm90b2NvbCBNVVNUIGJlIGEgc3RhbmRhcmQtdHJhY2sgZG9jdW1l bnQuICBJdCB3aWxsIHN0YW5kYXJkaXplIGEgZm9ybWF0IGZvciBzeXNsb2cgbWVzc2FnZXMsIHdp dGggdGhlIGdvYWwgb2YgbWFpbnRhaW5pbmcgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIGV4aXN0aW5n IHN5c2xvZyByZWNlaXZlcnMgYXMgbXVjaCBhcyBwb3NzaWJsZSwgYnVpbGRpbmcgb24gc3lzbG9n IGFzIGRvY3VtZW50ZWQgaW4gUkZDIDMxNjQsIHdpdGggYSBudW1iZXIgb2YgZW5oYW5jZW1lbnRz IGFuZCBtb2RpZmljYXRpb25zIHRvIGFkZHJlc3MgbmVlZGVkIGltcHJvdmVtZW50cy4NCg0KMi4g U3lzbG9nLXByb3RvY29sIE1VU1QgcHJlc2VydmUgdGhlIFBSSSBmaWVsZCwgYWxsb3dpbmcgb2xk LXN0eWxlIHJlY2VpdmVycyB0byBwcm9jZXNzIHRoZSBtZXNzYWdlIGJhc2VkIG9uIHNldmVyaXR5 IGFuZCBmYWNpbGl0eSBmaWVsZHMgY29udGFpbmVkIHdpdGhpbiB0aGF0IGZpZWxkLg0KDQozLiBT eXNsb2ctcHJvdG9jb2wgbWVzc2FnZSBmb3JtYXQgTVVTVCBzdXBwb3J0IHZlcnNpb25pbmcsIHdo aWNoIGFsbG93cyByZWNlaXZlciB0byBkZXRlcm1pbmUgdGhlIFJGQyB3aXRoIHdoaWNoIHRoZSBt ZXNzYWdlIGNsYWltcyB0byBiZSBjb21wbGFpbnQuDQoNCjQuIFN5c2xvZy1wcm90b2NvbCBNVVNU IGhhbmRsZSBpbnRlcm5hdGlvbmFsaXphdGlvbiAoVVRGLTgpLiAgSXQgaXMgb2sgaWYgb2xkLXN0 eWxlIHJlY2VpdmVycyBjYW4ndCByZWNlaXZlIFVURi04IG1lc3NhZ2VzLiANCg0KNS4gU3lzbG9n LXByb3RvY29sIE1VU1QgZGVmaW5lIGFiaWxpdHkgdG8gcGFzcyBzdHJ1Y3R1cmVkIGNvbnRlbnQg KGFrYSB0YWdzKS4NCg0KNi4gU3lzbG9nLXByb3RvY29sIE1VU1QgZGVmaW5lIGFiaWxpdHkgdG8g cGFzcyBzdGFuZGFyZGl6ZWQgdGltZSBzdGFtcCB3aXRoIHllYXIsIHRpbWUgb2Zmc2V0IGFuZCBv cHRpb25hbGx5IGZyYWN0aW9uIG9mIHNlY29uZCByZXNvbHV0aW9uLg0KDQo3LiBTeXNsb2ctcHJv dG9jb2wgTVVTVCBzZXBhcmF0aW9uIGRlZmluaXRpb24gb2YgbWVzc2FnZSBjb250ZW50IGRlZmlu aXRpb24gZnJvbSB0cmFuc3BvcnQgKGFzIGRlZmluZWQgaW4gY3VycmVudCBkcmFmdHMpLg0KDQo4 LiBBIGJhc2ljIFVEUC1iYXNlZCB0cmFuc3BvcnQgbWFwcGluZyBNVVNUIGJlIGRlZmluZWQgZm9y IHN5c2xvZy1wcm90b2NvbC4NCg0KOS4gQSBiYXNpYyBhbmQgc2VjdXJlIFRDUC1iYXNlZCB0cmFu c3BvcnQgbWFwcGluZyBNVVNUIGJlIGRlZmluZWQgZm9yIHN5c2xvZy1wcm90b2NvbCBiYXNlZCBv biBTU0wgb3IgU1NILg0KDQoxMC4gU3lzbG9nIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBpZGVudGlm aWNhdGlvbiBvZiBvcmlnaW5hdGluZyBIT1NUIGZvciBJUHY0IGFzIHdlbGwgYXMgSVB2Ni4gSWRl bnRpZmljYXRpb24gdXNpbmcgRlFETiBvciBob3N0bmFtZSBtdXN0IGFsc28gYmUgc3VwcG9ydGVk Lg0KDQoxMS4gU3lzbG9nLXByb3RvY29sIE1VU1Qgc3VwcG9ydCBtZXNzYWdlIElEIGlkZW50aWZp Y2F0aW9uLiBTeXNsb2cgcHJvdG9jb2wgU0hPVUxEIHN1cHBvcnQgYXBwbGljYXRpb24gYW5kIHBy b2Nlc3MgaWRlbnRpZmljYXRpb24uDQoNCjEyLiBTeXNsb2ctcHJvdG9jb2wgU0hPVUxEIHByb3Zp ZGUgc3VwcG9ydCBmb3IgZXh0ZW5kZWQgZmFjaWxpdGllcyB3aGljaCBnbyBiZXlvbmQgbG9jYWwg ZmFjaWxpdGllcyBkZWZpbmVkIGJ5IFJGQyAzMTY0Lg0K ------_=_NextPart_001_01C5EED4.CE200B58 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ------_=_NextPart_001_01C5EED4.CE200B58-- From syslog-bounces@lists.ietf.org Mon Nov 21 14:56:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeHmU-0003rX-A7; Mon, 21 Nov 2005 14:56:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeHmT-0003rQ-31 for syslog@megatron.ietf.org; Mon, 21 Nov 2005 14:56:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01534 for ; Mon, 21 Nov 2005 14:56:09 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeI4x-0006oa-MB for syslog@ietf.org; Mon, 21 Nov 2005 15:15:56 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2005 11:56:36 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jALJtwsY024586 for ; Mon, 21 Nov 2005 11:56:33 -0800 (PST) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 11:56:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Mon, 21 Nov 2005 11:56:15 -0800 Message-ID: Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu0Dhq9svvjD/bSre26hwjFQXXNQAAXyzg From: "Steve Chang \(schang99\)" To: X-OriginalArrivalTime: 21 Nov 2005 19:56:17.0324 (UTC) FILETIME=[A297F6C0:01C5EED5] X-Spam-Score: 0.9 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Please see my inline comments. > -----Original Message----- > From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Chris Lonvick (clonvick) > Sent: Monday, November 21, 2005 11:12 AM > To: syslog@ietf.org > Subject: [Syslog] New direction and proposed charter >=20 > Hi Folks, >=20 > I'd like for us to come to closure on some things. I'm going to be a bit > direct on these questions so we can focus quicker. We really need for > people to send in responses to see who's listening and involved. >=20 >=20 >=20 > >From the meeting, it sounds like we will get many more implementations if > we continue to use ... at the start of syslog messages. This will > allow current receivers to continue to receive messages and put them in > the right bins. Does anyone disagree with this? >=20 I agree. With retained, our server code will not be broken. And it can serve as message delimiter so we can pack as many short messages before placing it to transport layer delivery. >=20 > The WG has agreed to use the timestamp Rainer has in the current > syslog-protocol. >=20 >=20 > Using the FQDN and numeric notations for IPv4 and IPv6 addresses has been > agreed to. >=20 >=20 > Putting in the Structured Data still seems like a great evolutionary step > for syslog. I'd like to see that go into the new syslog-protocol. Does > anyone disagree with this? >=20 >=20 > Should we continue to have the MSGID in the header, or should that become > an SD-ID element? >=20 I support keeping it in the HEADER since MSGID is a main key to identifying=20 the message, it should not be buried too deep.=20 Same argument goes to APPNAME. I suggest keep it in the HEADER part. Without the APPNAME in the header, one important piece of information will have to find its place in the SD section and make it less obvious to identify uniquely the message since the MSGID field alone can be a vendor specific thing and may not be unique enough for our receiver to differentiate messages.=20 >=20 > We've had slow-downs in our prior discussions about truncation and message > length. To complete this work without revisiting those discussions, and > in the spirit of backwards compliance with traditional syslog, I propose > that we accept the length as Rainer has proposed in syslog-protocol, and > disallow any device to truncate the messages. At some future time, > someone can augment the syslog-protocol standard and define a mechanism > and signalling that will allow truncation. Does anyone disagree with > this? >=20 >=20 > Encoding has been discussed and we have agreed upon US-ASCII and UTF-8 in > appropriate places. Could we add a language tag as an element in an > SD-ID to indicate the language of the MSG? >=20 >=20 > We need a version. Should that be in the header (after ), or as an > element in an SD-ID? >=20 VERSION is here to help differentiate the format changes. So, I would suggest place it immediately after field. >=20 > One possibility would be to assemble a syslog message as: >=20 > TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG With the APPNAME and VERSION I mentioned above, the format will become: VERSION TIMESTAMP FQDN APPNAME MSGID [SD-ID]s MSG Of course, let's hear opinions from others. >=20 >=20 >=20 > If we can agree to this then I suspect that we can have a working document > within Rainer's timeframe. I'll propose the following charter to keep us > focused. >=20 > -------- Proposed Charter -------------- >=20 > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it > has some known security problems which were documented in RFC 3164. >=20 > The goal of this working group is to address the security and > integrity problems of the existing syslog mechanism while not breaking > backwards compatibility. The most obvious problems that need to be > addressed in the syslog protocol are the timestamp, which has not > formally included a means to indicate the year, and the identification > of the source which has been a hostname without a qualified domain > name. Additionally, a version, some type of message indicator, and a > means to convey structured data will be included in the protocol. >=20 > syslog has traditionally been transported over UDP and this WG has > already defined RFC 3195 for the reliable transport for the syslog > messages. The WG will separate the UDP transport from the protocol so > that others may define additional transports in the future. >=20 > - A standard will be produced that formally documents the syslog > protocol. A mechanism will also be defined in this specification > that will provide a means to convey structured data. >=20 > - A standard will be produced that documents the UDP transport for > syslog. >=20 > - A standard will be produced that documents a mechanism to sign > syslog messages to provide integrity checking and source > authentication. >=20 > - A MIB definition for syslog will be produced. >=20 > ------------------------------------------- >=20 >=20 > PLEASE review this and respond. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 15:12:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeI1w-0000wM-Kl; Mon, 21 Nov 2005 15:12:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeI1u-0000wE-KV for syslog@megatron.ietf.org; Mon, 21 Nov 2005 15:12:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03486 for ; Mon, 21 Nov 2005 15:12:09 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeIKQ-0007Pq-AZ for syslog@ietf.org; Mon, 21 Nov 2005 15:31:55 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 501279C00C; Mon, 21 Nov 2005 21:20:33 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31743-05; Mon, 21 Nov 2005 21:20:28 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 82D099C00B; Mon, 21 Nov 2005 21:20:28 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2005 21:12:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EC4@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu0DHp+Cdt1hggSCaNaodAhq5X9QABNcfA From: "Rainer Gerhards" To: "Chris Lonvick" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris & WG=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > Sent: Monday, November 21, 2005 8:12 PM > To: syslog@ietf.org > Subject: [Syslog] New direction and proposed charter >=20 > Hi Folks, >=20 > I'd like for us to come to closure on some things. I'm going=20 > to be a bit=20 > direct on these questions so we can focus quicker. We really=20 > need for=20 > people to send in responses to see who's listening and involved. I am also quite directly... >=20 >=20 >=20 > >From the meeting, it sounds like we will get many more=20 > implementations if=20 > we continue to use ... at the start of syslog messages. =20 ############################################################## > This will=20 > allow current receivers to continue to receive messages and=20 > put them in=20 > the right bins. =20 ############################################################## > Does anyone disagree with this? Yes, disagreement here. For the reasons outline in mail from Friday, this is *NOT* true. Existing syslog receivers will be broken if we just stick with and do not adjust the other header fields. Of course, it is doable. For details, review http://www.mail-archive.com/syslog%40lists.ietf.org/msg00121.html=20 (around the middle of the post). > The WG has agreed to use the timestamp Rainer has in the current=20 > syslog-protocol. >=20 See implications noted in previous mail quoted above. >=20 > Using the FQDN and numeric notations for IPv4 and IPv6=20 > addresses has been=20 > agreed to. >=20 See implications noted in previous mail quoted above. >=20 > Putting in the Structured Data still seems like a great=20 > evolutionary step=20 > for syslog. I'd like to see that go into the new=20 > syslog-protocol. Does=20 > anyone disagree with this? >=20 Agree, even does not hurt existing receivers. >=20 > Should we continue to have the MSGID in the header, or should=20 > that become=20 > an SD-ID element? Both is doable. If we want to stick as compatible as possible, it should go into an SD-ID element. >=20 >=20 > We've had slow-downs in our prior discussions about=20 > truncation and message=20 > length. To complete this work without revisiting those=20 > discussions, and=20 > in the spirit of backwards compliance with traditional=20 > syslog, I propose=20 > that we accept the length as Rainer has proposed in=20 > syslog-protocol, and=20 > disallow any device to truncate the messages. At some future time,=20 > someone can augment the syslog-protocol standard and define a=20 > mechanism=20 > and signalling that will allow truncation. Does anyone disagree with=20 > this? It's problematic. Syslog-protocol has no actual upper limit. Some (useful) applications need more than 2K - that was the sense of the compromise. So it is possible that a message gets truncated. However, we could accept that fact without specifying a header for it. That could go into a SD-ID, too. >=20 >=20 > Encoding has been discussed and we have agreed upon US-ASCII=20 > and UTF-8 in=20 > appropriate places. Could we add a language tag as an element in an=20 > SD-ID to indicate the language of the MSG? If so, we should include the *character set* not the language. In respect to existing implementations, that would also be usefule. We should strongly consider to allow (but not recommend) other encodings, too (like popular JIS or EUC). I also posted this in my previous mail. >=20 >=20 > We need a version. Should that be in the header (after=20 > ), or as an=20 > element in an SD-ID? >=20 Header breaks backward-compatibility. SD-ID makes it chatty. In general, if we try to keep backwards-compatible, we should do it "right" and be able to handle the situation without the need of a version. Well... It could still be an optional SD-ID. >=20 > One possibility would be to assemble a syslog message as: >=20 > TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG >=20 I object this. It is smaller than protocol-15, but does not address the backwards compatibility issue. If we go with that we can go with -protocol-15, too. >=20 >=20 > If we can agree to this then I suspect that we can have a=20 > working document=20 > within Rainer's timeframe. I'll propose the following=20 > charter to keep us=20 > focused. We need to address the backward compatibility issues if we want to have backward compatibility. Else we have the same problem again, just with another header. >=20 > -------- Proposed Charter -------------- >=20 > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it > has some known security problems which were documented in RFC 3164. >=20 > The goal of this working group is to address the security and > integrity problems of the existing syslog mechanism while not breaking > backwards compatibility. The most obvious problems that need to be > addressed in the syslog protocol are the timestamp, which has not > formally included a means to indicate the year, and the identification > of the source which has been a hostname without a qualified domain > name. Additionally, a version, some type of message indicator, and a=20 > means to convey structured data will be included in the protocol. >=20 > syslog has traditionally been transported over UDP and this WG has=20 > already defined RFC 3195 for the reliable transport for the syslog=20 > messages. The WG will separate the UDP transport from the=20 > protocol so=20 > that others may define additional transports in the future. >=20 > - A standard will be produced that formally documents the syslog > protocol. A mechanism will also be defined in this specification > that will provide a means to convey structured data. >=20 > - A standard will be produced that documents the UDP transport for > syslog. >=20 > - A standard will be produced that documents a mechanism to sign > syslog messages to provide integrity checking and source > authentication. >=20 > - A MIB definition for syslog will be produced. >=20 > ------------------------------------------- I think that would be a practical charter, given this is the consensus. >=20 >=20 > PLEASE review this and respond. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 15:21:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIAd-0002mt-N1; Mon, 21 Nov 2005 15:21:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIAc-0002ma-93 for syslog@megatron.ietf.org; Mon, 21 Nov 2005 15:21:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04233 for ; Mon, 21 Nov 2005 15:21:09 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeIT7-0007iS-WB for syslog@ietf.org; Mon, 21 Nov 2005 15:40:54 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4CA299C00C; Mon, 21 Nov 2005 21:29:51 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31743-06; Mon, 21 Nov 2005 21:29:47 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 2F2529C00B; Mon, 21 Nov 2005 21:29:47 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2005 21:21:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EC5@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu0Dhk1cG4enAnTqGgNu2JZ0COcAAAtywAAAFckIA= From: "Rainer Gerhards" To: "Alexander Clemm (alex)" , "Chris Lonvick (clonvick)" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: quoted-printable Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Reading the other responses to Chris' question, let me phrase my response a little differently. I, too, can agree with the charter. The big question is if we really feel that strong about backward compatibility. If we think it is vitally important, we have big constraints, which we MUST take care of. If we consider backward compatibility non-essential, we can of course use what was recommended. We just need to know that then we have not really departed from syslog-protocol - just removed some fields. Of course, that can be benefitial. But it is not what lead to this discussion. However, I consider it to be contra-productive to keep as this will trick older recievers into thinking it is something that the understand. Anyhow, I will do some testing this week with some older receivers to see how they actually react to the format Chris summed up a s potential consensus. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Alexander=20 > Clemm (alex) > Sent: Monday, November 21, 2005 8:50 PM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 > Hello Chris, >=20 > your proposal sounds good. I don't disagree with any of your items > (which means, I agree with alll of them:-) =20 >=20 > Concerning the particular questions that you raise: =20 >=20 > "Should we continue to have the MSGID in the header, or should that > become=20 > an SD-ID element?" =20 >=20 > I believe it will be preferrable to have it in the header, not require > an SD-ID for that. =20 >=20 > "Could we add a language tag as an element in an=20 > SD-ID to indicate the language of the MSG?" >=20 > I believe SD-ID would be the right place to put this one. A > corresponding SDE could be defined at a later point in time. =20 >=20 > "We need a version. Should that be in the header (after ), or as > an=20 > element in an SD-ID?" >=20 > I believe it is preferrable to have it in the header, not require an > SD-ID for that. >=20 > --- Alex >=20 >=20 >=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > (clonvick) > Sent: Monday, November 21, 2005 11:12 AM > To: syslog@ietf.org > Subject: [Syslog] New direction and proposed charter >=20 > Hi Folks, >=20 > I'd like for us to come to closure on some things. I'm going to be a > bit direct on these questions so we can focus quicker. We really need > for people to send in responses to see who's listening and involved. >=20 >=20 >=20 > >From the meeting, it sounds like we will get many more=20 > implementations=20 > >if > we continue to use ... at the start of syslog messages. =20 > This will > allow current receivers to continue to receive messages and=20 > put them in > the right bins. Does anyone disagree with this? >=20 >=20 > The WG has agreed to use the timestamp Rainer has in the current > syslog-protocol. >=20 >=20 > Using the FQDN and numeric notations for IPv4 and IPv6 addresses has > been=20 > agreed to. >=20 >=20 > Putting in the Structured Data still seems like a great evolutionary > step=20 > for syslog. I'd like to see that go into the new=20 > syslog-protocol. Does >=20 > anyone disagree with this? >=20 >=20 > Should we continue to have the MSGID in the header, or should that > become=20 > an SD-ID element? >=20 >=20 > We've had slow-downs in our prior discussions about truncation and > message=20 > length. To complete this work without revisiting those=20 > discussions, and >=20 > in the spirit of backwards compliance with traditional=20 > syslog, I propose >=20 > that we accept the length as Rainer has proposed in=20 > syslog-protocol, and >=20 > disallow any device to truncate the messages. At some future time,=20 > someone can augment the syslog-protocol standard and define a=20 > mechanism=20 > and signalling that will allow truncation. Does anyone disagree with=20 > this? >=20 >=20 > Encoding has been discussed and we have agreed upon US-ASCII and UTF-8 > in=20 > appropriate places. Could we add a language tag as an element in an=20 > SD-ID to indicate the language of the MSG? >=20 >=20 > We need a version. Should that be in the header (after=20 > ), or as an >=20 > element in an SD-ID? >=20 >=20 > One possibility would be to assemble a syslog message as: >=20 > TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG >=20 >=20 >=20 > If we can agree to this then I suspect that we can have a working > document=20 > within Rainer's timeframe. I'll propose the following charter to keep > us=20 > focused. >=20 > -------- Proposed Charter -------------- >=20 > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it > has some known security problems which were documented in RFC 3164. >=20 > The goal of this working group is to address the security and > integrity problems of the existing syslog mechanism while not breaking > backwards compatibility. The most obvious problems that need to be > addressed in the syslog protocol are the timestamp, which has not > formally included a means to indicate the year, and the identification > of the source which has been a hostname without a qualified domain > name. Additionally, a version, some type of message indicator, and a=20 > means to convey structured data will be included in the protocol. >=20 > syslog has traditionally been transported over UDP and this WG has=20 > already defined RFC 3195 for the reliable transport for the syslog=20 > messages. The WG will separate the UDP transport from the=20 > protocol so=20 > that others may define additional transports in the future. >=20 > - A standard will be produced that formally documents the syslog > protocol. A mechanism will also be defined in this specification > that will provide a means to convey structured data. >=20 > - A standard will be produced that documents the UDP transport for > syslog. >=20 > - A standard will be produced that documents a mechanism to sign > syslog messages to provide integrity checking and source > authentication. >=20 > - A MIB definition for syslog will be produced. >=20 > ------------------------------------------- >=20 >=20 > PLEASE review this and respond. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 15:29:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIIK-00057x-Vo; Mon, 21 Nov 2005 15:29:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIIK-00057s-D3 for syslog@megatron.ietf.org; Mon, 21 Nov 2005 15:29:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04931 for ; Mon, 21 Nov 2005 15:29:07 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeIaq-0007xz-MR for syslog@ietf.org; Mon, 21 Nov 2005 15:48:53 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id F35E39C00C; Mon, 21 Nov 2005 21:37:49 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31743-07; Mon, 21 Nov 2005 21:37:43 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 116339C00B; Mon, 21 Nov 2005 21:37:43 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2005 21:29:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EC6@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu0Dhq9svvjD/bSre26hwjFQXXNQAAXyzgAAHps4A= From: "Rainer Gerhards" To: "Steve Chang (schang99)" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > I agree. With retained, our server code will not be broken. > And it can serve as message delimiter so we can pack as many short > messages before placing it to transport layer delivery. This is a framing issue. If we want to have multiple messages within a single UDP packet, syslog-transport-udp must be specified to support proper framing. We can NOT assume that a value in brackets will never occur inside a valid message - especially not if we support UTF-8. Or should we include a rule "MSG MUST NOT CONTAIN "? ;) If we go for framing, we must use byte-couting, because we have not outruled any sequence. If we go for octet-stuffing, we must define an escape mechanism. Any of this would be helpful for plain tcp syslog, but that is definitely a big departure from current syslog. Please note that currently many syslogds do octet-stuffing and the message TRAILER is LF. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 15:32:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIKe-0005Tx-Qj; Mon, 21 Nov 2005 15:32:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIKd-0005TW-E1 for syslog@megatron.ietf.org; Mon, 21 Nov 2005 15:32:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05161 for ; Mon, 21 Nov 2005 15:31:29 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeId7-00083U-Tz for syslog@ietf.org; Mon, 21 Nov 2005 15:51:15 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 21 Nov 2005 15:31:55 -0500 X-IronPort-AV: i="3.97,357,1125892800"; d="scan'208"; a="76247382:sNHT24565936" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jALKVXeB016512; Mon, 21 Nov 2005 15:31:52 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 15:31:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Mon, 21 Nov 2005 15:31:50 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C2887F@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu0DHp+Cdt1hggSCaNaodAhq5X9QABNcfAAAERScA= From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 21 Nov 2005 20:31:51.0446 (UTC) FILETIME=[9AA12360:01C5EEDA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer: > > Encoding has been discussed and we have agreed upon=20 > US-ASCII and UTF-8=20 > > in appropriate places. Could we add a language tag as an=20 > element in=20 > > an SD-ID to indicate the language of the MSG? >=20 > If so, we should include the *character set* not the=20 > language. In respect to existing implementations, that would=20 > also be usefule. We should strongly consider to allow (but=20 > not recommend) other encodings, too (like popular JIS or=20 > EUC). I also posted this in my previous mail. By character sets, do you suggest the use of the various locale-specific = encodings instead of using Unicode with some UTF-8? =20 I think that horrible legacy of gazillion local-specific encodings = should be avoided at all cost! It is a dead-end. Unicode resolved that = issue -- we should stick to it. I thought this was an accepted = direction at IETF. It is in the industry too. If I understand correctly, Chris was proposing a mere indication of the = language(s) used, which could be useful to the person analyzing the = message. I don't think Chris was proposing to do something instead of = UTF-8, which covers all of Unicode, which in turn covers all languages. = Or did I misinterpret? Thanks, Anton _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 15:45:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIXF-00012s-Rh; Mon, 21 Nov 2005 15:45:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIXC-0000zX-Jq for syslog@megatron.ietf.org; Mon, 21 Nov 2005 15:45:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06474 for ; Mon, 21 Nov 2005 15:44:29 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeIpi-0000GD-DX for syslog@ietf.org; Mon, 21 Nov 2005 16:04:14 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 96F669C00C; Mon, 21 Nov 2005 21:53:11 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31760-06; Mon, 21 Nov 2005 21:53:08 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id EC3229C00B; Mon, 21 Nov 2005 21:53:07 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2005 21:44:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EC7@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu0DHp+Cdt1hggSCaNaodAhq5X9QABNcfAAAERScAAAKPSsA== From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , "Chris Lonvick (clonvick)" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton, Please read my message in the spirit of the question on backwards compatibility I posted after the initial reply. Sorry for not telling this together with the initla reply. I too find it not suitable to support a horrendous number of encodings, but if we really want backwards compatibility, we must do it - simply because it is currently done. All it boils down is how important backwards compatibility is. As of the language, I am not sure if it will be useful to have this. For example, what about a message that contains mixed language strings (english/some local language) is not uncommon. I do not see any benefit that is worth this trouble. Rainer=20 > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Monday, November 21, 2005 9:32 PM > To: Rainer Gerhards; Chris Lonvick (clonvick); syslog@ietf.org > Cc: hartmans-ietf@mit.edu > Subject: RE: [Syslog] New direction and proposed charter >=20 > Rainer: >=20 > > > Encoding has been discussed and we have agreed upon=20 > > US-ASCII and UTF-8=20 > > > in appropriate places. Could we add a language tag as an=20 > > element in=20 > > > an SD-ID to indicate the language of the MSG? > >=20 > > If so, we should include the *character set* not the=20 > > language. In respect to existing implementations, that would=20 > > also be usefule. We should strongly consider to allow (but=20 > > not recommend) other encodings, too (like popular JIS or=20 > > EUC). I also posted this in my previous mail. >=20 > By character sets, do you suggest the use of the various=20 > locale-specific encodings instead of using Unicode with some UTF-8? =20 >=20 > I think that horrible legacy of gazillion local-specific=20 > encodings should be avoided at all cost! It is a dead-end.=20 > Unicode resolved that issue -- we should stick to it. I=20 > thought this was an accepted direction at IETF. It is in the=20 > industry too. >=20 > If I understand correctly, Chris was proposing a mere=20 > indication of the language(s) used, which could be useful to=20 > the person analyzing the message. I don't think Chris was=20 > proposing to do something instead of UTF-8, which covers all=20 > of Unicode, which in turn covers all languages. Or did I misinterpret? >=20 > Thanks, > Anton >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 15:57:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIjX-0004Cr-5l; Mon, 21 Nov 2005 15:57:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIjV-0004Ch-RP for syslog@megatron.ietf.org; Mon, 21 Nov 2005 15:57:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08461 for ; Mon, 21 Nov 2005 15:57:12 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeJ22-0000vA-0A for syslog@ietf.org; Mon, 21 Nov 2005 16:16:58 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2005 12:57:39 -0800 X-IronPort-AV: i="3.97,357,1125903600"; d="scan'208"; a="232912152:sNHT101001776" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jALKvK6m022862; Mon, 21 Nov 2005 12:57:37 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 15:57:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Mon, 21 Nov 2005 15:57:21 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C288AA@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu0DHp+Cdt1hggSCaNaodAhq5X9QABNcfAAAERScAAAKPSsAAALxzg From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 21 Nov 2005 20:57:22.0298 (UTC) FILETIME=[2B169DA0:01C5EEDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer: I agree backwards compatibility is a messy subject. I think the = proposal on the table now is to do just with the hope that this = allows old receivers to at least process message with appropriate = severity/facility. Say long to a different file. For everything else, = all bets are off. =20 My experience with Solaris/Linux receivers shows they would accept a = message with good PRI and then junk. They just append their own = timestamp. But I agree, this won't guarantee backwards compatibility = with any receiver because receivers are not standard at this point. = Achieving interop with something that is not standard is a tough = problem. =20 If people want old in there, I am ok with that. But I agree with = you, let's not be na=EFve about what level of interop this would = achieve. If that very basic level is useful to people - fine. But there = is no grand goal of full backwards compatibility here. We have to be = clear about that in the charter. =20 To the specific issue... UTF-8 encoding of basic ASCII is the same 7-bit = ASCII code. So, if new sender only sends a subset of characters allowed = by RFC 3164 and encodes them as UTF-8, it will look exactly as old = encoding. So, I think that part is backwards compatible for the subset = of characters supported by old receivers. =20 Thanks, Anton.=20 =20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Monday, November 21, 2005 3:45 PM > To: Anton Okmianski (aokmians); Chris Lonvick (clonvick);=20 > syslog@ietf.org > Cc: hartmans-ietf@mit.edu > Subject: RE: [Syslog] New direction and proposed charter >=20 > Anton, >=20 > Please read my message in the spirit of the question on=20 > backwards compatibility I posted after the initial reply.=20 > Sorry for not telling this together with the initla reply. >=20 > I too find it not suitable to support a horrendous number of=20 > encodings, but if we really want backwards compatibility, we=20 > must do it - simply because it is currently done. >=20 > All it boils down is how important backwards compatibility is. >=20 > As of the language, I am not sure if it will be useful to=20 > have this. For example, what about a message that contains=20 > mixed language strings (english/some local language) is not=20 > uncommon. I do not see any benefit that is worth this trouble. >=20 > Rainer=20 >=20 > > -----Original Message----- > > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > > Sent: Monday, November 21, 2005 9:32 PM > > To: Rainer Gerhards; Chris Lonvick (clonvick); syslog@ietf.org > > Cc: hartmans-ietf@mit.edu > > Subject: RE: [Syslog] New direction and proposed charter > >=20 > > Rainer: > >=20 > > > > Encoding has been discussed and we have agreed upon > > > US-ASCII and UTF-8 > > > > in appropriate places. Could we add a language tag as an > > > element in > > > > an SD-ID to indicate the language of the MSG? > > >=20 > > > If so, we should include the *character set* not the language. In=20 > > > respect to existing implementations, that would also be=20 > usefule. We=20 > > > should strongly consider to allow (but not recommend) other=20 > > > encodings, too (like popular JIS or EUC). I also posted=20 > this in my=20 > > > previous mail. > >=20 > > By character sets, do you suggest the use of the various=20 > > locale-specific encodings instead of using Unicode with some UTF-8? > >=20 > > I think that horrible legacy of gazillion local-specific encodings=20 > > should be avoided at all cost! It is a dead-end. > > Unicode resolved that issue -- we should stick to it. I=20 > thought this=20 > > was an accepted direction at IETF. It is in the industry too. > >=20 > > If I understand correctly, Chris was proposing a mere indication of=20 > > the language(s) used, which could be useful to the person analyzing=20 > > the message. I don't think Chris was proposing to do=20 > something instead=20 > > of UTF-8, which covers all of Unicode, which in turn covers all=20 > > languages. Or did I misinterpret? > >=20 > > Thanks, > > Anton > >=20 > >=20 > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 15:58:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIkF-0004MV-28; Mon, 21 Nov 2005 15:58:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIkD-0004MK-Mf for syslog@megatron.ietf.org; Mon, 21 Nov 2005 15:58:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08564 for ; Mon, 21 Nov 2005 15:57:56 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeJ2h-0000xh-Or for syslog@ietf.org; Mon, 21 Nov 2005 16:17:42 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2005 12:58:22 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jALKwJs3023863; Mon, 21 Nov 2005 12:58:19 -0800 (PST) Date: Mon, 21 Nov 2005 12:58:19 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] New direction and proposed charter In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3EC4@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3EC4@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Rainer and all, On Mon, 21 Nov 2005, Rainer Gerhards wrote: > Chris & WG > >> >>> From the meeting, it sounds like we will get many more >> implementations if >> we continue to use ... at the start of syslog messages. > > ############################################################## >> This will >> allow current receivers to continue to receive messages and >> put them in >> the right bins. > ############################################################## > >> Does anyone disagree with this? > > Yes, disagreement here. For the reasons outline in mail from Friday, > this is *NOT* true. Existing syslog receivers will be broken if we just > stick with and do not adjust the other header fields. > > Of course, it is doable. For details, review > > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00121.html > > (around the middle of the post). > >From my perspective, I think that having a syslog receiver receive the message and get it into the right bin is acceptable. If we don't have that then we are breaking very much. If we can accomplish that, then receivers will continue to receive the messages and the parsers will have to be updated. I believe that the alternative that you're saying, Rainer, is that syslog transmitters COULD keep their existing headers and our Working Group only put things in there. If we go with that, then the parsers will still need to be updated to understand the SD-ID information. I'd prefer to just keep the and modify the rest of the packet. We need to hear from more people on this. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 16:15:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJ0B-0003TT-0Z; Mon, 21 Nov 2005 16:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJ09-0003Sx-9N for syslog@megatron.ietf.org; Mon, 21 Nov 2005 16:15:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13086 for ; Mon, 21 Nov 2005 16:14:23 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeJIe-0002c1-M9 for syslog@ietf.org; Mon, 21 Nov 2005 16:34:10 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 0BE1D9C00C; Mon, 21 Nov 2005 22:23:05 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31899-02; Mon, 21 Nov 2005 22:23:00 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4F0FF9C00B; Mon, 21 Nov 2005 22:23:00 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2005 22:14:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EC8@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu3lYEviCM28tbRQCu3/0hEpgHMwAANJKA From: "Rainer Gerhards" To: "Chris Lonvick" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, Anton, WG: OK, if we just want to retain the and hope that this will lead to the messages go to the right bin and also hope that the syslogd won't be broken, this might indeed be a solution. My understanding was that backwards-compatibility was requested and that would be more than this I'll do some checks hopefully tomorrow, but think this might be a workable solution. If we take that route, the charter should state our very limited understanding of backwards-compatibility, else this could be another source of a lot of discussion. This is also the reason I am stressing this point so much (do not pretend to do things you don't do...). Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Monday, November 21, 2005 9:58 PM > To: Rainer Gerhards > Cc: syslog@ietf.org; hartmans-ietf@mit.edu > Subject: RE: [Syslog] New direction and proposed charter >=20 > Hi Rainer and all, >=20 > On Mon, 21 Nov 2005, Rainer Gerhards wrote: >=20 > > Chris & WG > > > >> > >>> From the meeting, it sounds like we will get many more > >> implementations if > >> we continue to use ... at the start of syslog messages. > > > > ############################################################## > >> This will > >> allow current receivers to continue to receive messages and > >> put them in > >> the right bins. > > ############################################################## > > > >> Does anyone disagree with this? > > > > Yes, disagreement here. For the reasons outline in mail from Friday, > > this is *NOT* true. Existing syslog receivers will be=20 > broken if we just > > stick with and do not adjust the other header fields. > > > > Of course, it is doable. For details, review > > > > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00121.html > > > > (around the middle of the post). > > >=20 > From my perspective, I think that having a syslog receiver=20 > receive the=20 > message and get it into the right bin is acceptable. If we=20 > don't have=20 > that then we are breaking very much. If we can accomplish that, then=20 > receivers will continue to receive the messages and the=20 > parsers will have=20 > to be updated. >=20 > I believe that the alternative that you're saying, Rainer, is=20 > that syslog=20 > transmitters COULD keep their existing headers and our=20 > Working Group only=20 > put things in there. If we go with that, then the parsers=20 > will still need=20 > to be updated to understand the SD-ID information. I'd=20 > prefer to just=20 > keep the and modify the rest of the packet. >=20 > We need to hear from more people on this. >=20 > Thanks, > Chris >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 17:19:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeK0d-0004i8-43; Mon, 21 Nov 2005 17:19:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeK0b-0004i0-Qu for syslog@megatron.ietf.org; Mon, 21 Nov 2005 17:19:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19960 for ; Mon, 21 Nov 2005 17:18:56 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeKJ7-00054R-SW for syslog@ietf.org; Mon, 21 Nov 2005 17:38:43 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 21 Nov 2005 14:19:05 -0800 X-IronPort-AV: i="3.97,357,1125903600"; d="scan'208"; a="677262656:sNHT1261899852" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jALMJ2Cf015142; Mon, 21 Nov 2005 14:19:03 -0800 (PST) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 14:18:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Mon, 21 Nov 2005 14:18:33 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FBE9DBC0@xmb-sjc-236.amer.cisco.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu0DHp+Cdt1hggSCaNaodAhq5X9QABNcfAAAERScAAA7ecgA== From: "Alexander Clemm \(alex\)" To: "Anton Okmianski \(aokmians\)" , "Rainer Gerhards" , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 21 Nov 2005 22:18:34.0757 (UTC) FILETIME=[834CDB50:01C5EEE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org My understanding was also that Chris' comment relates to natural language - the language used in the message payload, that possibly a system administrator will interpret - not encoding where my understanding is we are set on UTF-8. Most systems use English, but for internationalization purposes, it is conceivable to send the same message with a message text in a different - local - language. Since in general the language will be English, plus the language is easily determined from looking at the message text itself, and in addition all syslog messages emitted by the same sender will tend to use the same language, having a language identifier as part of the header would not be appropriate, but allowing for it as an SD-ID if someone does care about it might make sense. =20 --- Alex -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton Okmianski (aokmians) Sent: Monday, November 21, 2005 12:32 PM To: Rainer Gerhards; Chris Lonvick (clonvick); syslog@ietf.org Cc: hartmans-ietf@mit.edu Subject: RE: [Syslog] New direction and proposed charter Rainer: > > Encoding has been discussed and we have agreed upon > US-ASCII and UTF-8 > > in appropriate places. Could we add a language tag as an > element in > > an SD-ID to indicate the language of the MSG? >=20 > If so, we should include the *character set* not the language. In=20 > respect to existing implementations, that would also be usefule. We=20 > should strongly consider to allow (but not recommend) other encodings, > too (like popular JIS or EUC). I also posted this in my previous mail. By character sets, do you suggest the use of the various locale-specific encodings instead of using Unicode with some UTF-8? =20 I think that horrible legacy of gazillion local-specific encodings should be avoided at all cost! It is a dead-end. Unicode resolved that issue -- we should stick to it. I thought this was an accepted direction at IETF. It is in the industry too. If I understand correctly, Chris was proposing a mere indication of the language(s) used, which could be useful to the person analyzing the message. I don't think Chris was proposing to do something instead of UTF-8, which covers all of Unicode, which in turn covers all languages. Or did I misinterpret? Thanks, Anton _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 17:34:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKFH-00025v-Ep; Mon, 21 Nov 2005 17:34:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKFG-00025l-F5 for syslog@megatron.ietf.org; Mon, 21 Nov 2005 17:34:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21290 for ; Mon, 21 Nov 2005 17:34:04 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeKXn-0005aF-M8 for syslog@ietf.org; Mon, 21 Nov 2005 17:53:52 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2005 14:34:32 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jALMXvsU010547; Mon, 21 Nov 2005 14:34:29 -0800 (PST) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 14:34:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Mon, 21 Nov 2005 14:34:25 -0800 Message-ID: Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu0DHp+Cdt1hggSCaNaodAhq5X9QABNcfAAAERScAAAKPSsAAAv2Ng From: "Steve Chang \(schang99\)" To: "Rainer Gerhards" , "Anton Okmianski \(aokmians\)" , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 21 Nov 2005 22:34:26.0334 (UTC) FILETIME=[BA7BFBE0:01C5EEEB] X-Spam-Score: 0.9 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Just FYI. For discussion on this language mixing stuffs, I am including some found in the junk email I received. I am sure it happens to other=20 non-English world too. In Chinese world, mixing Chinese and English is quite common in our = daily life reading materials! See example below (I am not doing commercial = here. I am including it to make a point.) =D2=B0=C8=CB=BB=A8=88@ - =D2=B0=C8=CB=BB=A8=88@=BE=AB=DFx = =93=8C=CF=C8=C2=A0=A3=A1( KKBOX=D0=C2=B8=E8=93=8C=CF=C8=C2=A0 - = 2005/11/01=A3=A9 =EE=8A=BE=B3=BEW=D3=8D=B9=C9=B7=DD=D3=D0=CF=DE=B9=AB=CB=BE 2005 Skysoft. = All Rights Reserved. = =BE=80=C9=CF=BF=CD=B7=FE=D0=C5=CF=E4=A1=A1=BF=CD=B7=FE=8C=A3=BE=8002-2655= -8520 I am not sure when such things will start to be seen in syslog messages = though. If you can not read those characters, perhaps your email reader do not = support traditional Chinese character set. You need to install that = first. Regards, Steve > -----Original Message----- > From: syslog-bounces@lists.ietf.org = [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Rainer Gerhards > Sent: Monday, November 21, 2005 12:45 PM > To: Anton Okmianski (aokmians); Chris Lonvick (clonvick); = syslog@ietf.org > Cc: hartmans-ietf@mit.edu > Subject: RE: [Syslog] New direction and proposed charter >=20 > Anton, >=20 > Please read my message in the spirit of the question on backwards > compatibility I posted after the initial reply. Sorry for not telling > this together with the initla reply. >=20 > I too find it not suitable to support a horrendous number of = encodings, > but if we really want backwards compatibility, we must do it - simply > because it is currently done. >=20 > All it boils down is how important backwards compatibility is. >=20 > As of the language, I am not sure if it will be useful to have this. = For > example, what about a message that contains mixed language strings > (english/some local language) is not uncommon. I do not see any = benefit > that is worth this trouble. >=20 > Rainer >=20 > > -----Original Message----- > > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > > Sent: Monday, November 21, 2005 9:32 PM > > To: Rainer Gerhards; Chris Lonvick (clonvick); syslog@ietf.org > > Cc: hartmans-ietf@mit.edu > > Subject: RE: [Syslog] New direction and proposed charter > > > > Rainer: > > > > > > Encoding has been discussed and we have agreed upon > > > US-ASCII and UTF-8 > > > > in appropriate places. Could we add a language tag as an > > > element in > > > > an SD-ID to indicate the language of the MSG? > > > > > > If so, we should include the *character set* not the > > > language. In respect to existing implementations, that would > > > also be usefule. We should strongly consider to allow (but > > > not recommend) other encodings, too (like popular JIS or > > > EUC). I also posted this in my previous mail. > > > > By character sets, do you suggest the use of the various > > locale-specific encodings instead of using Unicode with some UTF-8? > > > > I think that horrible legacy of gazillion local-specific > > encodings should be avoided at all cost! It is a dead-end. > > Unicode resolved that issue -- we should stick to it. I > > thought this was an accepted direction at IETF. It is in the > > industry too. > > > > If I understand correctly, Chris was proposing a mere > > indication of the language(s) used, which could be useful to > > the person analyzing the message. I don't think Chris was > > proposing to do something instead of UTF-8, which covers all > > of Unicode, which in turn covers all languages. Or did I = misinterpret? > > > > Thanks, > > Anton > > > > > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 17:49:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKTg-0007jW-UT; Mon, 21 Nov 2005 17:49:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKTf-0007jR-42 for syslog@megatron.ietf.org; Mon, 21 Nov 2005 17:49:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22514 for ; Mon, 21 Nov 2005 17:48:57 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeKmC-00064b-JC for syslog@ietf.org; Mon, 21 Nov 2005 18:08:44 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 21 Nov 2005 14:49:26 -0800 X-IronPort-AV: i="3.97,357,1125903600"; d="scan'208"; a="677281621:sNHT46135800" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jALMnNeT017632; Mon, 21 Nov 2005 14:49:24 -0800 (PST) Date: Mon, 21 Nov 2005 14:49:23 -0800 (PST) From: Chris Lonvick To: "Alexander Clemm (alex)" Subject: RE: [Syslog] New direction and proposed charter In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FBE9DBC0@xmb-sjc-236.amer.cisco.com> Message-ID: References: <85B2F271FDF6B949B3672BA5A7BB62FBE9DBC0@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, I was proposing just a SD-ID element that would indicate the natural language of the message content. I'd suggest using RFC 3066 language tags. http://www.ietf.org/rfc/rfc3066.txt ISO 639-1 and -2 codes for languages may be found here: http://www.loc.gov/standards/iso639-2/englangn.html I think this would address the internationalization issue. Thanks, Chris On Mon, 21 Nov 2005, Alexander Clemm (alex) wrote: > My understanding was also that Chris' comment relates to natural > language - the language used in the message payload, that possibly a > system administrator will interpret - not encoding where my > understanding is we are set on UTF-8. Most systems use English, but for > internationalization purposes, it is conceivable to send the same > message with a message text in a different - local - language. Since in > general the language will be English, plus the language is easily > determined from looking at the message text itself, and in addition all > syslog messages emitted by the same sender will tend to use the same > language, having a language identifier as part of the header would not > be appropriate, but allowing for it as an SD-ID if someone does care > about it might make sense. > > --- Alex > > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton Okmianski > (aokmians) > Sent: Monday, November 21, 2005 12:32 PM > To: Rainer Gerhards; Chris Lonvick (clonvick); syslog@ietf.org > Cc: hartmans-ietf@mit.edu > Subject: RE: [Syslog] New direction and proposed charter > > Rainer: > >>> Encoding has been discussed and we have agreed upon >> US-ASCII and UTF-8 >>> in appropriate places. Could we add a language tag as an >> element in >>> an SD-ID to indicate the language of the MSG? >> >> If so, we should include the *character set* not the language. In >> respect to existing implementations, that would also be usefule. We >> should strongly consider to allow (but not recommend) other encodings, > >> too (like popular JIS or EUC). I also posted this in my previous mail. > > By character sets, do you suggest the use of the various locale-specific > encodings instead of using Unicode with some UTF-8? > > I think that horrible legacy of gazillion local-specific encodings > should be avoided at all cost! It is a dead-end. Unicode resolved that > issue -- we should stick to it. I thought this was an accepted > direction at IETF. It is in the industry too. > > If I understand correctly, Chris was proposing a mere indication of the > language(s) used, which could be useful to the person analyzing the > message. I don't think Chris was proposing to do something instead of > UTF-8, which covers all of Unicode, which in turn covers all languages. > Or did I misinterpret? > > Thanks, > Anton > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 21 18:21:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKyz-0001VK-Ua; Mon, 21 Nov 2005 18:21:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKyx-0001V1-VE for syslog@megatron.ietf.org; Mon, 21 Nov 2005 18:21:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25887 for ; Mon, 21 Nov 2005 18:21:17 -0500 (EST) Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeLHT-0007IE-6T for syslog@ietf.org; Mon, 21 Nov 2005 18:41:05 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc14) with SMTP id <2005112123213001400ltau7e>; Mon, 21 Nov 2005 23:21:30 +0000 From: "David B Harrington" To: "'Chris Lonvick'" , Subject: RE: [Syslog] New direction and proposed charter Date: Mon, 21 Nov 2005 18:21:24 -0500 Message-ID: <022601c5eef2$4aa1ef30$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXuz/ZuCFizkvesS5SudxAL9QicpQAHO8Ng X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, I am concerned about the emphasis on backwards compatibility. The reason people want a standard is that existing server implementations have made different design decisions, and device and application vendors are forced to either interoperate with one vendor-specific server implementation, or need to write code to support different server implementations. Device and application vendors would like one consistent solution that is vendor-neutral so their implementations will interoperate with any standard-compliant server. If we strive for backwards compatibility, we will end up with a standard that simply rubber-stamps many of the non-interoperable, vendor-specific existing server implementations. We should be striving to produce a standard for syslog that is vendor-neutral and that helps server and equipment/application vendors produce interoperable implementations using one standard syslog specification. I am, however, a strong believer in making it fairly easy for vendors to migrate from their existing vendor-specific non-interoperable implementations to a vendor-neutral interoperable standard, and to make it possible for servers and senders to support both the existing syslog and the new standard for syslog. I believe we should emphasize "ease of migration and co-existence" rather than "backwards compatibility". I suggest changing "The goal of this working group is to address the security and integrity problems of the existing syslog mechanism while not breaking backwards compatibility." To "The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard." Some charter items could be interpreted as documenting existing practices, rather than documenting an agreed-to standardized approach for these aspects of syslog. I suggest changing > - A standard will be produced that formally documents the syslog > protocol. A mechanism will also be defined in this specification > that will provide a means to convey structured data. > > - A standard will be produced that documents the UDP transport for > syslog. > > - A standard will be produced that documents a mechanism to sign > syslog messages to provide integrity checking and source > authentication. > To " - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication." David Harrington dbharrington@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 02:29:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeSaM-000493-Ju; Tue, 22 Nov 2005 02:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeSaL-00048o-CR for syslog@megatron.ietf.org; Tue, 22 Nov 2005 02:29:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12805 for ; Tue, 22 Nov 2005 02:28:22 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeSsw-0004TG-K3 for syslog@ietf.org; Tue, 22 Nov 2005 02:48:15 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id EB3BF9C00D for ; Tue, 22 Nov 2005 08:37:07 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32358-01 for ; Tue, 22 Nov 2005 08:37:03 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 2730A9C00B for ; Tue, 22 Nov 2005 08:37:03 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Nov 2005 08:25:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EC9@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXuz/ZuCFizkvesS5SudxAL9QicpQAHO8NgABI1qgA= From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I fully agree with David. That charter would work well and also cover keeping the . It would make clear that we are not trying to get full backwards compatibility.=20 Rainer=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of David B Harrington > Sent: Tuesday, November 22, 2005 12:21 AM > To: 'Chris Lonvick'; syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 > Hi, >=20 > I am concerned about the emphasis on backwards compatibility. The > reason people want a standard is that existing server implementations > have made different design decisions, and device and application > vendors are forced to either interoperate with one vendor-specific > server implementation, or need to write code to support different > server implementations. Device and application vendors would like one > consistent solution that is vendor-neutral so their implementations > will interoperate with any standard-compliant server.=20 >=20 > If we strive for backwards compatibility, we will end up with a > standard that simply rubber-stamps many of the non-interoperable, > vendor-specific existing server implementations. We should be > striving to produce a standard for syslog that is vendor-neutral and > that helps server and equipment/application vendors produce > interoperable implementations using one standard syslog specification. >=20 > I am, however, a strong believer in making it fairly easy for vendors > to migrate from their existing vendor-specific non-interoperable > implementations to a vendor-neutral interoperable standard, and to > make it possible for servers and senders to support both the existing > syslog and the new standard for syslog.=20 >=20 > I believe we should emphasize "ease of migration and co-existence" > rather than "backwards compatibility". >=20 > I suggest changing=20 > "The goal of this working group is to address the security and > integrity problems of the existing syslog mechanism while not breaking > backwards compatibility." > To > "The goal of this working group is to address the security and > integrity problems, and to standardize the syslog protocol, transport, > and a select set of mechanisms in a manner that considers the ease of > migration between and the co-existence of existing versions and the > standard." >=20 > Some charter items could be interpreted as documenting existing > practices, rather than documenting an agreed-to standardized approach > for these aspects of syslog. >=20 > I suggest changing >=20 > > - A standard will be produced that formally documents the syslog > > protocol. A mechanism will also be defined in this specification > > that will provide a means to convey structured data. > >=20 > > - A standard will be produced that documents the UDP transport for > > syslog. > >=20 > > - A standard will be produced that documents a mechanism to sign > > syslog messages to provide integrity checking and source > > authentication. > >=20 >=20 > To > " > - A document will be produced that describes a standardized syslog > protocol. A mechanism will also be defined in this document > that will provide a means to convey structured data. >=20 > - A document will be produced that describes a standardized UDP > transport for syslog. >=20 > - A document will be produced that describes a standardized mechanism > to sign syslog messages to provide integrity checking and source > authentication." >=20 > David Harrington > dbharrington@comcast.net >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 02:29:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeSaY-0004FO-1W; Tue, 22 Nov 2005 02:29:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeSaX-0004FB-3p for syslog@megatron.ietf.org; Tue, 22 Nov 2005 02:29:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12817 for ; Tue, 22 Nov 2005 02:28:34 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeSsw-0004TF-Jz for syslog@ietf.org; Tue, 22 Nov 2005 02:48:15 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 2F0739C00B for ; Tue, 22 Nov 2005 08:37:08 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32143-06 for ; Tue, 22 Nov 2005 08:37:03 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4EAEF9C00C for ; Tue, 22 Nov 2005 08:37:03 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Nov 2005 08:28:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3ECA@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu7dpqaV8wzoopSbeJKrwpiALb4wASBrYA From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I personally do not think that this will address the initernationlization issue, but I do not violently object it. I agree with Steve Chang that it is redundant information at best. Multi-language messages are commen, at least e.g. in Non-English localized syslog messages. So this adds some complexity. However, if we make it optional, nobody needs to write that tag, which could resolve the ambiguity. This doesn't hurt the standard at all because the encoding (UTF-8) is well-specified in any case. So a language tag would just be another extra information for scripts (whatever) and be non-essential. Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Monday, November 21, 2005 11:49 PM > To: Alexander Clemm (alex) > Cc: Anton Okmianski (aokmians); Rainer Gerhards;=20 > syslog@ietf.org; hartmans-ietf@mit.edu > Subject: RE: [Syslog] New direction and proposed charter >=20 > Hi, >=20 > I was proposing just a SD-ID element that would indicate the natural=20 > language of the message content. I'd suggest using RFC 3066 language=20 > tags. > http://www.ietf.org/rfc/rfc3066.txt >=20 > ISO 639-1 and -2 codes for languages may be found here: > http://www.loc.gov/standards/iso639-2/englangn.html >=20 > I think this would address the internationalization issue. >=20 > Thanks, > Chris >=20 >=20 > On Mon, 21 Nov 2005, Alexander Clemm (alex) wrote: >=20 > > My understanding was also that Chris' comment relates to natural > > language - the language used in the message payload, that possibly a > > system administrator will interpret - not encoding where my > > understanding is we are set on UTF-8. Most systems use=20 > English, but for > > internationalization purposes, it is conceivable to send the same > > message with a message text in a different - local -=20 > language. Since in > > general the language will be English, plus the language is easily > > determined from looking at the message text itself, and in=20 > addition all > > syslog messages emitted by the same sender will tend to use the same > > language, having a language identifier as part of the=20 > header would not > > be appropriate, but allowing for it as an SD-ID if someone does care > > about it might make sense. > > > > --- Alex > > > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton Okmianski > > (aokmians) > > Sent: Monday, November 21, 2005 12:32 PM > > To: Rainer Gerhards; Chris Lonvick (clonvick); syslog@ietf.org > > Cc: hartmans-ietf@mit.edu > > Subject: RE: [Syslog] New direction and proposed charter > > > > Rainer: > > > >>> Encoding has been discussed and we have agreed upon > >> US-ASCII and UTF-8 > >>> in appropriate places. Could we add a language tag as an > >> element in > >>> an SD-ID to indicate the language of the MSG? > >> > >> If so, we should include the *character set* not the language. In > >> respect to existing implementations, that would also be usefule. We > >> should strongly consider to allow (but not recommend)=20 > other encodings, > > > >> too (like popular JIS or EUC). I also posted this in my=20 > previous mail. > > > > By character sets, do you suggest the use of the various=20 > locale-specific > > encodings instead of using Unicode with some UTF-8? > > > > I think that horrible legacy of gazillion local-specific encodings > > should be avoided at all cost! It is a dead-end. Unicode=20 > resolved that > > issue -- we should stick to it. I thought this was an accepted > > direction at IETF. It is in the industry too. > > > > If I understand correctly, Chris was proposing a mere=20 > indication of the > > language(s) used, which could be useful to the person analyzing the > > message. I don't think Chris was proposing to do something=20 > instead of > > UTF-8, which covers all of Unicode, which in turn covers=20 > all languages. > > Or did I misinterpret? > > > > Thanks, > > Anton > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 05:56:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeVon-0005di-K8; Tue, 22 Nov 2005 05:56:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeVol-0005dd-QK for syslog@megatron.ietf.org; Tue, 22 Nov 2005 05:56:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01945 for ; Tue, 22 Nov 2005 05:55:29 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeW7P-00041S-3X for syslog@ietf.org; Tue, 22 Nov 2005 06:15:23 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 308949C00D; Tue, 22 Nov 2005 12:04:15 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32446-05; Tue, 22 Nov 2005 12:04:10 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 1F1EB9C00B; Tue, 22 Nov 2005 12:04:10 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Nov 2005 11:55:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3ECE@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXu3lYEviCM28tbRQCu3/0hEpgHMwAb95KA From: "Rainer Gerhards" To: "Chris Lonvick" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org WG, I have completed the promised testing. I used various syslogds on Linux, BSD and Windows platforms. The list obviously is not complete, but I think I got a fair enough sample of what is deployed. The good news is that by putting the part in front of the message all of them were able to put the otherwise syslog-protocol-15 formatted message into the right bins. The format recorded was also acceptable, the non-recognized hostname was replaced by the sender address and the local date was added. This is within the typical current user experience when different syslogds are being used. Please note that some (e.g. BSD syslogd) do never pull the hostname from the message but always use the sender's address. The only culpit that I came along is associated with NUL octets. Many syslogds can not handle them. The message is only recorded up to the first NUL inside the message, no further interpretation happens.=20 We have had discussion on this topic previously. As a reminder, it was said that excluding the NUL would be a "crappy little rule" that could open the door for many more CLRs. I still tend to think this is true and the problem exposed is acceptable. I try to sum up yesterday's discussion and my current position on it: Once again, I think David's comments on the charter are in the right direction (http://www.mail-archive.com/syslog%40lists.ietf.org/msg00143.html). It calls for some compatibility but puts emphasis on newer development. I suggest we accept the wording. We have had several comments on the field order in syslog-protocol. Based on them, I propose the following format: VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG With (optional) SD-IDs for - Extended Facility - TRUNCATE=20 - MSGID - [Language Identification] Please note that I moved MSGID to the optional SD-ID part and instead re-introduced APP-NAME and PROCID as formal fields. I have done this because these two were designed as a replacement for TAG, whereas MSGID was meant to be something totally different. If we would prefer to have one field, only, I recommend to name it TAG and use the same semantics RFC 3164 describes. I support Chris proposal to leave the current size limitations exactly as they are in syslog-protocol. Everything else would cause the n-th re-iteration of the message size issue (side note: exactly the same discussion seems to have started on the NETCONF WG for event notifications right now, so this is an ever-popular topic). I have included an "Extended Facility" to provide finer-grain facility control within the message. This was brought up by Anton and others and does not seem to hurt anything if in SD-ID. I have included the Language Identification. I don't object it, but I question its usefulness. If we follow the message defition above, we can probably recycle most of the text in syslog-protocol, just shuffle it a little around. This has two advantages: - we do not loose what we already have discussed - the work can progress rather quickly Also, syslog-transport-udp most probably does not need any change at all, at most in a minor way. Modifying existing syslog receivers should not be very hard with the new definitions. The only major issue I see from the implementors point of view is UTF-8 decoding. But that is more of a storage problem. It is of course possible to receive the message and store it as UTF-8. I do not think this would cause non-compliance to the spec - or would it? If it would, UTF-8 would most probably be a major drawback when it comes to implementor acceptance. I am also a bit concerned about the NUL character, which can only be handled in one of two ways with existing syslog code base: - implementing a byte-counted string class and do not use the C RTL - replace NUL with an escape sequence upon reception (e.g. <00>) I guess most implementations would take the later route. If we consider this to be acceptable, the majority of syslogds should be fairly easy to upgrade. If we can agree on these points, I would volunteer to implement the resulting document in C code so that we might see if there were any hidden problems. I would try to apply as minimal changes as possible. Suggestion for progressing: - we need more comments from other list members! - we should re-charter - we should reach rough consensus on the new format - once done, I can update syslog-protocol to it - I (and others?) can do test implementations in parallel to the review - discussion can show if (hopefully minor) adjustments need to be made - the goal should still be to finish this work (including AD approval) by the next IETF meeting Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Monday, November 21, 2005 9:58 PM > To: Rainer Gerhards > Cc: syslog@ietf.org; hartmans-ietf@mit.edu > Subject: RE: [Syslog] New direction and proposed charter >=20 > Hi Rainer and all, >=20 > On Mon, 21 Nov 2005, Rainer Gerhards wrote: >=20 > > Chris & WG > > > >> > >>> From the meeting, it sounds like we will get many more > >> implementations if > >> we continue to use ... at the start of syslog messages. > > > > ############################################################## > >> This will > >> allow current receivers to continue to receive messages and > >> put them in > >> the right bins. > > ############################################################## > > > >> Does anyone disagree with this? > > > > Yes, disagreement here. For the reasons outline in mail from Friday, > > this is *NOT* true. Existing syslog receivers will be=20 > broken if we just > > stick with and do not adjust the other header fields. > > > > Of course, it is doable. For details, review > > > > http://www.mail-archive.com/syslog%40lists.ietf.org/msg00121.html > > > > (around the middle of the post). > > >=20 > From my perspective, I think that having a syslog receiver=20 > receive the=20 > message and get it into the right bin is acceptable. If we=20 > don't have=20 > that then we are breaking very much. If we can accomplish that, then=20 > receivers will continue to receive the messages and the=20 > parsers will have=20 > to be updated. >=20 > I believe that the alternative that you're saying, Rainer, is=20 > that syslog=20 > transmitters COULD keep their existing headers and our=20 > Working Group only=20 > put things in there. If we go with that, then the parsers=20 > will still need=20 > to be updated to understand the SD-ID information. I'd=20 > prefer to just=20 > keep the and modify the rest of the packet. >=20 > We need to hear from more people on this. >=20 > Thanks, > Chris >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 09:57:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZaS-0006q8-9G; Tue, 22 Nov 2005 09:57:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZaQ-0006nk-5U for syslog@megatron.ietf.org; Tue, 22 Nov 2005 09:57:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27114 for ; Tue, 22 Nov 2005 09:56:54 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeZt5-0007aG-47 for syslog@ietf.org; Tue, 22 Nov 2005 10:16:52 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 22 Nov 2005 06:57:24 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAMEvLeT003875; Tue, 22 Nov 2005 06:57:22 -0800 (PST) Date: Tue, 22 Nov 2005 06:57:21 -0800 (PST) From: Chris Lonvick To: David B Harrington Subject: RE: [Syslog] New direction and proposed charter In-Reply-To: <022601c5eef2$4aa1ef30$0400a8c0@DJYXPY41> Message-ID: References: <022601c5eef2$4aa1ef30$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org David, I think your words have cut through the confusion on this. I agree with your proposed changes. Many thanks, Chris On Mon, 21 Nov 2005, David B Harrington wrote: > Hi, > > I am concerned about the emphasis on backwards compatibility. The > reason people want a standard is that existing server implementations > have made different design decisions, and device and application > vendors are forced to either interoperate with one vendor-specific > server implementation, or need to write code to support different > server implementations. Device and application vendors would like one > consistent solution that is vendor-neutral so their implementations > will interoperate with any standard-compliant server. > > If we strive for backwards compatibility, we will end up with a > standard that simply rubber-stamps many of the non-interoperable, > vendor-specific existing server implementations. We should be > striving to produce a standard for syslog that is vendor-neutral and > that helps server and equipment/application vendors produce > interoperable implementations using one standard syslog specification. > > I am, however, a strong believer in making it fairly easy for vendors > to migrate from their existing vendor-specific non-interoperable > implementations to a vendor-neutral interoperable standard, and to > make it possible for servers and senders to support both the existing > syslog and the new standard for syslog. > > I believe we should emphasize "ease of migration and co-existence" > rather than "backwards compatibility". > > I suggest changing > "The goal of this working group is to address the security and > integrity problems of the existing syslog mechanism while not breaking > backwards compatibility." > To > "The goal of this working group is to address the security and > integrity problems, and to standardize the syslog protocol, transport, > and a select set of mechanisms in a manner that considers the ease of > migration between and the co-existence of existing versions and the > standard." > > Some charter items could be interpreted as documenting existing > practices, rather than documenting an agreed-to standardized approach > for these aspects of syslog. > > I suggest changing > >> - A standard will be produced that formally documents the syslog >> protocol. A mechanism will also be defined in this specification >> that will provide a means to convey structured data. >> >> - A standard will be produced that documents the UDP transport for >> syslog. >> >> - A standard will be produced that documents a mechanism to sign >> syslog messages to provide integrity checking and source >> authentication. >> > > To > " > - A document will be produced that describes a standardized syslog > protocol. A mechanism will also be defined in this document > that will provide a means to convey structured data. > > - A document will be produced that describes a standardized UDP > transport for syslog. > > - A document will be produced that describes a standardized mechanism > to sign syslog messages to provide integrity checking and source > authentication." > > David Harrington > dbharrington@comcast.net > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 11:48:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebJr-0006vl-Mr; Tue, 22 Nov 2005 11:48:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebJp-0006ub-V8 for syslog@megatron.ietf.org; Tue, 22 Nov 2005 11:48:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10585 for ; Tue, 22 Nov 2005 11:47:54 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EebcT-0005JF-VM for syslog@ietf.org; Tue, 22 Nov 2005 12:07:51 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAMGm3Us020268; Wed, 23 Nov 2005 03:48:03 +1100 (EST) From: Darren Reed Message-Id: <200511221647.jAMGldbx018777@firewall.reed.wattle.id.au> Subject: Re: [Syslog] New direction and proposed charter In-Reply-To: To: Chris Lonvick Date: Wed, 23 Nov 2005 03:47:39 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > David, > > I think your words have cut through the confusion on this. I agree with > your proposed changes. > > Many thanks, > Chris For what it's worth, I also agree with these proposed changes. Darren (on the road again for a few weeks) _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 11:52:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebNM-0002ME-BX; Tue, 22 Nov 2005 11:52:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebNK-0002Lk-5f for syslog@megatron.ietf.org; Tue, 22 Nov 2005 11:52:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11024 for ; Tue, 22 Nov 2005 11:51:29 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eebfx-0005XT-FO for syslog@ietf.org; Tue, 22 Nov 2005 12:11:27 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAMGpgR6022459; Wed, 23 Nov 2005 03:51:42 +1100 (EST) From: Darren Reed Message-Id: <200511221651.jAMGpOY3013690@firewall.reed.wattle.id.au> Subject: Re: [Syslog] New direction and proposed charter In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3ECE@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Wed, 23 Nov 2005 03:51:24 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.6 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > WG, > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG I would put the SD-IDs after the message. The SD-IDs and detailed bits of meaning to the MSG and without the MSG, are irrelevant. The exception being a language marker. > - replace NUL with an escape sequence upon reception (e.g. <00>) Why not \0 ? Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 11:56:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebRx-0004MU-Q9; Tue, 22 Nov 2005 11:56:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebRw-0004M9-GM for syslog@megatron.ietf.org; Tue, 22 Nov 2005 11:56:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11789 for ; Tue, 22 Nov 2005 11:56:18 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eebkc-0005rW-UW for syslog@ietf.org; Tue, 22 Nov 2005 12:16:15 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAMGuoiw021726; Wed, 23 Nov 2005 03:56:50 +1100 (EST) From: Darren Reed Message-Id: <200511221656.jAMGumTF020701@firewall.reed.wattle.id.au> Subject: Re: [Syslog] New direction and proposed charter In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3EC6@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Wed, 23 Nov 2005 03:56:48 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org .. > If we go for framing, we must use byte-couting, because we have not > outruled any sequence. If we go for octet-stuffing, we must define an > escape mechanism. Any of this would be helpful for plain tcp syslog, but > that is definitely a big departure from current syslog. Please note that > currently many syslogds do octet-stuffing and the message TRAILER is LF. That's unfortunate :( In nearly all IETF protocols, the message trailer or EOL marker is CR-LF. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 12:04:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebYw-0006yl-Q4; Tue, 22 Nov 2005 12:04:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebYv-0006yd-WE for syslog@megatron.ietf.org; Tue, 22 Nov 2005 12:04:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12682 for ; Tue, 22 Nov 2005 12:03:31 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eebrc-0006Fm-UQ for syslog@ietf.org; Tue, 22 Nov 2005 12:23:29 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 22 Nov 2005 09:04:00 -0800 X-IronPort-AV: i="3.97,362,1125903600"; d="scan'208"; a="677596485:sNHT25950368" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAMH3If0000970; Tue, 22 Nov 2005 09:03:58 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 12:03:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Tue, 22 Nov 2005 12:03:45 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C28B6D@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXvhWPR6C8njUk4TJahQIgDA5fwXgAAFQCQ From: "Anton Okmianski \(aokmians\)" To: "Darren Reed" , "Rainer Gerhards" X-OriginalArrivalTime: 22 Nov 2005 17:03:46.0175 (UTC) FILETIME=[B33DB8F0:01C5EF86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren: > > WG, > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG >=20 > I would put the SD-IDs after the message. >=20 > The SD-IDs and detailed bits of meaning to the MSG and=20 > without the MSG, are irrelevant. The exception being a=20 > language marker. I would prefer SD-ID where it is in example. I would also re-iterate = suggestion of having MSGID in the header, which a number of people = supported. Those two combined are arguably more important than the MSG = part itself. For example (in abbreviated syntax: host.domain.com MyApp proc1234 STARTED_UP [ip=3D1.1.1.1]: The = applications has started I could live without the MSG here if it got truncated. The MSGID and = SD-ID are much more important in this case. BTW, the possible = truncation of text and its variability (possible substitutable = variables) is another reason why MSGID is so useful. It makes it easier = for intelligent receivers to do things like event correlation.=20 Thanks, Anton.=20 >=20 > > - replace NUL with an escape sequence upon reception (e.g. <00>) >=20 > Why not \0 ? >=20 > Darren >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 12:22:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebqW-0001NW-A7; Tue, 22 Nov 2005 12:22:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebqT-0001Ma-Py for syslog@megatron.ietf.org; Tue, 22 Nov 2005 12:22:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14788 for ; Tue, 22 Nov 2005 12:21:39 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eec98-0007DG-0n for syslog@ietf.org; Tue, 22 Nov 2005 12:41:37 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id E9E0F9C00C; Tue, 22 Nov 2005 18:30:23 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00822-01; Tue, 22 Nov 2005 18:30:20 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 471719C00B; Tue, 22 Nov 2005 18:30:20 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Nov 2005 18:21:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3ED6@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXvhcH0Fb3f+qpWTI6L2UB0MupBRgAAztHA From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > If we go for framing, we must use byte-couting, because we have not > > outruled any sequence. If we go for octet-stuffing, we must=20 > define an > > escape mechanism. Any of this would be helpful for plain=20 > tcp syslog, but > > that is definitely a big departure from current syslog.=20 > Please note that > > currently many syslogds do octet-stuffing and the message=20 > TRAILER is LF. >=20 > That's unfortunate :( I agree, but that's the way it is in current (non-standard) implementations. >=20 > In nearly all IETF protocols, the message trailer or EOL=20 > marker is CR-LF. If we go for a very simplistic tcp transport, there is nothing that hinders us in chaning it to CR-LF. That would also be compatible to existing receivers, as LF thankfully comes after CR... Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 12:25:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebtY-00030s-Np; Tue, 22 Nov 2005 12:25:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebtX-00030M-G2 for syslog@megatron.ietf.org; Tue, 22 Nov 2005 12:25:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15417 for ; Tue, 22 Nov 2005 12:24:49 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EecCE-0007Nz-PV for syslog@ietf.org; Tue, 22 Nov 2005 12:44:47 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id A28489C00C; Tue, 22 Nov 2005 18:33:37 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00822-02; Tue, 22 Nov 2005 18:33:33 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 7EA649C00B; Tue, 22 Nov 2005 18:33:33 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Nov 2005 18:24:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3ED7@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXvhRXMJhbbLZUdQ5yWLNnOSACYJwAAx5pw From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > WG, > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG >=20 > I would put the SD-IDs after the message. This raises the question of what terminates the MSG part ;) That would mean we would need to introduce byte-counting, at least I think so. Other than that, I, too would find it better to place it at the end. On the other hand, a -protocol compliant syslogd could take out SD-IDs and put them after the message (or even discard them if the operator is not interested --> configuration option [not a protocol issue]). At least this was what I have on mind about how to implement it. >=20 > The SD-IDs and detailed bits of meaning to the MSG and without the > MSG, are irrelevant. The exception being a language marker. >=20 > > - replace NUL with an escape sequence upon reception (e.g. <00>) >=20 > Why not \0 ? That's another good choice. My point was that most implementations would do some modification on reception. That means a relay could actually *alter* the message, which in turn would break signatures. If we require relays to handle \0 correctly, that will probably cause a lot of trouble to existing syslogd code. That was my main message. Is it better to live with that or introduce a CLR on not allowing NUL? Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 12:43:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecAd-0004OI-1p; Tue, 22 Nov 2005 12:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecAb-0004Na-9I for syslog@megatron.ietf.org; Tue, 22 Nov 2005 12:43:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16930 for ; Tue, 22 Nov 2005 12:42:26 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EecT6-0008Fh-0R for syslog@ietf.org; Tue, 22 Nov 2005 13:02:13 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 22 Nov 2005 09:42:36 -0800 X-IronPort-AV: i="3.97,362,1125903600"; d="scan'208"; a="677615427:sNHT1136792508" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAMHgDsG029982; Tue, 22 Nov 2005 09:42:32 -0800 (PST) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 09:42:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Tue, 22 Nov 2005 09:42:28 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FBE9DE33@xmb-sjc-236.amer.cisco.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXvhWEgwcnXS3zNQjaFPqY9FA3kDgABmj7w From: "Alexander Clemm \(alex\)" To: "Darren Reed" , "Rainer Gerhards" X-OriginalArrivalTime: 22 Nov 2005 17:42:30.0494 (UTC) FILETIME=[1CA4A7E0:01C5EF8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org My preference would be to keep structured data before MSG. This way, it can effectively be treated as an "extended header". =20 --- Alex -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed Sent: Tuesday, November 22, 2005 8:51 AM To: Rainer Gerhards Cc: syslog@ietf.org Subject: Re: [Syslog] New direction and proposed charter > WG, > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG I would put the SD-IDs after the message. The SD-IDs and detailed bits of meaning to the MSG and without the MSG, are irrelevant. The exception being a language marker. > - replace NUL with an escape sequence upon reception (e.g. <00>) Why not \0 ? Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 12:43:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecAp-0004YI-DU; Tue, 22 Nov 2005 12:43:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecAn-0004Wl-Gb for syslog@megatron.ietf.org; Tue, 22 Nov 2005 12:43:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17049 for ; Tue, 22 Nov 2005 12:42:38 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EecQr-000818-9S for syslog@ietf.org; Tue, 22 Nov 2005 12:59:53 -0500 Received: from pc6 (1Cust79.tnt9.lnd4.gbr.da.uu.net [62.188.138.79]) by blaster.systems.pipex.net (Postfix) with SMTP id 365BBE00036F; Tue, 22 Nov 2005 17:40:15 +0000 (GMT) Message-ID: <030f01c5ef83$28eb7140$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] New direction and proposed charter Date: Tue, 22 Nov 2005 17:06:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org MSGID in the header is what I most want to see (and I believe that a well chosen message id makes an application field redundant) total backward compatability is too much a bar to progress (as dbh says). is worth it if it increases the number of implementations (not because it does or does not affect backward compatability) internationalisation is a big can of worms; I think specifying UTF8 as we have done is as far as we should go otherwise, no strong disagreements Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Monday, November 21, 2005 8:11 PM Subject: [Syslog] New direction and proposed charter > > I'd like for us to come to closure on some things. I'm going to be a bit > direct on these questions so we can focus quicker. We really need for > people to send in responses to see who's listening and involved. > > >From the meeting, it sounds like we will get many more implementations if > we continue to use ... at the start of syslog messages. This will > allow current receivers to continue to receive messages and put them in > the right bins. Does anyone disagree with this? > > The WG has agreed to use the timestamp Rainer has in the current > syslog-protocol. > > Using the FQDN and numeric notations for IPv4 and IPv6 addresses has been > agreed to. > > Putting in the Structured Data still seems like a great evolutionary step > for syslog. I'd like to see that go into the new syslog-protocol. Does > anyone disagree with this? > > Should we continue to have the MSGID in the header, or should that become > an SD-ID element? > > We've had slow-downs in our prior discussions about truncation and message > length. To complete this work without revisiting those discussions, and > in the spirit of backwards compliance with traditional syslog, I propose > that we accept the length as Rainer has proposed in syslog-protocol, and > disallow any device to truncate the messages. At some future time, > someone can augment the syslog-protocol standard and define a mechanism > and signalling that will allow truncation. Does anyone disagree with > this? > > Encoding has been discussed and we have agreed upon US-ASCII and UTF-8 in > appropriate places. Could we add a language tag as an element in an > SD-ID to indicate the language of the MSG? > > We need a version. Should that be in the header (after ), or as an > element in an SD-ID? > > One possibility would be to assemble a syslog message as: > > TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG > > If we can agree to this then I suspect that we can have a working document > within Rainer's timeframe. I'll propose the following charter to keep us > focused. > > -------- Proposed Charter -------------- > > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it > has some known security problems which were documented in RFC 3164. > > The goal of this working group is to address the security and > integrity problems of the existing syslog mechanism while not breaking > backwards compatibility. The most obvious problems that need to be > addressed in the syslog protocol are the timestamp, which has not > formally included a means to indicate the year, and the identification > of the source which has been a hostname without a qualified domain > name. Additionally, a version, some type of message indicator, and a > means to convey structured data will be included in the protocol. > > syslog has traditionally been transported over UDP and this WG has > already defined RFC 3195 for the reliable transport for the syslog > messages. The WG will separate the UDP transport from the protocol so > that others may define additional transports in the future. > > - A standard will be produced that formally documents the syslog > protocol. A mechanism will also be defined in this specification > that will provide a means to convey structured data. > > - A standard will be produced that documents the UDP transport for > syslog. > > - A standard will be produced that documents a mechanism to sign > syslog messages to provide integrity checking and source > authentication. > > - A MIB definition for syslog will be produced. > > ------------------------------------------- > > PLEASE review this and respond. > > Thanks, > Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 12:44:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecBd-0004wv-UU; Tue, 22 Nov 2005 12:44:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecBF-0004oL-C1 for syslog@megatron.ietf.org; Tue, 22 Nov 2005 12:43:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17372 for ; Tue, 22 Nov 2005 12:43:06 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EecFz-0007Zk-2u for syslog@ietf.org; Tue, 22 Nov 2005 12:48:39 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id CF5A09C00C; Tue, 22 Nov 2005 18:37:29 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00822-03; Tue, 22 Nov 2005 18:37:26 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 102359C00B; Tue, 22 Nov 2005 18:37:26 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Nov 2005 18:28:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3ED8@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXvhWPR6C8njUk4TJahQIgDA5fwXgAAFQCQAAEBHIA= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton:=20 > > > WG, > > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG > >=20 > > I would put the SD-IDs after the message. > >=20 > > The SD-IDs and detailed bits of meaning to the MSG and=20 > > without the MSG, are irrelevant. The exception being a=20 > > language marker. >=20 > I would prefer SD-ID where it is in example. I would also=20 > re-iterate suggestion of having MSGID in the header, which a=20 > number of people supported. Those two combined are arguably=20 > more important than the MSG part itself. For example (in=20 > abbreviated syntax: >=20 > host.domain.com MyApp proc1234 STARTED_UP [ip=3D1.1.1.1]: The=20 > applications has started >=20 > I could live without the MSG here if it got truncated. The=20 > MSGID and SD-ID are much more important in this case. BTW,=20 > the possible truncation of text and its variability (possible=20 > substitutable variables) is another reason why MSGID is so=20 > useful. It makes it easier for intelligent receivers to do=20 > things like event correlation.=20 I, too, would like to see the MSGID in the header, just as this VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [SD-ID]s MSG The issue is that we come closer and closer to the current syslog-protocol-15 header with just the . While this would be a workable (and probably good) solution in my point of view, I have heared some voices that would like to see fewer fields. I just caution to pull out APP-NAME and PROCID and leave MSGID, because I would bet more than one virtual can of beer that implementors will say "ah, MSGID is what was called TAG" - and use it in that spirit. That would give us the worst of both worlds... Rainer >=20 > Thanks, > Anton.=20 >=20 > >=20 > > > - replace NUL with an escape sequence upon reception (e.g. <00>) > >=20 > > Why not \0 ? > >=20 > > Darren > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 12:48:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecFp-00064x-9O; Tue, 22 Nov 2005 12:48:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecFn-00064s-TZ for syslog@megatron.ietf.org; Tue, 22 Nov 2005 12:48:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18183 for ; Tue, 22 Nov 2005 12:47:49 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EecYU-0000Mp-9v for syslog@ietf.org; Tue, 22 Nov 2005 13:07:47 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 22 Nov 2005 09:48:18 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAMHmGCN015781; Tue, 22 Nov 2005 09:48:17 -0800 (PST) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 09:48:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Tue, 22 Nov 2005 09:48:01 -0800 Message-ID: Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXvhWPR6C8njUk4TJahQIgDA5fwXgAAFQCQAAEUrvA= From: "Steve Chang \(schang99\)" To: "Anton Okmianski \(aokmians\)" , "Darren Reed" , "Rainer Gerhards" X-OriginalArrivalTime: 22 Nov 2005 17:48:03.0773 (UTC) FILETIME=[E34AFED0:01C5EF8C] X-Spam-Score: 0.9 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, I would like to second Anton's view on MSGID and SD-ID position. In my implementation, APP-NAME, MSGID and Severity (part of PRI) are used to uniquely identify a message. With those 3 fields, we can have very good sense on the nature of the event notification at the receiver side. Even the message could have been truncated; we can use those fields to look up what could have been included in the message body. So, it's OK to live with possibility that some part of the message can be truncated. The SD section is used to carries other useful and possible some critical information which may not be directly related to the MSG itself. By keeping it where it is, i.e. before MSG (which tends to be long), will make it less likely to be truncated. =20 Thanks, Steve > -----Original Message----- > From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Anton Okmianski (aokmians) > Sent: Tuesday, November 22, 2005 9:04 AM > To: Darren Reed; Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 > Darren: >=20 > > > WG, > > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG > > > > I would put the SD-IDs after the message. > > > > The SD-IDs and detailed bits of meaning to the MSG and > > without the MSG, are irrelevant. The exception being a > > language marker. >=20 > I would prefer SD-ID where it is in example. I would also re-iterate > suggestion of having MSGID in the header, which a number of people > supported. Those two combined are arguably more important than the MSG > part itself. For example (in abbreviated syntax: >=20 > host.domain.com MyApp proc1234 STARTED_UP [ip=3D1.1.1.1]: The applications > has started >=20 > I could live without the MSG here if it got truncated. The MSGID and SD-ID > are much more important in this case. BTW, the possible truncation of > text and its variability (possible substitutable variables) is another > reason why MSGID is so useful. It makes it easier for intelligent > receivers to do things like event correlation. >=20 > Thanks, > Anton. >=20 > > > > > - replace NUL with an escape sequence upon reception (e.g. <00>) > > > > Why not \0 ? > > > > Darren > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 22:20:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EelBk-0006u7-KA; Tue, 22 Nov 2005 22:20:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EelBi-0006tY-J8 for syslog@megatron.ietf.org; Tue, 22 Nov 2005 22:20:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29451 for ; Tue, 22 Nov 2005 22:20:09 -0500 (EST) Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EelUT-0002F1-7e for syslog@ietf.org; Tue, 22 Nov 2005 22:40:14 -0500 Received: (qmail 13446 invoked from network); 23 Nov 2005 03:20:40 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 23 Nov 2005 03:20:40 -0000 X-pair-Authenticated: 202.137.242.74 From: "Andrew Ross" To: "'Rainer Gerhards'" , "'Anton Okmianski \(aokmians\)'" , "'Darren Reed'" Date: Wed, 23 Nov 2005 16:20:35 +1300 Organization: Kiwi Enterprises Message-ID: <005601c5efdc$e0396ab0$d901a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3ED8@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org Subject: [Syslog] Message format X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org WG, Sorry for joining in the discussion late. I've only just found some time = to reply. My thoughts below... The new format looks great. VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [SD-ID]s MSG Replace all received null characters with either <00> or /0. My = preference is <00>. Keep MSGID in the header as a required field SD-IDs should come before the MSG. Otherwise encoding issues and MSG delimiter will become a problem. Store all messages written to disk in UTF-8 format. This allows any = received encoding to be stored safely without loss or corruption. My preference is to enforce UTF-8 for data encoding on the wire. This = allows US-ASCII to be used for the first 127 characters and Unicode mappings = into UTF-8 for all other international characters. Trying to switch encodings = for each message based on the SD-ID language or local setting will be a = parsing nightmare. As far as I know, all modern systems are now capable of = sending in US-ASCII or mapping their own language into UTF-8. Can anyone think = of a good reason not to enforce UTF-8? I believe the above format would be easy to implement in both a sender = and receiver. Mandating that the disk storage format is UTF-8 would also = help reporting and parsing of all languages and character sets.=20 Mapping over UDP should be limited to a single message per packet. When mapping over plain TCP I believe we should limit the total message = size to 65507 bytes (to keep it compatible with UDP) and delimit each message stream with an LF, or CRLF. Either delimiter would work for me. Rainer, keep up your good work and persistence on the drafts. I believe = the new format will solve a lot of problems. Cheers Andrew _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 22 23:31:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EemHg-00022m-Mt; Tue, 22 Nov 2005 23:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EemHf-00022b-AR for syslog@megatron.ietf.org; Tue, 22 Nov 2005 23:31:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06460 for ; Tue, 22 Nov 2005 23:30:24 -0500 (EST) Received: from [63.240.77.82] (helo=sccrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EemaS-0005vG-Ab for syslog@ietf.org; Tue, 22 Nov 2005 23:50:28 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc12) with SMTP id <200511230430440120025emje>; Wed, 23 Nov 2005 04:30:53 +0000 From: "David B Harrington" To: , "'Rainer Gerhards'" , "'Anton Okmianski \(aokmians\)'" , "'Darren Reed'" Subject: RE: [Syslog] Message format Date: Tue, 22 Nov 2005 23:30:11 -0500 Message-ID: <00c701c5efe6$a7145010$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXv3RR11XwsJI5xS8G+M9u5oqI+0QACUwsA In-Reply-To: <005601c5efdc$e0396ab0$d901a8c0@KiwiAndrew> X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, The IETF focuses on on-the-wire formats; we don't typically mandate how one stores data after it is received. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Andrew Ross > Sent: Tuesday, November 22, 2005 10:21 PM > To: 'Rainer Gerhards'; 'Anton Okmianski (aokmians)'; 'Darren Reed' > Cc: syslog@ietf.org > Subject: [Syslog] Message format > > > WG, > > Sorry for joining in the discussion late. I've only just > found some time to > reply. > > My thoughts below... > > The new format looks great. > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [SD-ID]s MSG > > Replace all received null characters with either <00> or /0. > My preference > is <00>. > > Keep MSGID in the header as a required field > > SD-IDs should come before the MSG. Otherwise encoding issues and MSG > delimiter will become a problem. > > Store all messages written to disk in UTF-8 format. This > allows any received > encoding to be stored safely without loss or corruption. > > My preference is to enforce UTF-8 for data encoding on the > wire. This allows > US-ASCII to be used for the first 127 characters and Unicode > mappings into > UTF-8 for all other international characters. Trying to > switch encodings for > each message based on the SD-ID language or local setting > will be a parsing > nightmare. As far as I know, all modern systems are now > capable of sending > in US-ASCII or mapping their own language into UTF-8. Can > anyone think of a > good reason not to enforce UTF-8? > > I believe the above format would be easy to implement in both > a sender and > receiver. Mandating that the disk storage format is UTF-8 > would also help > reporting and parsing of all languages and character sets. > > Mapping over UDP should be limited to a single message per packet. > > When mapping over plain TCP I believe we should limit the > total message size > to 65507 bytes (to keep it compatible with UDP) and delimit > each message > stream with an LF, or CRLF. Either delimiter would work for me. > > Rainer, keep up your good work and persistence on the drafts. > I believe the > new format will solve a lot of problems. > > Cheers > > Andrew > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 00:07:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eemqq-00039W-Pp; Wed, 23 Nov 2005 00:07:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eemqp-00037e-E5 for syslog@megatron.ietf.org; Wed, 23 Nov 2005 00:07:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09692 for ; Wed, 23 Nov 2005 00:06:44 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Een9a-0007eU-JM for syslog@ietf.org; Wed, 23 Nov 2005 00:26:48 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAN56tvl023011; Wed, 23 Nov 2005 16:06:55 +1100 (EST) From: Darren Reed Message-Id: <200511230506.jAN56QgI023214@firewall.reed.wattle.id.au> Subject: Re: [Syslog] New direction and proposed charter In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3ED7@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Wed, 23 Nov 2005 16:06:26 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, Darren Reed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > > WG, > > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG > > > > I would put the SD-IDs after the message. > > This raises the question of what terminates the MSG part ;) Using the above syntax, how do you distinguish between [] at the start of the message from actualy SD-ID data? I think what's missing from the above, is a ':' and the syntax should be: VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]: MSG The protocol document needs to outlaw ':' being in any field before the MSG. If you mark "VERSION", "PROCID" and "SD-ID" data as all being optional then the format comes back to being very close to what's in use today. > That would > mean we would need to introduce byte-counting, at least I think so. Well, without the ':' to say where the MSG starts, I'd have argued "How do you tell where SD-ID ends and MSG starts?" vs there just being a string of bad SD-ID data following some good SD-ID data. As for "but the SD has important information and the MSD does not", that's simply a matter of how you structure the message. > > > - replace NUL with an escape sequence upon reception (e.g. <00>) > > > > Why not \0 ? > > That's another good choice. It's also how data gets escaped, in general, in Internet stuff. > That was my main message. Is it better to live > with that or introduce a CLR on not allowing NUL? I'd like to see NUL outlawed from messages. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 03:09:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EephW-0008KF-H4; Wed, 23 Nov 2005 03:09:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EephV-0008JK-4s for syslog@megatron.ietf.org; Wed, 23 Nov 2005 03:09:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24868 for ; Wed, 23 Nov 2005 03:09:17 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eeq0I-0008Rp-Mj for syslog@ietf.org; Wed, 23 Nov 2005 03:29:24 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id E90DB9C00C; Wed, 23 Nov 2005 09:18:03 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01117-10; Wed, 23 Nov 2005 09:18:00 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 62A789C00B; Wed, 23 Nov 2005 09:18:00 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 09:09:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EDE@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXv68fc0QvX3Wr+S5SykHvtsUaj2gAGDzZQ From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org comments inline... And an important question for the WG close to the end of the message! Rainer=20 > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Wednesday, November 23, 2005 6:06 AM > To: Rainer Gerhards > Cc: Darren Reed; syslog@ietf.org > Subject: Re: [Syslog] New direction and proposed charter >=20 > > > > WG, > > > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG > > >=20 > > > I would put the SD-IDs after the message. > >=20 > > This raises the question of what terminates the MSG part ;) >=20 > Using the above syntax, how do you distinguish between [] at the start > of the message from actualy SD-ID data? I used the "short" syntax Chris used in his proposal. The full ABNF would be: VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP [SD-ID]s SP MSG This follows the IETF-tradition of SP-delemiting header fields. The SD-IDs are clearly parsable based on that SP. -protcol-15 has the details (everything from there would still apply). >=20 > I think what's missing from the above, is a ':' and the syntax should > be: >=20 > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]: MSG >=20 > The protocol document needs to outlaw ':' being in any field before > the MSG. >=20 > If you mark "VERSION", "PROCID" and "SD-ID" data as all being optional > then the format comes back to being very close to what's in use today. PROCID and SD-ID are optional (but need to have "-" if non-present. Version, IMHO, should NOT be optional because this will be a live-safer when we do the next iteration of the protocol in the future. It also shouldn't be a big deal to stick a "1" character in that position... >=20 > > That would > > mean we would need to introduce byte-counting, at least I think so. >=20 > Well, without the ':' to say where the MSG starts, I'd have argued > "How do you tell where SD-ID ends and MSG starts?" vs there just being > a string of bad SD-ID data following some good SD-ID data. If we have bad SD-ID data, than we have a bad message. I do not think that it is appropriate to try to process bad data - there has been too many security vulnerabilities because of this in recent days... >=20 > As for "but the SD has important information and the MSD does not", > that's simply a matter of how you structure the message. I agree on that. Trunction is always bad.. >=20 > > > > - replace NUL with an escape sequence upon reception (e.g. <00>) > > >=20 > > > Why not \0 ? > >=20 > > That's another good choice. >=20 > It's also how data gets escaped, in general, in Internet stuff. >=20 > > That was my main message. Is it better to live > > with that or introduce a CLR on not allowing NUL? >=20 > I'd like to see NUL outlawed from messages. That would indeed solve a number of issues. The last time we discussed this, it was consensus that this would be a CLR ("crappy little rule") that we wanted to avoid. In the sense of the current discussion: do we still think this is true?=20 Question to WG: should we outlaw NUL from MSG? Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 03:23:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eepu9-00056F-S1; Wed, 23 Nov 2005 03:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eepu8-00053G-D3 for syslog@megatron.ietf.org; Wed, 23 Nov 2005 03:23:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26519 for ; Wed, 23 Nov 2005 03:22:20 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeqCx-0000ue-IA for syslog@ietf.org; Wed, 23 Nov 2005 03:42:27 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id BF2B79C00D; Wed, 23 Nov 2005 09:31:13 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01363-06; Wed, 23 Nov 2005 09:31:10 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 2D4039C00B; Wed, 23 Nov 2005 09:31:10 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 09:22:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EE1@grfint2.intern.adiscon.com> Thread-Topic: Message format Thread-Index: AcXv3ObRgC2QjBkEQ/qz/wtKHo7DrgAKZQ/g From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org Subject: [Syslog] RE: Message format X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Andrew, (snipped for brevity) > Mapping over UDP should be limited to a single message per packet. I agree on that. If we need an ultra-compact UDP delivery, we could later add it in a separate transport mapping. > When mapping over plain TCP I believe we should limit the=20 > total message size > to 65507 bytes (to keep it compatible with UDP) and delimit=20 > each message > stream with an LF, or CRLF. Either delimiter would work for me. I would prefer not to restart the size discussion at this point. I think the current compromise (everyone must support 2K, anyone might support as much as he likes) is sufficient for most, if not all, cases. I would not like to see an application to become non-compliant just because it needs to transmit 65508 bytes inside a message. Rainer=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 03:33:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeq4A-0001xj-6v; Wed, 23 Nov 2005 03:33:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeq49-0001xe-Bt for syslog@megatron.ietf.org; Wed, 23 Nov 2005 03:33:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27312 for ; Wed, 23 Nov 2005 03:32:41 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeqMy-0001Nc-GZ for syslog@ietf.org; Wed, 23 Nov 2005 03:52:48 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 962089C00D; Wed, 23 Nov 2005 09:41:34 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01457-04; Wed, 23 Nov 2005 09:41:29 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id CB6339C00B; Wed, 23 Nov 2005 09:41:29 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] RE: Message format MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 09:33:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EE3@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] RE: Message format Thread-Index: AcXv3ObRgC2QjBkEQ/qz/wtKHo7DrgAKZQ/gAABQ+fA= From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Andrew & WG, a follow-up to my own posting, just some extra information.=20 > > When mapping over plain TCP I believe we should limit the=20 > > total message size > > to 65507 bytes (to keep it compatible with UDP) and delimit=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Anton and other already cautioned against using too-large UDP message sizes. I just want to throw in some of our practical experiences. I've done some testing on Windows and Linux, and the result is that UDP practical maximum tends to be around 4K. It is documented here: http://www.monitorware.com/Common/en/articles/ihe-syslog.php Of course, other software might modify the IP stack with different parameters. The rsyslogd I have tested with is derived from stock Linux syslogd, so that quite popular system is experiencing the same issue. While I always tell we need to allow larger-size messages, we need to be very careful when thinking about UDP. My testing did not even look into message loss and out-of-order delivery. For UDP, I consider the practical upper limit to be 4K.=20 Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 03:53:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeqNH-0003je-KC; Wed, 23 Nov 2005 03:53:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeqNG-0003jZ-6P for syslog@megatron.ietf.org; Wed, 23 Nov 2005 03:53:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29197 for ; Wed, 23 Nov 2005 03:52:26 -0500 (EST) Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eeqg4-0002Xu-JF for syslog@ietf.org; Wed, 23 Nov 2005 04:12:33 -0500 Received: (qmail 13439 invoked from network); 23 Nov 2005 08:52:56 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 23 Nov 2005 08:52:56 -0000 X-pair-Authenticated: 222.152.84.12 From: "Andrew Ross" To: "'Rainer Gerhards'" Date: Wed, 23 Nov 2005 21:52:52 +1300 Organization: Kiwi Enterprises Message-ID: <000c01c5f00b$4ae204c0$d9a8a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3EE1@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org Subject: [Syslog] RE: Message format X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >> Mapping over UDP should be limited to a single message per packet. >I agree on that. If we need an ultra-compact UDP delivery, we could >later add it in a separate transport mapping. Yes, good idea. I doubt anyone will ever want to do this, or at least go = to the effort of trying to get it drafted into an RFC ;-) >> When mapping over plain TCP I believe we should limit the=20 >> total message size >> to 65507 bytes (to keep it compatible with UDP) and delimit=20 >> each message >> stream with an LF, or CRLF. Either delimiter would work for me. >I would prefer not to restart the size discussion at this point. I = think >the current compromise (everyone must support 2K, anyone might support >as much as he likes) is sufficient for most, if not all, cases. I would >not like to see an application to become non-compliant just because it >needs to transmit 65508 bytes inside a message. I realise this should have been brought up earlier in the draft process, however, I would really like to see a limit on the message size so that = it is directly compatible with UDP. If we allow an opened ended message = size, people *will* use it for non syslog related things. I feel that any = message longer than will fit into a UDP packet should be broken into two or more separate messages by the sender, even if sent over TCP. This allows me = to allocate a maximum known buffer size for incoming TCP messages. There is = a potential for huge messages filling the memory and memory buffer = overflows happening if the messages are not limited in size. "Syslog" is meant to = be a human readable system log message. Anything longer (including binary = crash dumps or other things people misuse syslog for) should be broken into separate messages by the sender, or sent over a different protocol. I think we should keep syslog simple and flexible, but not at the = expense of making it handle things it was never meant for. If a message needs to be broken into many chunks, the SD-ID tags could be used to tie all the messages together again by the parser. The syslog receiver or relay will just handle them as separate messages and not even know they were split. This makes things so much simpler. Cheers Andrew _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 04:00:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeqUT-0006Yg-3R; Wed, 23 Nov 2005 04:00:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeqUR-0006Xr-8f for syslog@megatron.ietf.org; Wed, 23 Nov 2005 04:00:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29853 for ; Wed, 23 Nov 2005 03:59:51 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeqnG-0002uU-AB for syslog@ietf.org; Wed, 23 Nov 2005 04:19:59 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 3990C9C00C; Wed, 23 Nov 2005 10:08:44 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01363-10; Wed, 23 Nov 2005 10:08:40 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 74BC39C00B; Wed, 23 Nov 2005 10:08:40 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] RE: Message format MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 10:00:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EE6@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] RE: Message format Thread-Index: AcXwCwQxNsL4MSo7TuCC6eisdnNdywAAE/ig From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Andrew, on the size: Though I have some concerns, I can agree with your point of view. In fact, one of the syslog-protocol revisions had a mechanism called multi-part messages. This could be utilized. Maybe we should do a separate spec on "large size messages". That wouldn't be too much effort and be a truely optional feature (I even think we could simply carry over the text from that draft version). What I am currently concerned about is putting this size issue to a rest. I think the compromise is good enough, especially as we do NOT yet specify a plain tcp mapping (we even don't know if we will ever get consensus to do that). That means the currently proposed text keeps the options open to do anything we might later decide. And it acutally puts a hard limit to roughly 64K by the fact that only UDP is supported. As I have outlined in another mail, that practical limit seems to be more 4K than 64K. Given that situation, I strongly suggest not to get another round of max size discussion. I think we urgently need now a consensus on the lowest denominator and get that consensus published. Else we will be discussing and discussing but never achive any milestone. I like the approach of baby-steps, which will give us something usable after each step. The core thing we need to do is have a format specification including layered architecture) that allows us to build on. Then, I think, we can focus on specific issues. Rainer > -----Original Message----- > From: Andrew Ross [mailto:andrew@kiwisyslog.com]=20 > Sent: Wednesday, November 23, 2005 9:51 AM > To: Rainer Gerhards > Subject: RE: [Syslog] RE: Message format >=20 >=20 > >> Mapping over UDP should be limited to a single message per packet. > >I agree on that. If we need an ultra-compact UDP delivery, we could > >later add it in a separate transport mapping. >=20 > Yes, good idea. I doubt anyone will ever want to do this, or=20 > at least go to > the effort of trying to get it drafted into an RFC ;-) >=20 > >> When mapping over plain TCP I believe we should limit the=20 > >> total message size > >> to 65507 bytes (to keep it compatible with UDP) and delimit=20 > >> each message > >> stream with an LF, or CRLF. Either delimiter would work for me. >=20 > >I would prefer not to restart the size discussion at this=20 > point. I think > >the current compromise (everyone must support 2K, anyone=20 > might support > >as much as he likes) is sufficient for most, if not all,=20 > cases. I would > >not like to see an application to become non-compliant just=20 > because it > >needs to transmit 65508 bytes inside a message. >=20 > > I realise this should have been brought up earlier in the=20 > draft process, > however, I would really like to see a limit on the message=20 > size so that it > is directly compatible with UDP. If we allow an opened ended=20 > message size, > people *will* use it for non syslog related things. I feel=20 > that any message > longer than will fit into a UDP packet should be broken into=20 > two or more > separate messages by the sender, even if sent over TCP. This=20 > allows me to > allocate a maximum known buffer size for incoming TCP=20 > messages. There is a > potential for huge messages filling the memory and memory=20 > buffer overflows > happening if the messages are not limited in size. "Syslog"=20 > is meant to be a > human readable system log message. Anything longer (including=20 > binary crash > dumps or other things people misuse syslog for) should be broken into > separate messages by the sender, or sent over a different protocol. > >=20 > I think we should keep syslog simple and flexible, but not at=20 > the expense of > making it handle things it was never meant for. If a message=20 > needs to be > broken into many chunks, the SD-ID tags could be used to tie all the > messages together again by the parser. The syslog receiver or=20 > relay will > just handle them as separate messages and not even know they=20 > were split. > This makes things so much simpler. >=20 > Cheers >=20 > Andrew >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 04:15:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeqjE-0006Hb-O6; Wed, 23 Nov 2005 04:15:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeqjC-0006Dv-0a for syslog@megatron.ietf.org; Wed, 23 Nov 2005 04:15:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01448 for ; Wed, 23 Nov 2005 04:15:05 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eer20-0003iH-3v for syslog@ietf.org; Wed, 23 Nov 2005 04:35:13 -0500 Subject: RE: [Syslog] New direction and proposed charter From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3ECE@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E3ECE@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Wed, 23 Nov 2005 10:15:39 +0100 Message-Id: <1132737339.8374.7.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi everyone, Just in case someone doesn't know me (would not be too suprising as I have not posted to the list recently) I'm the author for syslog-ng a popular syslog implementation for various UNIXes. To be honest apart from being subscribed to this list I have not followed the discussions recently (the reasons are more or less explained in the last couple of mails by others), but I see the new proposals for the changed charter a sign in the good direction. And the new format for syslog-protocol is something that I personally like, so for what it's worth I support the format and I'm willing to implement support for this or a similar format in syslog-ng. > We have had several comments on the field order in syslog-protocol. > Based on them, I propose the following format: > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG > > With (optional) SD-IDs for > - Extended Facility > - TRUNCATE > - MSGID > - [Language Identification] > -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 06:02:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EesOW-0004aT-82; Wed, 23 Nov 2005 06:02:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EesOV-0004aL-6p for syslog@megatron.ietf.org; Wed, 23 Nov 2005 06:02:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13881 for ; Wed, 23 Nov 2005 06:01:52 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeshL-0001g2-DW for syslog@ietf.org; Wed, 23 Nov 2005 06:21:59 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 010FB9C00C for ; Wed, 23 Nov 2005 12:10:44 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01565-07 for ; Wed, 23 Nov 2005 12:10:40 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 55B5B9C00B for ; Wed, 23 Nov 2005 12:10:40 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 12:02:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EF1@grfint2.intern.adiscon.com> Thread-Topic: APP-NAME, PROCID, MSGID & non-IETF standards Thread-Index: AcXwHVo01NWLk7Q1TCCf+m1aoMRBaA== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] APP-NAME, PROCID, MSGID & non-IETF standards X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org WG, we have been discussing which of these fields to include as required in the header. This discussion so far has not looked at existing technology and standards. I am not talking about backwards-compatibility at the protocol level, but rather about the "real" log emitors, the applications. A very common use for syslog is event notification under Unix, Linux and similar systems. There is a system call (API) to do that. This system call is not necessarily be bound to network syslog format. Depending on syslogd configuration, only local logging might be involved. As such, this part of the "syslog process" is completely beyond IETF-control. However, the way the APIs are standardized there has some effect on what we can do on the wire. In POSIX, only a single string is specified to be used for identifying a message (besides, of course, the message itself). The same is true for glibc on Linux and other platforms. The concept of a MSGID is unknown to both. glibc extends the caller-provided string by the process ID and a colon and blank is appended to it. E.g. "myname" will become "myname[processid]: ". This is put into the field we currently know as TAG. The reason I am telling this is that we must find a way that a new, -protocol compliant syslogd can obtain the information it needs to put into the fields. I think we can not wait until the POSIX standard or glibc is updated (if ever). Even if they add support, probably the vast amount of software would still use the previous API and thus not provide any more information. For APP-NAME and PROCID, a new syslogd can extract the information from what is logged by the applications. It can subparse the TAG value (received via local interprocess communication, some kind of API) and extract them (APP-NAME is everything before the first '[', PROCID the value between '[' and ']'). MSGID must be set to unknown ('-'), but this is not problematic in such cases. Of course, newer software can call into an enhanced syslog library which fills all fields natively. But I think we must support the currently existing API. If we go for just MSGID, I have no way of mapping with the existing API other than to put the current TAG value into it. That would not be benefitial. So my reason for insisting on all three header fields is that we must support existing non-IETF standards and APIs while still enabling new devices and programs to support advanced format. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 07:39:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EetuH-0001jn-JM; Wed, 23 Nov 2005 07:39:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EetuG-0001ig-B6 for syslog@megatron.ietf.org; Wed, 23 Nov 2005 07:39:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23445 for ; Wed, 23 Nov 2005 07:38:44 -0500 (EST) Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeuD6-0006Bq-8B for syslog@ietf.org; Wed, 23 Nov 2005 07:58:52 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jANCd7nR020953 for ; Wed, 23 Nov 2005 21:39:07 +0900 (JST) Received: from [127.0.0.1] (bert.priv.cysol.co.jp [192.168.0.254]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jANCd6Ic023945 for ; Wed, 23 Nov 2005 21:39:07 +0900 (JST) Message-ID: <438462EA.30901@cysols.com> Date: Wed, 23 Nov 2005 21:39:06 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] New direction and proposed charter References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris/Rainer, > we continue to use ... at the start of syslog messages. This will > allow current receivers to continue to receive messages and put them in > the right bins. Does anyone disagree with this? Complete agreement. > > > The WG has agreed to use the timestamp Rainer has in the current > syslog-protocol. In principle I agree with the timestamp format. It is good. I may have missed the discussion on this matter, in that case please accept my apologies and ignore the rest of the mail. To get existing BSD syslog devices specifically relays into the compatibility fold it WILL be good idea to keep the timestamp in two parts RainerTimestamp = BSD_syslog_timestamp + RemainderTimestamp > One possibility would be to assemble a syslog message as: > > TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG In the context of what has been said above about the timestamp. I would suggest BSD_syslog_timestamp FQDN VERSION MSGID Remainder_Timestamp [SD-ID]s MSG That would allow existing BSD-syslog relays to handle the new syslog protocol in a transparent manner. Everything from VERSION to the end is treated as "message". We do not lose information. The Remainder_timestamp carries it - in a slightly less convenient place though. On the other hand if we insist on using RainerTimestamp, existing BSD_syslog relays will relay the message as BSD_syslog_timestamp FQDN RainerTimestamp FQDN VERSION MSGID [SD-ID]s MSG The message does get distorted to some extent. > If we can agree to this then I suspect that we can have a working > document within Rainer's timeframe. I'll propose the following charter > to keep us focused. > > -------- Proposed Charter -------------- > > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it > has some known security problems which were documented in RFC 3164. > > The goal of this working group is to address the security and > integrity problems of the existing syslog mechanism while not breaking > backwards compatibility. The most obvious problems that need to be > addressed in the syslog protocol are the timestamp, which has not > formally included a means to indicate the year, and the identification > of the source which has been a hostname without a qualified domain > name. Additionally, a version, some type of message indicator, and a > means to convey structured data will be included in the protocol. > > syslog has traditionally been transported over UDP and this WG has > already defined RFC 3195 for the reliable transport for the syslog > messages. The WG will separate the UDP transport from the protocol so > that others may define additional transports in the future. > > - A standard will be produced that formally documents the syslog > protocol. A mechanism will also be defined in this specification > that will provide a means to convey structured data. > > - A standard will be produced that documents the UDP transport for > syslog. > > - A standard will be produced that documents a mechanism to sign > syslog messages to provide integrity checking and source > authentication. > > - A MIB definition for syslog will be produced. > > ------------------------------------------- > > > PLEASE review this and respond. > Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 08:36:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeunq-0007m7-8W; Wed, 23 Nov 2005 08:36:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeunn-0007lw-QX for syslog@megatron.ietf.org; Wed, 23 Nov 2005 08:36:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00875 for ; Wed, 23 Nov 2005 08:36:08 -0500 (EST) Received: from ext-ch1gw-7.online-age.net ([64.37.194.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eev6d-0001PA-H9 for syslog@ietf.org; Wed, 23 Nov 2005 08:56:17 -0500 Received: from int-ch1gw-1.online-age.net (int-ch1gw-1 [3.159.232.65]) by ext-ch1gw-7.online-age.net (8.13.4/8.13.5/20051111-SVVS-TLS-DNSBL) with ESMTP id jANDaTaH029204 for ; Wed, 23 Nov 2005 08:36:29 -0500 Received: from cinmlef08.e2k.ad.ge.com (localhost [127.0.0.1]) by int-ch1gw-1.online-age.net (8.12.9/8.12.3/990426-RLH) with ESMTP id jANDaRCi001487 for ; Wed, 23 Nov 2005 08:36:28 -0500 (EST) Received: from MKEMLVEM07.e2k.ad.ge.com ([3.159.176.54]) by cinmlef08.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 08:36:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] RE: Message format Date: Wed, 23 Nov 2005 07:36:26 -0600 Message-ID: <45A5295FFA1CBE4D9BF44E8534D2686C0998417E@MKEMLVEM07.e2k.ad.ge.com> Thread-Topic: [Syslog] RE: Message format Thread-Index: AcXwC5+i4Sl9419yQbCc8cFXZ9BP9gAJiH7A From: "Moehrke, John \(GE Healthcare\)" To: , "Rainer Gerhards" X-OriginalArrivalTime: 23 Nov 2005 13:36:27.0008 (UTC) FILETIME=[E7553800:01C5F032] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org To all, The view that syslog must only be used to transport "human readable syslog messages" is disturbing. Is this the view of the syslog community? If it is then I know that healthcare will take it's security audit message (RFC3881) and build our own transport likely using web services. We will need to find experts in security audit event analysis, but we are tiring of this syslog community behavior. Don't get me wrong, I am ok with putting a MTU on the message when it is transported over UDP. As was pointed out 4k should be fine.=20 John > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Andrew Ross > Sent: Wednesday, November 23, 2005 2:53 AM > To: 'Rainer Gerhards' > Cc: syslog@ietf.org > Subject: [Syslog] RE: Message format >=20 >=20 > >> Mapping over UDP should be limited to a single message per packet. > >I agree on that. If we need an ultra-compact UDP delivery, we could > >later add it in a separate transport mapping. >=20 > Yes, good idea. I doubt anyone will ever want to do this, or=20 > at least go to > the effort of trying to get it drafted into an RFC ;-) >=20 > >> When mapping over plain TCP I believe we should limit the=20 > >> total message size > >> to 65507 bytes (to keep it compatible with UDP) and delimit=20 > >> each message > >> stream with an LF, or CRLF. Either delimiter would work for me. >=20 > >I would prefer not to restart the size discussion at this=20 > point. I think > >the current compromise (everyone must support 2K, anyone=20 > might support > >as much as he likes) is sufficient for most, if not all,=20 > cases. I would > >not like to see an application to become non-compliant just=20 > because it > >needs to transmit 65508 bytes inside a message. >=20 > > I realise this should have been brought up earlier in the=20 > draft process, > however, I would really like to see a limit on the message=20 > size so that it > is directly compatible with UDP. If we allow an opened ended=20 > message size, > people *will* use it for non syslog related things. I feel=20 > that any message > longer than will fit into a UDP packet should be broken into=20 > two or more > separate messages by the sender, even if sent over TCP. This=20 > allows me to > allocate a maximum known buffer size for incoming TCP=20 > messages. There is a > potential for huge messages filling the memory and memory=20 > buffer overflows > happening if the messages are not limited in size. "Syslog"=20 > is meant to be a > human readable system log message. Anything longer (including=20 > binary crash > dumps or other things people misuse syslog for) should be broken into > separate messages by the sender, or sent over a different protocol. > >=20 > I think we should keep syslog simple and flexible, but not at=20 > the expense of > making it handle things it was never meant for. If a message=20 > needs to be > broken into many chunks, the SD-ID tags could be used to tie all the > messages together again by the parser. The syslog receiver or=20 > relay will > just handle them as separate messages and not even know they=20 > were split. > This makes things so much simpler. >=20 > Cheers >=20 > Andrew >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 09:04:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EevEw-00007C-Bq; Wed, 23 Nov 2005 09:04:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EevEs-000077-Qh for syslog@megatron.ietf.org; Wed, 23 Nov 2005 09:04:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04594 for ; Wed, 23 Nov 2005 09:04:07 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EevXk-00037u-CH for syslog@ietf.org; Wed, 23 Nov 2005 09:24:17 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 30C2C9C00C; Wed, 23 Nov 2005 15:13:00 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01628-09; Wed, 23 Nov 2005 15:12:53 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 16C6E9C00B; Wed, 23 Nov 2005 15:12:53 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 15:04:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EF3@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXwK5bTkOq+RR+QSAaU0j1N5FMirwABb8pQ From: "Rainer Gerhards" To: "Glenn Mansfield Keeni" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Glenn, very interesting approach with the timestamp. I think your ideas can be the key to maintaining a lot of backwards compatibility by still retaining new functionality. First some bad news: I am not sure if by "BSD syslog" you are refering to RFC 3164 or a specific distribution of BSD. I have created a small script to test out your recommendation. I used FreeBSD stock syslogd as the receiver. It did NOT work as expected. There are two reasons a) (that) BSD syslogd takes the sender always from the system that send it b) even worse, when relaying, it puts "Forwarded from : " into the hostname part (yes, with all that spaces) So while the idea sounds excellent, it does not work with stock FreeBSD syslogd. I am not sure about other BSD variants, nor have I checked the sysklogd package. I believe it will have less issues in this regard. =20 This was the message I sent (via perl script): "<148>Oct 11 22:14:15 mymachine.example.com 1 ID47 2003T.003Z 'su root' failed for lonvick on /dev/pts/8" this was the raw message received after being relayed once by FreeBSD stock syslogd: "<148>Oct 11 22:14:15 Forwarded from 172.19.2.7: mymachine.example.com 1 ID47 2003T.003Z 'su root' failed for lonvick on /dev/pts/8" As you can see, the message is somewhat distorted - definitely enough for digital signatures to be broken. [Implementor's side-note: This can be fixed on a syslog-application layer level, far beyond the IETF scope. It's straightforward and easy to do, so it will probably happen.] Even though this actual sample seems not to work, it paves the way to a very elegant compatibility solution. The key is to add the extra information (e.g. Timestamp) in a different place. At least I was so focussed on fields at whole that I did not notice this possibility. I have experiemented a bit more with Glenn's proposal, shuffeling some fields. The result was this: BSD_syslog_timestamp FQDN TAG "@#"VERSION MSGID Remainder_Timestamp [SD-ID]s MSG or in an actual sample: "<148>Oct 11 22:14:15 mymachine.example.com su[4711]: @#1 ID47 2003T.003Z [SD-IDs] 'su root' failed for lonvick on /dev/pts/8" I have used the BSD timestamp and FAQN as Glenn suggested. Then, I have added the "TAG" again. If we think in the spirit of my mail this morning on syslog & non-IETF standards, it would not really hurt if we standardize TAG instead of two fields. If I would like to retain the APP-NAME and PROCESSID, I could do the following ABNF: TAG =3D APP-NAME ["[" PROCESSID "]"] ":" The side-effect of this is that almost all syslog-messages currently emited comply with that format. So I suggest that we strongly consider joining these two again. Out of the sudden, we have the "old" header, but it is parsable by a hyptothetical new syslogd. Next, I have used a trick from syslog-sign. I have changed the VERSION from a number to a number plus a cookie. The version would now be "@#1". I do not care if the cookie is "@#" or something else. The key point is that it, together with the version should be very unlikely to exist at that place in old-style syslog. That would allow a "new" receiver to differentiate between old and new style syslog messages. The rest of the message is just applying Glenn's proposal again: it has the MSG, the missing parts of the timestamp, SD-IDs and MSG. The Remainder_Timestamp looks strange. We might like it, we might like something else. That's easy to change and discuss. It's the concept that matters right now, not the exact format. If we take the outlined route, we would be able to extend the syslog protocol with as much backward compatibility as is possible in a not-yet-standardized world. I find this very desirable. I think we even have good chances that many existing "old" syslogds would relay such messages without changing them, thus keeping digital signatures intact. The required text changes for syslog-protocol should be moderate. I strongly propose we go in that direction. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn=20 > Mansfield Keeni > Sent: Wednesday, November 23, 2005 1:39 PM > To: syslog@ietf.org > Subject: Re: [Syslog] New direction and proposed charter >=20 > Chris/Rainer, >=20 > > we continue to use ... at the start of syslog=20 > messages. This will > > allow current receivers to continue to receive messages and=20 > put them in > > the right bins. Does anyone disagree with this? >=20 > Complete agreement. > >=20 > >=20 > > The WG has agreed to use the timestamp Rainer has in the current > > syslog-protocol. > In principle I agree with the timestamp format. It is good. > I may have missed the discussion on this matter, in that case please > accept my apologies and ignore the rest of the mail. >=20 > To get existing BSD syslog devices specifically relays into=20 > the compatibility > fold it WILL be good idea to keep the timestamp in two parts >=20 > RainerTimestamp =3D BSD_syslog_timestamp + RemainderTimestamp >=20 > > One possibility would be to assemble a syslog message as: > >=20 > > TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG >=20 > In the context of what has been said above about the=20 > timestamp. I would > suggest > BSD_syslog_timestamp FQDN VERSION MSGID=20 > Remainder_Timestamp [SD-ID]s MSG >=20 > That would allow existing BSD-syslog relays to handle the new=20 > syslog protocol > in a transparent manner. Everything from VERSION to the end=20 > is treated as "message". >=20 > We do not lose information. > The Remainder_timestamp carries it - in a slightly less=20 > convenient place > though. >=20 > On the other hand if we insist on using RainerTimestamp,=20 > existing BSD_syslog > relays will relay the message as >=20 > BSD_syslog_timestamp FQDN RainerTimestamp FQDN VERSION=20 > MSGID [SD-ID]s MSG >=20 > The message does get distorted to some extent. >=20 > > If we can agree to this then I suspect that we can have a working > > document within Rainer's timeframe. I'll propose the=20 > following charter > > to keep us focused. > >=20 > > -------- Proposed Charter -------------- > >=20 > > Syslog is a de-facto standard for logging system events. =20 > However, the > > protocol component of this event logging system has not=20 > been formally > > documented. While the protocol has been very useful and=20 > scalable, it > > has some known security problems which were documented in RFC 3164. > >=20 > > The goal of this working group is to address the security and > > integrity problems of the existing syslog mechanism while=20 > not breaking > > backwards compatibility. The most obvious problems that need to be > > addressed in the syslog protocol are the timestamp, which has not > > formally included a means to indicate the year, and the=20 > identification > > of the source which has been a hostname without a qualified domain > > name. Additionally, a version, some type of message=20 > indicator, and a > > means to convey structured data will be included in the protocol. > >=20 > > syslog has traditionally been transported over UDP and this WG has > > already defined RFC 3195 for the reliable transport for the syslog > > messages. The WG will separate the UDP transport from the=20 > protocol so > > that others may define additional transports in the future. > >=20 > > - A standard will be produced that formally documents the syslog > > protocol. A mechanism will also be defined in this specification > > that will provide a means to convey structured data. > >=20 > > - A standard will be produced that documents the UDP transport for > > syslog. > >=20 > > - A standard will be produced that documents a mechanism to sign > > syslog messages to provide integrity checking and source > > authentication. > >=20 > > - A MIB definition for syslog will be produced. > >=20 > > ------------------------------------------- > >=20 > >=20 > > PLEASE review this and respond. > >=20 >=20 > Glenn >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 09:25:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EevYj-00040I-O8; Wed, 23 Nov 2005 09:25:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EevYi-0003v3-0i for syslog@megatron.ietf.org; Wed, 23 Nov 2005 09:25:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07612 for ; Wed, 23 Nov 2005 09:24:35 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EevrY-0004PS-0k for syslog@ietf.org; Wed, 23 Nov 2005 09:44:45 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jANEP3Yh017494 for ; Thu, 24 Nov 2005 01:25:03 +1100 (EST) From: Darren Reed Message-Id: <200511231424.jANEOdlu013490@firewall.reed.wattle.id.au> To: syslog@ietf.org Date: Thu, 24 Nov 2005 01:24:39 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Subject: [Syslog] Do we have a new charter? X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Before we get lost in discussions about the technical merits of message formats, do we have consensus on what the new charter should be ? Chris, can you post what the latest charter is so we can all take a look and provide any last comments ? Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 10:00:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eew6T-0003MV-Pp; Wed, 23 Nov 2005 10:00:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eew6R-0003Lh-Ds for syslog@megatron.ietf.org; Wed, 23 Nov 2005 10:00:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11987 for ; Wed, 23 Nov 2005 09:59:27 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EewPG-0006eN-Ni for syslog@ietf.org; Wed, 23 Nov 2005 10:19:38 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jANE8oCQ025148; Thu, 24 Nov 2005 01:08:50 +1100 (EST) From: Darren Reed Message-Id: <200511231408.jANE8YtS021007@firewall.reed.wattle.id.au> Subject: Re: [Syslog] RE: Message format In-Reply-To: <45A5295FFA1CBE4D9BF44E8534D2686C0998417E@MKEMLVEM07.e2k.ad.ge.com> To: "Moehrke, John (GE Healthcare)" Date: Thu, 24 Nov 2005 01:08:34 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, andrew@kiwisyslog.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > To all, > > The view that syslog must only be used to transport "human readable > syslog messages" is disturbing. Is this the view of the syslog > community? At present what we're concerned with is a logging facility that does generate and consume human readable messages. At some point in the future, when we have agreement on the human readable version, then we can consider what to do with messages that aren't human readable. So while I accept your assertion, addressing it is out of scope for the current discussion. We have smaller fish to fry, first, before attempting the big ones. Trying to solve "all the problems" is what got this group into the situation we are in now. We need to take a step back and focus on resolving smaller and more well defined problems before looking at a "grand unified logging protocol" (GULP). Nothing lasts forever, not even standards. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 10:03:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eew9T-0004gq-C9; Wed, 23 Nov 2005 10:03:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eew9S-0004gD-1r for syslog@megatron.ietf.org; Wed, 23 Nov 2005 10:03:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12300 for ; Wed, 23 Nov 2005 10:02:34 -0500 (EST) Received: from ext-nj2ut-13.online-age.net ([64.14.54.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EewSH-0006pi-RD for syslog@ietf.org; Wed, 23 Nov 2005 10:22:45 -0500 Received: from int-nj2ut-2.online-age.net (int-nj2ut-2.online-age.net [3.159.237.71]) by ext-nj2ut-13.online-age.net (8.13.5/8.13.5/20051114-SVVS-TLS-DNSBL) with ESMTP id jANF2wUY032432 for ; Wed, 23 Nov 2005 10:02:58 -0500 Received: from cinmlef06.e2k.ad.ge.com (localhost.localdomain [127.0.0.1]) by int-nj2ut-2.online-age.net (8.11.6/8.11.6/20050510-SVVS) with ESMTP id jANF2uY21048 for ; Wed, 23 Nov 2005 10:02:58 -0500 Received: from MKEMLVEM07.e2k.ad.ge.com ([3.159.176.54]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 10:02:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] RE: Message format Date: Wed, 23 Nov 2005 09:02:55 -0600 Message-ID: <45A5295FFA1CBE4D9BF44E8534D2686C09984372@MKEMLVEM07.e2k.ad.ge.com> Thread-Topic: [Syslog] RE: Message format Thread-Index: AcXwN+o1GPzgyC0RT+WXMES5OwL6mAABMqLg From: "Moehrke, John \(GE Healthcare\)" To: "Darren Reed" X-OriginalArrivalTime: 23 Nov 2005 15:02:55.0551 (UTC) FILETIME=[FBF20CF0:01C5F03E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, andrew@kiwisyslog.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I don't think we are asking for anything specific. The XML payload (RFC 3881) is text, and somewhat human readable. We went with XML payload because we have well defined object identifiers that have been standardized and used throughout the hospital by many different systems provided by many different vendors. These identifiers cover data objects, patients, doctors, equipment, drugs, orders, etc... Taking this nicely coded information and putting it into a unformatted string seemed very counter. The XML string is descriptive enough that simple string parsing works, but is also well defined so that XML parsing can be done as well. What I am trying to do is figure out if the charter for this group is really to force the payload to be a human readable text string, or if the payload can include an XML formatted event description.=20 We do not need binary. We do not need Mega-Byte MTUs. We really have tried to fit within the requirements that we understood syslog to have. We (healthcare) want to do what we do best (treat patients), and leave you (syslog) community to what you do best. We don't want to analyze/report/alert/etc on security events, we expect you are experts in this field. It is a shame to see this get in the way of an opportunity for both of us. John > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Wednesday, November 23, 2005 8:09 AM > To: Moehrke, John (GE Healthcare) > Cc: andrew@kiwisyslog.com; Rainer Gerhards; syslog@ietf.org > Subject: Re: [Syslog] RE: Message format >=20 > > To all, > >=20 > > The view that syslog must only be used to transport "human readable > > syslog messages" is disturbing. Is this the view of the syslog > > community? >=20 > At present what we're concerned with is a logging facility that does > generate and consume human readable messages. >=20 > At some point in the future, when we have agreement on the human > readable version, then we can consider what to do with messages > that aren't human readable. >=20 > So while I accept your assertion, addressing it is out of scope for > the current discussion. We have smaller fish to fry, first, before > attempting the big ones. Trying to solve "all the problems" is what > got this group into the situation we are in now. We need to take a > step back and focus on resolving smaller and more well defined > problems before looking at a "grand unified logging protocol" (GULP). >=20 > Nothing lasts forever, not even standards. >=20 > Darren >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 10:13:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewJr-0001yY-0a; Wed, 23 Nov 2005 10:13:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewJp-0001yQ-NA for syslog@megatron.ietf.org; Wed, 23 Nov 2005 10:13:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13508 for ; Wed, 23 Nov 2005 10:13:17 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eewci-0007T8-7C for syslog@ietf.org; Wed, 23 Nov 2005 10:33:28 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id C59FB9C00C; Wed, 23 Nov 2005 16:22:11 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01816-02; Wed, 23 Nov 2005 16:22:07 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id C91359C00B; Wed, 23 Nov 2005 16:22:07 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] RE: Message format MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 16:13:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EF4@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] RE: Message format Thread-Index: AcXwN+o1GPzgyC0RT+WXMES5OwL6mAABMqLgAADm4iA= From: "Rainer Gerhards" To: "Moehrke, John (GE Healthcare)" , "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: andrew@kiwisyslog.com, syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I think this is a valid use case. Syslog traditionally has not only focussed on network management but has always been used for application-layer event notifications. I think what John asks for is within our charter and doesn't even require any change to what we have been discussing so far. Rainer=20 > -----Original Message----- > From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com]=20 > Sent: Wednesday, November 23, 2005 4:03 PM > To: Darren Reed > Cc: andrew@kiwisyslog.com; Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] RE: Message format >=20 > I don't think we are asking for anything specific. The XML=20 > payload (RFC > 3881) is text, and somewhat human readable. We went with XML payload > because we have well defined object identifiers that have been > standardized and used throughout the hospital by many=20 > different systems > provided by many different vendors. These identifiers cover data > objects, patients, doctors, equipment, drugs, orders, etc...=20 > Taking this > nicely coded information and putting it into a unformatted=20 > string seemed > very counter. The XML string is descriptive enough that simple string > parsing works, but is also well defined so that XML parsing=20 > can be done > as well. >=20 > What I am trying to do is figure out if the charter for this group is > really to force the payload to be a human readable text string, or if > the payload can include an XML formatted event description.=20 >=20 > We do not need binary. We do not need Mega-Byte MTUs. We really have > tried to fit within the requirements that we understood=20 > syslog to have. > We (healthcare) want to do what we do best (treat patients), and leave > you (syslog) community to what you do best. We don't want to > analyze/report/alert/etc on security events, we expect you are experts > in this field. It is a shame to see this get in the way of an > opportunity for both of us. >=20 > John >=20 > > -----Original Message----- > > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > > Sent: Wednesday, November 23, 2005 8:09 AM > > To: Moehrke, John (GE Healthcare) > > Cc: andrew@kiwisyslog.com; Rainer Gerhards; syslog@ietf.org > > Subject: Re: [Syslog] RE: Message format > >=20 > > > To all, > > >=20 > > > The view that syslog must only be used to transport=20 > "human readable > > > syslog messages" is disturbing. Is this the view of the syslog > > > community? > >=20 > > At present what we're concerned with is a logging facility that does > > generate and consume human readable messages. > >=20 > > At some point in the future, when we have agreement on the human > > readable version, then we can consider what to do with messages > > that aren't human readable. > >=20 > > So while I accept your assertion, addressing it is out of scope for > > the current discussion. We have smaller fish to fry, first, before > > attempting the big ones. Trying to solve "all the problems" is what > > got this group into the situation we are in now. We need to take a > > step back and focus on resolving smaller and more well defined > > problems before looking at a "grand unified logging=20 > protocol" (GULP). > >=20 > > Nothing lasts forever, not even standards. > >=20 > > Darren > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 10:28:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewYH-0003FO-3N; Wed, 23 Nov 2005 10:28:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewYE-0003EG-VB for syslog@megatron.ietf.org; Wed, 23 Nov 2005 10:28:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15521 for ; Wed, 23 Nov 2005 10:28:10 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eewr7-0008Oo-C7 for syslog@ietf.org; Wed, 23 Nov 2005 10:48:22 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2005 07:28:41 -0800 X-IronPort-AV: i="3.97,364,1125903600"; d="scan'208"; a="369400196:sNHT30449700" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jANFS8eq015634; Wed, 23 Nov 2005 07:28:38 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 10:28:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Wed, 23 Nov 2005 10:28:25 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C855A0@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXwK5bTkOq+RR+QSAaU0j1N5FMirwABb8pQAAP7QmA= From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , "Glenn Mansfield Keeni" , X-OriginalArrivalTime: 23 Nov 2005 15:28:26.0303 (UTC) FILETIME=[8C5844F0:01C5F042] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer, Glenn, all: I second Rainer's findings. Relays don't work as described on Solaris = and Linux syslog daemons either. Each of them does their own things. = Linux comes the closest to the described behavior. Only it inserts its = own timestamp and hostname regardless of what you send. Solaris inserts = a socket identifier (IP + encoded port). Like this: Oct 11 22:14:15 [161.44.64.231.14.198] mymachine su: my message I think backwards compatibility on anything other than field is a = shaky proposition. This certainly has to be settled as part of charter = definition because we have to scope our work clearly this time. =20 Thanks, Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, November 23, 2005 9:04 AM > To: Glenn Mansfield Keeni; syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 > Glenn, >=20 > very interesting approach with the timestamp. I think your=20 > ideas can be the key to maintaining a lot of backwards=20 > compatibility by still retaining new functionality. >=20 > First some bad news: I am not sure if by "BSD syslog" you are=20 > refering to RFC 3164 or a specific distribution of BSD. I=20 > have created a small script to test out your recommendation.=20 > I used FreeBSD stock syslogd as the receiver. >=20 > It did NOT work as expected. There are two reasons >=20 > a) (that) BSD syslogd takes the sender always from the system=20 > that send it > b) even worse, when relaying, it puts "Forwarded from=20 > : " into >=20 > the hostname part (yes, with all that spaces) >=20 > So while the idea sounds excellent, it does not work with=20 > stock FreeBSD syslogd. I am not sure about other BSD=20 > variants, nor have I checked the sysklogd package. I believe=20 > it will have less issues in this regard. > =20 > This was the message I sent (via perl script): >=20 > "<148>Oct 11 22:14:15 mymachine.example.com 1 ID47 2003T.003Z=20 > 'su root' > failed for lonvick on /dev/pts/8" >=20 > this was the raw message received after being relayed once by=20 > FreeBSD stock syslogd: >=20 > "<148>Oct 11 22:14:15 Forwarded from 172.19.2.7:=20 > mymachine.example.com 1 > ID47 2003T.003Z 'su root' failed for lonvick on /dev/pts/8" >=20 > As you can see, the message is somewhat distorted -=20 > definitely enough for digital signatures to be broken.=20 > [Implementor's side-note: This can be fixed on a=20 > syslog-application layer level, far beyond the IETF scope. > It's straightforward and easy to do, so it will probably happen.] >=20 > Even though this actual sample seems not to work, it paves=20 > the way to a very elegant compatibility solution. The key is=20 > to add the extra information (e.g. Timestamp) in a different=20 > place. At least I was so focussed on fields at whole that I=20 > did not notice this possibility. I have experiemented a bit=20 > more with Glenn's proposal, shuffeling some fields. The=20 > result was this: >=20 > BSD_syslog_timestamp FQDN TAG "@#"VERSION MSGID=20 > Remainder_Timestamp [SD-ID]s MSG >=20 > or in an actual sample: >=20 > "<148>Oct 11 22:14:15 mymachine.example.com su[4711]: @#1=20 > ID47 2003T.003Z [SD-IDs] 'su root' failed for lonvick on /dev/pts/8" >=20 > I have used the BSD timestamp and FAQN as Glenn suggested.=20 > Then, I have added the "TAG" again. If we think in the spirit=20 > of my mail this morning on syslog & non-IETF standards, it=20 > would not really hurt if we standardize TAG instead of two=20 > fields. If I would like to retain the APP-NAME and PROCESSID,=20 > I could do the following ABNF: >=20 > TAG =3D APP-NAME ["[" PROCESSID "]"] ":" >=20 > The side-effect of this is that almost all syslog-messages=20 > currently emited comply with that format. So I suggest that=20 > we strongly consider joining these two again. Out of the=20 > sudden, we have the "old" header, but it is parsable by a=20 > hyptothetical new syslogd. Next, I have used a trick from=20 > syslog-sign. I have changed the VERSION from a number to a=20 > number plus a cookie. The version would now be "@#1". I do=20 > not care if the cookie is "@#" or something else. The key=20 > point is that it, together with the version should be very=20 > unlikely to exist at that place in old-style syslog. That=20 > would allow a "new" receiver to differentiate between old and=20 > new style syslog messages. The rest of the message is just=20 > applying Glenn's proposal again: it has the MSG, the missing=20 > parts of the timestamp, SD-IDs and MSG. The=20 > Remainder_Timestamp looks strange. > We might like it, we might like something else. That's easy=20 > to change and discuss. It's the concept that matters right=20 > now, not the exact format. >=20 > If we take the outlined route, we would be able to extend the=20 > syslog protocol with as much backward compatibility as is=20 > possible in a not-yet-standardized world. I find this very=20 > desirable. I think we even have good chances that many=20 > existing "old" syslogds would relay such messages without=20 > changing them, thus keeping digital signatures intact. > The required text changes for syslog-protocol should be moderate. >=20 > I strongly propose we go in that direction. >=20 > Rainer > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn Mansfield=20 > > Keeni > > Sent: Wednesday, November 23, 2005 1:39 PM > > To: syslog@ietf.org > > Subject: Re: [Syslog] New direction and proposed charter > >=20 > > Chris/Rainer, > >=20 > > > we continue to use ... at the start of syslog > > messages. This will > > > allow current receivers to continue to receive messages and > > put them in > > > the right bins. Does anyone disagree with this? > >=20 > > Complete agreement. > > >=20 > > >=20 > > > The WG has agreed to use the timestamp Rainer has in the current=20 > > > syslog-protocol. > > In principle I agree with the timestamp format. It is good. > > I may have missed the discussion on this matter, in that=20 > case please=20 > > accept my apologies and ignore the rest of the mail. > >=20 > > To get existing BSD syslog devices specifically relays into the=20 > > compatibility fold it WILL be good idea to keep the=20 > timestamp in two=20 > > parts > >=20 > > RainerTimestamp =3D BSD_syslog_timestamp + = RemainderTimestamp > >=20 > > > One possibility would be to assemble a syslog message as: > > >=20 > > > TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG > >=20 > > In the context of what has been said above about the timestamp. I=20 > > would suggest > > BSD_syslog_timestamp FQDN VERSION MSGID Remainder_Timestamp=20 > > [SD-ID]s MSG > >=20 > > That would allow existing BSD-syslog relays to handle the=20 > new syslog=20 > > protocol in a transparent manner. Everything from VERSION=20 > to the end=20 > > is treated as "message". > >=20 > > We do not lose information. > > The Remainder_timestamp carries it - in a slightly less=20 > > convenient place > > though. > >=20 > > On the other hand if we insist on using RainerTimestamp, existing=20 > > BSD_syslog relays will relay the message as > >=20 > > BSD_syslog_timestamp FQDN RainerTimestamp FQDN VERSION MSGID=20 > > [SD-ID]s MSG > >=20 > > The message does get distorted to some extent. > >=20 > > > If we can agree to this then I suspect that we can have a working=20 > > > document within Rainer's timeframe. I'll propose the > > following charter > > > to keep us focused. > > >=20 > > > -------- Proposed Charter -------------- > > >=20 > > > Syslog is a de-facto standard for logging system events. =20 > > However, the > > > protocol component of this event logging system has not > > been formally > > > documented. While the protocol has been very useful and > > scalable, it > > > has some known security problems which were documented in=20 > RFC 3164. > > >=20 > > > The goal of this working group is to address the security and=20 > > > integrity problems of the existing syslog mechanism while > > not breaking > > > backwards compatibility. The most obvious problems that=20 > need to be=20 > > > addressed in the syslog protocol are the timestamp, which has not=20 > > > formally included a means to indicate the year, and the > > identification > > > of the source which has been a hostname without a=20 > qualified domain=20 > > > name. Additionally, a version, some type of message > > indicator, and a > > > means to convey structured data will be included in the protocol. > > >=20 > > > syslog has traditionally been transported over UDP and=20 > this WG has=20 > > > already defined RFC 3195 for the reliable transport for=20 > the syslog=20 > > > messages. The WG will separate the UDP transport from the > > protocol so > > > that others may define additional transports in the future. > > >=20 > > > - A standard will be produced that formally documents the syslog=20 > > > protocol. A mechanism will also be defined in this specification=20 > > > that will provide a means to convey structured data. > > >=20 > > > - A standard will be produced that documents the UDP=20 > transport for=20 > > > syslog. > > >=20 > > > - A standard will be produced that documents a mechanism to sign=20 > > > syslog messages to provide integrity checking and source=20 > > > authentication. > > >=20 > > > - A MIB definition for syslog will be produced. > > >=20 > > > ------------------------------------------- > > >=20 > > >=20 > > > PLEASE review this and respond. > > >=20 > >=20 > > Glenn > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 10:29:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewZ1-0003S8-QC; Wed, 23 Nov 2005 10:29:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewYz-0003S3-P5 for syslog@megatron.ietf.org; Wed, 23 Nov 2005 10:29:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15644 for ; Wed, 23 Nov 2005 10:28:57 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eewrr-0008QL-Vg for syslog@ietf.org; Wed, 23 Nov 2005 10:49:08 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 177F49C00C; Wed, 23 Nov 2005 16:37:52 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01731-07; Wed, 23 Nov 2005 16:37:48 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 604469C00B; Wed, 23 Nov 2005 16:37:48 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 16:29:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EF5@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXwK5bTkOq+RR+QSAaU0j1N5FMirwABb8pQAAPPXRA= From: "Rainer Gerhards" To: "Rainer Gerhards" , "Glenn Mansfield Keeni" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This is really disappointing... I have done further testing with more syslogds to confirm the initial findings. The more different programs / versions I try, the more a mess this gets. OK, we knew FreeBSD syslogd does not include the hostname. Next I tested with some Windows products, which looked promising. Then I looked at the sysklogd source. It is the standard Linux package, so if it works, a lot would be won. The source tells me that at least the timestamp should correctly be extracted. Then I actually tried it out with a Debian system - the timestamp was ignored. Checking that source tree I see that *that* sysklogd does deliberately ignore the data and always pulls the local date (or ist it a bug - who cares...). When it comes to relaying it is even stranger: sysklogd does neither relay the timestamp nor the host part. At that point, I have stopped further analysis, because I think I would be able to find another good number of variants of syslog behaviour. Conclusion: 1. There is no point in trying to preserve backward compatibility besides sticking with the . Everything other than is handled differently by different implementations=20 and/or versions. 2. We can NOT expect that relaying over existing syslog=20 implementations will ever work. Please note that this would=20 also have broken syslog-sign without specifically implemented daemons. As such, I revert back to proposing=20 VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP [SD-ID]s SP MSG or, somewhat incorrect but shorter: VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [SD-ID]s MSG Please note that I have added the MSGID to the header. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, November 23, 2005 3:04 PM > To: Glenn Mansfield Keeni; syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 > Glenn, >=20 > very interesting approach with the timestamp. I think your=20 > ideas can be > the key to maintaining a lot of backwards compatibility by still > retaining new functionality. >=20 > First some bad news: I am not sure if by "BSD syslog" you are refering > to RFC 3164 or a specific distribution of BSD. I have created a small > script to test out your recommendation. I used FreeBSD stock=20 > syslogd as > the receiver. >=20 > It did NOT work as expected. There are two reasons >=20 > a) (that) BSD syslogd takes the sender always from the system=20 > that send > it > b) even worse, when relaying, it puts "Forwarded from=20 > : " into >=20 > the hostname part (yes, with all that spaces) >=20 > So while the idea sounds excellent, it does not work with=20 > stock FreeBSD > syslogd. I am not sure about other BSD variants, nor have I=20 > checked the > sysklogd package. I believe it will have less issues in this regard. > =20 > This was the message I sent (via perl script): >=20 > "<148>Oct 11 22:14:15 mymachine.example.com 1 ID47 2003T.003Z=20 > 'su root' > failed for lonvick on /dev/pts/8" >=20 > this was the raw message received after being relayed once by FreeBSD > stock syslogd: >=20 > "<148>Oct 11 22:14:15 Forwarded from 172.19.2.7:=20 > mymachine.example.com 1 > ID47 2003T.003Z 'su root' failed for lonvick on /dev/pts/8" >=20 > As you can see, the message is somewhat distorted - definitely enough > for digital signatures to be broken. [Implementor's=20 > side-note: This can > be fixed on a syslog-application layer level, far beyond the=20 > IETF scope. > It's straightforward and easy to do, so it will probably happen.] >=20 > Even though this actual sample seems not to work, it paves=20 > the way to a > very elegant compatibility solution. The key is to add the extra > information (e.g. Timestamp) in a different place. At least I was so > focussed on fields at whole that I did not notice this possibility. I > have experiemented a bit more with Glenn's proposal, shuffeling some > fields. The result was this: >=20 > BSD_syslog_timestamp FQDN TAG "@#"VERSION MSGID=20 > Remainder_Timestamp > [SD-ID]s MSG >=20 > or in an actual sample: >=20 > "<148>Oct 11 22:14:15 mymachine.example.com su[4711]: @#1 ID47 > 2003T.003Z [SD-IDs] 'su root' failed for lonvick on /dev/pts/8" >=20 > I have used the BSD timestamp and FAQN as Glenn suggested.=20 > Then, I have > added the "TAG" again. If we think in the spirit of my mail=20 > this morning > on syslog & non-IETF standards, it would not really hurt if we > standardize TAG instead of two fields. If I would like to retain the > APP-NAME and PROCESSID, I could do the following ABNF: >=20 > TAG =3D APP-NAME ["[" PROCESSID "]"] ":" >=20 > The side-effect of this is that almost all syslog-messages currently > emited comply with that format. So I suggest that we strongly consider > joining these two again. Out of the sudden, we have the "old" header, > but it is parsable by a hyptothetical new syslogd. Next, I have used a > trick from syslog-sign. I have changed the VERSION from a number to a > number plus a cookie. The version would now be "@#1". I do not care if > the cookie is "@#" or something else. The key point is that=20 > it, together > with the version should be very unlikely to exist at that place in > old-style syslog. That would allow a "new" receiver to differentiate > between old and new style syslog messages. The rest of the message is > just applying Glenn's proposal again: it has the MSG, the=20 > missing parts > of the timestamp, SD-IDs and MSG. The Remainder_Timestamp=20 > looks strange. > We might like it, we might like something else. That's easy to change > and discuss. It's the concept that matters right now, not the exact > format. >=20 > If we take the outlined route, we would be able to extend the syslog > protocol with as much backward compatibility as is possible in a > not-yet-standardized world. I find this very desirable. I=20 > think we even > have good chances that many existing "old" syslogds would relay such > messages without changing them, thus keeping digital=20 > signatures intact. > The required text changes for syslog-protocol should be moderate. >=20 > I strongly propose we go in that direction. >=20 > Rainer > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn=20 > > Mansfield Keeni > > Sent: Wednesday, November 23, 2005 1:39 PM > > To: syslog@ietf.org > > Subject: Re: [Syslog] New direction and proposed charter > >=20 > > Chris/Rainer, > >=20 > > > we continue to use ... at the start of syslog=20 > > messages. This will > > > allow current receivers to continue to receive messages and=20 > > put them in > > > the right bins. Does anyone disagree with this? > >=20 > > Complete agreement. > > >=20 > > >=20 > > > The WG has agreed to use the timestamp Rainer has in the current > > > syslog-protocol. > > In principle I agree with the timestamp format. It is good. > > I may have missed the discussion on this matter, in that=20 > case please > > accept my apologies and ignore the rest of the mail. > >=20 > > To get existing BSD syslog devices specifically relays into=20 > > the compatibility > > fold it WILL be good idea to keep the timestamp in two parts > >=20 > > RainerTimestamp =3D BSD_syslog_timestamp + = RemainderTimestamp > >=20 > > > One possibility would be to assemble a syslog message as: > > >=20 > > > TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG > >=20 > > In the context of what has been said above about the=20 > > timestamp. I would > > suggest > > BSD_syslog_timestamp FQDN VERSION MSGID=20 > > Remainder_Timestamp [SD-ID]s MSG > >=20 > > That would allow existing BSD-syslog relays to handle the new=20 > > syslog protocol > > in a transparent manner. Everything from VERSION to the end=20 > > is treated as "message". > >=20 > > We do not lose information. > > The Remainder_timestamp carries it - in a slightly less=20 > > convenient place > > though. > >=20 > > On the other hand if we insist on using RainerTimestamp,=20 > > existing BSD_syslog > > relays will relay the message as > >=20 > > BSD_syslog_timestamp FQDN RainerTimestamp FQDN VERSION=20 > > MSGID [SD-ID]s MSG > >=20 > > The message does get distorted to some extent. > >=20 > > > If we can agree to this then I suspect that we can have a working > > > document within Rainer's timeframe. I'll propose the=20 > > following charter > > > to keep us focused. > > >=20 > > > -------- Proposed Charter -------------- > > >=20 > > > Syslog is a de-facto standard for logging system events. =20 > > However, the > > > protocol component of this event logging system has not=20 > > been formally > > > documented. While the protocol has been very useful and=20 > > scalable, it > > > has some known security problems which were documented in=20 > RFC 3164. > > >=20 > > > The goal of this working group is to address the security and > > > integrity problems of the existing syslog mechanism while=20 > > not breaking > > > backwards compatibility. The most obvious problems that=20 > need to be > > > addressed in the syslog protocol are the timestamp, which has not > > > formally included a means to indicate the year, and the=20 > > identification > > > of the source which has been a hostname without a qualified domain > > > name. Additionally, a version, some type of message=20 > > indicator, and a > > > means to convey structured data will be included in the protocol. > > >=20 > > > syslog has traditionally been transported over UDP and this WG has > > > already defined RFC 3195 for the reliable transport for the syslog > > > messages. The WG will separate the UDP transport from the=20 > > protocol so > > > that others may define additional transports in the future. > > >=20 > > > - A standard will be produced that formally documents the syslog > > > protocol. A mechanism will also be defined in this specification > > > that will provide a means to convey structured data. > > >=20 > > > - A standard will be produced that documents the UDP transport for > > > syslog. > > >=20 > > > - A standard will be produced that documents a mechanism to sign > > > syslog messages to provide integrity checking and source > > > authentication. > > >=20 > > > - A MIB definition for syslog will be produced. > > >=20 > > > ------------------------------------------- > > >=20 > > >=20 > > > PLEASE review this and respond. > > >=20 > >=20 > > Glenn > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 10:44:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eewni-0006r5-0s; Wed, 23 Nov 2005 10:44:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eewng-0006lQ-Gs for syslog@megatron.ietf.org; Wed, 23 Nov 2005 10:44:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17520 for ; Wed, 23 Nov 2005 10:44:04 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eex6U-0000wI-2e for syslog@ietf.org; Wed, 23 Nov 2005 11:04:16 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jANFiLnj026236; Thu, 24 Nov 2005 02:44:21 +1100 (EST) From: Darren Reed Message-Id: <200511231544.jANFiG63020106@firewall.reed.wattle.id.au> Subject: Re: [Syslog] RE: Message format In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3EF4@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Thu, 24 Nov 2005 02:44:16 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: andrew@kiwisyslog.com, syslog@ietf.org, Darren Reed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > I think this is a valid use case. Syslog traditionally has not only > focussed on network management but has always been used for > application-layer event notifications. I think what John asks for is > within our charter and doesn't even require any change to what we have > been discussing so far. So long as XML in the message can be satisfied by saying it is part of the "MSG" section, then yes. I don't believe there are any planned restrictions on what the text content of "MSG" can be. Otherwise we're just going back down the road of 3195. If John wanted to see XML in syslog formalised, then my vote would for it to be a follow on draft that documented a particular SD-ID as the means for indicating the MSG was expected to be XML. But I cannot emphasise strongly enough that it is not appropriate for this group to take on syslog and XML, beyond what exists in 3195, at the present time. We need to focus on the charter and achieve a basic set of goals first before moving on to things like this. This isn't to say that it won't be addressed, but not here and now. If this puts you, John, in uncertain land for the time being then I think that has to just be accepted with an understanding that it can be redressed at some point in the future, even if it doesn't make our current charter. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 10:50:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewtA-0001ch-Iv; Wed, 23 Nov 2005 10:50:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eewt6-0001bY-WE for syslog@megatron.ietf.org; Wed, 23 Nov 2005 10:50:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18018 for ; Wed, 23 Nov 2005 10:49:44 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EexBz-0001Gp-RM for syslog@ietf.org; Wed, 23 Nov 2005 11:09:56 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id CA3F69C00C; Wed, 23 Nov 2005 16:58:39 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01816-05; Wed, 23 Nov 2005 16:58:36 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 2C1FA9C00B; Wed, 23 Nov 2005 16:58:36 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] RE: Message format MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 16:50:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EF7@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] RE: Message format Thread-Index: AcXwRM1BHp7Xm4dnQ6a7HE4ZWcrOlgAACDvQ From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: andrew@kiwisyslog.com, syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, I fully agree with you. My understanding is that John just needs to transmit text in the MSG part which co-incidently "looks like" XML It must, however, a bit longer than 1K, which is backed by the current state of discussion. I, too, strongly object mandating XML or anything else formatted in a specific way (other than structured data). I have begun to become very sceptic about RFC 3195 (again, I have implemented it). I think we need to very carefully evaluate it *after* we have finished the base work. BTW: my recent findings about the total incompatibility of various well-deployed implementations are a strong point that we need to standardize the basic format. But just what the bare essentials - and the quicker, the better. Already a lot of time has passed. Rainer > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Wednesday, November 23, 2005 4:44 PM > To: Rainer Gerhards > Cc: Moehrke, John (GE Healthcare); Darren Reed;=20 > andrew@kiwisyslog.com; syslog@ietf.org > Subject: Re: [Syslog] RE: Message format >=20 > > I think this is a valid use case. Syslog traditionally has not only > > focussed on network management but has always been used for > > application-layer event notifications. I think what John asks for is > > within our charter and doesn't even require any change to=20 > what we have > > been discussing so far. >=20 > So long as XML in the message can be satisfied by saying it is part > of the "MSG" section, then yes. I don't believe there are any planned > restrictions on what the text content of "MSG" can be. >=20 > Otherwise we're just going back down the road of 3195. >=20 > If John wanted to see XML in syslog formalised, then my vote would for > it to be a follow on draft that documented a particular SD-ID as the > means for indicating the MSG was expected to be XML. >=20 > But I cannot emphasise strongly enough that it is not appropriate for > this group to take on syslog and XML, beyond what exists in 3195, at > the present time. We need to focus on the charter and achieve a basic > set of goals first before moving on to things like this. This isn't > to say that it won't be addressed, but not here and now. If this puts > you, John, in uncertain land for the time being then I think that has > to just be accepted with an understanding that it can be redressed at > some point in the future, even if it doesn't make our current charter. >=20 > Darren >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 11:44:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eexj5-0005wr-B6; Wed, 23 Nov 2005 11:44:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eexj2-0005wO-Tm for syslog@megatron.ietf.org; Wed, 23 Nov 2005 11:44:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24487 for ; Wed, 23 Nov 2005 11:43:24 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eey1v-0004iQ-CR for syslog@ietf.org; Wed, 23 Nov 2005 12:03:36 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2005 08:43:54 -0800 X-IronPort-AV: i="3.97,364,1125903600"; d="scan'208"; a="369435431:sNHT26628660" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jANGhpeS018437; Wed, 23 Nov 2005 08:43:51 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 11:43:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] RE: Message format Date: Wed, 23 Nov 2005 11:43:50 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C855F7@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] RE: Message format Thread-Index: AcXwPywNg+Qpfi2yTbaNYsTBbrQVmwAA3pEA From: "Anton Okmianski \(aokmians\)" To: "Darren Reed" , "Moehrke, John \(GE Healthcare\)" X-OriginalArrivalTime: 23 Nov 2005 16:43:50.0714 (UTC) FILETIME=[151A99A0:01C5F04D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, andrew@kiwisyslog.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren: > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Wednesday, November 23, 2005 9:09 AM > To: Moehrke, John (GE Healthcare) > Cc: syslog@ietf.org; andrew@kiwisyslog.com > Subject: Re: [Syslog] RE: Message format >=20 > > To all, > >=20 > > The view that syslog must only be used to transport "human readable=20 > > syslog messages" is disturbing. Is this the view of the syslog=20 > > community? >=20 > At present what we're concerned with is a logging facility=20 > that does generate and consume human readable messages. How do you define "human readable"? Is assembly code human readable? :) Maybe you implied it should be limited to printed characters... well any = octet can be represented in print in some shape or form (say by hex), = and I thought it is out of scope how stuff is printed, displayed or = stored on disk for the on-the-wire protocol. If you limit it to = "language" characters, you don't really want to exclude control = characters such as tabs.=20 I really don't think there is a good reason to exclude any octet in the = payload. It would be like saying you can't send certain octets in email = (including binary attachments) because it must be human readable. Well, = let the two sides figure out what is readable to them and just transport = the payload with appropriate agreed-upon header. =20 At a minimum, I hope that if we put terms like "human readable" into the = charter, we would be clear about what they mean. =20 Also consider that programmatic parsing and interpretation of syslog = messages is common-place today and must continue. For example, = gazillions of systems (home grown and commercial) have been built around = Cisco's use of syslog to do automated fault detection, correlation, etc. = Use google to find examples.=20 In summary, I am not comfortable with "human readable" restriction going = into the charter. =20 Thanks, Anton. =20 >=20 > At some point in the future, when we have agreement on the=20 > human readable version, then we can consider what to do with=20 > messages that aren't human readable. >=20 > So while I accept your assertion, addressing it is out of=20 > scope for the current discussion. We have smaller fish to=20 > fry, first, before attempting the big ones. Trying to solve=20 > "all the problems" is what got this group into the situation=20 > we are in now. We need to take a step back and focus on=20 > resolving smaller and more well defined problems before=20 > looking at a "grand unified logging protocol" (GULP). >=20 > Nothing lasts forever, not even standards. >=20 > Darren >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 11:48:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eexn1-0000Vi-Is; Wed, 23 Nov 2005 11:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eexn0-0000Ux-G8 for syslog@megatron.ietf.org; Wed, 23 Nov 2005 11:48:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25014 for ; Wed, 23 Nov 2005 11:47:29 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eey5t-0004wH-Go for syslog@ietf.org; Wed, 23 Nov 2005 12:07:42 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 9C88D9C00C; Wed, 23 Nov 2005 17:56:24 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01947-06; Wed, 23 Nov 2005 17:56:20 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id D90439C00B; Wed, 23 Nov 2005 17:56:20 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] RE: Message format MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 17:47:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EFB@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] RE: Message format Thread-Index: AcXwPywNg+Qpfi2yTbaNYsTBbrQVmwAA3pEAAAK2JeA= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , "Darren Reed" , "Moehrke, John (GE Healthcare)" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, andrew@kiwisyslog.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, Anton: While I agree with Darren we should NOT specify any specfic format of MSG, I agree with Anton that we should NOT put the wording "human readable" into the charter. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton=20 > Okmianski (aokmians) > Sent: Wednesday, November 23, 2005 5:44 PM > To: Darren Reed; Moehrke, John (GE Healthcare) > Cc: syslog@ietf.org; andrew@kiwisyslog.com > Subject: RE: [Syslog] RE: Message format >=20 > Darren: >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > > Sent: Wednesday, November 23, 2005 9:09 AM > > To: Moehrke, John (GE Healthcare) > > Cc: syslog@ietf.org; andrew@kiwisyslog.com > > Subject: Re: [Syslog] RE: Message format > >=20 > > > To all, > > >=20 > > > The view that syslog must only be used to transport=20 > "human readable=20 > > > syslog messages" is disturbing. Is this the view of the syslog=20 > > > community? > >=20 > > At present what we're concerned with is a logging facility=20 > > that does generate and consume human readable messages. >=20 > How do you define "human readable"? Is assembly code human=20 > readable? :) >=20 > Maybe you implied it should be limited to printed=20 > characters... well any octet can be represented in print in=20 > some shape or form (say by hex), and I thought it is out of=20 > scope how stuff is printed, displayed or stored on disk for=20 > the on-the-wire protocol. If you limit it to "language"=20 > characters, you don't really want to exclude control=20 > characters such as tabs.=20 >=20 > I really don't think there is a good reason to exclude any=20 > octet in the payload. It would be like saying you can't send=20 > certain octets in email (including binary attachments)=20 > because it must be human readable. Well, let the two sides=20 > figure out what is readable to them and just transport the=20 > payload with appropriate agreed-upon header. =20 >=20 > At a minimum, I hope that if we put terms like "human=20 > readable" into the charter, we would be clear about what they mean. =20 >=20 > Also consider that programmatic parsing and interpretation of=20 > syslog messages is common-place today and must continue. For=20 > example, gazillions of systems (home grown and commercial)=20 > have been built around Cisco's use of syslog to do automated=20 > fault detection, correlation, etc. Use google to find examples.=20 >=20 > In summary, I am not comfortable with "human readable"=20 > restriction going into the charter. =20 >=20 > Thanks, > Anton. =20 >=20 > >=20 > > At some point in the future, when we have agreement on the=20 > > human readable version, then we can consider what to do with=20 > > messages that aren't human readable. > >=20 > > So while I accept your assertion, addressing it is out of=20 > > scope for the current discussion. We have smaller fish to=20 > > fry, first, before attempting the big ones. Trying to solve=20 > > "all the problems" is what got this group into the situation=20 > > we are in now. We need to take a step back and focus on=20 > > resolving smaller and more well defined problems before=20 > > looking at a "grand unified logging protocol" (GULP). > >=20 > > Nothing lasts forever, not even standards. > >=20 > > Darren > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 11:49:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eexoi-0001FZ-WE; Wed, 23 Nov 2005 11:49:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eexog-0001Ep-LJ for syslog@megatron.ietf.org; Wed, 23 Nov 2005 11:49:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25366 for ; Wed, 23 Nov 2005 11:49:15 -0500 (EST) Received: from ext-nj2ut-3.online-age.net ([64.14.54.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eey7Y-00053P-SD for syslog@ietf.org; Wed, 23 Nov 2005 12:09:26 -0500 Received: from int-nj2ut-5.online-age.net (int-nj2ut-5.online-age.net [3.159.237.74]) by ext-nj2ut-3.online-age.net (8.13.5/8.13.5/20051114-SVVS-TLS-DNSBL) with ESMTP id jANGnZTF021888 for ; Wed, 23 Nov 2005 11:49:35 -0500 Received: from cinmlef10.e2k.ad.ge.com (localhost.localdomain [127.0.0.1]) by int-nj2ut-5.online-age.net (8.11.6/8.11.6/20050510-SVVS) with ESMTP id jANGnZC13105 for ; Wed, 23 Nov 2005 11:49:35 -0500 Received: from MKEMLVEM07.e2k.ad.ge.com ([3.159.176.54]) by cinmlef10.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 11:49:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] RE: Message format Date: Wed, 23 Nov 2005 10:49:34 -0600 Message-ID: <45A5295FFA1CBE4D9BF44E8534D2686C0998466E@MKEMLVEM07.e2k.ad.ge.com> Thread-Topic: [Syslog] RE: Message format Thread-Index: AcXwRM1BHp7Xm4dnQ6a7HE4ZWcrOlgAACDvQAAF2OOA= From: "Moehrke, John \(GE Healthcare\)" To: X-OriginalArrivalTime: 23 Nov 2005 16:49:35.0158 (UTC) FILETIME=[E2689560:01C5F04D] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Yes, at this point I am happy putting my serialized XML into the MSG part. I just want to know if there is going to be a requirement forbidding us from putting our serialized XML into the MSG part. I was getting that impression. I want to continue to work together, I really don't want to invent something different.=20 NOTE: We have 47 different healthcare vendor products signed up to test RFC 3881 over syslog at a connectathon in January 2006. Companies big and small in the healthcare space including: GE, Siemens, Philips, McKesson, Kodak, Canon, Agfa, IBM, etc. We would like to use 3195, but you all know the problems there. Thus we are using BSD SYSLOG and violating the MTU. We are making do with what we have, we are trying to 'wait' for you. We appreciate what Rainer is doing, and support him in his efforts to document (standardize) what is used today.=20 John=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Wednesday, November 23, 2005 9:50 AM > To: Darren Reed > Cc: Moehrke, John (GE Healthcare); andrew@kiwisyslog.com;=20 > syslog@ietf.org > Subject: RE: [Syslog] RE: Message format >=20 > Darren, >=20 > I fully agree with you. My understanding is that John just needs to > transmit text in the MSG part which co-incidently "looks like" XML It > must, however, a bit longer than 1K, which is backed by the current > state of discussion. I, too, strongly object mandating XML or anything > else formatted in a specific way (other than structured data). I have > begun to become very sceptic about RFC 3195 (again, I have implemented > it). I think we need to very carefully evaluate it *after* we have > finished the base work. >=20 > BTW: my recent findings about the total incompatibility of various > well-deployed implementations are a strong point that we need to > standardize the basic format. But just what the bare essentials - and > the quicker, the better. Already a lot of time has passed. >=20 > Rainer >=20 > > -----Original Message----- > > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > > Sent: Wednesday, November 23, 2005 4:44 PM > > To: Rainer Gerhards > > Cc: Moehrke, John (GE Healthcare); Darren Reed;=20 > > andrew@kiwisyslog.com; syslog@ietf.org > > Subject: Re: [Syslog] RE: Message format > >=20 > > > I think this is a valid use case. Syslog traditionally=20 > has not only > > > focussed on network management but has always been used for > > > application-layer event notifications. I think what John=20 > asks for is > > > within our charter and doesn't even require any change to=20 > > what we have > > > been discussing so far. > >=20 > > So long as XML in the message can be satisfied by saying it is part > > of the "MSG" section, then yes. I don't believe there are=20 > any planned > > restrictions on what the text content of "MSG" can be. > >=20 > > Otherwise we're just going back down the road of 3195. > >=20 > > If John wanted to see XML in syslog formalised, then my=20 > vote would for > > it to be a follow on draft that documented a particular SD-ID as the > > means for indicating the MSG was expected to be XML. > >=20 > > But I cannot emphasise strongly enough that it is not=20 > appropriate for > > this group to take on syslog and XML, beyond what exists in 3195, at > > the present time. We need to focus on the charter and=20 > achieve a basic > > set of goals first before moving on to things like this. This isn't > > to say that it won't be addressed, but not here and now. =20 > If this puts > > you, John, in uncertain land for the time being then I=20 > think that has > > to just be accepted with an understanding that it can be=20 > redressed at > > some point in the future, even if it doesn't make our=20 > current charter. > >=20 > > Darren > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 12:05:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eey3s-0000fx-HS; Wed, 23 Nov 2005 12:05:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eey3r-0000fs-P5 for syslog@megatron.ietf.org; Wed, 23 Nov 2005 12:05:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27518 for ; Wed, 23 Nov 2005 12:04:57 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeyMk-000641-GB for syslog@ietf.org; Wed, 23 Nov 2005 12:25:07 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 23 Nov 2005 09:05:25 -0800 X-IronPort-AV: i="3.97,364,1125903600"; d="scan'208"; a="678002751:sNHT24060272" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jANH5PCK006174 for ; Wed, 23 Nov 2005 09:05:25 -0800 (PST) Date: Wed, 23 Nov 2005 09:05:25 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Syslog] Revised proposed charter X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi All, ==== v2 of proposed charter === Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in RFC 3164. The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. === === Comments please. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 12:15:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyDm-0003Sr-H4; Wed, 23 Nov 2005 12:15:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyDk-0003R1-HC for syslog@megatron.ietf.org; Wed, 23 Nov 2005 12:15:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29107 for ; Wed, 23 Nov 2005 12:15:09 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeyWR-0006f9-Rq for syslog@ietf.org; Wed, 23 Nov 2005 12:35:08 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2005 09:15:27 -0800 X-IronPort-AV: i="3.97,364,1125903600"; d="scan'208"; a="369447727:sNHT25659066" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jANHFOs3024936; Wed, 23 Nov 2005 09:15:25 -0800 (PST) Date: Wed, 23 Nov 2005 09:15:24 -0800 (PST) From: Chris Lonvick To: "Moehrke, John (GE Healthcare)" Subject: RE: [Syslog] RE: Message format In-Reply-To: <45A5295FFA1CBE4D9BF44E8534D2686C0998466E@MKEMLVEM07.e2k.ad.ge.com> Message-ID: References: <45A5295FFA1CBE4D9BF44E8534D2686C0998466E@MKEMLVEM07.e2k.ad.ge.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi John, On Wed, 23 Nov 2005, Moehrke, John (GE Healthcare) wrote: > Yes, at this point I am happy putting my serialized XML into the MSG > part. I just want to know if there is going to be a requirement > forbidding us from putting our serialized XML into the MSG part. I was > getting that impression. I want to continue to work together, I really > don't want to invent something different. I don't think that we want to prohibit any future, useful applications of syslog. As others have said, we're going to focus on getting the document out the door right now so please keep reviewing the work so that your ideas can be implemented. > > NOTE: We have 47 different healthcare vendor products signed up to test > RFC 3881 over syslog at a connectathon in January 2006. Companies big > and small in the healthcare space including: GE, Siemens, Philips, > McKesson, Kodak, Canon, Agfa, IBM, etc. We would like to use 3195, but > you all know the problems there. Thus we are using BSD SYSLOG and > violating the MTU. We are making do with what we have, we are trying to > 'wait' for you. We appreciate what Rainer is doing, and support him in > his efforts to document (standardize) what is used today. Valid reasons to update 3195 when we have syslog-protocol nailed down. Thanks, Chris > > John > >> -----Original Message----- >> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] >> Sent: Wednesday, November 23, 2005 9:50 AM >> To: Darren Reed >> Cc: Moehrke, John (GE Healthcare); andrew@kiwisyslog.com; >> syslog@ietf.org >> Subject: RE: [Syslog] RE: Message format >> >> Darren, >> >> I fully agree with you. My understanding is that John just needs to >> transmit text in the MSG part which co-incidently "looks like" XML It >> must, however, a bit longer than 1K, which is backed by the current >> state of discussion. I, too, strongly object mandating XML or anything >> else formatted in a specific way (other than structured data). I have >> begun to become very sceptic about RFC 3195 (again, I have implemented >> it). I think we need to very carefully evaluate it *after* we have >> finished the base work. >> >> BTW: my recent findings about the total incompatibility of various >> well-deployed implementations are a strong point that we need to >> standardize the basic format. But just what the bare essentials - and >> the quicker, the better. Already a lot of time has passed. >> >> Rainer >> >>> -----Original Message----- >>> From: Darren Reed [mailto:darrenr@reed.wattle.id.au] >>> Sent: Wednesday, November 23, 2005 4:44 PM >>> To: Rainer Gerhards >>> Cc: Moehrke, John (GE Healthcare); Darren Reed; >>> andrew@kiwisyslog.com; syslog@ietf.org >>> Subject: Re: [Syslog] RE: Message format >>> >>>> I think this is a valid use case. Syslog traditionally >> has not only >>>> focussed on network management but has always been used for >>>> application-layer event notifications. I think what John >> asks for is >>>> within our charter and doesn't even require any change to >>> what we have >>>> been discussing so far. >>> >>> So long as XML in the message can be satisfied by saying it is part >>> of the "MSG" section, then yes. I don't believe there are >> any planned >>> restrictions on what the text content of "MSG" can be. >>> >>> Otherwise we're just going back down the road of 3195. >>> >>> If John wanted to see XML in syslog formalised, then my >> vote would for >>> it to be a follow on draft that documented a particular SD-ID as the >>> means for indicating the MSG was expected to be XML. >>> >>> But I cannot emphasise strongly enough that it is not >> appropriate for >>> this group to take on syslog and XML, beyond what exists in 3195, at >>> the present time. We need to focus on the charter and >> achieve a basic >>> set of goals first before moving on to things like this. This isn't >>> to say that it won't be addressed, but not here and now. >> If this puts >>> you, John, in uncertain land for the time being then I >> think that has >>> to just be accepted with an understanding that it can be >> redressed at >>> some point in the future, even if it doesn't make our >> current charter. >>> >>> Darren >>> >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 12:19:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyHj-00063Q-QW; Wed, 23 Nov 2005 12:19:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyHi-00062y-0y for syslog@megatron.ietf.org; Wed, 23 Nov 2005 12:19:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29739 for ; Wed, 23 Nov 2005 12:19:15 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eeyab-000706-LJ for syslog@ietf.org; Wed, 23 Nov 2005 12:39:26 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 1C4BE9C00C for ; Wed, 23 Nov 2005 18:28:09 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02000-07 for ; Wed, 23 Nov 2005 18:28:04 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4A2809C00B for ; Wed, 23 Nov 2005 18:28:04 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] Revised proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 18:19:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EFE@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Revised proposed charter Thread-Index: AcXwURiQMlgeSr9oQSGhTkh0A0mNeQAAPa/Q From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I fully agreee. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > Sent: Wednesday, November 23, 2005 6:05 PM > To: syslog@ietf.org > Subject: [Syslog] Revised proposed charter >=20 > Hi All, >=20 > =3D=3D=3D=3D v2 of proposed charter =3D=3D=3D >=20 > Syslog is a de-facto standard for logging system events. =20 > However, the=20 > protocol component of this event logging system has not been formally=20 > documented. While the protocol has been very useful and=20 > scalable, it has=20 > some known security problems which were documented in RFC 3164. >=20 > The goal of this working group is to address the security and=20 > integrity=20 > problems, and to standardize the syslog protocol, transport,=20 > and a select=20 > set of mechanisms in a manner that considers the ease of=20 > migration between=20 > and the co-existence of existing versions and the standard. >=20 > syslog has traditionally been transported over UDP and this=20 > WG has already=20 > defined RFC 3195 for the reliable transport for the syslog=20 > messages. The=20 > WG will separate the UDP transport from the protocol so that=20 > others may=20 > define additional transports in the future. >=20 >=20 > - A document will be produced that describes a standardized syslog > protocol. A mechanism will also be defined in this document > that will provide a means to convey structured data. >=20 > - A document will be produced that describes a standardized UDP > transport for syslog. >=20 > - A document will be produced that describes a standardized mechanism > to sign syslog messages to provide integrity checking and source > authentication. >=20 >=20 > =3D=3D=3D =3D=3D=3D >=20 > Comments please. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 12:27:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyOl-00081w-Gq; Wed, 23 Nov 2005 12:27:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyOk-00080u-55 for syslog@megatron.ietf.org; Wed, 23 Nov 2005 12:27:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00913 for ; Wed, 23 Nov 2005 12:26:31 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eeyh7-0007Vr-71 for syslog@ietf.org; Wed, 23 Nov 2005 12:46:42 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 95AEC9C00C for ; Wed, 23 Nov 2005 18:34:52 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02000-09 for ; Wed, 23 Nov 2005 18:34:46 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id D74389C00B for ; Wed, 23 Nov 2005 18:34:46 +0100 (CET) Received: from adisconone ([172.19.2.14]) by grfint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Nov 2005 18:26:22 +0100 Subject: RE: [Syslog] New direction and proposed charter From: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3EF5@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E3EF5@grfint2.intern.adiscon.com> Content-Type: text/plain Organization: Adiscon Message-Id: <1132766781.2187.4.camel@rh9lt.intern.adiscon.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 23 Nov 2005 18:26:21 +0100 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Nov 2005 17:26:22.0218 (UTC) FILETIME=[05EB36A0:01C5F053] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org For what it is worth... I have tried to create a send-template for rsyslogd, my *nix syslogd. It covers: > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP > [SD-ID]s SP MSG > > or, somewhat incorrect but shorter: > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [SD-ID]s MSG > > Please note that I have added the MSGID to the header. It was easy to do, actually a 5 minute job. Of course, sending a message is another beast then parsing it, but I think this will also be sufficiently simple. As far as I know (some) other syslogds have similar template systems, so this point eventually proves that the modifications required will not break anything at all. The only tricky issue that remains is the NUL octect. The more I think about it, the more I think the CLR to disallow it is less evil than to make it stay... Rainer On Wed, 2005-11-23 at 16:29, Rainer Gerhards wrote: > This is really disappointing... > > I have done further testing with more syslogds to confirm the initial > findings. The more different programs / versions I try, the more a mess > this gets. OK, we knew FreeBSD syslogd does not include the hostname. > Next I tested with some Windows products, which looked promising. Then I > looked at the sysklogd source. It is the standard Linux package, so if > it works, a lot would be won. The source tells me that at least the > timestamp should correctly be extracted. Then I actually tried it out > with a Debian system - the timestamp was ignored. Checking that source > tree I see that *that* sysklogd does deliberately ignore the data and > always pulls the local date (or ist it a bug - who cares...). When it > comes to relaying it is even stranger: sysklogd does neither relay the > timestamp nor the host part. At that point, I have stopped further > analysis, because I think I would be able to find another good number of > variants of syslog behaviour. > > Conclusion: > > 1. There is no point in trying to preserve backward > compatibility besides sticking with the . Everything other > than is handled differently by different implementations > and/or versions. > > 2. We can NOT expect that relaying over existing syslog > implementations will ever work. Please note that this would > also have broken syslog-sign without specifically implemented > daemons. > > As such, I revert back to proposing > > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP > [SD-ID]s SP MSG > > or, somewhat incorrect but shorter: > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [SD-ID]s MSG > > Please note that I have added the MSGID to the header. > > Rainer > > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Wednesday, November 23, 2005 3:04 PM > > To: Glenn Mansfield Keeni; syslog@ietf.org > > Subject: RE: [Syslog] New direction and proposed charter > > > > Glenn, > > > > very interesting approach with the timestamp. I think your > > ideas can be > > the key to maintaining a lot of backwards compatibility by still > > retaining new functionality. > > > > First some bad news: I am not sure if by "BSD syslog" you are refering > > to RFC 3164 or a specific distribution of BSD. I have created a small > > script to test out your recommendation. I used FreeBSD stock > > syslogd as > > the receiver. > > > > It did NOT work as expected. There are two reasons > > > > a) (that) BSD syslogd takes the sender always from the system > > that send > > it > > b) even worse, when relaying, it puts "Forwarded from > > : " into > > > > the hostname part (yes, with all that spaces) > > > > So while the idea sounds excellent, it does not work with > > stock FreeBSD > > syslogd. I am not sure about other BSD variants, nor have I > > checked the > > sysklogd package. I believe it will have less issues in this regard. > > > > This was the message I sent (via perl script): > > > > "<148>Oct 11 22:14:15 mymachine.example.com 1 ID47 2003T.003Z > > 'su root' > > failed for lonvick on /dev/pts/8" > > > > this was the raw message received after being relayed once by FreeBSD > > stock syslogd: > > > > "<148>Oct 11 22:14:15 Forwarded from 172.19.2.7: > > mymachine.example.com 1 > > ID47 2003T.003Z 'su root' failed for lonvick on /dev/pts/8" > > > > As you can see, the message is somewhat distorted - definitely enough > > for digital signatures to be broken. [Implementor's > > side-note: This can > > be fixed on a syslog-application layer level, far beyond the > > IETF scope. > > It's straightforward and easy to do, so it will probably happen.] > > > > Even though this actual sample seems not to work, it paves > > the way to a > > very elegant compatibility solution. The key is to add the extra > > information (e.g. Timestamp) in a different place. At least I was so > > focussed on fields at whole that I did not notice this possibility. I > > have experiemented a bit more with Glenn's proposal, shuffeling some > > fields. The result was this: > > > > BSD_syslog_timestamp FQDN TAG "@#"VERSION MSGID > > Remainder_Timestamp > > [SD-ID]s MSG > > > > or in an actual sample: > > > > "<148>Oct 11 22:14:15 mymachine.example.com su[4711]: @#1 ID47 > > 2003T.003Z [SD-IDs] 'su root' failed for lonvick on /dev/pts/8" > > > > I have used the BSD timestamp and FAQN as Glenn suggested. > > Then, I have > > added the "TAG" again. If we think in the spirit of my mail > > this morning > > on syslog & non-IETF standards, it would not really hurt if we > > standardize TAG instead of two fields. If I would like to retain the > > APP-NAME and PROCESSID, I could do the following ABNF: > > > > TAG = APP-NAME ["[" PROCESSID "]"] ":" > > > > The side-effect of this is that almost all syslog-messages currently > > emited comply with that format. So I suggest that we strongly consider > > joining these two again. Out of the sudden, we have the "old" header, > > but it is parsable by a hyptothetical new syslogd. Next, I have used a > > trick from syslog-sign. I have changed the VERSION from a number to a > > number plus a cookie. The version would now be "@#1". I do not care if > > the cookie is "@#" or something else. The key point is that > > it, together > > with the version should be very unlikely to exist at that place in > > old-style syslog. That would allow a "new" receiver to differentiate > > between old and new style syslog messages. The rest of the message is > > just applying Glenn's proposal again: it has the MSG, the > > missing parts > > of the timestamp, SD-IDs and MSG. The Remainder_Timestamp > > looks strange. > > We might like it, we might like something else. That's easy to change > > and discuss. It's the concept that matters right now, not the exact > > format. > > > > If we take the outlined route, we would be able to extend the syslog > > protocol with as much backward compatibility as is possible in a > > not-yet-standardized world. I find this very desirable. I > > think we even > > have good chances that many existing "old" syslogds would relay such > > messages without changing them, thus keeping digital > > signatures intact. > > The required text changes for syslog-protocol should be moderate. > > > > I strongly propose we go in that direction. > > > > Rainer > > > -----Original Message----- > > > From: syslog-bounces@lists.ietf.org > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn > > > Mansfield Keeni > > > Sent: Wednesday, November 23, 2005 1:39 PM > > > To: syslog@ietf.org > > > Subject: Re: [Syslog] New direction and proposed charter > > > > > > Chris/Rainer, > > > > > > > we continue to use ... at the start of syslog > > > messages. This will > > > > allow current receivers to continue to receive messages and > > > put them in > > > > the right bins. Does anyone disagree with this? > > > > > > Complete agreement. > > > > > > > > > > > > The WG has agreed to use the timestamp Rainer has in the current > > > > syslog-protocol. > > > In principle I agree with the timestamp format. It is good. > > > I may have missed the discussion on this matter, in that > > case please > > > accept my apologies and ignore the rest of the mail. > > > > > > To get existing BSD syslog devices specifically relays into > > > the compatibility > > > fold it WILL be good idea to keep the timestamp in two parts > > > > > > RainerTimestamp = BSD_syslog_timestamp + RemainderTimestamp > > > > > > > One possibility would be to assemble a syslog message as: > > > > > > > > TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG > > > > > > In the context of what has been said above about the > > > timestamp. I would > > > suggest > > > BSD_syslog_timestamp FQDN VERSION MSGID > > > Remainder_Timestamp [SD-ID]s MSG > > > > > > That would allow existing BSD-syslog relays to handle the new > > > syslog protocol > > > in a transparent manner. Everything from VERSION to the end > > > is treated as "message". > > > > > > We do not lose information. > > > The Remainder_timestamp carries it - in a slightly less > > > convenient place > > > though. > > > > > > On the other hand if we insist on using RainerTimestamp, > > > existing BSD_syslog > > > relays will relay the message as > > > > > > BSD_syslog_timestamp FQDN RainerTimestamp FQDN VERSION > > > MSGID [SD-ID]s MSG > > > > > > The message does get distorted to some extent. > > > > > > > If we can agree to this then I suspect that we can have a working > > > > document within Rainer's timeframe. I'll propose the > > > following charter > > > > to keep us focused. > > > > > > > > -------- Proposed Charter -------------- > > > > > > > > Syslog is a de-facto standard for logging system events. > > > However, the > > > > protocol component of this event logging system has not > > > been formally > > > > documented. While the protocol has been very useful and > > > scalable, it > > > > has some known security problems which were documented in > > RFC 3164. > > > > > > > > The goal of this working group is to address the security and > > > > integrity problems of the existing syslog mechanism while > > > not breaking > > > > backwards compatibility. The most obvious problems that > > need to be > > > > addressed in the syslog protocol are the timestamp, which has not > > > > formally included a means to indicate the year, and the > > > identification > > > > of the source which has been a hostname without a qualified domain > > > > name. Additionally, a version, some type of message > > > indicator, and a > > > > means to convey structured data will be included in the protocol. > > > > > > > > syslog has traditionally been transported over UDP and this WG has > > > > already defined RFC 3195 for the reliable transport for the syslog > > > > messages. The WG will separate the UDP transport from the > > > protocol so > > > > that others may define additional transports in the future. > > > > > > > > - A standard will be produced that formally documents the syslog > > > > protocol. A mechanism will also be defined in this specification > > > > that will provide a means to convey structured data. > > > > > > > > - A standard will be produced that documents the UDP transport for > > > > syslog. > > > > > > > > - A standard will be produced that documents a mechanism to sign > > > > syslog messages to provide integrity checking and source > > > > authentication. > > > > > > > > - A MIB definition for syslog will be produced. > > > > > > > > ------------------------------------------- > > > > > > > > > > > > PLEASE review this and respond. > > > > > > > > > > Glenn > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 12:30:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeySH-0004es-IK; Wed, 23 Nov 2005 12:30:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeySG-0004cD-4G for syslog@megatron.ietf.org; Wed, 23 Nov 2005 12:30:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01109 for ; Wed, 23 Nov 2005 12:30:09 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eeyl9-0007fC-TQ for syslog@ietf.org; Wed, 23 Nov 2005 12:50:20 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Nov 2005 12:30:39 -0500 X-IronPort-AV: i="3.97,364,1125892800"; d="scan'208"; a="76397894:sNHT25903932" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jANHU5eH017813 for ; Wed, 23 Nov 2005 12:30:37 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 12:29:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Revised proposed charter Date: Wed, 23 Nov 2005 12:29:18 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C85635@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Revised proposed charter Thread-Index: AcXwUSI/WOaa07KxQQGDejhRZvGDUgAAFJlQ From: "Anton Okmianski \(aokmians\)" To: "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 23 Nov 2005 17:29:19.0546 (UTC) FILETIME=[6F9D51A0:01C5F053] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris: This is fine, but does not include all the other specific details we = agreed on and as such is not different from what we had before. I think = we can focus our efforts better by creating narrower scope. How about = limiting backwards compatibility to only. Requiring = standardization of better time stamp. Support for FQDN, IPv6. MSGID. = Internationalization (UTF-8). Etc... I am afraid that if we leave the = charter open-ended as before, we will be debating the charter again 2 = years from now. =20 Also, sorry if I missed some earlier discussions on signing messages. = Proposed charter mentions source authentication. For TCP mappings (such = as BEEP), TLS already provides authentication and encryption. SSH = transport would provide similar facilities. Is there an overlap here? Is = message signing targeted at just UDP transport? =20 Thanks, Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris=20 > Lonvick (clonvick) > Sent: Wednesday, November 23, 2005 12:05 PM > To: syslog@ietf.org > Subject: [Syslog] Revised proposed charter >=20 > Hi All, >=20 > =3D=3D=3D=3D v2 of proposed charter =3D=3D=3D >=20 > Syslog is a de-facto standard for logging system events. =20 > However, the protocol component of this event logging system=20 > has not been formally documented. While the protocol has=20 > been very useful and scalable, it has some known security=20 > problems which were documented in RFC 3164. >=20 > The goal of this working group is to address the security and=20 > integrity problems, and to standardize the syslog protocol,=20 > transport, and a select set of mechanisms in a manner that=20 > considers the ease of migration between and the co-existence=20 > of existing versions and the standard. >=20 > syslog has traditionally been transported over UDP and this=20 > WG has already defined RFC 3195 for the reliable transport=20 > for the syslog messages. The WG will separate the UDP=20 > transport from the protocol so that others may define=20 > additional transports in the future. >=20 >=20 > - A document will be produced that describes a standardized=20 > syslog protocol. A mechanism will also be defined in this=20 > document that will provide a means to convey structured data. >=20 > - A document will be produced that describes a standardized=20 > UDP transport for syslog. >=20 > - A document will be produced that describes a standardized=20 > mechanism to sign syslog messages to provide integrity=20 > checking and source authentication. >=20 >=20 > =3D=3D=3D =3D=3D=3D >=20 > Comments please. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 12:38:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyZk-0000tP-IY; Wed, 23 Nov 2005 12:38:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyZi-0000qp-Ri for syslog@megatron.ietf.org; Wed, 23 Nov 2005 12:38:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01917 for ; Wed, 23 Nov 2005 12:37:51 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eeysc-00086N-RM for syslog@ietf.org; Wed, 23 Nov 2005 12:58:03 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4EB8A9C00C for ; Wed, 23 Nov 2005 18:46:46 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02087-05 for ; Wed, 23 Nov 2005 18:46:42 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id CFA329C00B for ; Wed, 23 Nov 2005 18:46:42 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] Revised proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2005 18:38:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3EFF@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Revised proposed charter Thread-Index: AcXwUSI/WOaa07KxQQGDejhRZvGDUgAAFJlQAACb6hA= From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Also, sorry if I missed some earlier discussions on signing=20 > messages. Proposed charter mentions source authentication.=20 > For TCP mappings (such as BEEP), TLS already provides=20 > authentication and encryption. SSH transport would provide=20 > similar facilities. Is there an overlap here? Is message=20 > signing targeted at just UDP transport? =20 Signing - as I understand syslog-sign - goes beyong that. You could also say it serves a different purpose. -sign is about signature inside the messages that you can use to verify the correctness not only in transit but also years later in an offline copy. The details are not 100% technically correct, but I think it conveys the overall idea. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 12:51:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeylo-0007az-GT; Wed, 23 Nov 2005 12:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeyln-0007ar-UZ for syslog@megatron.ietf.org; Wed, 23 Nov 2005 12:51:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03335 for ; Wed, 23 Nov 2005 12:50:20 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eez4h-0000He-VE for syslog@ietf.org; Wed, 23 Nov 2005 13:10:32 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 23 Nov 2005 09:50:51 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jANHoJsU011787 for ; Wed, 23 Nov 2005 09:50:48 -0800 (PST) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 09:50:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Revised proposed charter Date: Wed, 23 Nov 2005 09:50:47 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FBEFCE71@xmb-sjc-236.amer.cisco.com> Thread-Topic: [Syslog] Revised proposed charter Thread-Index: AcXwUSI/WOaa07KxQQGDejhRZvGDUgAAFJlQAADxJVA= From: "Alexander Clemm \(alex\)" To: "Anton Okmianski \(aokmians\)" , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 23 Nov 2005 17:50:47.0886 (UTC) FILETIME=[6F8666E0:01C5F056] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I think the charter looks good. It describes what the working group has to do and its deliverables. I agree that there is a next level of details that spells out the specifics of how to do it. We had a lot of discussion on this and seem to have come to a consensus, which is something that we should capture. However, the question is if that next level (the "how" in addition to the "what") really belongs in a charter - not sure if the charter would be the right place. =20 -- Alex -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton Okmianski (aokmians) Sent: Wednesday, November 23, 2005 9:29 AM To: Chris Lonvick (clonvick); syslog@ietf.org Subject: RE: [Syslog] Revised proposed charter Chris: This is fine, but does not include all the other specific details we agreed on and as such is not different from what we had before. I think we can focus our efforts better by creating narrower scope. How about limiting backwards compatibility to only. Requiring standardization of better time stamp. Support for FQDN, IPv6. MSGID. Internationalization (UTF-8). Etc... I am afraid that if we leave the charter open-ended as before, we will be debating the charter again 2 years from now. =20 Also, sorry if I missed some earlier discussions on signing messages. Proposed charter mentions source authentication. For TCP mappings (such as BEEP), TLS already provides authentication and encryption. SSH transport would provide similar facilities. Is there an overlap here? Is message signing targeted at just UDP transport? =20 Thanks, Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick=20 > (clonvick) > Sent: Wednesday, November 23, 2005 12:05 PM > To: syslog@ietf.org > Subject: [Syslog] Revised proposed charter >=20 > Hi All, >=20 > =3D=3D=3D=3D v2 of proposed charter =3D=3D=3D >=20 > Syslog is a de-facto standard for logging system events. =20 > However, the protocol component of this event logging system has not=20 > been formally documented. While the protocol has been very useful and > scalable, it has some known security problems which were documented in > RFC 3164. >=20 > The goal of this working group is to address the security and=20 > integrity problems, and to standardize the syslog protocol, transport, > and a select set of mechanisms in a manner that considers the ease of=20 > migration between and the co-existence of existing versions and the=20 > standard. >=20 > syslog has traditionally been transported over UDP and this WG has=20 > already defined RFC 3195 for the reliable transport for the syslog=20 > messages. The WG will separate the UDP transport from the protocol so > that others may define additional transports in the future. >=20 >=20 > - A document will be produced that describes a standardized=20 > syslog protocol. A mechanism will also be defined in this=20 > document that will provide a means to convey structured data. >=20 > - A document will be produced that describes a standardized=20 > UDP transport for syslog. >=20 > - A document will be produced that describes a standardized=20 > mechanism to sign syslog messages to provide integrity=20 > checking and source authentication. >=20 >=20 > =3D=3D=3D =3D=3D=3D >=20 > Comments please. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 17:11:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef2ps-0008Hb-3V; Wed, 23 Nov 2005 17:11:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef2pq-0008G8-1F for syslog@megatron.ietf.org; Wed, 23 Nov 2005 17:11:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06705 for ; Wed, 23 Nov 2005 17:10:45 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef38k-0007i4-WA for syslog@ietf.org; Wed, 23 Nov 2005 17:31:00 -0500 Received: from pc6 (1Cust132.tnt1.lnd4.gbr.da.uu.net [62.188.130.132]) by galaxy.systems.pipex.net (Postfix) with SMTP id A9BB1E00022F; Wed, 23 Nov 2005 22:11:06 +0000 (GMT) Message-ID: <023a01c5f072$2a16c340$0601a8c0@pc6> From: "Tom Petch" To: "Moehrke, John (GE Healthcare)" References: <45A5295FFA1CBE4D9BF44E8534D2686C09984372@MKEMLVEM07.e2k.ad.ge.com> Subject: XML payload was Re: [Syslog] RE: Message format Date: Wed, 23 Nov 2005 22:05:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, andrew@kiwisyslog.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sounds more like one for the netconf WG, where XML is king, backwards compatability is not an issue, messages can be orders of magnitudes larger, security is inherent etc etc. The only downside is that work on notifications/events has only just started but one school of thought is that it should be syslog-like. What you want could be to netconf as private.enterprises is to SNMP. Tom Petch ----- Original Message ----- From: "Moehrke, John (GE Healthcare)" To: "Darren Reed" Cc: ; Sent: Wednesday, November 23, 2005 4:02 PM Subject: RE: [Syslog] RE: Message format I don't think we are asking for anything specific. The XML payload (RFC 3881) is text, and somewhat human readable. We went with XML payload because we have well defined object identifiers that have been standardized and used throughout the hospital by many different systems provided by many different vendors. These identifiers cover data objects, patients, doctors, equipment, drugs, orders, etc... Taking this nicely coded information and putting it into a unformatted string seemed very counter. The XML string is descriptive enough that simple string parsing works, but is also well defined so that XML parsing can be done as well. What I am trying to do is figure out if the charter for this group is really to force the payload to be a human readable text string, or if the payload can include an XML formatted event description. We do not need binary. We do not need Mega-Byte MTUs. We really have tried to fit within the requirements that we understood syslog to have. We (healthcare) want to do what we do best (treat patients), and leave you (syslog) community to what you do best. We don't want to analyze/report/alert/etc on security events, we expect you are experts in this field. It is a shame to see this get in the way of an opportunity for both of us. John > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au] > Sent: Wednesday, November 23, 2005 8:09 AM > To: Moehrke, John (GE Healthcare) > Cc: andrew@kiwisyslog.com; Rainer Gerhards; syslog@ietf.org > Subject: Re: [Syslog] RE: Message format > > > To all, > > > > The view that syslog must only be used to transport "human readable > > syslog messages" is disturbing. Is this the view of the syslog > > community? > > At present what we're concerned with is a logging facility that does > generate and consume human readable messages. > > At some point in the future, when we have agreement on the human > readable version, then we can consider what to do with messages > that aren't human readable. > > So while I accept your assertion, addressing it is out of scope for > the current discussion. We have smaller fish to fry, first, before > attempting the big ones. Trying to solve "all the problems" is what > got this group into the situation we are in now. We need to take a > step back and focus on resolving smaller and more well defined > problems before looking at a "grand unified logging protocol" (GULP). > > Nothing lasts forever, not even standards. > > Darren > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 17:35:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef3Da-0006ek-51; Wed, 23 Nov 2005 17:35:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef3DZ-0006eO-8D for syslog@megatron.ietf.org; Wed, 23 Nov 2005 17:35:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09422 for ; Wed, 23 Nov 2005 17:35:16 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef3WV-0000eX-Mt for syslog@ietf.org; Wed, 23 Nov 2005 17:55:32 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 23 Nov 2005 14:35:48 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jANMZb6e005192; Wed, 23 Nov 2005 14:35:45 -0800 (PST) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 14:35:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: XML payload was Re: [Syslog] RE: Message format Date: Wed, 23 Nov 2005 14:35:42 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FBEFCFE8@xmb-sjc-236.amer.cisco.com> Thread-Topic: XML payload was Re: [Syslog] RE: Message format Thread-Index: AcXwe2uOf4EFlSUlRA6l4WpsHAc+3AAAGHrw From: "Alexander Clemm \(alex\)" To: "Tom Petch" , "Moehrke, John \(GE Healthcare\)" X-OriginalArrivalTime: 23 Nov 2005 22:35:43.0436 (UTC) FILETIME=[3D4450C0:01C5F07E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, andrew@kiwisyslog.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org There should be no issue with allowing different types of payload format in the message text. If someone wants to define syslog messages with a message text that happens to be formatted as XML, that should not be an issue but constitutes a valid scenario. Syslog is a mechanism, a tool; what particular messages you define respectively use this for should be up to the individual implementation. Just my 2 cents. =20 --- Alex=20 -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Tom Petch Sent: Wednesday, November 23, 2005 1:06 PM To: Moehrke, John (GE Healthcare) Cc: syslog@ietf.org; andrew@kiwisyslog.com Subject: XML payload was Re: [Syslog] RE: Message format Sounds more like one for the netconf WG, where XML is king, backwards compatability is not an issue, messages can be orders of magnitudes larger, security is inherent etc etc. The only downside is that work on notifications/events has only just started but one school of thought is that it should be syslog-like. What you want could be to netconf as private.enterprises is to SNMP. Tom Petch ----- Original Message ----- From: "Moehrke, John (GE Healthcare)" To: "Darren Reed" Cc: ; Sent: Wednesday, November 23, 2005 4:02 PM Subject: RE: [Syslog] RE: Message format I don't think we are asking for anything specific. The XML payload (RFC 3881) is text, and somewhat human readable. We went with XML payload because we have well defined object identifiers that have been standardized and used throughout the hospital by many different systems provided by many different vendors. These identifiers cover data objects, patients, doctors, equipment, drugs, orders, etc... Taking this nicely coded information and putting it into a unformatted string seemed very counter. The XML string is descriptive enough that simple string parsing works, but is also well defined so that XML parsing can be done as well. What I am trying to do is figure out if the charter for this group is really to force the payload to be a human readable text string, or if the payload can include an XML formatted event description. We do not need binary. We do not need Mega-Byte MTUs. We really have tried to fit within the requirements that we understood syslog to have. We (healthcare) want to do what we do best (treat patients), and leave you (syslog) community to what you do best. We don't want to analyze/report/alert/etc on security events, we expect you are experts in this field. It is a shame to see this get in the way of an opportunity for both of us. John > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au] > Sent: Wednesday, November 23, 2005 8:09 AM > To: Moehrke, John (GE Healthcare) > Cc: andrew@kiwisyslog.com; Rainer Gerhards; syslog@ietf.org > Subject: Re: [Syslog] RE: Message format > > > To all, > > > > The view that syslog must only be used to transport "human readable=20 > > syslog messages" is disturbing. Is this the view of the syslog=20 > > community? > > At present what we're concerned with is a logging facility that does=20 > generate and consume human readable messages. > > At some point in the future, when we have agreement on the human=20 > readable version, then we can consider what to do with messages that=20 > aren't human readable. > > So while I accept your assertion, addressing it is out of scope for=20 > the current discussion. We have smaller fish to fry, first, before=20 > attempting the big ones. Trying to solve "all the problems" is what=20 > got this group into the situation we are in now. We need to take a=20 > step back and focus on resolving smaller and more well defined=20 > problems before looking at a "grand unified logging protocol" (GULP). > > Nothing lasts forever, not even standards. > > Darren > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 18:08:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef3ie-0006Cp-VA; Wed, 23 Nov 2005 18:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef3id-0006BY-QY for syslog@megatron.ietf.org; Wed, 23 Nov 2005 18:08:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13044 for ; Wed, 23 Nov 2005 18:07:22 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ef41Z-0002Vl-J4 for syslog@ietf.org; Wed, 23 Nov 2005 18:27:38 -0500 Received: (qmail 75574 invoked from network); 23 Nov 2005 23:07:50 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 23 Nov 2005 23:07:50 -0000 X-pair-Authenticated: 202.137.242.74 From: "Andrew Ross" To: "'Rainer Gerhards'" Subject: RE: [Syslog] RE: Message format Date: Thu, 24 Nov 2005 12:07:45 +1300 Organization: Kiwi Enterprises Message-ID: <001f01c5f082$b8da82f0$d901a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3EE6@grfint2.intern.adiscon.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, I concur on the message size issue. Let's leave it as it stands until we = get to a TCP mapping. Can you mention in your document that the real life = max UDP size was found to be 4K bytes? I think this is a valuable finding = and would save a lot of hair pulling on the part of implementers. Cheers Andrew -----Original Message----- From: syslog-bounces@lists.ietf.org = [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards Sent: Wednesday, 23 November 2005 10:00 p.m. To: andrew@kiwisyslog.com Cc: syslog@ietf.org Subject: RE: [Syslog] RE: Message format Andrew, on the size: Though I have some concerns, I can agree with your point of view. In fact, one of the syslog-protocol revisions had a mechanism called multi-part messages. This could be utilized. Maybe we should do a separate spec on "large size messages". That wouldn't be too much effort and be a truely optional feature (I even think we could simply carry over the text from that draft version). What I am currently concerned about is putting this size issue to a rest. I think the compromise is good enough, especially as we do NOT yet specify a plain tcp mapping (we even don't know if we will ever get consensus to do that). That means the currently proposed text keeps the options open to do anything we might later decide. And it acutally puts a hard limit to roughly 64K by the fact that only UDP is supported. As I have outlined in another mail, that practical limit seems to be more 4K than 64K. Given that situation, I strongly suggest not to get another round of max size discussion. I think we urgently need now a consensus on the lowest denominator and get that consensus published. Else we will be discussing and discussing but never achive any milestone. I like the approach of baby-steps, which will give us something usable after each step. The core thing we need to do is have a format specification including layered architecture) that allows us to build on. Then, I think, we can focus on specific issues. Rainer > -----Original Message----- > From: Andrew Ross [mailto:andrew@kiwisyslog.com]=20 > Sent: Wednesday, November 23, 2005 9:51 AM > To: Rainer Gerhards > Subject: RE: [Syslog] RE: Message format >=20 >=20 > >> Mapping over UDP should be limited to a single message per packet. > >I agree on that. If we need an ultra-compact UDP delivery, we could > >later add it in a separate transport mapping. >=20 > Yes, good idea. I doubt anyone will ever want to do this, or=20 > at least go to > the effort of trying to get it drafted into an RFC ;-) >=20 > >> When mapping over plain TCP I believe we should limit the=20 > >> total message size > >> to 65507 bytes (to keep it compatible with UDP) and delimit=20 > >> each message > >> stream with an LF, or CRLF. Either delimiter would work for me. >=20 > >I would prefer not to restart the size discussion at this=20 > point. I think > >the current compromise (everyone must support 2K, anyone=20 > might support > >as much as he likes) is sufficient for most, if not all,=20 > cases. I would > >not like to see an application to become non-compliant just=20 > because it > >needs to transmit 65508 bytes inside a message. >=20 > > I realise this should have been brought up earlier in the=20 > draft process, > however, I would really like to see a limit on the message=20 > size so that it > is directly compatible with UDP. If we allow an opened ended=20 > message size, > people *will* use it for non syslog related things. I feel=20 > that any message > longer than will fit into a UDP packet should be broken into=20 > two or more > separate messages by the sender, even if sent over TCP. This=20 > allows me to > allocate a maximum known buffer size for incoming TCP=20 > messages. There is a > potential for huge messages filling the memory and memory=20 > buffer overflows > happening if the messages are not limited in size. "Syslog"=20 > is meant to be a > human readable system log message. Anything longer (including=20 > binary crash > dumps or other things people misuse syslog for) should be broken into > separate messages by the sender, or sent over a different protocol. > >=20 > I think we should keep syslog simple and flexible, but not at=20 > the expense of > making it handle things it was never meant for. If a message=20 > needs to be > broken into many chunks, the SD-ID tags could be used to tie all the > messages together again by the parser. The syslog receiver or=20 > relay will > just handle them as separate messages and not even know they=20 > were split. > This makes things so much simpler. >=20 > Cheers >=20 > Andrew >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 18:17:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef3rc-0002r2-2I; Wed, 23 Nov 2005 18:17:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef3rb-0002qw-57 for syslog@megatron.ietf.org; Wed, 23 Nov 2005 18:17:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13544 for ; Wed, 23 Nov 2005 18:16:40 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ef4AW-0002vS-Ri for syslog@ietf.org; Wed, 23 Nov 2005 18:36:54 -0500 Received: (qmail 78168 invoked from network); 23 Nov 2005 23:17:15 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 23 Nov 2005 23:17:15 -0000 X-pair-Authenticated: 202.137.242.74 From: "Andrew Ross" To: "'Rainer Gerhards'" Subject: RE: [Syslog] New direction and proposed charter Date: Thu, 24 Nov 2005 12:17:11 +1300 Organization: Kiwi Enterprises Message-ID: <002001c5f084$09a0a740$d901a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1132766781.2187.4.camel@rh9lt.intern.adiscon.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >The only tricky issue that remains is the NUL octet. The more I think >about it, the more I think the CLR to disallow it is less evil than to >make it stay... I agree that having the CLR for NUL octet exclusion is OK. Quick question, if someone is sending international data in UTF-8 = format, can there ever be a valid UTF-8 sequence that includes a NUL octet = value? If so, we need to allow NUL values in the MSG.=20 Does anyone on the list know UTF-8 well enough to answer this? Cheers Andrew _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 23 19:02:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef4Ys-0007Rn-30; Wed, 23 Nov 2005 19:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef4Yr-0007Rg-1q for syslog@megatron.ietf.org; Wed, 23 Nov 2005 19:02:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18814 for ; Wed, 23 Nov 2005 19:01:21 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef4rn-0005en-D7 for syslog@ietf.org; Wed, 23 Nov 2005 19:21:36 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Nov 2005 16:01:49 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,367,1125903600"; d="scan'208"; a="15889114:sNHT22307260" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAO01elr018316; Wed, 23 Nov 2005 19:01:46 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 19:01:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Wed, 23 Nov 2005 19:01:44 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C85785@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXwhGi60geOEbzwSBCfB3qZBlEzEgAA5nJQ From: "Anton Okmianski \(aokmians\)" To: , "Rainer Gerhards" X-OriginalArrivalTime: 24 Nov 2005 00:01:45.0489 (UTC) FILETIME=[42171810:01C5F08A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Andrew: The \u0000 is a valid Unicode and UTF-8 character.=20 See section 1 (first bullet point) in UTF-8 RFC: http://www.ietf.org/rfc/rfc3629.txt Also defined as valid in Unicode standard: http://www.unicode.org/Public/UNIDATA/Blocks.txt I can't tell what it could possibly be used to indicate now and in the = future.=20 I can see something like this error message: ...MyApp pid123 MALFORMED_INPUT: Bad input received from client: = [aaa\u0000] The question is does not it need to be escaped for transport or only in = display. I'd personally prefer deferring any kind of escaping until it = is really needed, like when displaying binary to the user. =20 Thanks, Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Andrew Ross > Sent: Wednesday, November 23, 2005 6:17 PM > To: 'Rainer Gerhards' > Cc: syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 >=20 > >The only tricky issue that remains is the NUL octet. The=20 > more I think=20 > >about it, the more I think the CLR to disallow it is less=20 > evil than to=20 > >make it stay... >=20 > I agree that having the CLR for NUL octet exclusion is OK. >=20 > Quick question, if someone is sending international data in=20 > UTF-8 format, can there ever be a valid UTF-8 sequence that=20 > includes a NUL octet value? If so, we need to allow NUL=20 > values in the MSG.=20 >=20 > Does anyone on the list know UTF-8 well enough to answer this? >=20 > Cheers >=20 > Andrew >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 03:23:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCNt-0007BP-Gv; Thu, 24 Nov 2005 03:23:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCNq-0007Au-BA for syslog@megatron.ietf.org; Thu, 24 Nov 2005 03:23:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00398 for ; Thu, 24 Nov 2005 03:22:29 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfCgp-000227-CS for syslog@ietf.org; Thu, 24 Nov 2005 03:42:50 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id DDB329C00D for ; Thu, 24 Nov 2005 09:31:08 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02527-06 for ; Thu, 24 Nov 2005 09:31:05 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 41D1E9C00B for ; Thu, 24 Nov 2005 09:31:05 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] RE: Message format MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 09:22:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F01@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] RE: Message format Thread-Index: AcXwgrzFEesaEfS2T8u1K5rKJZ+ofgATN5lw From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Happy thanksgiving to all US list members! I hope you have better to do than read my postings today. I'll send them anyhow looking forward to a healthy discussion next week :) Rainer > -----Original Message----- > From: Andrew Ross [mailto:andrew@kiwisyslog.com]=20 >=20 > I concur on the message size issue. Let's leave it as it=20 > stands until we get > to a TCP mapping. Can you mention in your document that the=20 > real life max > UDP size was found to be 4K bytes? I think this is a valuable=20 > finding and > would save a lot of hair pulling on the part of implementers. This is an item for Anton's UDP transport mapping. Please notet that I did no extensive analysis and there are probably ways to increase the MTU. I have not looked at this because I was interested in what you can expect in "the usual case". I think Anton has done some more work in this regard and can eventually provide further insight. >=20 > Cheers >=20 > Andrew >=20 >=20 >=20 >=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Rainer Gerhards > Sent: Wednesday, 23 November 2005 10:00 p.m. > To: andrew@kiwisyslog.com > Cc: syslog@ietf.org > Subject: RE: [Syslog] RE: Message format >=20 >=20 > Andrew, >=20 > on the size: Though I have some concerns, I can agree with=20 > your point of > view. In fact, one of the syslog-protocol revisions had a mechanism > called multi-part messages. This could be utilized. Maybe we=20 > should do a > separate spec on "large size messages". That wouldn't be too=20 > much effort > and be a truely optional feature (I even think we could simply carry > over the text from that draft version). >=20 > What I am currently concerned about is putting this size issue to a > rest. I think the compromise is good enough, especially as we=20 > do NOT yet > specify a plain tcp mapping (we even don't know if we will ever get > consensus to do that). That means the currently proposed text=20 > keeps the > options open to do anything we might later decide. And it=20 > acutally puts > a hard limit to roughly 64K by the fact that only UDP is=20 > supported. As I > have outlined in another mail, that practical limit seems to=20 > be more 4K > than 64K. >=20 > Given that situation, I strongly suggest not to get another=20 > round of max > size discussion. >=20 > I think we urgently need now a consensus on the lowest denominator and > get that consensus published. Else we will be discussing and=20 > discussing > but never achive any milestone. I like the approach of=20 > baby-steps, which > will give us something usable after each step. The core thing=20 > we need to > do is have a format specification including layered architecture) that > allows us to build on. Then, I think, we can focus on specific issues. >=20 > Rainer >=20 > > -----Original Message----- > > From: Andrew Ross [mailto:andrew@kiwisyslog.com]=20 > > Sent: Wednesday, November 23, 2005 9:51 AM > > To: Rainer Gerhards > > Subject: RE: [Syslog] RE: Message format > >=20 > >=20 > > >> Mapping over UDP should be limited to a single message=20 > per packet. > > >I agree on that. If we need an ultra-compact UDP delivery, we could > > >later add it in a separate transport mapping. > >=20 > > Yes, good idea. I doubt anyone will ever want to do this, or=20 > > at least go to > > the effort of trying to get it drafted into an RFC ;-) > >=20 > > >> When mapping over plain TCP I believe we should limit the=20 > > >> total message size > > >> to 65507 bytes (to keep it compatible with UDP) and delimit=20 > > >> each message > > >> stream with an LF, or CRLF. Either delimiter would work for me. > >=20 > > >I would prefer not to restart the size discussion at this=20 > > point. I think > > >the current compromise (everyone must support 2K, anyone=20 > > might support > > >as much as he likes) is sufficient for most, if not all,=20 > > cases. I would > > >not like to see an application to become non-compliant just=20 > > because it > > >needs to transmit 65508 bytes inside a message. > >=20 > > > > I realise this should have been brought up earlier in the=20 > > draft process, > > however, I would really like to see a limit on the message=20 > > size so that it > > is directly compatible with UDP. If we allow an opened ended=20 > > message size, > > people *will* use it for non syslog related things. I feel=20 > > that any message > > longer than will fit into a UDP packet should be broken into=20 > > two or more > > separate messages by the sender, even if sent over TCP. This=20 > > allows me to > > allocate a maximum known buffer size for incoming TCP=20 > > messages. There is a > > potential for huge messages filling the memory and memory=20 > > buffer overflows > > happening if the messages are not limited in size. "Syslog"=20 > > is meant to be a > > human readable system log message. Anything longer (including=20 > > binary crash > > dumps or other things people misuse syslog for) should be=20 > broken into > > separate messages by the sender, or sent over a different protocol. > > > >=20 > > I think we should keep syslog simple and flexible, but not at=20 > > the expense of > > making it handle things it was never meant for. If a message=20 > > needs to be > > broken into many chunks, the SD-ID tags could be used to tie all the > > messages together again by the parser. The syslog receiver or=20 > > relay will > > just handle them as separate messages and not even know they=20 > > were split. > > This makes things so much simpler. > >=20 > > Cheers > >=20 > > Andrew > >=20 > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 03:36:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCaa-0002kE-Lf; Thu, 24 Nov 2005 03:36:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfCaZ-0002k7-VL for syslog@megatron.ietf.org; Thu, 24 Nov 2005 03:36:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01770 for ; Thu, 24 Nov 2005 03:35:39 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfCtb-0002YE-HF for syslog@ietf.org; Thu, 24 Nov 2005 03:56:00 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 5BD139C00D for ; Thu, 24 Nov 2005 09:44:38 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02801-04 for ; Thu, 24 Nov 2005 09:44:34 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id CCE519C00B for ; Thu, 24 Nov 2005 09:44:34 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 09:36:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F02@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXwhGi60geOEbzwSBCfB3qZBlEzEgAA5nJQABIbOMA= From: "Rainer Gerhards" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton:=20 > I can see something like this error message: >=20 > ...MyApp pid123 MALFORMED_INPUT: Bad input received from=20 > client: [aaa\u0000] >=20 > The question is does not it need to be escaped for transport=20 > or only in display. I'd personally prefer deferring any kind=20 > of escaping until it is really needed, like when displaying=20 > binary to the user. =20 I agree it can be a valid character. Also note that we (quickly at that time) went over this topic in the past and agreed that we would need to support NUL. My point is a different one. I have begun to look at the draft from the implementors point of view. Especially from the view of someone who want's to upgrade an existing syslogd implementation to syslog-protocol. One goal of such a person would definitely to do it with as less effort as possible.=20 The issue is that many syslogds are written in C/C++. NUL is used as string terminator. I can back this by testing. If I send NUL characters embedded inside the message, almost all existing syslogds terminate the message text at this point. (side-note: I am currently thinking about if that is a security vulnerability in almost all syslogds). If you want to upgrade an existing syslogd to support NUL you can do one of two things: #1 rewrite your syslogd so that it uses byte-counted strings and not the C RTL string functions #2 replace the NUL with an escape, e.g. \0 or <00> #1 would obviously be the best choice (also from a security point of view). I just doubt that many implementors will accept the (considerable) effort required. I think that most will resort to #2. #2 must be done early, right after message reception (else you already deal with C-strings). So when it comes to relaying, the orginal message will not be preserved (side note: it will also not be preserved when writing to a file). That means that digital signatures (syslog-sign) will be broken. While I see this is an implementation issue (not a protocol one), I also see that allowing NUL will almost ask for this common implementation "error". It would also render all efforts in regard to syslog-sign useless. So I wonder if it wouldn't be wiser to accept that CLR here and disallow NUL. After all, I can not see a valid use case for it either... (in the sample you provided it honestly believe the sender should not send a NUL octet but a "\u0000" string). Rainer >=20 > Thanks, > Anton. =20 >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Andrew Ross > > Sent: Wednesday, November 23, 2005 6:17 PM > > To: 'Rainer Gerhards' > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] New direction and proposed charter > >=20 > >=20 > > >The only tricky issue that remains is the NUL octet. The=20 > > more I think=20 > > >about it, the more I think the CLR to disallow it is less=20 > > evil than to=20 > > >make it stay... > >=20 > > I agree that having the CLR for NUL octet exclusion is OK. > >=20 > > Quick question, if someone is sending international data in=20 > > UTF-8 format, can there ever be a valid UTF-8 sequence that=20 > > includes a NUL octet value? If so, we need to allow NUL=20 > > values in the MSG.=20 > >=20 > > Does anyone on the list know UTF-8 well enough to answer this? > >=20 > > Cheers > >=20 > > Andrew > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 04:08:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfD6B-0005Go-AI; Thu, 24 Nov 2005 04:08:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfD69-0005Gj-VF for syslog@megatron.ietf.org; Thu, 24 Nov 2005 04:08:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04762 for ; Thu, 24 Nov 2005 04:08:17 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfDP8-0003rL-01 for syslog@ietf.org; Thu, 24 Nov 2005 04:28:37 -0500 Subject: RE: [Syslog] New direction and proposed charter From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F02@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E3F02@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Thu, 24 Nov 2005 10:08:48 +0100 Message-Id: <1132823329.4078.16.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > Anton: > So I wonder if it wouldn't be wiser to accept that CLR here and disallow > NUL. After all, I can not see a valid use case for it either... (in the > sample you provided it honestly believe the sender should not send a NUL > octet but a "\u0000" string). > \u0000 is a NUL octet at least in its canonical encoding. UTF-8 allows the same character to be encoded in multiple ways, see a description on the encoding format: http://www1.tip.nl/~t876506/utf8tbl.html And I think it would be wise to require the canonical encoding to be used and treat all other encodings of the same characters as errors. this is a large can of worms, lot's of security problems arised from this issue. (see the IIS problems couple of years ago) -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 04:24:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfDLX-0004KN-14; Thu, 24 Nov 2005 04:24:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfDLU-0004Ho-C4 for syslog@megatron.ietf.org; Thu, 24 Nov 2005 04:24:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06163 for ; Thu, 24 Nov 2005 04:24:07 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfDeU-0004Qg-Iw for syslog@ietf.org; Thu, 24 Nov 2005 04:44:28 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 938F29C00D; Thu, 24 Nov 2005 10:33:04 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02862-02; Thu, 24 Nov 2005 10:32:59 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 9EFFD9C00B; Thu, 24 Nov 2005 10:32:59 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 10:24:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F04@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXw1q1oOeqNAjFkReuUMeRcHwChrAAARVrw From: "Rainer Gerhards" To: "Balazs Scheidler" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > > Anton:=20 >=20 > > So I wonder if it wouldn't be wiser to accept that CLR here=20 > and disallow > > NUL. After all, I can not see a valid use case for it=20 > either... (in the > > sample you provided it honestly believe the sender should=20 > not send a NUL > > octet but a "\u0000" string). > >=20 >=20 > \u0000 is a NUL octet at least in its canonical encoding.=20 OK, looks like I need to dig up the ASCII table. My fault I didn't do it in the first place. Anston's sample was ...MyApp pid123 MALFORMED_INPUT: Bad input received from client: [aaa\u0000] For simplicity, let me strip the rest and just look at that part \u0000 I think the sender of the sample message should not encode it as NUL (0x00) but instead as 0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0) Encoding it as NUL in an otherwise human-readable message makes no sense to me.=20 I am questioning if there is any legitimate case where an actual NUL needs to be part of MSG. > UTF-8 allows > the same character to be encoded in multiple ways, see a=20 > description on > the encoding format: >=20 > http://www1.tip.nl/~t876506/utf8tbl.html >=20 > And I think it would be wise to require the canonical encoding to be > used and treat all other encodings of the same characters as errors. > this is a large can of worms, lot's of security problems arised from > this issue. (see the IIS problems couple of years ago) "Shortest possible form" thanksfully is already required in syslog-protocol-15. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 05:48:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfEeW-0000pT-L4; Thu, 24 Nov 2005 05:48:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfEeU-0000nY-KD for syslog@megatron.ietf.org; Thu, 24 Nov 2005 05:48:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13686 for ; Thu, 24 Nov 2005 05:47:49 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfExU-0007e9-Ft for syslog@ietf.org; Thu, 24 Nov 2005 06:08:11 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 24 Nov 2005 02:48:18 -0800 X-IronPort-AV: i="3.97,371,1125903600"; d="scan'208"; a="369771944:sNHT27701720" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAOAmEs2016493; Thu, 24 Nov 2005 02:48:15 -0800 (PST) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Nov 2005 02:48:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Thu, 24 Nov 2005 02:48:12 -0800 Message-ID: Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXw1q1oOeqNAjFkReuUMeRcHwChrAAARVrwAAG+8uA= From: "Steve Chang \(schang99\)" To: "Rainer Gerhards" , "Balazs Scheidler" X-OriginalArrivalTime: 24 Nov 2005 10:48:14.0789 (UTC) FILETIME=[92508F50:01C5F0E4] X-Spam-Score: 0.9 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer: > -----Original Message----- > From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Rainer Gerhards > Sent: Thursday, November 24, 2005 1:25 AM > To: Balazs Scheidler > Cc: syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 > > On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > > > Anton: > > > > > So I wonder if it wouldn't be wiser to accept that CLR here > > and disallow > > > NUL. After all, I can not see a valid use case for it > > either... (in the > > > sample you provided it honestly believe the sender should > > not send a NUL > > > octet but a "\u0000" string). > > > > > > > \u0000 is a NUL octet at least in its canonical encoding. >=20 > OK, looks like I need to dig up the ASCII table. My fault I didn't do it > in the first place. >=20 > Anston's sample was >=20 > ...MyApp pid123 MALFORMED_INPUT: Bad input received from client: > [aaa\u0000] >=20 > For simplicity, let me strip the rest and just look at that part >=20 > \u0000 >=20 > I think the sender of the sample message should not encode it as >=20 > NUL (0x00) >=20 > but instead as >=20 > 0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0) >=20 > Encoding it as NUL in an otherwise human-readable message makes no sense > to me. >=20 >From the perspective of formatting a piece of device internal raw data=20 into an outgoing syslog message and considering the CPU cycles needed to encode a NULL character into some other form to keep the whole MSG intact, =20 I would say prepend the length of MSG (or say, add a fixed 4 digits byte length of the MSG between SD-IDs and MSG) will be much easier for the sender. With this, I think the new IETF syslog compliant receiver should also have easier time fetching in the complete MSG, regardless it's a plain text, XML-formated, or even binary data. [** side note: a fixed 4 digit MSG length can handle up to 9999 bytes. Big enough for foreseeable future. Also, the first MSG can be appended with other feature specific information before it gets sent out. And hence updating the final MSG length can be easier.]=20 As to what will happen to the old syslog receivers receiving the message will NULL character? The message will probably be cut short right at reading the NULL character as you have explained. And I don't think there will be a good compromised solution for it.=20 At the sender side, the overhead in checking for a NULL character in any of the incoming raw message and encode it to other form is just not practical. I would rather not have to pay that overhead if possible. Besides, if mandated, you will be limiting how MSG is to be used. I would say it should be sufficient to just explicitly point out the danger of having the NUL in the MSG part in the new IETF syslog protocol. And you can be kind to add some suggestions as to how the syslog message initial sending device can choose to do to handle this situation themselves.=20 Vendors should make their own decisions on this issue. With this caveat, we get to keep the flexibility of having the MSG part=20 in plain text, or in binary for the IETF syslog protocol. It's tradeoff for WG to debate. > I am questioning if there is any legitimate case where an actual NUL > needs to be part of MSG. >=20 > > UTF-8 allows > > the same character to be encoded in multiple ways, see a > > description on > > the encoding format: > > > > http://www1.tip.nl/~t876506/utf8tbl.html > > > > And I think it would be wise to require the canonical encoding to be > > used and treat all other encodings of the same characters as errors. > > this is a large can of worms, lot's of security problems arised from > > this issue. (see the IIS problems couple of years ago) >=20 > "Shortest possible form" thanksfully is already required in > syslog-protocol-15. >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 06:51:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfFdC-0004dl-Ai; Thu, 24 Nov 2005 06:51:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfFdB-0004dg-RY for syslog@megatron.ietf.org; Thu, 24 Nov 2005 06:51:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19434 for ; Thu, 24 Nov 2005 06:50:32 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfFvi-0001Gp-Vc for syslog@ietf.org; Thu, 24 Nov 2005 07:10:55 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 98C0F9C00D for ; Thu, 24 Nov 2005 12:58:59 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02862-07 for ; Thu, 24 Nov 2005 12:58:54 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 874F39C00B for ; Thu, 24 Nov 2005 12:58:54 +0100 (CET) Received: from adisconone ([172.19.2.14]) by grfint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Nov 2005 12:50:26 +0100 Subject: RE: [Syslog] New direction and proposed charter From: Rainer Gerhards To: syslog@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Adiscon Message-Id: <1132833025.2183.1.camel@rh9lt.intern.adiscon.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 24 Nov 2005 12:50:25 +0100 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2005 11:50:26.0041 (UTC) FILETIME=[42506E90:01C5F0ED] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Steve, no reply, but a question very important to me. What do you consider a valid use case for the US-ASCII NUL character inside MSG? If I had a good sample, I'd probably have a better time understanding why this is important... Rainer On Thu, 2005-11-24 at 11:48, Steve Chang (schang99) wrote: > Rainer: > > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] > > On Behalf Of Rainer Gerhards > > Sent: Thursday, November 24, 2005 1:25 AM > > To: Balazs Scheidler > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] New direction and proposed charter > > > > > On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > > > > Anton: > > > > > > > So I wonder if it wouldn't be wiser to accept that CLR here > > > and disallow > > > > NUL. After all, I can not see a valid use case for it > > > either... (in the > > > > sample you provided it honestly believe the sender should > > > not send a NUL > > > > octet but a "\u0000" string). > > > > > > > > > > \u0000 is a NUL octet at least in its canonical encoding. > > > > OK, looks like I need to dig up the ASCII table. My fault I didn't do > it > > in the first place. > > > > Anston's sample was > > > > ...MyApp pid123 MALFORMED_INPUT: Bad input received from client: > > [aaa\u0000] > > > > For simplicity, let me strip the rest and just look at that part > > > > \u0000 > > > > I think the sender of the sample message should not encode it as > > > > NUL (0x00) > > > > but instead as > > > > 0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0) > > > > Encoding it as NUL in an otherwise human-readable message makes no > sense > > to me. > > > > From the perspective of formatting a piece of device internal raw data > into an outgoing syslog message and considering the CPU cycles needed to > encode a NULL character into some other form to keep the whole MSG > intact, > I would say prepend the length of MSG (or say, add a fixed 4 digits byte > length of the MSG between SD-IDs and MSG) will be much easier for the > sender. With this, I think the new IETF syslog compliant receiver > should also have easier time fetching in the complete MSG, regardless > it's a plain text, XML-formated, or even binary data. > [** side note: a fixed 4 digit MSG length can handle up to 9999 bytes. > Big enough for foreseeable future. Also, the first MSG can be appended > with other feature specific information before it gets sent out. And > hence updating the final MSG length can be easier.] > > As to what will happen to the old syslog receivers receiving the message > will NULL character? The message will probably be cut short right at > reading the NULL character as you have explained. And I don't think > there will be a good compromised solution for it. > > At the sender side, the overhead in checking for a NULL character in any > of the incoming raw message and encode it to other form is just not > practical. I would rather not have to pay that overhead if possible. > Besides, if mandated, you will be limiting how MSG is to be used. > > I would say it should be sufficient to just explicitly point out the > danger of having the NUL in the MSG part in the new IETF syslog > protocol. > And you can be kind to add some suggestions as to how the syslog message > initial sending device can choose to do to handle this situation > themselves. > Vendors should make their own decisions on this issue. > > With this caveat, we get to keep the flexibility of having the MSG part > in plain text, or in binary for the IETF syslog protocol. > > It's tradeoff for WG to debate. > > > > I am questioning if there is any legitimate case where an actual NUL > > needs to be part of MSG. > > > > > UTF-8 allows > > > the same character to be encoded in multiple ways, see a > > > description on > > > the encoding format: > > > > > > http://www1.tip.nl/~t876506/utf8tbl.html > > > > > > And I think it would be wise to require the canonical encoding to be > > > used and treat all other encodings of the same characters as errors. > > > this is a large can of worms, lot's of security problems arised from > > > this issue. (see the IIS problems couple of years ago) > > > > "Shortest possible form" thanksfully is already required in > > syslog-protocol-15. > > > > Rainer > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 07:36:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfGKn-0003Iy-AR; Thu, 24 Nov 2005 07:36:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfGKl-0003IO-Qy for syslog@megatron.ietf.org; Thu, 24 Nov 2005 07:36:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24173 for ; Thu, 24 Nov 2005 07:35:35 -0500 (EST) Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfGdo-00038F-FP for syslog@ietf.org; Thu, 24 Nov 2005 07:55:57 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jAOCZqnR000791 for ; Thu, 24 Nov 2005 21:35:52 +0900 (JST) Received: from [127.0.0.1] (bert.priv.cysol.co.jp [192.168.0.254]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jAOCZpIc008638 for ; Thu, 24 Nov 2005 21:35:52 +0900 (JST) Message-ID: <4385A10B.6060100@cysols.com> Date: Thu, 24 Nov 2005 20:16:27 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] New direction and proposed charter References: <577465F99B41C842AAFBE9ED71E70ABA0E3EF5@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3EF5@grfint2.intern.adiscon.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer, Let me try once again. In the following please read "RFC3164" for "BSD_syslog". RainerTimestamp = BSD_syslog_timestamp + RemainderTimestamp Format-A: VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [SD-ID]s MSG Format-B: BSD_syslog_timestamp HOSTNAME VERSION Remainder_Timestamp APP-NAME PROCID MSGID [SD-ID]s MSG Format-B would allow existing BSD-syslog (RFC-3164) compliant daemons AND relays AND applications to handle the new syslog protocol in a transparent manner. Everything from VERSION to the end is treated as "message". We do not lose information. The Remainder_timestamp carries it - in a slightly less convenient place though. On the other hand if we insist on using RainerTimestamp as in FORMAT-A, RFC3164 compliant syslogd implementations and applications will not find the timestamp. RFC3164 compliant syslogd implementations and applications will not find the hostname. RFC-3164 compliant relays will relay the message as BSD_syslog_timestamp FQDN RainerTimestamp FQDN VERSION MSGID [SD-ID]s MSG The message does get distorted to some extent. Now the question is : are there any RFC3164 compliant devices (relays and syslogd's) and applications. If there are then we gain some and lose very little. [ Correct me here if am wrong in saying that we lose very little. I may have missed something] I will agree that many implementations are not RFC3164 compliant. But, it will be difficult to convince IESG folks or, anyone for that matter, that there are no RFC3164 compliant devices or applications at all. [ Note that the applications matter too!] My suggestion is- avoid changes wherever we can, Cheers Glenn Rainer Gerhards wrote: > This is really disappointing... > > I have done further testing with more syslogds to confirm the initial > findings. The more different programs / versions I try, the more a mess > this gets. OK, we knew FreeBSD syslogd does not include the hostname. > Next I tested with some Windows products, which looked promising. Then I > looked at the sysklogd source. It is the standard Linux package, so if > it works, a lot would be won. The source tells me that at least the > timestamp should correctly be extracted. Then I actually tried it out > with a Debian system - the timestamp was ignored. Checking that source > tree I see that *that* sysklogd does deliberately ignore the data and > always pulls the local date (or ist it a bug - who cares...). When it > comes to relaying it is even stranger: sysklogd does neither relay the > timestamp nor the host part. At that point, I have stopped further > analysis, because I think I would be able to find another good number of > variants of syslog behaviour. > > Conclusion: > > 1. There is no point in trying to preserve backward > compatibility besides sticking with the . Everything other > than is handled differently by different implementations > and/or versions. > > 2. We can NOT expect that relaying over existing syslog > implementations will ever work. Please note that this would > also have broken syslog-sign without specifically implemented > daemons. > > As such, I revert back to proposing > > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP > [SD-ID]s SP MSG > > or, somewhat incorrect but shorter: > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [SD-ID]s MSG > > Please note that I have added the MSGID to the header. > > Rainer > > >>-----Original Message----- >>From: syslog-bounces@lists.ietf.org >>[mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards >>Sent: Wednesday, November 23, 2005 3:04 PM >>To: Glenn Mansfield Keeni; syslog@ietf.org >>Subject: RE: [Syslog] New direction and proposed charter >> >>Glenn, >> >>very interesting approach with the timestamp. I think your >>ideas can be >>the key to maintaining a lot of backwards compatibility by still >>retaining new functionality. >> >>First some bad news: I am not sure if by "BSD syslog" you are refering >>to RFC 3164 or a specific distribution of BSD. I have created a small >>script to test out your recommendation. I used FreeBSD stock >>syslogd as >>the receiver. >> >>It did NOT work as expected. There are two reasons >> >>a) (that) BSD syslogd takes the sender always from the system >>that send >>it >>b) even worse, when relaying, it puts "Forwarded from >>: " into >> >> the hostname part (yes, with all that spaces) >> >>So while the idea sounds excellent, it does not work with >>stock FreeBSD >>syslogd. I am not sure about other BSD variants, nor have I >>checked the >>sysklogd package. I believe it will have less issues in this regard. >> >>This was the message I sent (via perl script): >> >>"<148>Oct 11 22:14:15 mymachine.example.com 1 ID47 2003T.003Z >> 'su root' >>failed for lonvick on /dev/pts/8" >> >>this was the raw message received after being relayed once by FreeBSD >>stock syslogd: >> >>"<148>Oct 11 22:14:15 Forwarded from 172.19.2.7: >>mymachine.example.com 1 >>ID47 2003T.003Z 'su root' failed for lonvick on /dev/pts/8" >> >>As you can see, the message is somewhat distorted - definitely enough >>for digital signatures to be broken. [Implementor's >>side-note: This can >>be fixed on a syslog-application layer level, far beyond the >>IETF scope. >>It's straightforward and easy to do, so it will probably happen.] >> >>Even though this actual sample seems not to work, it paves >>the way to a >>very elegant compatibility solution. The key is to add the extra >>information (e.g. Timestamp) in a different place. At least I was so >>focussed on fields at whole that I did not notice this possibility. I >>have experiemented a bit more with Glenn's proposal, shuffeling some >>fields. The result was this: >> >>BSD_syslog_timestamp FQDN TAG "@#"VERSION MSGID >>Remainder_Timestamp >>[SD-ID]s MSG >> >>or in an actual sample: >> >>"<148>Oct 11 22:14:15 mymachine.example.com su[4711]: @#1 ID47 >>2003T.003Z [SD-IDs] 'su root' failed for lonvick on /dev/pts/8" >> >>I have used the BSD timestamp and FAQN as Glenn suggested. >>Then, I have >>added the "TAG" again. If we think in the spirit of my mail >>this morning >>on syslog & non-IETF standards, it would not really hurt if we >>standardize TAG instead of two fields. If I would like to retain the >>APP-NAME and PROCESSID, I could do the following ABNF: >> >>TAG = APP-NAME ["[" PROCESSID "]"] ":" >> >>The side-effect of this is that almost all syslog-messages currently >>emited comply with that format. So I suggest that we strongly consider >>joining these two again. Out of the sudden, we have the "old" header, >>but it is parsable by a hyptothetical new syslogd. Next, I have used a >>trick from syslog-sign. I have changed the VERSION from a number to a >>number plus a cookie. The version would now be "@#1". I do not care if >>the cookie is "@#" or something else. The key point is that >>it, together >>with the version should be very unlikely to exist at that place in >>old-style syslog. That would allow a "new" receiver to differentiate >>between old and new style syslog messages. The rest of the message is >>just applying Glenn's proposal again: it has the MSG, the >>missing parts >>of the timestamp, SD-IDs and MSG. The Remainder_Timestamp >>looks strange. >>We might like it, we might like something else. That's easy to change >>and discuss. It's the concept that matters right now, not the exact >>format. >> >>If we take the outlined route, we would be able to extend the syslog >>protocol with as much backward compatibility as is possible in a >>not-yet-standardized world. I find this very desirable. I >>think we even >>have good chances that many existing "old" syslogds would relay such >>messages without changing them, thus keeping digital >>signatures intact. >>The required text changes for syslog-protocol should be moderate. >> >>I strongly propose we go in that direction. >> >>Rainer >> >>>-----Original Message----- >>>From: syslog-bounces@lists.ietf.org >>>[mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn >>>Mansfield Keeni >>>Sent: Wednesday, November 23, 2005 1:39 PM >>>To: syslog@ietf.org >>>Subject: Re: [Syslog] New direction and proposed charter >>> >>>Chris/Rainer, >>> >>> >>>>we continue to use ... at the start of syslog >>> >>>messages. This will >>> >>>>allow current receivers to continue to receive messages and >>> >>>put them in >>> >>>>the right bins. Does anyone disagree with this? >>> >>>Complete agreement. >>> >>>> >>>>The WG has agreed to use the timestamp Rainer has in the current >>>>syslog-protocol. >>> >>>In principle I agree with the timestamp format. It is good. >>>I may have missed the discussion on this matter, in that >> >>case please >> >>>accept my apologies and ignore the rest of the mail. >>> >>>To get existing BSD syslog devices specifically relays into >>>the compatibility >>>fold it WILL be good idea to keep the timestamp in two parts >>> >>> RainerTimestamp = BSD_syslog_timestamp + RemainderTimestamp >>> >>> >>>>One possibility would be to assemble a syslog message as: >>>> >>>>TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG >>> >>>In the context of what has been said above about the >>>timestamp. I would >>>suggest >>> BSD_syslog_timestamp FQDN VERSION MSGID >>>Remainder_Timestamp [SD-ID]s MSG >>> >>>That would allow existing BSD-syslog relays to handle the new >>>syslog protocol >>>in a transparent manner. Everything from VERSION to the end >>>is treated as "message". >>> >>>We do not lose information. >>> The Remainder_timestamp carries it - in a slightly less >>>convenient place >>> though. >>> >>>On the other hand if we insist on using RainerTimestamp, >>>existing BSD_syslog >>>relays will relay the message as >>> >>>BSD_syslog_timestamp FQDN RainerTimestamp FQDN VERSION >>>MSGID [SD-ID]s MSG >>> >>>The message does get distorted to some extent. >>> >>> >>>>If we can agree to this then I suspect that we can have a working >>>>document within Rainer's timeframe. I'll propose the >>> >>>following charter >>> >>>>to keep us focused. >>>> >>>>-------- Proposed Charter -------------- >>>> >>>>Syslog is a de-facto standard for logging system events. >>> >>>However, the >>> >>>>protocol component of this event logging system has not >>> >>>been formally >>> >>>>documented. While the protocol has been very useful and >>> >>>scalable, it >>> >>>>has some known security problems which were documented in >> >>RFC 3164. >> >>>>The goal of this working group is to address the security and >>>>integrity problems of the existing syslog mechanism while >>> >>>not breaking >>> >>>>backwards compatibility. The most obvious problems that >> >>need to be >> >>>>addressed in the syslog protocol are the timestamp, which has not >>>>formally included a means to indicate the year, and the >>> >>>identification >>> >>>>of the source which has been a hostname without a qualified domain >>>>name. Additionally, a version, some type of message >>> >>>indicator, and a >>> >>>>means to convey structured data will be included in the protocol. >>>> >>>>syslog has traditionally been transported over UDP and this WG has >>>>already defined RFC 3195 for the reliable transport for the syslog >>>>messages. The WG will separate the UDP transport from the >>> >>>protocol so >>> >>>>that others may define additional transports in the future. >>>> >>>>- A standard will be produced that formally documents the syslog >>>>protocol. A mechanism will also be defined in this specification >>>>that will provide a means to convey structured data. >>>> >>>>- A standard will be produced that documents the UDP transport for >>>>syslog. >>>> >>>>- A standard will be produced that documents a mechanism to sign >>>>syslog messages to provide integrity checking and source >>>>authentication. >>>> >>>>- A MIB definition for syslog will be produced. >>>> >>>>------------------------------------------- >>>> >>>> >>>>PLEASE review this and respond. >>>> >>> >>>Glenn >>> >>> >>>_______________________________________________ >>>Syslog mailing list >>>Syslog@lists.ietf.org >>>https://www1.ietf.org/mailman/listinfo/syslog >>> >> >>_______________________________________________ >>Syslog mailing list >>Syslog@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/syslog >> > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 07:36:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfGKn-0003JP-Ht; Thu, 24 Nov 2005 07:36:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfGKm-0003Id-0p for syslog@megatron.ietf.org; Thu, 24 Nov 2005 07:36:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24175 for ; Thu, 24 Nov 2005 07:35:36 -0500 (EST) Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfGdo-00038E-FL for syslog@ietf.org; Thu, 24 Nov 2005 07:55:58 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jAOCZpnR000788 for ; Thu, 24 Nov 2005 21:35:51 +0900 (JST) Received: from [127.0.0.1] (bert.priv.cysol.co.jp [192.168.0.254]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jAOCZoIc008635 for ; Thu, 24 Nov 2005 21:35:51 +0900 (JST) Message-ID: <438596ED.3070302@cysols.com> Date: Thu, 24 Nov 2005 19:33:17 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Revised proposed charter References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, You seem to have dropped the last deliverable which is in good shape > - A MIB definition for syslog will be produced. I would strongly recommend that we include it. It is an important aspect of the protocol. Some effort has gone into it. And it is the least controversial [there are no issues of backward compatibility]. And it is very close to completion. Glenn Chris Lonvick wrote: > Hi All, > > ==== v2 of proposed charter === > > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it > has some known security problems which were documented in RFC 3164. > > The goal of this working group is to address the security and integrity > problems, and to standardize the syslog protocol, transport, and a > select set of mechanisms in a manner that considers the ease of > migration between and the co-existence of existing versions and the > standard. > > syslog has traditionally been transported over UDP and this WG has > already defined RFC 3195 for the reliable transport for the syslog > messages. The WG will separate the UDP transport from the protocol so > that others may define additional transports in the future. > > > - A document will be produced that describes a standardized syslog > protocol. A mechanism will also be defined in this document > that will provide a means to convey structured data. > > - A document will be produced that describes a standardized UDP > transport for syslog. > > - A document will be produced that describes a standardized mechanism > to sign syslog messages to provide integrity checking and source > authentication. > > > === === > > Comments please. > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 07:48:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfGWj-0001gI-Hf; Thu, 24 Nov 2005 07:48:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfGWi-0001fY-Q0 for syslog@megatron.ietf.org; Thu, 24 Nov 2005 07:48:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25257 for ; Thu, 24 Nov 2005 07:47:57 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfGpm-0003og-Gz for syslog@ietf.org; Thu, 24 Nov 2005 08:08:19 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 016689C00D; Thu, 24 Nov 2005 13:56:56 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02963-05; Thu, 24 Nov 2005 13:56:50 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 6990A9C00B; Thu, 24 Nov 2005 13:56:50 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] Revised proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 13:48:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F06@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Revised proposed charter Thread-Index: AcXw8/bXw1avtaBfTn6E90UI/0q2HAAAU37A From: "Rainer Gerhards" To: "Glenn Mansfield Keeni" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Oops, I have overlooked that one. I agree with Glenn that this should be in the charter. Rainer=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn=20 > Mansfield Keeni > Sent: Thursday, November 24, 2005 11:33 AM > To: syslog@ietf.org > Subject: Re: [Syslog] Revised proposed charter >=20 > Chris, > You seem to have dropped the last deliverable which is=20 > in good shape >=20 > > - A MIB definition for syslog will be produced. >=20 > I would strongly recommend that we include it. It is an=20 > important aspect > of the protocol. Some effort has gone into it. And it is the least > controversial [there are no issues of backward compatibility]. And it > is very close to completion. >=20 > Glenn >=20 > Chris Lonvick wrote: > > Hi All, > >=20 > > =3D=3D=3D=3D v2 of proposed charter =3D=3D=3D > >=20 > > Syslog is a de-facto standard for logging system events. =20 > However, the > > protocol component of this event logging system has not=20 > been formally > > documented. While the protocol has been very useful and=20 > scalable, it > > has some known security problems which were documented in RFC 3164. > >=20 > > The goal of this working group is to address the security=20 > and integrity > > problems, and to standardize the syslog protocol, transport, and a > > select set of mechanisms in a manner that considers the ease of > > migration between and the co-existence of existing versions and the > > standard. > >=20 > > syslog has traditionally been transported over UDP and this WG has > > already defined RFC 3195 for the reliable transport for the syslog > > messages. The WG will separate the UDP transport from the=20 > protocol so > > that others may define additional transports in the future. > >=20 > >=20 > > - A document will be produced that describes a standardized syslog > > protocol. A mechanism will also be defined in this document > > that will provide a means to convey structured data. > >=20 > > - A document will be produced that describes a standardized UDP > > transport for syslog. > >=20 > > - A document will be produced that describes a standardized=20 > mechanism > > to sign syslog messages to provide integrity checking and source > > authentication. > >=20 > >=20 > > =3D=3D=3D =3D=3D=3D > >=20 > > Comments please. > >=20 > > Thanks, > > Chris > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 08:02:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfGk0-0007Ws-Jj; Thu, 24 Nov 2005 08:02:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfGjy-0007Vu-04 for syslog@megatron.ietf.org; Thu, 24 Nov 2005 08:02:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26735 for ; Thu, 24 Nov 2005 08:01:37 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfH30-0004KN-3U for syslog@ietf.org; Thu, 24 Nov 2005 08:21:59 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 0122C9C00D; Thu, 24 Nov 2005 14:10:35 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03078-02; Thu, 24 Nov 2005 14:10:29 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 150B69C00B; Thu, 24 Nov 2005 14:10:29 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 14:01:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F07@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXw890nQ+jERl7uR9u23gJ8H7GCewAAY9JA From: "Rainer Gerhards" To: "Glenn Mansfield Keeni" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Glenn, > Now the question is : are there any RFC3164 compliant devices > (relays and syslogd's) and applications. I have to admit that I have written at least one compliant to RFC 3164. But my feeling is that I am very lonley with that. In one project, we had to make RFC 3164 not only optional but to disable it by default, because as soon as you enable it, everything is broken.=20 Also, I have done a lot of testing with different syslogds yesterday. None of this quite popular systems is compliant. I neither know any compliant device. Anton has backed this point of view (for example, he adds Solaris as being non-compliant). RFC 3164 is an informational document whichs utility was primarily to describe security issues. It is good in that. However, it does not even remotely describe what BSD syslog is about (a good indication of that might be that BSD syslog works totally different from RFC 3164...). I question that it makes any sense to modify our efforts to take care of an informational RFC that doesn't even describe what is current technology. Don't take me wrong: I myself based a lot of my decisions on RFC 3164. Now, after extended testing, I thinkt that was a great failure. When it comes to the observed format, RFC 3164 should tell about only. Other than that, there are no similarities in observed syslog behaviour. Sorry for the harsh words, but if you go to the lab, that's where you end up (notice my own disappointment yesterday...). > If there are then we gain some and lose very little. [ Correct > me here if am wrong in saying that we lose very little. I may > have missed something] >=20 No sure on "lose very little". I am tired of taklking theory. I will implement something and then tell. I guess we will loose some things, at least in ease of parsing. And I still think we do not gain anything at all... > I will agree that many implementations are not RFC3164 compliant. > But, it will be difficult to convince IESG folks or, anyone for > that matter, that there are no RFC3164 compliant devices or > applications at all. [ Note that the applications matter too!] OK, let's poll the list: who has implemented RFC 3164 including relay behaviour described there? I have two candidates, MonitorWare/WinSyslog (some core component) on Windows and rsyslogd on *nix. MonitorWare is the one with default-disabled rfc3164. rsyslogd uses a much enhanced parser (non compliant) to get its work done. rsyslogd would probably benefit from your suggestion. However, I do not think this to be worthwhile enough, because a) there are currently too few deployed to make it matter and b) the next version will natively support-syslog protocol and is an extremely easy upgrade. > My suggestion is- avoid changes wherever we can, I agree on this, but in that specific case I really think its not worth it. RFC 3164 creates a false impression of format understanding. Other than , there is noting in common about existing syslog implementations. Rainer >=20 > Cheers >=20 > Glenn >=20 > Rainer Gerhards wrote: > > This is really disappointing... > >=20 > > I have done further testing with more syslogds to confirm=20 > the initial > > findings. The more different programs / versions I try, the=20 > more a mess > > this gets. OK, we knew FreeBSD syslogd does not include the=20 > hostname. > > Next I tested with some Windows products, which looked=20 > promising. Then I > > looked at the sysklogd source. It is the standard Linux=20 > package, so if > > it works, a lot would be won. The source tells me that at least the > > timestamp should correctly be extracted. Then I actually=20 > tried it out > > with a Debian system - the timestamp was ignored. Checking=20 > that source > > tree I see that *that* sysklogd does deliberately ignore=20 > the data and > > always pulls the local date (or ist it a bug - who=20 > cares...). When it > > comes to relaying it is even stranger: sysklogd does=20 > neither relay the > > timestamp nor the host part. At that point, I have stopped further > > analysis, because I think I would be able to find another=20 > good number of > > variants of syslog behaviour. > >=20 > > Conclusion: > >=20 > > 1. There is no point in trying to preserve backward > > compatibility besides sticking with the . Everything other > > than is handled differently by different implementations=20 > > and/or versions. > >=20 > > 2. We can NOT expect that relaying over existing syslog=20 > > implementations will ever work. Please note that this would=20 > > also have broken syslog-sign without specifically implemented > > daemons. > >=20 > > As such, I revert back to proposing=20 > >=20 > > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID=20 > SP MSGID SP > > [SD-ID]s SP MSG > >=20 > > or, somewhat incorrect but shorter: > >=20 > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [SD-ID]s MSG > >=20 > > Please note that I have added the MSGID to the header. > >=20 > > Rainer > >=20 > >=20 > >>-----Original Message----- > >>From: syslog-bounces@lists.ietf.org=20 > >>[mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > >>Sent: Wednesday, November 23, 2005 3:04 PM > >>To: Glenn Mansfield Keeni; syslog@ietf.org > >>Subject: RE: [Syslog] New direction and proposed charter > >> > >>Glenn, > >> > >>very interesting approach with the timestamp. I think your=20 > >>ideas can be > >>the key to maintaining a lot of backwards compatibility by still > >>retaining new functionality. > >> > >>First some bad news: I am not sure if by "BSD syslog" you=20 > are refering > >>to RFC 3164 or a specific distribution of BSD. I have=20 > created a small > >>script to test out your recommendation. I used FreeBSD stock=20 > >>syslogd as > >>the receiver. > >> > >>It did NOT work as expected. There are two reasons > >> > >>a) (that) BSD syslogd takes the sender always from the system=20 > >>that send > >>it > >>b) even worse, when relaying, it puts "Forwarded from=20 > >>: " into > >> > >> the hostname part (yes, with all that spaces) > >> > >>So while the idea sounds excellent, it does not work with=20 > >>stock FreeBSD > >>syslogd. I am not sure about other BSD variants, nor have I=20 > >>checked the > >>sysklogd package. I believe it will have less issues in this regard. > >> =20 > >>This was the message I sent (via perl script): > >> > >>"<148>Oct 11 22:14:15 mymachine.example.com 1 ID47 2003T.003Z=20 > >> 'su root' > >>failed for lonvick on /dev/pts/8" > >> > >>this was the raw message received after being relayed once=20 > by FreeBSD > >>stock syslogd: > >> > >>"<148>Oct 11 22:14:15 Forwarded from 172.19.2.7:=20 > >>mymachine.example.com 1 > >>ID47 2003T.003Z 'su root' failed for lonvick on /dev/pts/8" > >> > >>As you can see, the message is somewhat distorted -=20 > definitely enough > >>for digital signatures to be broken. [Implementor's=20 > >>side-note: This can > >>be fixed on a syslog-application layer level, far beyond the=20 > >>IETF scope. > >>It's straightforward and easy to do, so it will probably happen.] > >> > >>Even though this actual sample seems not to work, it paves=20 > >>the way to a > >>very elegant compatibility solution. The key is to add the extra > >>information (e.g. Timestamp) in a different place. At least I was so > >>focussed on fields at whole that I did not notice this=20 > possibility. I > >>have experiemented a bit more with Glenn's proposal, shuffeling some > >>fields. The result was this: > >> > >>BSD_syslog_timestamp FQDN TAG "@#"VERSION MSGID=20 > >>Remainder_Timestamp > >>[SD-ID]s MSG > >> > >>or in an actual sample: > >> > >>"<148>Oct 11 22:14:15 mymachine.example.com su[4711]: @#1 ID47 > >>2003T.003Z [SD-IDs] 'su root' failed for lonvick on /dev/pts/8" > >> > >>I have used the BSD timestamp and FAQN as Glenn suggested.=20 > >>Then, I have > >>added the "TAG" again. If we think in the spirit of my mail=20 > >>this morning > >>on syslog & non-IETF standards, it would not really hurt if we > >>standardize TAG instead of two fields. If I would like to retain the > >>APP-NAME and PROCESSID, I could do the following ABNF: > >> > >>TAG =3D APP-NAME ["[" PROCESSID "]"] ":" > >> > >>The side-effect of this is that almost all syslog-messages currently > >>emited comply with that format. So I suggest that we=20 > strongly consider > >>joining these two again. Out of the sudden, we have the=20 > "old" header, > >>but it is parsable by a hyptothetical new syslogd. Next, I=20 > have used a > >>trick from syslog-sign. I have changed the VERSION from a=20 > number to a > >>number plus a cookie. The version would now be "@#1". I do=20 > not care if > >>the cookie is "@#" or something else. The key point is that=20 > >>it, together > >>with the version should be very unlikely to exist at that place in > >>old-style syslog. That would allow a "new" receiver to differentiate > >>between old and new style syslog messages. The rest of the=20 > message is > >>just applying Glenn's proposal again: it has the MSG, the=20 > >>missing parts > >>of the timestamp, SD-IDs and MSG. The Remainder_Timestamp=20 > >>looks strange. > >>We might like it, we might like something else. That's easy=20 > to change > >>and discuss. It's the concept that matters right now, not the exact > >>format. > >> > >>If we take the outlined route, we would be able to extend the syslog > >>protocol with as much backward compatibility as is possible in a > >>not-yet-standardized world. I find this very desirable. I=20 > >>think we even > >>have good chances that many existing "old" syslogds would relay such > >>messages without changing them, thus keeping digital=20 > >>signatures intact. > >>The required text changes for syslog-protocol should be moderate. > >> > >>I strongly propose we go in that direction. > >> > >>Rainer > >> > >>>-----Original Message----- > >>>From: syslog-bounces@lists.ietf.org=20 > >>>[mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn=20 > >>>Mansfield Keeni > >>>Sent: Wednesday, November 23, 2005 1:39 PM > >>>To: syslog@ietf.org > >>>Subject: Re: [Syslog] New direction and proposed charter > >>> > >>>Chris/Rainer, > >>> > >>> > >>>>we continue to use ... at the start of syslog=20 > >>> > >>>messages. This will > >>> > >>>>allow current receivers to continue to receive messages and=20 > >>> > >>>put them in > >>> > >>>>the right bins. Does anyone disagree with this? > >>> > >>>Complete agreement. > >>> > >>>> > >>>>The WG has agreed to use the timestamp Rainer has in the current > >>>>syslog-protocol. > >>> > >>>In principle I agree with the timestamp format. It is good. > >>>I may have missed the discussion on this matter, in that=20 > >> > >>case please > >> > >>>accept my apologies and ignore the rest of the mail. > >>> > >>>To get existing BSD syslog devices specifically relays into=20 > >>>the compatibility > >>>fold it WILL be good idea to keep the timestamp in two parts > >>> > >>> RainerTimestamp =3D BSD_syslog_timestamp +=20 > RemainderTimestamp > >>> > >>> > >>>>One possibility would be to assemble a syslog message as: > >>>> > >>>>TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG > >>> > >>>In the context of what has been said above about the=20 > >>>timestamp. I would > >>>suggest > >>> BSD_syslog_timestamp FQDN VERSION MSGID=20 > >>>Remainder_Timestamp [SD-ID]s MSG > >>> > >>>That would allow existing BSD-syslog relays to handle the new=20 > >>>syslog protocol > >>>in a transparent manner. Everything from VERSION to the end=20 > >>>is treated as "message". > >>> > >>>We do not lose information. > >>> The Remainder_timestamp carries it - in a slightly less=20 > >>>convenient place > >>> though. > >>> > >>>On the other hand if we insist on using RainerTimestamp,=20 > >>>existing BSD_syslog > >>>relays will relay the message as > >>> > >>>BSD_syslog_timestamp FQDN RainerTimestamp FQDN VERSION=20 > >>>MSGID [SD-ID]s MSG > >>> > >>>The message does get distorted to some extent. > >>> > >>> > >>>>If we can agree to this then I suspect that we can have a working > >>>>document within Rainer's timeframe. I'll propose the=20 > >>> > >>>following charter > >>> > >>>>to keep us focused. > >>>> > >>>>-------- Proposed Charter -------------- > >>>> > >>>>Syslog is a de-facto standard for logging system events. =20 > >>> > >>>However, the > >>> > >>>>protocol component of this event logging system has not=20 > >>> > >>>been formally > >>> > >>>>documented. While the protocol has been very useful and=20 > >>> > >>>scalable, it > >>> > >>>>has some known security problems which were documented in=20 > >> > >>RFC 3164. > >> > >>>>The goal of this working group is to address the security and > >>>>integrity problems of the existing syslog mechanism while=20 > >>> > >>>not breaking > >>> > >>>>backwards compatibility. The most obvious problems that=20 > >> > >>need to be > >> > >>>>addressed in the syslog protocol are the timestamp, which has not > >>>>formally included a means to indicate the year, and the=20 > >>> > >>>identification > >>> > >>>>of the source which has been a hostname without a qualified domain > >>>>name. Additionally, a version, some type of message=20 > >>> > >>>indicator, and a > >>> > >>>>means to convey structured data will be included in the protocol. > >>>> > >>>>syslog has traditionally been transported over UDP and this WG has > >>>>already defined RFC 3195 for the reliable transport for the syslog > >>>>messages. The WG will separate the UDP transport from the=20 > >>> > >>>protocol so > >>> > >>>>that others may define additional transports in the future. > >>>> > >>>>- A standard will be produced that formally documents the syslog > >>>>protocol. A mechanism will also be defined in this specification > >>>>that will provide a means to convey structured data. > >>>> > >>>>- A standard will be produced that documents the UDP transport for > >>>>syslog. > >>>> > >>>>- A standard will be produced that documents a mechanism to sign > >>>>syslog messages to provide integrity checking and source > >>>>authentication. > >>>> > >>>>- A MIB definition for syslog will be produced. > >>>> > >>>>------------------------------------------- > >>>> > >>>> > >>>>PLEASE review this and respond. > >>>> > >>> > >>>Glenn > >>> > >>> > >>>_______________________________________________ > >>>Syslog mailing list > >>>Syslog@lists.ietf.org > >>>https://www1.ietf.org/mailman/listinfo/syslog > >>> > >> > >>_______________________________________________ > >>Syslog mailing list > >>Syslog@lists.ietf.org > >>https://www1.ietf.org/mailman/listinfo/syslog > >> > >=20 > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 09:12:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfHpf-0001Ly-1K; Thu, 24 Nov 2005 09:12:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfHpd-0001Lj-TH for syslog@megatron.ietf.org; Thu, 24 Nov 2005 09:12:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04606 for ; Thu, 24 Nov 2005 09:11:33 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfI8h-0007LH-9G for syslog@ietf.org; Thu, 24 Nov 2005 09:31:56 -0500 Subject: RE: [Syslog] New direction and proposed charter From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F04@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E3F04@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Thu, 24 Nov 2005 15:12:16 +0100 Message-Id: <1132841536.4078.28.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Thu, 2005-11-24 at 10:24 +0100, Rainer Gerhards wrote: > > On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > > > Anton: > For simplicity, let me strip the rest and just look at that part > > \u0000 > > I think the sender of the sample message should not encode it as > > NUL (0x00) > > but instead as > > 0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0) > > Encoding it as NUL in an otherwise human-readable message makes no sense > to me. > > I am questioning if there is any legitimate case where an actual NUL > needs to be part of MSG. > Now I understand, and we perfectly agree. I don't see a reason to include 0x00 octet. In fact syslog-ng filters everything below 32, to avoid nasty tricks with escape sequences in the log files viewed. Though this could be opened up a bit if needed. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 11:42:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfKAr-0001fi-EN; Thu, 24 Nov 2005 11:42:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfKAq-0001fX-2w for syslog@megatron.ietf.org; Thu, 24 Nov 2005 11:42:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25533 for ; Thu, 24 Nov 2005 11:41:35 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfKTw-00067M-3G for syslog@ietf.org; Thu, 24 Nov 2005 12:02:00 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 24 Nov 2005 08:42:07 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAOGg3eT020190; Thu, 24 Nov 2005 08:42:04 -0800 (PST) Date: Thu, 24 Nov 2005 08:42:03 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] Revised proposed charter In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F06@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3F06@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, OK - sorry 'bout that. Glenn - please update it and get it into the ID repository. All - who will commit to reviewing this document? I will need someone to commit to this before I put it into the proposed charter. Thanks, Chris On Thu, 24 Nov 2005, Rainer Gerhards wrote: > Oops, I have overlooked that one. I agree with Glenn that this should be > in the charter. > > Rainer > >> -----Original Message----- >> From: syslog-bounces@lists.ietf.org >> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn >> Mansfield Keeni >> Sent: Thursday, November 24, 2005 11:33 AM >> To: syslog@ietf.org >> Subject: Re: [Syslog] Revised proposed charter >> >> Chris, >> You seem to have dropped the last deliverable which is >> in good shape >> >>> - A MIB definition for syslog will be produced. >> >> I would strongly recommend that we include it. It is an >> important aspect >> of the protocol. Some effort has gone into it. And it is the least >> controversial [there are no issues of backward compatibility]. And it >> is very close to completion. >> >> Glenn >> >> Chris Lonvick wrote: >>> Hi All, >>> >>> ==== v2 of proposed charter === >>> >>> Syslog is a de-facto standard for logging system events. >> However, the >>> protocol component of this event logging system has not >> been formally >>> documented. While the protocol has been very useful and >> scalable, it >>> has some known security problems which were documented in RFC 3164. >>> >>> The goal of this working group is to address the security >> and integrity >>> problems, and to standardize the syslog protocol, transport, and a >>> select set of mechanisms in a manner that considers the ease of >>> migration between and the co-existence of existing versions and the >>> standard. >>> >>> syslog has traditionally been transported over UDP and this WG has >>> already defined RFC 3195 for the reliable transport for the syslog >>> messages. The WG will separate the UDP transport from the >> protocol so >>> that others may define additional transports in the future. >>> >>> >>> - A document will be produced that describes a standardized syslog >>> protocol. A mechanism will also be defined in this document >>> that will provide a means to convey structured data. >>> >>> - A document will be produced that describes a standardized UDP >>> transport for syslog. >>> >>> - A document will be produced that describes a standardized >> mechanism >>> to sign syslog messages to provide integrity checking and source >>> authentication. >>> >>> >>> === === >>> >>> Comments please. >>> >>> Thanks, >>> Chris >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >> >> >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 11:59:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfKR9-0007jd-Rp; Thu, 24 Nov 2005 11:59:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfKR8-0007jF-Ae for syslog@megatron.ietf.org; Thu, 24 Nov 2005 11:59:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27802 for ; Thu, 24 Nov 2005 11:58:25 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfKkE-0006rv-Bg for syslog@ietf.org; Thu, 24 Nov 2005 12:18:50 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id D8DA19C00E; Thu, 24 Nov 2005 18:07:25 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03159-09; Thu, 24 Nov 2005 18:07:21 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4D7B99C00B; Thu, 24 Nov 2005 18:07:21 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] Revised proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 17:59:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F0E@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Revised proposed charter Thread-Index: AcXxFgagh7AZJX15SRC3CZHKXHAEfQAAjtZg From: "Rainer Gerhards" To: "Chris Lonvick" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Hi, >=20 > OK - sorry 'bout that. >=20 > Glenn - please update it and get it into the ID repository. >=20 > All - who will commit to reviewing this document? I will=20 > need someone to=20 > commit to this before I put it into the proposed charter. I can look at the syslog side of it, but I am far from being an SNMP expert. I think we need at least one such expert to review it. So count' me as half a volunteer ;) Rainer >=20 > Thanks, > Chris >=20 >=20 >=20 > On Thu, 24 Nov 2005, Rainer Gerhards wrote: >=20 > > Oops, I have overlooked that one. I agree with Glenn that=20 > this should be > > in the charter. > > > > Rainer > > > >> -----Original Message----- > >> From: syslog-bounces@lists.ietf.org > >> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn > >> Mansfield Keeni > >> Sent: Thursday, November 24, 2005 11:33 AM > >> To: syslog@ietf.org > >> Subject: Re: [Syslog] Revised proposed charter > >> > >> Chris, > >> You seem to have dropped the last deliverable which is > >> in good shape > >> > >>> - A MIB definition for syslog will be produced. > >> > >> I would strongly recommend that we include it. It is an > >> important aspect > >> of the protocol. Some effort has gone into it. And it is the least > >> controversial [there are no issues of backward=20 > compatibility]. And it > >> is very close to completion. > >> > >> Glenn > >> > >> Chris Lonvick wrote: > >>> Hi All, > >>> > >>> =3D=3D=3D=3D v2 of proposed charter =3D=3D=3D > >>> > >>> Syslog is a de-facto standard for logging system events. > >> However, the > >>> protocol component of this event logging system has not > >> been formally > >>> documented. While the protocol has been very useful and > >> scalable, it > >>> has some known security problems which were documented in=20 > RFC 3164. > >>> > >>> The goal of this working group is to address the security > >> and integrity > >>> problems, and to standardize the syslog protocol, transport, and a > >>> select set of mechanisms in a manner that considers the ease of > >>> migration between and the co-existence of existing=20 > versions and the > >>> standard. > >>> > >>> syslog has traditionally been transported over UDP and this WG has > >>> already defined RFC 3195 for the reliable transport for the syslog > >>> messages. The WG will separate the UDP transport from the > >> protocol so > >>> that others may define additional transports in the future. > >>> > >>> > >>> - A document will be produced that describes a standardized syslog > >>> protocol. A mechanism will also be defined in this document > >>> that will provide a means to convey structured data. > >>> > >>> - A document will be produced that describes a standardized UDP > >>> transport for syslog. > >>> > >>> - A document will be produced that describes a standardized > >> mechanism > >>> to sign syslog messages to provide integrity checking and source > >>> authentication. > >>> > >>> > >>> =3D=3D=3D =3D=3D=3D > >>> > >>> Comments please. > >>> > >>> Thanks, > >>> Chris > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >> > >> > >> > >> > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > >> > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 14:33:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfMqR-0008Bc-Rw; Thu, 24 Nov 2005 14:33:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfMqQ-0008Ab-JA for syslog@megatron.ietf.org; Thu, 24 Nov 2005 14:33:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15443 for ; Thu, 24 Nov 2005 14:32:42 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfN9X-00045L-D6 for syslog@ietf.org; Thu, 24 Nov 2005 14:53:08 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2005 11:33:12 -0800 X-IronPort-AV: i="3.97,373,1125903600"; d="scan'208"; a="234085590:sNHT28636704" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAOJXAeS001791; Thu, 24 Nov 2005 11:33:10 -0800 (PST) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Nov 2005 11:33:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Thu, 24 Nov 2005 11:33:07 -0800 Message-ID: Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXw7XNdduIR7yZuShCOU8fOtRVIDQAOVDcg From: "Steve Chang \(schang99\)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 24 Nov 2005 19:33:10.0105 (UTC) FILETIME=[E6FC6490:01C5F12D] X-Spam-Score: 0.9 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer: OK. Here are a few of my imagined uses of the MSG with mixed text and binary data. 1.) With the option to include binary data in the MSG, a new set of diagnostic messages can include some system internal data structure=20 values of concern for analysis. The beginning text in MSG will state=20 detailed description of the following binary data structure values. With proper tools provided, the binary data structure values can be examined in great details at the receiving end. =20 2.) Or the MSG can be used to capture the original incoming packet data=20 detected containing certain pattern.=20 3.) We can also include some voice data (binary) in MSG for certain situations.=20 4.) It can become backup route for SNMP traps because it can now carry text and binary data in MSG. The possible usage is basically up to device vendor's imaginations. =20 But if you only allow for text data because of the concern at hand=20 over NULL character, then the door is shut. With potentially rich feature sets to be imagined and to come with this binary-data-capable MSG, the syslog message receiver will have to be upgraded to be able to enjoy the benefits. I will leave it to=20 sales/marketing people to convince the customers so NULL sensitive=20 syslog message receiver will not be in the way. Thanks, Steve > -----Original Message----- > From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Rainer Gerhards > Sent: Thursday, November 24, 2005 3:50 AM > To: syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 > Steve, >=20 > no reply, but a question very important to me. What do you consider a > valid use case for the US-ASCII NUL character inside MSG? If I had a > good sample, I'd probably have a better time understanding why this is > important... >=20 > Rainer >=20 > On Thu, 2005-11-24 at 11:48, Steve Chang (schang99) wrote: > > Rainer: > > > > > -----Original Message----- > > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] > > > On Behalf Of Rainer Gerhards > > > Sent: Thursday, November 24, 2005 1:25 AM > > > To: Balazs Scheidler > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] New direction and proposed charter > > > > > > > On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > > > > > Anton: > > > > > > > > > So I wonder if it wouldn't be wiser to accept that CLR here > > > > and disallow > > > > > NUL. After all, I can not see a valid use case for it > > > > either... (in the > > > > > sample you provided it honestly believe the sender should > > > > not send a NUL > > > > > octet but a "\u0000" string). > > > > > > > > > > > > > \u0000 is a NUL octet at least in its canonical encoding. > > > > > > OK, looks like I need to dig up the ASCII table. My fault I didn't do > > it > > > in the first place. > > > > > > Anston's sample was > > > > > > ...MyApp pid123 MALFORMED_INPUT: Bad input received from client: > > > [aaa\u0000] > > > > > > For simplicity, let me strip the rest and just look at that part > > > > > > \u0000 > > > > > > I think the sender of the sample message should not encode it as > > > > > > NUL (0x00) > > > > > > but instead as > > > > > > 0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0) > > > > > > Encoding it as NUL in an otherwise human-readable message makes no > > sense > > > to me. > > > > > > > From the perspective of formatting a piece of device internal raw data > > into an outgoing syslog message and considering the CPU cycles needed to > > encode a NULL character into some other form to keep the whole MSG > > intact, > > I would say prepend the length of MSG (or say, add a fixed 4 digits byte > > length of the MSG between SD-IDs and MSG) will be much easier for the > > sender. With this, I think the new IETF syslog compliant receiver > > should also have easier time fetching in the complete MSG, regardless > > it's a plain text, XML-formated, or even binary data. > > [** side note: a fixed 4 digit MSG length can handle up to 9999 bytes. > > Big enough for foreseeable future. Also, the first MSG can be appended > > with other feature specific information before it gets sent out. And > > hence updating the final MSG length can be easier.] > > > > As to what will happen to the old syslog receivers receiving the message > > will NULL character? The message will probably be cut short right at > > reading the NULL character as you have explained. And I don't think > > there will be a good compromised solution for it. > > > > At the sender side, the overhead in checking for a NULL character in any > > of the incoming raw message and encode it to other form is just not > > practical. I would rather not have to pay that overhead if possible. > > Besides, if mandated, you will be limiting how MSG is to be used. > > > > I would say it should be sufficient to just explicitly point out the > > danger of having the NUL in the MSG part in the new IETF syslog > > protocol. > > And you can be kind to add some suggestions as to how the syslog message > > initial sending device can choose to do to handle this situation > > themselves. > > Vendors should make their own decisions on this issue. > > > > With this caveat, we get to keep the flexibility of having the MSG part > > in plain text, or in binary for the IETF syslog protocol. > > > > It's tradeoff for WG to debate. > > > > > > > I am questioning if there is any legitimate case where an actual NUL > > > needs to be part of MSG. > > > > > > > UTF-8 allows > > > > the same character to be encoded in multiple ways, see a > > > > description on > > > > the encoding format: > > > > > > > > http://www1.tip.nl/~t876506/utf8tbl.html > > > > > > > > And I think it would be wise to require the canonical encoding to be > > > > used and treat all other encodings of the same characters as errors. > > > > this is a large can of worms, lot's of security problems arised from > > > > this issue. (see the IIS problems couple of years ago) > > > > > > "Shortest possible form" thanksfully is already required in > > > syslog-protocol-15. > > > > > > Rainer > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 15:40:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfNt8-0006ia-HC; Thu, 24 Nov 2005 15:40:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfNt6-0006hB-ST for syslog@megatron.ietf.org; Thu, 24 Nov 2005 15:40:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22213 for ; Thu, 24 Nov 2005 15:39:32 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfOCE-0006Wa-JL for syslog@ietf.org; Thu, 24 Nov 2005 15:59:59 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 0D0F29C00D for ; Thu, 24 Nov 2005 21:48:33 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03367-02 for ; Thu, 24 Nov 2005 21:48:28 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 19C1D9C00B for ; Thu, 24 Nov 2005 21:48:28 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 21:39:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F11@grfint2.intern.adiscon.com> Thread-Topic: Running code... Thread-Index: AcXxNzpcAGGhXN1hTHugq/q/3mxoTQ== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] Running code... X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi WG, I think we have made good progress not only on the charter but also on ideas of how the next revision of syslog-protocol could look like. However, we have some very theoretic discussions about practical issues of compatibility and modifying existing code. I have become tired of thinking what could happen and so I have actually *implemented* today what we discussed so far.=20 My arguments are now backed by actual experience. I guess that's a nice asset ;) The good news is that it basically is quite easy to modify an existing code base to support what we currently have. However, there are some things that do not work out as we thought. Some other points (like NUL) have proven to be quite problematic. I have documented my proof-of-concept and all notes on its projects home page. I could copy and paste everything in here, but I think there is no point in reformatting html to email, so please visit http://www.rsyslog.com/index.php?module=3DStatic_Docs&func=3Dview&f=3D/sy= slog- protocol.html If you would like to have a look at the code, you need to obtain it via anonymous CVS (use the link on the home page). The downloadable packages do not include today's changes. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 15:41:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfNu1-0007Ii-Ta; Thu, 24 Nov 2005 15:41:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfNu0-0007IW-KB for syslog@megatron.ietf.org; Thu, 24 Nov 2005 15:41:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22289 for ; Thu, 24 Nov 2005 15:40:27 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfOD7-0006Zs-S2 for syslog@ietf.org; Thu, 24 Nov 2005 16:00:54 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 003989C00D for ; Thu, 24 Nov 2005 21:49:28 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03242-08 for ; Thu, 24 Nov 2005 21:49:24 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 477209C00B for ; Thu, 24 Nov 2005 21:49:24 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 21:40:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F12@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXw7XNdduIR7yZuShCOU8fOtRVIDQAOVDcgAAL5+/A= From: "Rainer Gerhards" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Steve: Sorry to be blunt: this is *faaaaaaaaaaar* bejond what we currently try to acomplish. I guess this should be defined in a smime to syslog mapping document. I am just a bit concerend about your proposed limit of 9999 octets. I am not sure how much voice will fit into it... Honestly - this is no payload for syslog. I also see no point in SNMP backup.=20 Some people might find that some of the samples are actual valid use cases, and I may become convinced over time. But - to say it with Darren - we have smaller fish to fry today ;) I also do not find it very consistent to vote in a meeting for backwards compatibility and then ask on list for a syslog revolution... Rainer > -----Original Message----- > From: Steve Chang (schang99) [mailto:schang99@cisco.com]=20 > Sent: Thursday, November 24, 2005 8:33 PM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 > Rainer: >=20 > OK. Here are a few of my imagined uses of the MSG with mixed text and > binary data. >=20 > 1.) With the option to include binary data in the MSG, a new set of > diagnostic messages can include some system internal data structure=20 > values of concern for analysis. The beginning text in MSG will > state=20 > detailed description of the following binary data structure > values. With proper tools provided, the binary data structure > values can be > examined in great details at the receiving end. =20 >=20 > 2.) Or the MSG can be used to capture the original incoming=20 > packet data=20 > detected containing certain pattern.=20 >=20 > 3.) We can also include some voice data (binary) in MSG for certain > situations.=20 >=20 > 4.) It can become backup route for SNMP traps because it can now carry > text and binary data in MSG. >=20 > The possible usage is basically up to device vendor's imaginations. =20 > But if you only allow for text data because of the concern at hand=20 > over NULL character, then the door is shut. >=20 > With potentially rich feature sets to be imagined and to come=20 > with this > binary-data-capable MSG, the syslog message receiver will have to be > upgraded to be able to enjoy the benefits. I will leave it to=20 > sales/marketing people to convince the customers so NULL sensitive=20 > syslog message receiver will not be in the way. >=20 >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] > > On Behalf Of Rainer Gerhards > > Sent: Thursday, November 24, 2005 3:50 AM > > To: syslog@ietf.org > > Subject: RE: [Syslog] New direction and proposed charter > >=20 > > Steve, > >=20 > > no reply, but a question very important to me. What do you=20 > consider a > > valid use case for the US-ASCII NUL character inside MSG? If I had a > > good sample, I'd probably have a better time understanding=20 > why this is > > important... > >=20 > > Rainer > >=20 > > On Thu, 2005-11-24 at 11:48, Steve Chang (schang99) wrote: > > > Rainer: > > > > > > > -----Original Message----- > > > > From: syslog-bounces@lists.ietf.org > > > [mailto:syslog-bounces@lists.ietf.org] > > > > On Behalf Of Rainer Gerhards > > > > Sent: Thursday, November 24, 2005 1:25 AM > > > > To: Balazs Scheidler > > > > Cc: syslog@ietf.org > > > > Subject: RE: [Syslog] New direction and proposed charter > > > > > > > > > On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > > > > > > Anton: > > > > > > > > > > > So I wonder if it wouldn't be wiser to accept that CLR here > > > > > and disallow > > > > > > NUL. After all, I can not see a valid use case for it > > > > > either... (in the > > > > > > sample you provided it honestly believe the sender should > > > > > not send a NUL > > > > > > octet but a "\u0000" string). > > > > > > > > > > > > > > > > \u0000 is a NUL octet at least in its canonical encoding. > > > > > > > > OK, looks like I need to dig up the ASCII table. My=20 > fault I didn't > do > > > it > > > > in the first place. > > > > > > > > Anston's sample was > > > > > > > > ...MyApp pid123 MALFORMED_INPUT: Bad input received=20 > from client: > > > > [aaa\u0000] > > > > > > > > For simplicity, let me strip the rest and just look at that part > > > > > > > > \u0000 > > > > > > > > I think the sender of the sample message should not encode it as > > > > > > > > NUL (0x00) > > > > > > > > but instead as > > > > > > > > 0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0) > > > > > > > > Encoding it as NUL in an otherwise human-readable=20 > message makes no > > > sense > > > > to me. > > > > > > > > > > From the perspective of formatting a piece of device internal raw > data > > > into an outgoing syslog message and considering the CPU cycles > needed to > > > encode a NULL character into some other form to keep the whole MSG > > > intact, > > > I would say prepend the length of MSG (or say, add a=20 > fixed 4 digits > byte > > > length of the MSG between SD-IDs and MSG) will be much easier for > the > > > sender. With this, I think the new IETF syslog compliant receiver > > > should also have easier time fetching in the complete MSG, > regardless > > > it's a plain text, XML-formated, or even binary data. > > > [** side note: a fixed 4 digit MSG length can handle up to 9999 > bytes. > > > Big enough for foreseeable future. Also, the first MSG can be > appended > > > with other feature specific information before it gets=20 > sent out. And > > > hence updating the final MSG length can be easier.] > > > > > > As to what will happen to the old syslog receivers receiving the > message > > > will NULL character? The message will probably be cut short right > at > > > reading the NULL character as you have explained. And I=20 > don't think > > > there will be a good compromised solution for it. > > > > > > At the sender side, the overhead in checking for a NULL=20 > character in > any > > > of the incoming raw message and encode it to other form=20 > is just not > > > practical. I would rather not have to pay that overhead=20 > if possible. > > > Besides, if mandated, you will be limiting how MSG is to be used. > > > > > > I would say it should be sufficient to just explicitly=20 > point out the > > > danger of having the NUL in the MSG part in the new IETF syslog > > > protocol. > > > And you can be kind to add some suggestions as to how the syslog > message > > > initial sending device can choose to do to handle this situation > > > themselves. > > > Vendors should make their own decisions on this issue. > > > > > > With this caveat, we get to keep the flexibility of having the MSG > part > > > in plain text, or in binary for the IETF syslog protocol. > > > > > > It's tradeoff for WG to debate. > > > > > > > > > > I am questioning if there is any legitimate case where an actual > NUL > > > > needs to be part of MSG. > > > > > > > > > UTF-8 allows > > > > > the same character to be encoded in multiple ways, see a > > > > > description on > > > > > the encoding format: > > > > > > > > > > http://www1.tip.nl/~t876506/utf8tbl.html > > > > > > > > > > And I think it would be wise to require the canonical encoding > to be > > > > > used and treat all other encodings of the same characters as > errors. > > > > > this is a large can of worms, lot's of security=20 > problems arised > from > > > > > this issue. (see the IIS problems couple of years ago) > > > > > > > > "Shortest possible form" thanksfully is already required in > > > > syslog-protocol-15. > > > > > > > > Rainer > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 17:04:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfPCX-0003yM-9P; Thu, 24 Nov 2005 17:04:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfPCV-0003wZ-Uh for syslog@megatron.ietf.org; Thu, 24 Nov 2005 17:04:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01884 for ; Thu, 24 Nov 2005 17:03:38 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfPVd-0001Js-Ij for syslog@ietf.org; Thu, 24 Nov 2005 17:24:07 -0500 Received: (qmail 13433 invoked from network); 24 Nov 2005 22:04:10 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 24 Nov 2005 22:04:10 -0000 X-pair-Authenticated: 202.137.242.74 From: "Andrew Ross" To: "'Rainer Gerhards'" , Date: Fri, 25 Nov 2005 11:04:03 +1300 Organization: Kiwi Enterprises Message-ID: <001601c5f142$fdf95a80$d901a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1132833025.2183.1.camel@rh9lt.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] Null character X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer, FWIIW, I've seen Netscreen, NetGear and some LinkSys devices send a Null character at the end of each message. Not all versions of the firmware = would include the Null at the end which leads me to believe it may be a bug in some releases of the firmware. When sending syslog over TCP, Netscreen firewalls will delimit each = message with LF NULL. This probably won't have any impact on the 'CLR' since it is the very = last character in the message, but I thought I would raise the issue with you = as a real-life case of a Null character being used. Cheers Andrew _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 17:07:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfPFI-0004RG-Dc; Thu, 24 Nov 2005 17:07:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfPFH-0004R3-4c for syslog@megatron.ietf.org; Thu, 24 Nov 2005 17:07:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02171 for ; Thu, 24 Nov 2005 17:06:30 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfPYO-0001Q4-W9 for syslog@ietf.org; Thu, 24 Nov 2005 17:26:58 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 31D609C00D; Thu, 24 Nov 2005 23:15:31 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03367-07; Thu, 24 Nov 2005 23:15:27 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id C4B119C00B; Thu, 24 Nov 2005 23:15:27 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 23:06:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F13@grfint2.intern.adiscon.com> Thread-Topic: Null character Thread-Index: AcXxQwLM9/lHmhUqT5am+FA2X18rFAAACwTQ From: "Rainer Gerhards" To: , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] RE: Null character X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Andrew: Thanks for that info. I've to admit I've always overlooked this. Eventually, this creates a new situation. Do you think we should support NUL natively (I mean without escaping it, e.g. in <000> as your syslogd does currently)? Rainer=20 > -----Original Message----- > From: Andrew Ross [mailto:andrew@kiwisyslog.com]=20 > Sent: Thursday, November 24, 2005 11:04 PM > To: Rainer Gerhards; syslog@ietf.org > Subject: Null character >=20 >=20 > Rainer, >=20 > FWIIW, I've seen Netscreen, NetGear and some LinkSys devices=20 > send a Null > character at the end of each message. Not all versions of the=20 > firmware would > include the Null at the end which leads me to believe it may=20 > be a bug in > some releases of the firmware. >=20 > When sending syslog over TCP, Netscreen firewalls will=20 > delimit each message > with LF NULL. >=20 > This probably won't have any impact on the 'CLR' since it is=20 > the very last > character in the message, but I thought I would raise the=20 > issue with you as > a real-life case of a Null character being used. >=20 > Cheers >=20 > Andrew >=20 >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 17:20:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfPS2-0001SC-Jk; Thu, 24 Nov 2005 17:20:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfPS1-0001S2-3J for syslog@megatron.ietf.org; Thu, 24 Nov 2005 17:20:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03756 for ; Thu, 24 Nov 2005 17:19:40 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfPlA-0001xl-49 for syslog@ietf.org; Thu, 24 Nov 2005 17:40:08 -0500 Received: (qmail 17654 invoked from network); 24 Nov 2005 22:20:19 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 24 Nov 2005 22:20:19 -0000 X-pair-Authenticated: 202.137.242.74 From: "Andrew Ross" To: "'Rainer Gerhards'" Subject: RE: [Syslog] New direction and proposed charter Date: Fri, 25 Nov 2005 11:20:15 +1300 Organization: Kiwi Enterprises Message-ID: <001701c5f145$3f934260$d901a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F07@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer, I agree that 3164 is only really valid with respect to the . When = we implemented it in Kiwi Syslog we found no device actually used the 3164 format exactly. Sometimes the hostname was there, sometimes not. Having = to write parsing code to work out if a hostname was actually a TAG or not = was a huge processing overhead. We now disable 3164 parsing by default. Cheers Andrew _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 17:22:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfPTi-00034e-0b; Thu, 24 Nov 2005 17:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfPTg-00031p-Cf for syslog@megatron.ietf.org; Thu, 24 Nov 2005 17:22:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03970 for ; Thu, 24 Nov 2005 17:21:23 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfPmp-00020v-EP for syslog@ietf.org; Thu, 24 Nov 2005 17:41:51 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 14CCE9C00D; Thu, 24 Nov 2005 23:30:26 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03367-09; Thu, 24 Nov 2005 23:30:22 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 9A7F49C00B; Thu, 24 Nov 2005 23:30:22 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2005 23:21:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F14@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXxRUSfPTQXctNRTiCT+VGIB1HPCwAACEag From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Andrew, That's exactly our experience. 100% same story... Rainer=20 > -----Original Message----- > From: Andrew Ross [mailto:andrew@kiwisyslog.com]=20 > Sent: Thursday, November 24, 2005 11:20 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 >=20 > Rainer, >=20 > I agree that 3164 is only really valid with respect to the=20 > . When we > implemented it in Kiwi Syslog we found no device actually=20 > used the 3164 > format exactly. Sometimes the hostname was there, sometimes=20 > not. Having to > write parsing code to work out if a hostname was actually a=20 > TAG or not was a > huge processing overhead. We now disable 3164 parsing by default. >=20 > Cheers >=20 > Andrew >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 18:01:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfQ5M-0000wK-Au; Thu, 24 Nov 2005 18:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfQ5K-0000v0-QG for syslog@megatron.ietf.org; Thu, 24 Nov 2005 18:00:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07562 for ; Thu, 24 Nov 2005 18:00:16 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfQOP-0003H9-Da for syslog@ietf.org; Thu, 24 Nov 2005 18:20:45 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAON0dkP029174; Fri, 25 Nov 2005 10:00:39 +1100 (EST) From: Darren Reed Message-Id: <200511242300.jAON0Quk001683@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Null character In-Reply-To: <001601c5f142$fdf95a80$d901a8c0@KiwiAndrew> To: andrew@kiwisyslog.com Date: Fri, 25 Nov 2005 10:00:26 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > Rainer, > > FWIIW, I've seen Netscreen, NetGear and some LinkSys devices send a Null > character at the end of each message. Not all versions of the firmware would > include the Null at the end which leads me to believe it may be a bug in > some releases of the firmware. > > When sending syslog over TCP, Netscreen firewalls will delimit each message > with LF NULL. > > This probably won't have any impact on the 'CLR' since it is the very last > character in the message, but I thought I would raise the issue with you as > a real-life case of a Null character being used. Buggy software does not equate to a "real-life case". But to judge whether or not it is a bug requires knowing what their protocol spec is. In this case, it is a delimeter and that is not something that requires escaping. In fact, it would be a bug to escape it if it were being used in this manner. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 24 18:37:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfQen-0005QX-Dn; Thu, 24 Nov 2005 18:37:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfQel-0005QS-95 for syslog@megatron.ietf.org; Thu, 24 Nov 2005 18:37:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11305 for ; Thu, 24 Nov 2005 18:36:53 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfQxt-0004hq-TD for syslog@ietf.org; Thu, 24 Nov 2005 18:57:23 -0500 Received: (qmail 30228 invoked from network); 24 Nov 2005 23:37:27 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 24 Nov 2005 23:37:27 -0000 X-pair-Authenticated: 202.137.242.74 From: "Andrew Ross" To: "'Moehrke, John \(GE Healthcare\)'" Subject: RE: [Syslog] RE: Message format (human readable) Date: Fri, 25 Nov 2005 12:37:24 +1300 Organization: Kiwi Enterprises Message-ID: <001c01c5f150$06a5e420$d901a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <45A5295FFA1CBE4D9BF44E8534D2686C09984372@MKEMLVEM07.e2k.ad.ge.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi John, I guess the whole thing depends on how one would define "human = readable". In my view, XML tags and content are still human readable. Binary data = could also be counted as human readable if it was preceded with a tag and = encoded in base64 etc. Something like [Bin_Data_Base64 =3D "kahskdjashd=3D=3D"] = would be fine. That way it would be obvious to someone reading the log what part = is what.=20 The idea is to avoid someone trying to send chunks of unencoded binary = or hex data over syslog.=20 Syslog was originally intended as a way of alerting operators to system malfunctions or things that required their attention. By tailing the Alert/Warning/Error logs on the console, it was easy to keep an eye on = the condition of the systems. Some apps would also send verbose debug information to the logs. This was usually never seen by the operator and simply written to disk for analysis later.=20 Sending XML medical or encoded binary data over syslog would fall into = the debug category since no human would be reviewing the logs in real time = on the screen. As long as you choose the level and facility () = correctly, I feel it would still work fine. That is just my opinion. I'd be interested to hear what others on the = list have to say. Cheers Andrew _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 25 04:53:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaGy-0003er-Ce; Fri, 25 Nov 2005 04:53:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaGw-0003eA-Vj for syslog@megatron.ietf.org; Fri, 25 Nov 2005 04:53:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04335 for ; Fri, 25 Nov 2005 04:52:57 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfaaA-0007Rj-Nz for syslog@ietf.org; Fri, 25 Nov 2005 05:13:32 -0500 Received: from pc6 (1Cust58.tnt29.lnd3.gbr.da.uu.net [62.188.120.58]) by ranger.systems.pipex.net (Postfix) with SMTP id 1F08AE0003A9; Fri, 25 Nov 2005 09:53:18 +0000 (GMT) Message-ID: <008c01c5f19d$6b37b6a0$0601a8c0@pc6> From: "Tom Petch" To: "Alexander Clemm (alex)" , "Chris Lonvick (clonvick)" , References: <85B2F271FDF6B949B3672BA5A7BB62FBEFCE71@xmb-sjc-236.amer.cisco.com> Subject: Re: [Syslog] Revised proposed charter Date: Fri, 25 Nov 2005 09:40:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Alexander Clemm (alex)" To: "Anton Okmianski (aokmians)" ; "Chris Lonvick (clonvick)" ; Sent: Wednesday, November 23, 2005 6:50 PM Subject: RE: [Syslog] Revised proposed charter I think the charter looks good. It describes what the working group has to do and its deliverables. I agree that there is a next level of details that spells out the specifics of how to do it. We had a lot of discussion on this and seem to have come to a consensus, which is something that we should capture. [tp] Strange, I was thiinking quite the opposite, that we had a fragile consensus which disappeared in Vancouver and has not been refound. Looking back at the messages posted in the past few days, about what should be in the header in what order, I was thinking, what now? because I see no consensus, rather the re-emergence of many different points of view. So while the proposed charter looks ok, because it does not go into that detail, I do not see how we progress any further, into the next level of technical detail, of what and how should be in the header. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 25 04:53:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaGy-0003fF-Ja; Fri, 25 Nov 2005 04:53:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaGx-0003eG-2C for syslog@megatron.ietf.org; Fri, 25 Nov 2005 04:53:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04336 for ; Fri, 25 Nov 2005 04:52:57 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfaaB-0007S2-J6 for syslog@ietf.org; Fri, 25 Nov 2005 05:13:32 -0500 Received: from pc6 (1Cust58.tnt29.lnd3.gbr.da.uu.net [62.188.120.58]) by ranger.systems.pipex.net (Postfix) with SMTP id F4182E0004EE; Fri, 25 Nov 2005 09:53:22 +0000 (GMT) Message-ID: <008d01c5f19d$6bdf8f60$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" References: <577465F99B41C842AAFBE9ED71E70ABA0E3F06@grfint2.intern.adiscon.com> Subject: MIB was Re: [Syslog] Revised proposed charter Date: Fri, 25 Nov 2005 09:47:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris I was not, am not, quite clear what you are asking for but I am an SNMP expert and do review MIBs and was planning to do so for the syslog MIB as and when the protocol that the MIB is of is stable. (Be warned, when I commit to do something, I tend to avoid committing to a date and vice versa:-) I would expect a MIB to be required of us by IESG unless we can put up a very strong case why not. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: "Rainer Gerhards" Cc: Sent: Thursday, November 24, 2005 5:42 PM Subject: RE: [Syslog] Revised proposed charter > > OK - sorry 'bout that. > > Glenn - please update it and get it into the ID repository. > > All - who will commit to reviewing this document? I will need someone to > commit to this before I put it into the proposed charter. > > Thanks, > Chris > > On Thu, 24 Nov 2005, Rainer Gerhards wrote: > > > Oops, I have overlooked that one. I agree with Glenn that this should be > > in the charter. > > > > Rainer > > > >> -----Original Message----- > >> From: syslog-bounces@lists.ietf.org > >> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn > >> Mansfield Keeni > >> Sent: Thursday, November 24, 2005 11:33 AM > >> To: syslog@ietf.org > >> Subject: Re: [Syslog] Revised proposed charter > >> > >> Chris, > >> You seem to have dropped the last deliverable which is > >> in good shape > >> > >>> - A MIB definition for syslog will be produced. > >> > >> I would strongly recommend that we include it. It is an > >> important aspect > >> of the protocol. Some effort has gone into it. And it is the least > >> controversial [there are no issues of backward compatibility]. And it > >> is very close to completion. > >> > >> Glenn > >> > >> Chris Lonvick wrote: > >>> Hi All, > >>> > >>> ==== v2 of proposed charter === > >>> > >>> Syslog is a de-facto standard for logging system events. > >> However, the > >>> protocol component of this event logging system has not > >> been formally > >>> documented. While the protocol has been very useful and > >> scalable, it > >>> has some known security problems which were documented in RFC 3164. > >>> > >>> The goal of this working group is to address the security > >> and integrity > >>> problems, and to standardize the syslog protocol, transport, and a > >>> select set of mechanisms in a manner that considers the ease of > >>> migration between and the co-existence of existing versions and the > >>> standard. > >>> > >>> syslog has traditionally been transported over UDP and this WG has > >>> already defined RFC 3195 for the reliable transport for the syslog > >>> messages. The WG will separate the UDP transport from the > >> protocol so > >>> that others may define additional transports in the future. > >>> > >>> > >>> - A document will be produced that describes a standardized syslog > >>> protocol. A mechanism will also be defined in this document > >>> that will provide a means to convey structured data. > >>> > >>> - A document will be produced that describes a standardized UDP > >>> transport for syslog. > >>> > >>> - A document will be produced that describes a standardized > >> mechanism > >>> to sign syslog messages to provide integrity checking and source > >>> authentication. > >>> > >>> > >>> === === > >>> > >>> Comments please. > >>> > >>> Thanks, > >>> Chris > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >> > >> > >> > >> > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > >> > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 25 06:57:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfcCX-00060q-FG; Fri, 25 Nov 2005 06:57:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfcCW-0005yr-2V for syslog@megatron.ietf.org; Fri, 25 Nov 2005 06:57:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15761 for ; Fri, 25 Nov 2005 06:56:30 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfcVk-0003Ce-Gn for syslog@ietf.org; Fri, 25 Nov 2005 07:17:06 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id F37079C00D; Fri, 25 Nov 2005 13:05:28 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03913-10; Fri, 25 Nov 2005 13:05:24 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id A75E99C00B; Fri, 25 Nov 2005 13:05:24 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] Consensus? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Nov 2005 12:57:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F1C@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Consensus? Thread-Index: AcXxpmQZ397qYU8fQt6uCreM5f0DhgAAfhAg From: "Rainer Gerhards" To: "Tom Petch" , "Alexander Clemm (alex)" , "Chris Lonvick (clonvick)" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, WG: Comments inline... Rainer > [tp] Strange, I was thiinking quite the opposite, that we had=20 > a fragile > consensus which disappeared in > Vancouver and has not been refound. Looking back at the=20 > messages posted in the > past few days, about what should be in the header in what=20 > order, I was thinking, > what now? because I see no consensus, rather the re-emergence of many > different points of view. >=20 > So while the proposed charter looks ok, because it does not=20 > go into that detail, > I do not see how we progress any further, into the next level=20 > of technical > detail, of what and > how should be in the header. I agree that we have not found consensus again. However, I think we are in a better shape on the details than it it might look. My personal view is that many items are shortly before reaching actual consensus. Let me sum up the items I see. We might use that as a potential basis for reaching consensus. #1 testing and code review has shown that there is no point in trying to preserve more than ; RFC 3164 provides a false impression of common behaviour. =20 This is controversal, but the facts are suggesting this is the way it is. We should try to reach consensus on this. #2 The max message length issue resurfaces. There seems to be a fragile consensus that we can life with the compromise in syslog-protocol and eventualy open a debate if we (ever) go to a TCP transport. Again, controversal, too. #3 There is a question if NUL octets are to be supported in the MSG content. No consensus yet. #4 There seems to be a fragile consensus that MSG should=20 primarily contain textual data, including XMLified content. On the contrary, pure binary data should not be used. This is somewhat controversal. #5 Character encoding in MSG: due to my proof-of-concept implementation, I have raised the (ugly) question if we need to allow encodings other than UTF-8. Please note that this question arises from needs introduced by e.g. POSIX. So we can't easily argue them away by whishful thinking ;) Not even discussed yet. #6 field order This is related to #1 and can, I think, quickly be fixed once #1 is settled. #7 Header fields: there seems to be a fragile consensus that MSGID, PROCID, APP-NAME, and VERSION should be in the header and TRUNCATE should not be in it. This needs to be finalized, but I think we are very close. #8 MSG-octet counting and/or trailer is resurfacing. I think this item is not well understood and well discussed. We need to discuss it. #9 I have found some minor items not already discussed during my proof-of-concept implementation (like "drop requirements" and such). These are not absolutely vital, but should be considered before a final text is issued (or even the next revision). This needs to be discussed. As it is new, I have no idea what the discussion may lead to. #10 STRUCTURED-DATA: there has been surprisingly few discussion about STRUCTURED-DATA. I conclude that this is non-controversal. The good thing is that more people (especially implementors) are expressing themselfs on the list. This is what finally makes me feel positive about finally reaching our goal. I think we can produce some useful documents if we manage to keep discussing in the current paste. My whish would be that we focus more on practical things in this discussion, especially when it comes to compatibility with existing (deployed) technology. It does not help if we theoretice things would be this and that when they are acutally different - even though this "real world" is kind of dirty... Also, we should try to "fry the small fish" and not solve any need that might surface. I would also like to see this group moving in a direction that focusses on results usable in practice. I personally prefer a solution that is 80% theoretically "clean" but has a 95% chance of implementation over a 95% "clean" solution with just a low chance of getting implemented (hint: RFC 3195). I am an IETF freshman. Anyhow, I often read that the IETF was driven by "rough consensus and running code". I say "was", because my impression is that this is no longer the case. I would prefer it were... If this WG fails, what probably happens is that some implementors stick together and implement something that is pretty similar to what we have right now (or totally different - who knows). Just as syslog/tcp is implemented in this "industry-standard" way. The IETF does not like plain tcp syslog. Guess what? No implementor or end user cares... ;) This often-violently-objected transport mode has brought more security and reliability to the syslog community than anything this group has done the past years. And yes, it is true, plain tcp syslog as it is deployed is far from being a clean solution. It's only plus is it works... So I think it would be a very helpful if we manage to produce a standard that solves the currently horrible syslog format scenario. But we need one that gets implemented... Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 25 16:54:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EflWK-00027q-PZ; Fri, 25 Nov 2005 16:54:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EflWJ-00026o-JS for syslog@megatron.ietf.org; Fri, 25 Nov 2005 16:54:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22296 for ; Fri, 25 Nov 2005 16:53:33 -0500 (EST) Received: from dsl254-102-222.nyc1.dsl.speakeasy.net ([216.254.102.222] helo=gandalf.taltos.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eflpd-0007xw-Oo for syslog@ietf.org; Fri, 25 Nov 2005 17:14:14 -0500 Received: from gandalf.taltos.org (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id 7FAF821C04 for ; Fri, 25 Nov 2005 16:53:54 -0500 (EST) Received: from localhost.localdomain (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id 64EBA21B70 for ; Fri, 25 Nov 2005 16:53:54 -0500 (EST) Date: Fri, 25 Nov 2005 16:53:54 -0500 From: Carson Gaspar To: syslog@ietf.org Subject: RE: [Syslog] Consensus? Message-ID: <77687404CA3D1184D7AD1FAF@gaspac.ny.ficc.gs.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F1C@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E3F1C@grfint2.intern.adiscon.c om> X-Mailer: Mulberry/4.0.0b4 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on gandalf.taltos.org X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org --On Friday, November 25, 2005 12:57:03 PM +0100 Rainer Gerhards wrote: ># 8 MSG-octet counting and/or trailer is resurfacing. I think > this item is not well understood and well discussed. > > We need to discuss it. IFF we decide to do octet-counting we should put the length at a fixed offset (barring other considerations). This allows implementors to do a quick recvmsg(...MSG_PEEK) and extract the message length without having to parse random data. -- Carson Gaspar _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 25 17:36:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfmB4-0007fe-EZ; Fri, 25 Nov 2005 17:36:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfmB2-0007fW-VG for syslog@megatron.ietf.org; Fri, 25 Nov 2005 17:36:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26276 for ; Fri, 25 Nov 2005 17:35:38 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfmUM-0000ol-By for syslog@ietf.org; Fri, 25 Nov 2005 17:56:20 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAPMZkoS000603; Sat, 26 Nov 2005 09:35:46 +1100 (EST) From: Darren Reed Message-Id: <200511252235.jAPMZLpl007161@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Revised proposed charter In-Reply-To: <008c01c5f19d$6b37b6a0$0601a8c0@pc6> To: Tom Petch Date: Sat, 26 Nov 2005 09:35:21 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org [ Charset ISO-8859-1 unsupported, converting... ] > [tp] Strange, I was thiinking quite the opposite, that we had a fragile > consensus which disappeared in > Vancouver and has not been refound. Looking back at the messages posted > in the past few days, about what should be in the header in what order, > I was thinking, > what now? because I see no consensus, rather the re-emergence of many > different points of view. > > So while the proposed charter looks ok, because it does not go into that > detail, I do not see how we progress any further, into the next level of > technical detail, of what and how should be in the header. So long as everyone wants to solve every problem in one single RFC, we will go nowhere. For those people I say "go use 3195" and stop bothering the group with yoru quibbles. All this nonsense about NUL characters and message lengths, XML, structured data, etc. Too many people here have a pet peeve they want to see the first draft solve and seem determined to overload it with that so that they're covered/happy. This is not a way forward but a way backward. We need to evolve the syslog protocol and we need to do that starting with the basic protocol that has been used for years, build upon that in a structured manner and conquer one piece of the problem at a time. If one thing is clear from this, it won't be possible to write a single document that makes good all of the evolutions of the syslog protocol. Some are going to have to be put in the "bad basket." If that happens to be yours, or mine, stiff. We're all going to need to make sacrifices and changes if anything useful is going to be achieved. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 25 18:07:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfmfA-0001Nv-MY; Fri, 25 Nov 2005 18:07:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efmf4-0001Nq-KQ for syslog@megatron.ietf.org; Fri, 25 Nov 2005 18:07:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29741 for ; Fri, 25 Nov 2005 18:06:40 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfmyP-0001r0-5t for syslog@ietf.org; Fri, 25 Nov 2005 18:27:22 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAPN7FfJ006330; Sat, 26 Nov 2005 10:07:15 +1100 (EST) From: Darren Reed Message-Id: <200511252307.jAPN7574002939@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Revised proposed charter In-Reply-To: To: Chris Lonvick Date: Sat, 26 Nov 2005 10:07:05 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, Let me have a go at rewriting the charter... > The goal of this working group is to address the security and integrity > problems, and to standardize the syslog protocol, transport, and a select > set of mechanisms in a manner that considers the ease of migration between > and the co-existence of existing versions and the standard. The goal of this working group is to address the security and integrity concerns about individual messages, as well as to standardise the message format and the mechanisms used to transport those messages. A primary requirement of this work is to make it accept the traditional BSD format syslog message. > syslog has traditionally been transported over UDP and this WG has already > defined RFC 3195 for the reliable transport for the syslog messages. The > WG will separate the UDP transport from the protocol so that others may > define additional transports in the future. In RFC 3164, this WG documented the historical syslog protocol over UDP. The WG then proceeded to develop a reliable transport for syslog messages and this can be found in RFC 3195. Using this work, we intend to develop a number of documents that evolve the syslog protocol and provide a series of seperate documents showing how it is used over various transports (eg. UDP, TCP, ssh, etc.) - A document will be produced that describes how syslog works, its architecture, relaying, security issues, plans going forward, etc. Information in RFC 3164 will form he basis of this document. - A document will be produced that describes a modern syslog message format that is based upon what was presented in RFC 3164. The message format in this document will be backward compatible with RFC 3164. - A document will be produced that describes a standardized (plain) UDP transport for modern modern syslog messages. (i.e. syslog/udp) - A document will be produced that describes a standardized (plain) TCP transport for syslog messages. (i.e. syslog/tcp) - A document will be produced that describes transporting moden syslog messages over for the purpose of secrecy and/or integrity. (i.e. syslog/ssh) - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. (i.e. syslog-sign) If in doing some of the above we place the format of some vendor messages (such as netscreen) outside of that documented and accepted by the IETF then so be it. We should not be about trying to come up with something that we can shoehorn everything that exists into but rather something that makes good technical sense. If a vendor ends up with a format in existing products that doesn't interoperate, so be it. They've have to issue a patch if they want to comply. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Nov 26 05:35:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfxP6-0001fY-U3; Sat, 26 Nov 2005 05:35:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfxP5-0001fT-R3 for syslog@megatron.ietf.org; Sat, 26 Nov 2005 05:35:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24243 for ; Sat, 26 Nov 2005 05:34:53 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfxiX-0004Wk-DY for syslog@ietf.org; Sat, 26 Nov 2005 05:55:41 -0500 Received: from pc6 (1Cust181.tnt21.lnd4.gbr.da.uu.net [62.188.150.181]) by ranger.systems.pipex.net (Postfix) with SMTP id 32680E0001AE; Sat, 26 Nov 2005 10:35:16 +0000 (GMT) Message-ID: <002f01c5f26c$74a3aa80$0601a8c0@pc6> From: "Tom Petch" To: "Darren Reed" References: <200511252235.jAPMZLpl007161@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Revised proposed charter Date: Sat, 26 Nov 2005 10:29:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Darren Reed" To: "Tom Petch" Cc: Sent: Friday, November 25, 2005 11:35 PM Subject: Re: [Syslog] Revised proposed charter > [ Charset ISO-8859-1 unsupported, converting... ] > > [tp] Strange, I was thiinking quite the opposite, that we had a fragile > > consensus which disappeared in > > Vancouver and has not been refound. Looking back at the messages posted > > in the past few days, about what should be in the header in what order, > > I was thinking, > > what now? because I see no consensus, rather the re-emergence of many > > different points of view. > > > > So while the proposed charter looks ok, because it does not go into that > > detail, I do not see how we progress any further, into the next level of > > technical detail, of what and how should be in the header. > > So long as everyone wants to solve every problem in one single RFC, > we will go nowhere. For those people I say "go use 3195" and stop > bothering the group with yoru quibbles. > > All this nonsense about NUL characters and message lengths, XML, > structured data, etc. Too many people here have a pet peeve they > want to see the first draft solve and seem determined to overload > it with that so that they're covered/happy. > > This is not a way forward but a way backward. > > We need to evolve the syslog protocol and we need to do that starting > with the basic protocol that has been used for years, build upon that > in a structured manner and conquer one piece of the problem at a time. > > If one thing is clear from this, it won't be possible to write a > single document that makes good all of the evolutions of the syslog > protocol. Some are going to have to be put in the "bad basket." > > If that happens to be yours, or mine, stiff. We're all going to > need to make sacrifices and changes if anything useful is going > to be achieved. > > Darren Mmmm I agree that sacrifices are needed but am puzzled by your reference to first draft. Syslog-protocol is at -15 and represents a (fragile) consensus about XML, null octet, truncation etc. What I don't understand is that Vancouver seems to say that we must reinstate - ok - and while we are at it, go back to square one on lots of other things. If that is how it is, so be it (but I am still puzzled). Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Nov 26 05:35:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfxP9-0001g1-45; Sat, 26 Nov 2005 05:35:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfxP3-0001fS-OG for syslog@megatron.ietf.org; Sat, 26 Nov 2005 05:35:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24230 for ; Sat, 26 Nov 2005 05:34:51 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfxiV-0004WO-8D for syslog@ietf.org; Sat, 26 Nov 2005 05:55:39 -0500 Received: from pc6 (1Cust181.tnt21.lnd4.gbr.da.uu.net [62.188.150.181]) by ranger.systems.pipex.net (Postfix) with SMTP id 9F788E0000C4; Sat, 26 Nov 2005 10:35:12 +0000 (GMT) Message-ID: <002e01c5f26c$6eb6f140$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] Revised proposed charter Date: Sat, 26 Nov 2005 10:23:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Based on the discussions of the past few days, the one detail that I would add to the charter is about and backward compatability, something along the lines of While compatability with existing syslog systems is desirable, research shows that these are so diverse that there is nothing in common amongst them apart from so that whilst that field will be retained, other fields may not be. added to the paragraph on syslog protocol. And yes, IESG and the ietf list will doubtless want to know why we regard that as acceptable. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Wednesday, November 23, 2005 6:05 PM Subject: [Syslog] Revised proposed charter > Hi All, > > ==== v2 of proposed charter === > > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it has > some known security problems which were documented in RFC 3164. > > The goal of this working group is to address the security and integrity > problems, and to standardize the syslog protocol, transport, and a select > set of mechanisms in a manner that considers the ease of migration between > and the co-existence of existing versions and the standard. > > syslog has traditionally been transported over UDP and this WG has already > defined RFC 3195 for the reliable transport for the syslog messages. The > WG will separate the UDP transport from the protocol so that others may > define additional transports in the future. > > > - A document will be produced that describes a standardized syslog > protocol. A mechanism will also be defined in this document > that will provide a means to convey structured data. > > - A document will be produced that describes a standardized UDP > transport for syslog. > > - A document will be produced that describes a standardized mechanism > to sign syslog messages to provide integrity checking and source > authentication. > > > === === > > Comments please. > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Nov 26 06:40:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfyPu-0000WK-9G; Sat, 26 Nov 2005 06:40:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfyPs-0000W8-V5 for syslog@megatron.ietf.org; Sat, 26 Nov 2005 06:40:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29263 for ; Sat, 26 Nov 2005 06:39:46 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfyjH-0006DR-7g for syslog@ietf.org; Sat, 26 Nov 2005 07:00:35 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAQBduco009343; Sat, 26 Nov 2005 22:39:56 +1100 (EST) From: Darren Reed Message-Id: <200511261139.jAQBdQ8A027468@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Revised proposed charter In-Reply-To: <002e01c5f26c$6eb6f140$0601a8c0@pc6> To: Tom Petch Date: Sat, 26 Nov 2005 22:39:26 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org [ Charset ISO-8859-1 unsupported, converting... ] > Based on the discussions of the past few days, the one detail that I would add > to the charter is about and backward compatability, something along the > lines of > > While compatability with existing syslog systems is desirable, research shows > that these are so diverse that there is nothing in common amongst them apart > from so that whilst that field will be retained, other fields may not > be. > > added to the paragraph on syslog protocol. Why ? The charter shouldn't be mentioning any specifics of the protocol(s) that the group intends to work on. The charter should be as relatively open ended as possible with respect to the actual specifics delivered. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Nov 26 06:54:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfydH-0004Ed-KT; Sat, 26 Nov 2005 06:54:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfydG-0004Dv-5j for syslog@megatron.ietf.org; Sat, 26 Nov 2005 06:54:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00533 for ; Sat, 26 Nov 2005 06:53:35 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efywh-0006dh-BX for syslog@ietf.org; Sat, 26 Nov 2005 07:14:25 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAQBs4Cm003610; Sat, 26 Nov 2005 22:54:05 +1100 (EST) From: Darren Reed Message-Id: <200511261153.jAQBrYh3004501@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Revised proposed charter In-Reply-To: <002f01c5f26c$74a3aa80$0601a8c0@pc6> To: Tom Petch Date: Sat, 26 Nov 2005 22:53:34 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, Darren Reed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Why? Because the community implementing syslog protocol things seems to be ignoring what the group has been doing. This may be because they're unaware of the work or because it is being regarded as a "WTF?!" and doing their own thing. Most people seem to be ignoring 3195. Lets learn from that experience and try to develop something that'll be what people want to use rather than what we think they need. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Nov 26 13:52:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg5A2-00056m-Lp; Sat, 26 Nov 2005 13:52:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg59z-00055s-BV for syslog@megatron.ietf.org; Sat, 26 Nov 2005 13:52:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14875 for ; Sat, 26 Nov 2005 13:51:48 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eg5IW-0003H5-Kw for syslog@ietf.org; Sat, 26 Nov 2005 14:01:23 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 26 Nov 2005 10:41:01 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAQIevs3014137; Sat, 26 Nov 2005 10:40:58 -0800 (PST) Date: Sat, 26 Nov 2005 10:40:57 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] Consensus? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F1C@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3F1C@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi All, I am finding that the people contributing to the mailing list are making progress in defining a useful protocol. I also see that they are discussing implementation details. Both of these tell me that we're on the right track. What we found in Vancouver is that we were on the wrong track. The protocol being discussed was going to break existing receivers and information was going to be dropped on the floor. By keeping , the existing receivers will not drop things on the floor and we can expect a much better acceptance rate from the community. We've seen that RFC 3195 is being implemented. I do not want to de-focus this group by encouraging discussion of that at this time. After we get syslog-protocol and syslog-transport-udp submitted to the IESG, I will ask how we want to proceed with a revision of that Proposed Standard. One person has suggested to me that it can be revised through an individual submissionn. Rainer's list (below) will serve as our list of issues. I'd like for these to be closed out within 2 weeks. I'm going to look for rough consensus on these issues and I will greatly appreciate everyone accepting the decisions we make at the end of that time. After that, I'll ask for Rainer to submit a new ID. If needed, I'll also ask for Anton to submit a new ID. I'll allow a week of review on those. If we still see implementors willing to implement this then we will progress these to the IESG. Addtional comments below. On Fri, 25 Nov 2005, Rainer Gerhards wrote: > Tom, WG: > > Comments inline... > > Rainer > >> [tp] Strange, I was thiinking quite the opposite, that we had >> a fragile >> consensus which disappeared in >> Vancouver and has not been refound. Looking back at the >> messages posted in the >> past few days, about what should be in the header in what >> order, I was thinking, >> what now? because I see no consensus, rather the re-emergence of many >> different points of view. >> >> So while the proposed charter looks ok, because it does not >> go into that detail, >> I do not see how we progress any further, into the next level >> of technical >> detail, of what and >> how should be in the header. > > I agree that we have not found consensus again. However, I think we are > in a better shape on the details than it it might look. My personal view > is that many items are shortly before reaching actual consensus. Let me > sum up the items I see. We might use that as a potential basis for > reaching consensus. > > #1 testing and code review has shown that there is no point > in trying to preserve more than ; RFC 3164 provides > a false impression of common behaviour. > > This is controversal, but the facts are suggesting this is the way it > is. > We should try to reach consensus on this. 3164 was written based upon what Eric told me of how things originally worked. Obviously not much has stayed that way since. We can accept that things are received and placed in the right bins if a message has . I'm OK with keeping that and defining the rest of the message as long as we keep the free-form text which has been the basis of syslog for all of these years. > > #2 The max message length issue resurfaces. There seems to be a > fragile consensus that we can life with the compromise in > syslog-protocol and eventualy open a debate if we (ever) go to > a TCP transport. > > Again, controversal, too. > > #3 There is a question if NUL octets are to be supported in > the MSG content. > > No consensus yet. > > #4 There seems to be a fragile consensus that MSG should > primarily contain textual data, including XMLified content. > On the contrary, pure binary data should not be used. > > This is somewhat controversal. If we can agree that a natural language indicator (likely an SD-ID element) can be defined, then I believe that we are setting the stage so that future definitions may be made to allow for XML, binary, and perhaps even Martian. Those are outside of the current scope of the WG. Let's concentrate on transferring the textual information. > > #5 Character encoding in MSG: due to my proof-of-concept > implementation, I have raised the (ugly) question if we need > to allow encodings other than UTF-8. Please note that this > question arises from needs introduced by e.g. POSIX. So we > can't easily argue them away by whishful thinking ;) > > Not even discussed yet. I haven't reviewed that yet. However, I'll note that allowing different encoding can be accomplished in the future as long as we establish a default encoding and a way to identify it in our current work. > > #6 field order > > This is related to #1 and can, I think, quickly be fixed once #1 is > settled. Agreed. > > #7 Header fields: there seems to be a fragile consensus that > MSGID, PROCID, APP-NAME, and VERSION should be in the header > and TRUNCATE should not be in it. > > This needs to be finalized, but I think we are very close. Agreed. > > #8 MSG-octet counting and/or trailer is resurfacing. I think > this item is not well understood and well discussed. > > We need to discuss it. > > #9 I have found some minor items not already discussed during > my proof-of-concept implementation (like "drop requirements" > and such). These are not absolutely vital, but should be > considered before a final text is issued (or even the next > revision). > > This needs to be discussed. As it is new, I have no idea what the > discussion may lead to. Running code carries weight in our discussions. > > #10 STRUCTURED-DATA: there has been surprisingly few discussion > about STRUCTURED-DATA. I conclude that this is non-controversal. This appears to have been accepted by the community. This item is closed. Thanks, Chris > > The good thing is that more people (especially implementors) are > expressing themselfs on the list. This is what finally makes me feel > positive about finally reaching our goal. > > I think we can produce some useful documents if we manage to keep > discussing in the current paste. My whish would be that we focus more on > practical things in this discussion, especially when it comes to > compatibility with existing (deployed) technology. It does not help if > we theoretice things would be this and that when they are acutally > different - even though this "real world" is kind of dirty... > > Also, we should try to "fry the small fish" and not solve any need that > might surface. I would also like to see this group moving in a direction > that focusses on results usable in practice. I personally prefer a > solution that is 80% theoretically "clean" but has a 95% chance of > implementation over a 95% "clean" solution with just a low chance of > getting implemented (hint: RFC 3195). > > I am an IETF freshman. Anyhow, I often read that the IETF was driven by > "rough consensus and running code". I say "was", because my impression > is that this is no longer the case. I would prefer it were... > > If this WG fails, what probably happens is that some implementors stick > together and implement something that is pretty similar to what we have > right now (or totally different - who knows). Just as syslog/tcp is > implemented in this "industry-standard" way. The IETF does not like > plain tcp syslog. Guess what? No implementor or end user cares... ;) > This often-violently-objected transport mode has brought more security > and reliability to the syslog community than anything this group has > done the past years. And yes, it is true, plain tcp syslog as it is > deployed is far from being a clean solution. It's only plus is it > works... > > So I think it would be a very helpful if we manage to produce a standard > that solves the currently horrible syslog format scenario. But we need > one that gets implemented... > > Rainer > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Nov 26 16:25:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg7Xt-0002rI-De; Sat, 26 Nov 2005 16:25:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg7Xr-0002rC-TR for syslog@megatron.ietf.org; Sat, 26 Nov 2005 16:25:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27380 for ; Sat, 26 Nov 2005 16:24:38 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eg7rN-00089D-8Z for syslog@ietf.org; Sat, 26 Nov 2005 16:45:31 -0500 Received: from pc6 (1Cust15.tnt103.lnd4.gbr.da.uu.net [213.116.54.15]) by ranger.systems.pipex.net (Postfix) with SMTP id 59309E000191; Sat, 26 Nov 2005 21:24:52 +0000 (GMT) Message-ID: <012201c5f2c7$347abd80$0601a8c0@pc6> From: "Tom Petch" To: "Darren Reed" References: <200511261139.jAQBdQ8A027468@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Revised proposed charter Date: Sat, 26 Nov 2005 21:22:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Darren Reed" To: "Tom Petch" Cc: "Chris Lonvick" ; Sent: Saturday, November 26, 2005 12:39 PM Subject: Re: [Syslog] Revised proposed charter > [ Charset ISO-8859-1 unsupported, converting... ] > > Based on the discussions of the past few days, the one detail that I would add > > to the charter is about and backward compatability, something along the > > lines of > > > > While compatability with existing syslog systems is desirable, research shows > > that these are so diverse that there is nothing in common amongst them apart > > from so that whilst that field will be retained, other fields may not > > be. > > > > added to the paragraph on syslog protocol. > > Why ? The charter shouldn't be mentioning any specifics of the protocol(s) > that the group intends to work on. The charter should be as relatively > open ended as possible with respect to the actual specifics delivered. > > Darren I see it the other way round. If the charter can be specific, it should be, to keep the subsequent discussion focussed on the more contentious areas. Based on the post-Vancouver discussion, I see no alternative to including and if that is the case, then we should nail that down now. I am, implicitly, agreeing with Rainer's list of 10 items; if we can agree a charter, then the items he says need discussing are the ones we then focus on, leaving the rest of -15 unchanged.. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Nov 26 19:52:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgAmP-0001Lc-AY; Sat, 26 Nov 2005 19:52:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgAmO-0001LX-7x for syslog@megatron.ietf.org; Sat, 26 Nov 2005 19:52:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11213 for ; Sat, 26 Nov 2005 19:51:48 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgB5u-0004d2-9j for syslog@ietf.org; Sat, 26 Nov 2005 20:12:44 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAR0q4HB013254; Sun, 27 Nov 2005 11:52:04 +1100 (EST) From: Darren Reed Message-Id: <200511270051.jAR0pe6w001689@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Consensus? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F1C@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Sun, 27 Nov 2005 11:51:40 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer, I've put some comments about your list below. If you repost this, you might want to re-order ... there are a few dependencies within this list. > #1 testing and code review has shown that there is no point > in trying to preserve more than ; RFC 3164 provides > a false impression of common behaviour. > > This is controversal, but the facts are suggesting this is the way it > is. > We should try to reach consensus on this. A catch here is that extending the format to be: VERSION may produce unexpected results with various syslog daemons. > #2 The max message length issue resurfaces. There seems to be a > fragile consensus that we can life with the compromise in > syslog-protocol and eventualy open a debate if we (ever) go to > a TCP transport. > > Again, controversal, too. This should be defined by each of the syslog/transport documents. It shouldn't be documented in syslog-protocol because it is largely dependent on the implementation. > #3 There is a question if NUL octets are to be supported in > the MSG content. > > No consensus yet. Why not just use '\' as the escape character to quote any value outside of 32-126 ? Isn't this close enough to a defacto-standard to use? > #4 There seems to be a fragile consensus that MSG should > primarily contain textual data, including XMLified content. > On the contrary, pure binary data should not be used. > > This is somewhat controversal. I don't think this should be discussed. It's data that fits #3. End of story, as far as I'm concerned :) > #5 Character encoding in MSG: due to my proof-of-concept > implementation, I have raised the (ugly) question if we need > to allow encodings other than UTF-8. Please note that this > question arises from needs introduced by e.g. POSIX. So we > can't easily argue them away by whishful thinking ;) > > Not even discussed yet. This has implications for #3 & #4 and is possibly dependent on #10. > #6 field order > > This is related to #1 and can, I think, quickly be fixed once #1 is > settled. This needs the header fields (#7, #10) to be accepted, as well, before it can be settled. > #7 Header fields: there seems to be a fragile consensus that > MSGID, PROCID, APP-NAME, and VERSION should be in the header > and TRUNCATE should not be in it. > > This needs to be finalized, but I think we are very close. We should consider how to make them optional, too. > #8 MSG-octet counting and/or trailer is resurfacing. I think > this item is not well understood and well discussed. > > We need to discuss it. By trailer do you mean an End of Message (EOM) or EOR marker ? Or something else ? > #9 I have found some minor items not already discussed during > my proof-of-concept implementation (like "drop requirements" > and such). These are not absolutely vital, but should be > considered before a final text is issued (or even the next > revision). > > This needs to be discussed. As it is new, I have no idea what the > discussion may lead to. Are you referring to implementation details, here, with things like "drop requirements" ? If so, this is part of what would be a different document again, syslog-implementation. > #10 STRUCTURED-DATA: there has been surprisingly few discussion > about STRUCTURED-DATA. I conclude that this is non-controversal. Is this mean to be a header field? Examples posted, so far, suggest that it is. To explain that comment, I'm considering everything prior to MSG as a header. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Nov 26 19:55:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgAon-0001aU-Bh; Sat, 26 Nov 2005 19:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgAom-0001aI-41 for syslog@megatron.ietf.org; Sat, 26 Nov 2005 19:55:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11397 for ; Sat, 26 Nov 2005 19:54:17 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgB8K-0004gv-27 for syslog@ietf.org; Sat, 26 Nov 2005 20:15:13 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAR0scDY017399; Sun, 27 Nov 2005 11:54:38 +1100 (EST) From: Darren Reed Message-Id: <200511270054.jAR0sbhu008382@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Revised proposed charter In-Reply-To: <012201c5f2c7$347abd80$0601a8c0@pc6> To: Tom Petch Date: Sun, 27 Nov 2005 11:54:37 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > I see it the other way round. If the charter can be specific, it should > be, to keep the subsequent discussion focussed on the more contentious > areas. Based on the > post-Vancouver discussion, I see no alternative > to including and if that is the case, then we should nail that > down now. > > I am, implicitly, agreeing with Rainer's list of 10 items; if we can > agree a charter, then the items he says need discussing are the ones > we then focus on, leaving the rest of -15 unchanged.. We don't re-charter every time that there is a disagreement on focus, just when we need to change direction. Tieing the charter down to details will require us to change it when details change. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Nov 27 05:07:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgJRN-00081S-5M; Sun, 27 Nov 2005 05:07:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgJRK-00081D-9e for syslog@megatron.ietf.org; Sun, 27 Nov 2005 05:07:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23278 for ; Sun, 27 Nov 2005 05:06:40 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgJky-0006Cj-EB for syslog@ietf.org; Sun, 27 Nov 2005 05:27:40 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id CE4C89C00D; Sun, 27 Nov 2005 11:15:43 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05334-04; Sun, 27 Nov 2005 11:15:40 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 167369C00B; Sun, 27 Nov 2005 11:15:40 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #1 - RFC3164, was: Consensus? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Nov 2005 11:06:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F2A@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #1 - RFC3164, was: Consensus? Thread-Index: AcXy7NEbMw56AnLNQfuAc4lN08gwTwATLxIg From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, > > #1 testing and code review has shown that there is no point > > in trying to preserve more than ; RFC 3164 provides > > a false impression of common behaviour. > > =20 > > This is controversal, but the facts are suggesting this is=20 > the way it > > is. > > We should try to reach consensus on this. >=20 > A catch here is that extending the format to be: >=20 > VERSION >=20 > may produce unexpected results with various syslog daemons. Please let us know which actual syslog deamons you mean (at best with platform and version information). I would also appreciate if you could do a quick test with them and post the results. If possible, please send two messages to them. One as such: "<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8" the other one "<148>1 2003-10-11T22:14:15.003Z mymachine.example.com su 4711 MSGID - 'su root' failed for lonvick on /dev/pts/9" I would appreciate if you could let us know the resulting format both in log files as well as when relaying. Information about the extend of message distortion will probably help us to determine the importance of this issue. Many thanks, Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Nov 27 15:24:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgT49-0001zX-Pd; Sun, 27 Nov 2005 15:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgT48-0001yU-Es for syslog@megatron.ietf.org; Sun, 27 Nov 2005 15:24:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24604 for ; Sun, 27 Nov 2005 15:23:19 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgTNm-0008Fo-TY for syslog@ietf.org; Sun, 27 Nov 2005 15:44:27 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jARKNW3B015249; Mon, 28 Nov 2005 07:23:32 +1100 (EST) From: Darren Reed Message-Id: <200511272023.jARKN88Q015537@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #1 - RFC3164, was: Consensus? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F2A@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Mon, 28 Nov 2005 07:23:08 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Darren, .. > Please let us know which actual syslog deamons you mean (at best with > platform and version information). > > I would also appreciate if you could do a quick test with them and post > the results. If possible, please send two messages to them. One as such: > > "<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on > /dev/pts/8" > > the other one > > "<148>1 2003-10-11T22:14:15.003Z mymachine.example.com su 4711 MSGID - > 'su root' failed for lonvick on /dev/pts/9" > > I would appreciate if you could let us know the resulting format both in > log files as well as when relaying. > > Information about the extend of message distortion will probably help us > to determine the importance of this issue. Why not just read the source code ? Also, read down and observe what ^ is used for. This has been forgotten in RFC 3164... printline() { .. /* test for special codes */ pri = DEFUPRI; p = msg; if (*p == '<') { pri = 0; while (isdigit(*++p)) pri = 10 * pri + (*p - '0'); if (*p == '>') ++p; } if (pri &~ (LOG_FACMASK|LOG_PRIMASK)) pri = DEFUPRI; /* don't allow users to log kernel messages */ if (LOG_FAC(pri) == LOG_KERN) pri = LOG_MAKEPRI(LOG_USER, LOG_PRI(pri)); q = line; while ((c = *p++) != '\0' && q < &line[sizeof(line) - 2]) { c &= 0177; if (iscntrl(c)) if (c == '\n') *q++ = ' '; else if (c == '\t') *q++ = '\t'; else { *q++ = '^'; *q++ = c ^ 0100; } else *q++ = c; } *q = '\0'; logmsg(pri, line, hname, 0); } logmsg() { .. msglen = strlen(msg); if (msglen < 16 || msg[3] != ' ' || msg[6] != ' ' || msg[9] != ':' || msg[12] != ':' || msg[15] != ' ') flags |= ADDDATE; .. } On top of this, source code exists to map LF to "\n" and use the \377 format for non-ASCII characters. It would seem to me that some of our issues have been "solved" by some vendors that need to be wide-character set savvy... Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Nov 27 15:30:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgT9s-00035f-Ou; Sun, 27 Nov 2005 15:30:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgT9r-00035a-LQ for syslog@megatron.ietf.org; Sun, 27 Nov 2005 15:29:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25012 for ; Sun, 27 Nov 2005 15:29:15 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgTTb-0008QO-8w for syslog@ietf.org; Sun, 27 Nov 2005 15:50:23 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 2AD8E9C00D; Sun, 27 Nov 2005 21:38:31 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06025-09; Sun, 27 Nov 2005 21:38:27 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id A7D489C00B; Sun, 27 Nov 2005 21:38:27 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #1 - RFC3164, was: Consensus? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Nov 2005 21:29:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABAB69D@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #1 - RFC3164, was: Consensus? Thread-Index: AcXzkHf7+IZMaGMwTECeVbsWMOkBrwAAHjTQ From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, You are quoting out of context. I'v read the source - more than one (if you read more than one, you'll notice the subtle differences ;)). BTW: the ^ tells you that signatures are broken as soon as characters < 32 are included in the message. However, none of that relates to what you have state. The source you state is incomplete and if you look at everything (including forwarding rules) plus at different versions (e.g. sysklogd 1.4.1 in debian and syslogd.c in FreeBSD) date processing is different. So again, can you please tell me what backs your argument? Rainer > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Sunday, November 27, 2005 9:23 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] #1 - RFC3164, was: Consensus? >=20 >=20 > > Darren, > .. > > Please let us know which actual syslog deamons you mean (at=20 > best with=20 > > platform and version information). > >=20 > > I would also appreciate if you could do a quick test with them and=20 > > post the results. If possible, please send two messages to=20 > them. One=20 > > as such: > >=20 > > "<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on=20 > > /dev/pts/8" > >=20 > > the other one > >=20 > > "<148>1 2003-10-11T22:14:15.003Z mymachine.example.com su=20 > 4711 MSGID -=20 > > 'su root' failed for lonvick on /dev/pts/9" > >=20 > > I would appreciate if you could let us know the resulting=20 > format both=20 > > in log files as well as when relaying. > >=20 > > Information about the extend of message distortion will=20 > probably help=20 > > us to determine the importance of this issue. >=20 > Why not just read the source code ? >=20 > Also, read down and observe what ^ is used for. > This has been forgotten in RFC 3164... >=20 > printline() > { > .. > /* test for special codes */ > pri =3D DEFUPRI; > p =3D msg; > if (*p =3D=3D '<') { > pri =3D 0; > while (isdigit(*++p)) > pri =3D 10 * pri + (*p - '0'); > if (*p =3D=3D '>') > ++p; > } > if (pri &~ (LOG_FACMASK|LOG_PRIMASK)) > pri =3D DEFUPRI; >=20 > /* don't allow users to log kernel messages */ > if (LOG_FAC(pri) =3D=3D LOG_KERN) > pri =3D LOG_MAKEPRI(LOG_USER, LOG_PRI(pri)); >=20 > q =3D line; >=20 > while ((c =3D *p++) !=3D '\0' && > q < &line[sizeof(line) - 2]) { > c &=3D 0177; > if (iscntrl(c)) > if (c =3D=3D '\n') > *q++ =3D ' '; > else if (c =3D=3D '\t') > *q++ =3D '\t'; > else { > *q++ =3D '^'; > *q++ =3D c ^ 0100; > } > else > *q++ =3D c; > } > *q =3D '\0'; > =20 > logmsg(pri, line, hname, 0); > } >=20 > logmsg() > { > .. > msglen =3D strlen(msg);=20 > if (msglen < 16 || msg[3] !=3D ' ' || msg[6] !=3D ' ' || > msg[9] !=3D ':' || msg[12] !=3D ':' || msg[15] !=3D ' ') > flags |=3D ADDDATE; > .. > } >=20 > On top of this, source code exists to map LF to "\n" and use=20 > the \377 format for non-ASCII characters. >=20 > It would seem to me that some of our issues have been=20 > "solved" by some vendors that need to be wide-character set savvy... >=20 > Darren >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 28 10:34:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egl1t-0000Im-99; Mon, 28 Nov 2005 10:34:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egl1r-0000Id-8P for syslog@megatron.ietf.org; Mon, 28 Nov 2005 10:34:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20469 for ; Mon, 28 Nov 2005 10:34:10 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EglLj-0001is-Ic for syslog@ietf.org; Mon, 28 Nov 2005 10:55:29 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 28 Nov 2005 07:34:44 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jASFXssc023338; Mon, 28 Nov 2005 07:34:41 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 10:34:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Mon, 28 Nov 2005 10:34:34 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C859A6@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXw1q1oOeqNAjFkReuUMeRcHwChrAAARVrwAAG+8uAA1JUGIA== From: "Anton Okmianski \(aokmians\)" To: "Steve Chang \(schang99\)" , "Rainer Gerhards" , "Balazs Scheidler" X-OriginalArrivalTime: 28 Nov 2005 15:34:35.0562 (UTC) FILETIME=[3C8178A0:01C5F431] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org For whatever its worth... I ran a test on Solaris. It syslogd cuts off = message at the nul character, but handles the left part of it fine.=20 Thanks, Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Steve=20 > Chang (schang99) > Sent: Thursday, November 24, 2005 5:48 AM > To: Rainer Gerhards; Balazs Scheidler > Cc: syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 > Rainer: >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] > > On Behalf Of Rainer Gerhards > > Sent: Thursday, November 24, 2005 1:25 AM > > To: Balazs Scheidler > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] New direction and proposed charter > >=20 > > > On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > > > > Anton: > > > > > > > So I wonder if it wouldn't be wiser to accept that CLR here > > > and disallow > > > > NUL. After all, I can not see a valid use case for it > > > either... (in the > > > > sample you provided it honestly believe the sender should > > > not send a NUL > > > > octet but a "\u0000" string). > > > > > > > > > > \u0000 is a NUL octet at least in its canonical encoding. > >=20 > > OK, looks like I need to dig up the ASCII table. My fault I=20 > didn't do > it > > in the first place. > >=20 > > Anston's sample was > >=20 > > ...MyApp pid123 MALFORMED_INPUT: Bad input received from client: > > [aaa\u0000] > >=20 > > For simplicity, let me strip the rest and just look at that part > >=20 > > \u0000 > >=20 > > I think the sender of the sample message should not encode it as > >=20 > > NUL (0x00) > >=20 > > but instead as > >=20 > > 0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0) > >=20 > > Encoding it as NUL in an otherwise human-readable message makes no > sense > > to me. > >=20 >=20 > >From the perspective of formatting a piece of device=20 > internal raw data > into an outgoing syslog message and considering the CPU=20 > cycles needed to encode a NULL character into some other form=20 > to keep the whole MSG intact, I would say prepend the length=20 > of MSG (or say, add a fixed 4 digits byte length of the MSG=20 > between SD-IDs and MSG) will be much easier for the sender. =20 > With this, I think the new IETF syslog compliant receiver=20 > should also have easier time fetching in the complete MSG,=20 > regardless it's a plain text, XML-formated, or even binary data. > [** side note: a fixed 4 digit MSG length can handle up to 9999 bytes. > Big enough for foreseeable future. Also, the first MSG can be=20 > appended with other feature specific information before it=20 > gets sent out. And hence updating the final MSG length can be=20 > easier.]=20 >=20 > As to what will happen to the old syslog receivers receiving=20 > the message will NULL character? The message will probably=20 > be cut short right at reading the NULL character as you have=20 > explained. And I don't think there will be a good compromised=20 > solution for it.=20 >=20 > At the sender side, the overhead in checking for a NULL=20 > character in any of the incoming raw message and encode it to=20 > other form is just not practical. I would rather not have to=20 > pay that overhead if possible. > Besides, if mandated, you will be limiting how MSG is to be used. >=20 > I would say it should be sufficient to just explicitly point=20 > out the danger of having the NUL in the MSG part in the new=20 > IETF syslog protocol. > And you can be kind to add some suggestions as to how the=20 > syslog message initial sending device can choose to do to=20 > handle this situation themselves.=20 > Vendors should make their own decisions on this issue. >=20 > With this caveat, we get to keep the flexibility of having=20 > the MSG part in plain text, or in binary for the IETF syslog protocol. >=20 > It's tradeoff for WG to debate. >=20 >=20 > > I am questioning if there is any legitimate case where an=20 > actual NUL=20 > > needs to be part of MSG. > >=20 > > > UTF-8 allows > > > the same character to be encoded in multiple ways, see a=20 > description=20 > > > on the encoding format: > > > > > > http://www1.tip.nl/~t876506/utf8tbl.html > > > > > > And I think it would be wise to require the canonical=20 > encoding to be=20 > > > used and treat all other encodings of the same characters=20 > as errors. > > > this is a large can of worms, lot's of security problems=20 > arised from=20 > > > this issue. (see the IIS problems couple of years ago) > >=20 > > "Shortest possible form" thanksfully is already required in=20 > > syslog-protocol-15. > >=20 > > Rainer > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 28 10:59:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglPj-00066j-Gz; Mon, 28 Nov 2005 10:59:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglPi-00066e-2k for syslog@megatron.ietf.org; Mon, 28 Nov 2005 10:59:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23671 for ; Mon, 28 Nov 2005 10:58:49 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eglja-0002bq-LB for syslog@ietf.org; Mon, 28 Nov 2005 11:20:08 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 28 Nov 2005 07:59:23 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,385,1125903600"; d="scan'208"; a="16084814:sNHT26423720" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jASFwsmD020665; Mon, 28 Nov 2005 10:59:21 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 10:59:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New direction and proposed charter Date: Mon, 28 Nov 2005 10:59:17 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C859D6@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXw7XNdduIR7yZuShCOU8fOtRVIDQAOVDcgAAL5+/AAwEHlQA== From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" X-OriginalArrivalTime: 28 Nov 2005 15:59:18.0210 (UTC) FILETIME=[B03B9A20:01C5F434] X-Spam-Score: 1.1 (+) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer: They are valid use-cases. I believe Cisco IOS logs binary diagnostic = messages today, and for good reasons. I am not sure how they are encoded = (you can of course encode binary in ASCII). I am not fresh on details, = but it seems to be a valid use-case to me.=20 Is not it a problem if logging library has to allocate memory (for = possible character substitutions) and has to scan the message in search = of invalid characters to escape? When you are running out of memory and = are trying to log a critical message, this could be the difference = between being able to send it or not. =20 Thanks, Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Thursday, November 24, 2005 3:41 PM > Cc: syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 > Steve: >=20 > Sorry to be blunt: this is *faaaaaaaaaaar* bejond what we=20 > currently try to acomplish. I guess this should be defined in=20 > a smime to syslog mapping document. I am just a bit concerend=20 > about your proposed limit of > 9999 octets. I am not sure how much voice will fit into it... >=20 > Honestly - this is no payload for syslog. I also see no point=20 > in SNMP backup.=20 >=20 > Some people might find that some of the samples are actual=20 > valid use cases, and I may become convinced over time. But -=20 > to say it with Darren > - we have smaller fish to fry today ;) >=20 > I also do not find it very consistent to vote in a meeting=20 > for backwards compatibility and then ask on list for a syslog=20 > revolution... >=20 > Rainer >=20 > > -----Original Message----- > > From: Steve Chang (schang99) [mailto:schang99@cisco.com] > > Sent: Thursday, November 24, 2005 8:33 PM > > To: Rainer Gerhards; syslog@ietf.org > > Subject: RE: [Syslog] New direction and proposed charter > >=20 > > Rainer: > >=20 > > OK. Here are a few of my imagined uses of the MSG with=20 > mixed text and=20 > > binary data. > >=20 > > 1.) With the option to include binary data in the MSG, a new set of=20 > > diagnostic messages can include some system internal data structure > > values of concern for analysis. The beginning text in=20 > MSG will state > > detailed description of the following binary data structure > > values. With proper tools provided, the binary data structure > > values can be > > examined in great details at the receiving end. =20 > >=20 > > 2.) Or the MSG can be used to capture the original incoming packet=20 > > data > > detected containing certain pattern.=20 > >=20 > > 3.) We can also include some voice data (binary) in MSG for certain > > situations.=20 > >=20 > > 4.) It can become backup route for SNMP traps because it=20 > can now carry > > text and binary data in MSG. > >=20 > > The possible usage is basically up to device vendor's=20 > imaginations. =20 > > But if you only allow for text data because of the concern at hand=20 > > over NULL character, then the door is shut. > >=20 > > With potentially rich feature sets to be imagined and to come with=20 > > this binary-data-capable MSG, the syslog message receiver=20 > will have to=20 > > be upgraded to be able to enjoy the benefits. I will leave it to=20 > > sales/marketing people to convince the customers so NULL sensitive=20 > > syslog message receiver will not be in the way. > >=20 > >=20 > > Thanks, > >=20 > > Steve > >=20 > > > -----Original Message----- > > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] > > > On Behalf Of Rainer Gerhards > > > Sent: Thursday, November 24, 2005 3:50 AM > > > To: syslog@ietf.org > > > Subject: RE: [Syslog] New direction and proposed charter > > >=20 > > > Steve, > > >=20 > > > no reply, but a question very important to me. What do you > > consider a > > > valid use case for the US-ASCII NUL character inside MSG?=20 > If I had a=20 > > > good sample, I'd probably have a better time understanding > > why this is > > > important... > > >=20 > > > Rainer > > >=20 > > > On Thu, 2005-11-24 at 11:48, Steve Chang (schang99) wrote: > > > > Rainer: > > > > > > > > > -----Original Message----- > > > > > From: syslog-bounces@lists.ietf.org > > > > [mailto:syslog-bounces@lists.ietf.org] > > > > > On Behalf Of Rainer Gerhards > > > > > Sent: Thursday, November 24, 2005 1:25 AM > > > > > To: Balazs Scheidler > > > > > Cc: syslog@ietf.org > > > > > Subject: RE: [Syslog] New direction and proposed charter > > > > > > > > > > > On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > > > > > > > Anton: > > > > > > > > > > > > > So I wonder if it wouldn't be wiser to accept=20 > that CLR here > > > > > > and disallow > > > > > > > NUL. After all, I can not see a valid use case for it > > > > > > either... (in the > > > > > > > sample you provided it honestly believe the sender should > > > > > > not send a NUL > > > > > > > octet but a "\u0000" string). > > > > > > > > > > > > > > > > > > > \u0000 is a NUL octet at least in its canonical encoding. > > > > > > > > > > OK, looks like I need to dig up the ASCII table. My > > fault I didn't > > do > > > > it > > > > > in the first place. > > > > > > > > > > Anston's sample was > > > > > > > > > > ...MyApp pid123 MALFORMED_INPUT: Bad input received > > from client: > > > > > [aaa\u0000] > > > > > > > > > > For simplicity, let me strip the rest and just look=20 > at that part > > > > > > > > > > \u0000 > > > > > > > > > > I think the sender of the sample message should not=20 > encode it as > > > > > > > > > > NUL (0x00) > > > > > > > > > > but instead as > > > > > > > > > > 0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0) > > > > > > > > > > Encoding it as NUL in an otherwise human-readable > > message makes no > > > > sense > > > > > to me. > > > > > > > > > > > > > From the perspective of formatting a piece of device=20 > internal raw > > data > > > > into an outgoing syslog message and considering the CPU cycles > > needed to > > > > encode a NULL character into some other form to keep=20 > the whole MSG=20 > > > > intact, I would say prepend the length of MSG (or say, add a > > fixed 4 digits > > byte > > > > length of the MSG between SD-IDs and MSG) will be much=20 > easier for > > the > > > > sender. With this, I think the new IETF syslog=20 > compliant receiver=20 > > > > should also have easier time fetching in the complete MSG, > > regardless > > > > it's a plain text, XML-formated, or even binary data. > > > > [** side note: a fixed 4 digit MSG length can handle up to 9999 > > bytes. > > > > Big enough for foreseeable future. Also, the first MSG can be > > appended > > > > with other feature specific information before it gets > > sent out. And > > > > hence updating the final MSG length can be easier.] > > > > > > > > As to what will happen to the old syslog receivers receiving the > > message > > > > will NULL character? The message will probably be cut=20 > short right > > at > > > > reading the NULL character as you have explained. And I > > don't think > > > > there will be a good compromised solution for it. > > > > > > > > At the sender side, the overhead in checking for a NULL > > character in > > any > > > > of the incoming raw message and encode it to other form > > is just not > > > > practical. I would rather not have to pay that overhead > > if possible. > > > > Besides, if mandated, you will be limiting how MSG is=20 > to be used. > > > > > > > > I would say it should be sufficient to just explicitly > > point out the > > > > danger of having the NUL in the MSG part in the new IETF syslog=20 > > > > protocol. > > > > And you can be kind to add some suggestions as to how the syslog > > message > > > > initial sending device can choose to do to handle this=20 > situation=20 > > > > themselves. > > > > Vendors should make their own decisions on this issue. > > > > > > > > With this caveat, we get to keep the flexibility of=20 > having the MSG > > part > > > > in plain text, or in binary for the IETF syslog protocol. > > > > > > > > It's tradeoff for WG to debate. > > > > > > > > > > > > > I am questioning if there is any legitimate case=20 > where an actual > > NUL > > > > > needs to be part of MSG. > > > > > > > > > > > UTF-8 allows > > > > > > the same character to be encoded in multiple ways, see a=20 > > > > > > description on the encoding format: > > > > > > > > > > > > http://www1.tip.nl/~t876506/utf8tbl.html > > > > > > > > > > > > And I think it would be wise to require the=20 > canonical encoding > > to be > > > > > > used and treat all other encodings of the same characters as > > errors. > > > > > > this is a large can of worms, lot's of security > > problems arised > > from > > > > > > this issue. (see the IIS problems couple of years ago) > > > > > > > > > > "Shortest possible form" thanksfully is already required in=20 > > > > > syslog-protocol-15. > > > > > > > > > > Rainer > > > > > > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > Syslog@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 28 11:01:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglS3-0006qB-Pu; Mon, 28 Nov 2005 11:01:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglS2-0006q0-FH for syslog@megatron.ietf.org; Mon, 28 Nov 2005 11:01:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24036 for ; Mon, 28 Nov 2005 11:01:13 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egllu-0002hO-0o for syslog@ietf.org; Mon, 28 Nov 2005 11:22:32 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 28 Nov 2005 08:01:47 -0800 X-IronPort-AV: i="3.97,385,1125903600"; d="scan'208"; a="370984603:sNHT25203648" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jASG1BsS005382; Mon, 28 Nov 2005 08:01:43 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 11:01:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Null character Date: Mon, 28 Nov 2005 11:01:33 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C859DA@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Null character Thread-Index: AcXxSz90SvJnFNklQuSgTwEVCmhQMgC6bBtQ From: "Anton Okmianski \(aokmians\)" To: "Darren Reed" , X-OriginalArrivalTime: 28 Nov 2005 16:01:34.0088 (UTC) FILETIME=[0138F080:01C5F435] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sounds like a CLR is becoming a CBR (crappy bigger rule)...=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Thursday, November 24, 2005 6:00 PM > To: andrew@kiwisyslog.com > Cc: syslog@ietf.org > Subject: Re: [Syslog] Null character >=20 > >=20 > > Rainer, > >=20 > > FWIIW, I've seen Netscreen, NetGear and some LinkSys devices send a=20 > > Null character at the end of each message. Not all versions of the=20 > > firmware would include the Null at the end which leads me=20 > to believe=20 > > it may be a bug in some releases of the firmware. > >=20 > > When sending syslog over TCP, Netscreen firewalls will delimit each=20 > > message with LF NULL. > >=20 > > This probably won't have any impact on the 'CLR' since it=20 > is the very=20 > > last character in the message, but I thought I would raise=20 > the issue=20 > > with you as a real-life case of a Null character being used. >=20 > Buggy software does not equate to a "real-life case". >=20 > But to judge whether or not it is a bug requires knowing what=20 > their protocol spec is. >=20 > In this case, it is a delimeter and that is not something=20 > that requires escaping. In fact, it would be a bug to escape=20 > it if it were being used in this manner. >=20 > Darren >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 28 11:30:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eglta-0006R8-2x; Mon, 28 Nov 2005 11:30:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgltY-0006Pq-1T for syslog@megatron.ietf.org; Mon, 28 Nov 2005 11:30:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27317 for ; Mon, 28 Nov 2005 11:29:39 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgmDR-0003gC-3E for syslog@ietf.org; Mon, 28 Nov 2005 11:50:58 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 28 Nov 2005 08:30:01 -0800 X-IronPort-AV: i="3.97,385,1125903600"; d="scan'208"; a="371002330:sNHT2106807122" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jASGTuCV006068; Mon, 28 Nov 2005 08:30:00 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 11:29:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Revised proposed charter Date: Mon, 28 Nov 2005 11:29:41 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C859FE@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] Revised proposed charter Thread-Index: AcXydXI6iLiADDGfS8aoiRMJy4zipwBwn4Cg From: "Anton Okmianski \(aokmians\)" To: "Tom Petch" , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 28 Nov 2005 16:29:42.0176 (UTC) FILETIME=[EF66BA00:01C5F438] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I support this clarification. =20 Anton.=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Saturday, November 26, 2005 4:23 AM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: Re: [Syslog] Revised proposed charter >=20 > Based on the discussions of the past few days, the one detail=20 > that I would add to the charter is about and backward=20 > compatability, something along the lines of >=20 > While compatability with existing syslog systems is=20 > desirable, research shows that these are so diverse that=20 > there is nothing in common amongst them apart from so=20 > that whilst that field will be retained, other fields may not be. >=20 > added to the paragraph on syslog protocol. >=20 > And yes, IESG and the ietf list will doubtless want to know=20 > why we regard that as acceptable. >=20 > Tom Petch > ----- Original Message ----- > From: "Chris Lonvick" > To: > Sent: Wednesday, November 23, 2005 6:05 PM > Subject: [Syslog] Revised proposed charter >=20 >=20 > > Hi All, > > > > =3D=3D=3D=3D v2 of proposed charter =3D=3D=3D > > > > Syslog is a de-facto standard for logging system events. =20 > However, the=20 > > protocol component of this event logging system has not=20 > been formally=20 > > documented. While the protocol has been very useful and=20 > scalable, it=20 > > has some known security problems which were documented in RFC 3164. > > > > The goal of this working group is to address the security and=20 > > integrity problems, and to standardize the syslog protocol,=20 > transport,=20 > > and a select set of mechanisms in a manner that considers=20 > the ease of=20 > > migration between and the co-existence of existing versions=20 > and the standard. > > > > syslog has traditionally been transported over UDP and this WG has=20 > > already defined RFC 3195 for the reliable transport for the syslog=20 > > messages. The WG will separate the UDP transport from the=20 > protocol so=20 > > that others may define additional transports in the future. > > > > > > - A document will be produced that describes a standardized syslog=20 > > protocol. A mechanism will also be defined in this=20 > document that will=20 > > provide a means to convey structured data. > > > > - A document will be produced that describes a standardized UDP=20 > > transport for syslog. > > > > - A document will be produced that describes a standardized=20 > mechanism=20 > > to sign syslog messages to provide integrity checking and source=20 > > authentication. > > > > > > =3D=3D=3D =3D=3D=3D > > > > Comments please. > > > > Thanks, > > Chris > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 28 11:40:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egm3g-0000Kg-LR; Mon, 28 Nov 2005 11:40:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egm3f-0000Kb-CR for syslog@megatron.ietf.org; Mon, 28 Nov 2005 11:40:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28556 for ; Mon, 28 Nov 2005 11:40:06 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgmNY-000407-Jq for syslog@ietf.org; Mon, 28 Nov 2005 12:01:26 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Nov 2005 08:40:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,385,1125903600"; d="scan'208"; a="16088651:sNHT24426300" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jASGeWdv020642; Mon, 28 Nov 2005 11:40:37 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 11:40:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #1 - RFC3164, was: Consensus? Date: Mon, 28 Nov 2005 11:40:32 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C85A0F@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] #1 - RFC3164, was: Consensus? Thread-Index: AcXzkLoInLWrKVdoQeC+4iyRgdJlzgAqVRQA From: "Anton Okmianski \(aokmians\)" To: "Darren Reed" , "Rainer Gerhards" X-OriginalArrivalTime: 28 Nov 2005 16:40:33.0382 (UTC) FILETIME=[738CE060:01C5F43A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Which system is this source from?=20 On Solaris, if you send \r\n characters, you will see "^M\n" in the log. = Anton.=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Sunday, November 27, 2005 3:23 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] #1 - RFC3164, was: Consensus? >=20 > > Darren, > .. > > Please let us know which actual syslog deamons you mean (at=20 > best with=20 > > platform and version information). > >=20 > > I would also appreciate if you could do a quick test with them and=20 > > post the results. If possible, please send two messages to=20 > them. One as such: > >=20 > > "<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on=20 > > /dev/pts/8" > >=20 > > the other one > >=20 > > "<148>1 2003-10-11T22:14:15.003Z mymachine.example.com su=20 > 4711 MSGID -=20 > > 'su root' failed for lonvick on /dev/pts/9" > >=20 > > I would appreciate if you could let us know the resulting=20 > format both=20 > > in log files as well as when relaying. > >=20 > > Information about the extend of message distortion will=20 > probably help=20 > > us to determine the importance of this issue. >=20 > Why not just read the source code ? >=20 > Also, read down and observe what ^ is used for. > This has been forgotten in RFC 3164... >=20 > printline() > { > .. > /* test for special codes */ > pri =3D DEFUPRI; > p =3D msg; > if (*p =3D=3D '<') { > pri =3D 0; > while (isdigit(*++p)) > pri =3D 10 * pri + (*p - '0'); > if (*p =3D=3D '>') > ++p; > } > if (pri &~ (LOG_FACMASK|LOG_PRIMASK)) > pri =3D DEFUPRI; >=20 > /* don't allow users to log kernel messages */ > if (LOG_FAC(pri) =3D=3D LOG_KERN) > pri =3D LOG_MAKEPRI(LOG_USER, LOG_PRI(pri)); >=20 > q =3D line; >=20 > while ((c =3D *p++) !=3D '\0' && > q < &line[sizeof(line) - 2]) { > c &=3D 0177; > if (iscntrl(c)) > if (c =3D=3D '\n') > *q++ =3D ' '; > else if (c =3D=3D '\t') > *q++ =3D '\t'; > else { > *q++ =3D '^'; > *q++ =3D c ^ 0100; > } > else > *q++ =3D c; > } > *q =3D '\0'; > =20 > logmsg(pri, line, hname, 0); > } >=20 > logmsg() > { > .. > msglen =3D strlen(msg);=20 > if (msglen < 16 || msg[3] !=3D ' ' || msg[6] !=3D ' ' || > msg[9] !=3D ':' || msg[12] !=3D ':' || msg[15] !=3D ' ') > flags |=3D ADDDATE; > .. > } >=20 > On top of this, source code exists to map LF to "\n" and use the > \377 format for non-ASCII characters. >=20 > It would seem to me that some of our issues have been=20 > "solved" by some vendors that need to be wide-character set savvy... >=20 > Darren >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 28 13:58:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgoCv-0008Dz-T2; Mon, 28 Nov 2005 13:58:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgoCu-0008Dj-IF for syslog@megatron.ietf.org; Mon, 28 Nov 2005 13:58:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20540 for ; Mon, 28 Nov 2005 13:57:48 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgoWo-0002PC-S8 for syslog@ietf.org; Mon, 28 Nov 2005 14:19:08 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id B97D99C00B; Mon, 28 Nov 2005 20:07:11 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07161-01; Mon, 28 Nov 2005 20:07:07 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id E0AC59C00C; Mon, 28 Nov 2005 20:07:06 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] New direction and proposed charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Nov 2005 19:58:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABAB6A3@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] New direction and proposed charter Thread-Index: AcXw7XNdduIR7yZuShCOU8fOtRVIDQAOVDcgAAL5+/AAwEHlQAAGZseQ From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton: If we agree this is a valid use case, then we must reconsider the UTF-8 requirement/recommendation. Because binary data will not result in proper UTF-8 encoding. I have to admit that I strongly doubt this is something that should be in syslog-protocol - maybe something for a later add-on using structured data (base-64 encoded binary structured-data would be an option)... Please also check my implementation report on other difficulties with UTF-8 encoding, only. Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Monday, November 28, 2005 4:59 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter >=20 >=20 > Rainer: >=20 > They are valid use-cases. I believe Cisco IOS logs binary=20 > diagnostic messages today, and for good reasons. I am not=20 > sure how they are encoded (you can of course encode binary in=20 > ASCII). I am not fresh on details, but it seems to be a valid=20 > use-case to me.=20 >=20 > Is not it a problem if logging library has to allocate memory=20 > (for possible character substitutions) and has to scan the=20 > message in search of invalid characters to escape? When you=20 > are running out of memory and are trying to log a critical=20 > message, this could be the difference between being able to=20 > send it or not. =20 >=20 > Thanks, > Anton. =20 >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Thursday, November 24, 2005 3:41 PM > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] New direction and proposed charter > >=20 > > Steve: > >=20 > > Sorry to be blunt: this is *faaaaaaaaaaar* bejond what we > > currently try to acomplish. I guess this should be defined in=20 > > a smime to syslog mapping document. I am just a bit concerend=20 > > about your proposed limit of > > 9999 octets. I am not sure how much voice will fit into it... > >=20 > > Honestly - this is no payload for syslog. I also see no point > > in SNMP backup.=20 > >=20 > > Some people might find that some of the samples are actual > > valid use cases, and I may become convinced over time. But -=20 > > to say it with Darren > > - we have smaller fish to fry today ;) > >=20 > > I also do not find it very consistent to vote in a meeting > > for backwards compatibility and then ask on list for a syslog=20 > > revolution... > >=20 > > Rainer > >=20 > > > -----Original Message----- > > > From: Steve Chang (schang99) [mailto:schang99@cisco.com] > > > Sent: Thursday, November 24, 2005 8:33 PM > > > To: Rainer Gerhards; syslog@ietf.org > > > Subject: RE: [Syslog] New direction and proposed charter > > >=20 > > > Rainer: > > >=20 > > > OK. Here are a few of my imagined uses of the MSG with > > mixed text and > > > binary data. > > >=20 > > > 1.) With the option to include binary data in the MSG, a=20 > new set of > > > diagnostic messages can include some system internal data=20 > structure > > > values of concern for analysis. The beginning text in=20 > > MSG will state > > > detailed description of the following binary data structure > > > values. With proper tools provided, the binary data structure > > > values can be > > > examined in great details at the receiving end. > > >=20 > > > 2.) Or the MSG can be used to capture the original incoming packet > > > data > > > detected containing certain pattern.=20 > > >=20 > > > 3.) We can also include some voice data (binary) in MSG=20 > for certain > > > situations. > > >=20 > > > 4.) It can become backup route for SNMP traps because it > > can now carry > > > text and binary data in MSG. > > >=20 > > > The possible usage is basically up to device vendor's > > imaginations. > > > But if you only allow for text data because of the concern at hand > > > over NULL character, then the door is shut. > > >=20 > > > With potentially rich feature sets to be imagined and to come with > > > this binary-data-capable MSG, the syslog message receiver=20 > > will have to > > > be upgraded to be able to enjoy the benefits. I will leave it to > > > sales/marketing people to convince the customers so NULL=20 > sensitive=20 > > > syslog message receiver will not be in the way. > > >=20 > > >=20 > > > Thanks, > > >=20 > > > Steve > > >=20 > > > > -----Original Message----- > > > > From: syslog-bounces@lists.ietf.org > > > [mailto:syslog-bounces@lists.ietf.org] > > > > On Behalf Of Rainer Gerhards > > > > Sent: Thursday, November 24, 2005 3:50 AM > > > > To: syslog@ietf.org > > > > Subject: RE: [Syslog] New direction and proposed charter > > > >=20 > > > > Steve, > > > >=20 > > > > no reply, but a question very important to me. What do you > > > consider a > > > > valid use case for the US-ASCII NUL character inside MSG? > > If I had a > > > > good sample, I'd probably have a better time understanding > > > why this is > > > > important... > > > >=20 > > > > Rainer > > > >=20 > > > > On Thu, 2005-11-24 at 11:48, Steve Chang (schang99) wrote: > > > > > Rainer: > > > > > > > > > > > -----Original Message----- > > > > > > From: syslog-bounces@lists.ietf.org > > > > > [mailto:syslog-bounces@lists.ietf.org] > > > > > > On Behalf Of Rainer Gerhards > > > > > > Sent: Thursday, November 24, 2005 1:25 AM > > > > > > To: Balazs Scheidler > > > > > > Cc: syslog@ietf.org > > > > > > Subject: RE: [Syslog] New direction and proposed charter > > > > > > > > > > > > > On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > > > > > > > > Anton: > > > > > > > > > > > > > > > So I wonder if it wouldn't be wiser to accept > > that CLR here > > > > > > > and disallow > > > > > > > > NUL. After all, I can not see a valid use case for it > > > > > > > either... (in the > > > > > > > > sample you provided it honestly believe the=20 > sender should > > > > > > > not send a NUL > > > > > > > > octet but a "\u0000" string). > > > > > > > > > > > > > > > > > > > > > > \u0000 is a NUL octet at least in its canonical encoding. > > > > > > > > > > > > OK, looks like I need to dig up the ASCII table. My > > > fault I didn't > > > do > > > > > it > > > > > > in the first place. > > > > > > > > > > > > Anston's sample was > > > > > > > > > > > > ...MyApp pid123 MALFORMED_INPUT: Bad input received > > > from client: > > > > > > [aaa\u0000] > > > > > > > > > > > > For simplicity, let me strip the rest and just look > > at that part > > > > > > > > > > > > \u0000 > > > > > > > > > > > > I think the sender of the sample message should not > > encode it as > > > > > > > > > > > > NUL (0x00) > > > > > > > > > > > > but instead as > > > > > > > > > > > > 0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0) > > > > > > > > > > > > Encoding it as NUL in an otherwise human-readable > > > message makes no > > > > > sense > > > > > > to me. > > > > > > > > > > > > > > > > From the perspective of formatting a piece of device > > internal raw > > > data > > > > > into an outgoing syslog message and considering the CPU cycles > > > needed to > > > > > encode a NULL character into some other form to keep > > the whole MSG > > > > > intact, I would say prepend the length of MSG (or say, add a > > > fixed 4 digits > > > byte > > > > > length of the MSG between SD-IDs and MSG) will be much > > easier for > > > the > > > > > sender. With this, I think the new IETF syslog > > compliant receiver > > > > > should also have easier time fetching in the complete MSG, > > > regardless > > > > > it's a plain text, XML-formated, or even binary data. > > > > > [** side note: a fixed 4 digit MSG length can handle=20 > up to 9999 > > > bytes. > > > > > Big enough for foreseeable future. Also, the first MSG can be > > > appended > > > > > with other feature specific information before it gets > > > sent out. And > > > > > hence updating the final MSG length can be easier.] > > > > > > > > > > As to what will happen to the old syslog receivers=20 > receiving the > > > message > > > > > will NULL character? The message will probably be cut > > short right > > > at > > > > > reading the NULL character as you have explained. And I > > > don't think > > > > > there will be a good compromised solution for it. > > > > > > > > > > At the sender side, the overhead in checking for a NULL > > > character in > > > any > > > > > of the incoming raw message and encode it to other form > > > is just not > > > > > practical. I would rather not have to pay that overhead > > > if possible. > > > > > Besides, if mandated, you will be limiting how MSG is > > to be used. > > > > > > > > > > I would say it should be sufficient to just explicitly > > > point out the > > > > > danger of having the NUL in the MSG part in the new=20 > IETF syslog > > > > > protocol. > > > > > And you can be kind to add some suggestions as to how=20 > the syslog > > > message > > > > > initial sending device can choose to do to handle this > > situation > > > > > themselves. > > > > > Vendors should make their own decisions on this issue. > > > > > > > > > > With this caveat, we get to keep the flexibility of > > having the MSG > > > part > > > > > in plain text, or in binary for the IETF syslog protocol. > > > > > > > > > > It's tradeoff for WG to debate. > > > > > > > > > > > > > > > > I am questioning if there is any legitimate case > > where an actual > > > NUL > > > > > > needs to be part of MSG. > > > > > > > > > > > > > UTF-8 allows > > > > > > > the same character to be encoded in multiple ways, see a > > > > > > > description on the encoding format: > > > > > > > > > > > > > > http://www1.tip.nl/~t876506/utf8tbl.html > > > > > > > > > > > > > > And I think it would be wise to require the > > canonical encoding > > > to be > > > > > > > used and treat all other encodings of the same=20 > characters as > > > errors. > > > > > > > this is a large can of worms, lot's of security > > > problems arised > > > from > > > > > > > this issue. (see the IIS problems couple of years ago) > > > > > > > > > > > > "Shortest possible form" thanksfully is already required in > > > > > > syslog-protocol-15. > > > > > > > > > > > > Rainer > > > > > > > > > > > > _______________________________________________ > > > > > > Syslog mailing list > > > > > > Syslog@lists.ietf.org=20 > > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org=20 > > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 01:39:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egz9N-0001to-SC; Tue, 29 Nov 2005 01:39:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egz9M-0001sR-Rd for syslog@megatron.ietf.org; Tue, 29 Nov 2005 01:39:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20430 for ; Tue, 29 Nov 2005 01:38:52 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgzTL-0006VU-Rq for syslog@ietf.org; Tue, 29 Nov 2005 02:00:18 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAT6dEhv022694; Tue, 29 Nov 2005 17:39:14 +1100 (EST) From: Darren Reed Message-Id: <200511290638.jAT6cq42020393@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #1 - RFC3164, was: Consensus? In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122C85A0F@xmb-rtp-20d.amer.cisco.com> To: "Anton Okmianski (aokmians)" Date: Tue, 29 Nov 2005 17:38:52 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org [ Charset ISO-8859-1 unsupported, converting... ] > Which system is this source from? BSD > On Solaris, if you send \r\n characters, you will see "^M\n" in the log. Yes and Solaris allows for non-ascii data through the use of escaping. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 06:35:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh3lf-0001Yv-3T; Tue, 29 Nov 2005 06:35:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh3ld-0001Yq-L9 for syslog@megatron.ietf.org; Tue, 29 Nov 2005 06:35:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21152 for ; Tue, 29 Nov 2005 06:34:40 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh45g-0007sz-DV for syslog@ietf.org; Tue, 29 Nov 2005 06:56:10 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id F3F659C00C; Tue, 29 Nov 2005 12:43:53 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07639-09; Tue, 29 Nov 2005 12:43:46 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 0D81C9C00B; Tue, 29 Nov 2005 12:43:46 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #1 - RFC3164, was: Consensus? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Nov 2005 12:34:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F48@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #1 - RFC3164, was: Consensus? Thread-Index: AcX0r8tgXrG2hdGHRNKKZT6qo0kveQAJ+7dg From: "Rainer Gerhards" To: "Darren Reed" , "Anton Okmianski (aokmians)" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren & WG: I have used this morning to compile a short list of currently existing and deployed syslogds. As I suggested, I have sent several messages to them. I suggest you have a look at the results at http://www.syslog.cc/ietf/existing-syslog.html I do not see much in that result backing the theory that retaining the old-style timestamp would do any good. Maybe I am overlooking the obvious, so you can point me. Ah, yes: Of course I see that sometimes the 3164 timestamp survives in the first column of the log entry where the -protocol formatted does not. But when I look at relaying, I think it is far better to have the timestamp replaced by the time of reception than to have it throw away. In most cases, digital signatures would be borken anyhow. Surprisingly, the -protocol formatted message has a better chance to survive being relayed by existing syslogd than the RFC 3164 formatted message. I propose that we accept this testing as proof of irrelevance of sticking with the rfc 3164 timestamp. Anybody with a different view please object. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Tuesday, November 29, 2005 7:39 AM > To: Anton Okmianski (aokmians) > Cc: syslog@ietf.org > Subject: Re: [Syslog] #1 - RFC3164, was: Consensus? >=20 > [ Charset ISO-8859-1 unsupported, converting... ] > > Which system is this source from?=20 >=20 > BSD >=20 > > On Solaris, if you send \r\n characters, you will see=20 > "^M\n" in the log.=20 >=20 > Yes and Solaris allows for non-ascii data through the use of escaping. >=20 > Darren >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 11:27:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8K0-0007vT-2U; Tue, 29 Nov 2005 11:27:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8Jz-0007vO-3A for syslog@megatron.ietf.org; Tue, 29 Nov 2005 11:27:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28585 for ; Tue, 29 Nov 2005 11:26:25 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh8e4-0001cr-TW for syslog@ietf.org; Tue, 29 Nov 2005 11:47:58 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id C94969C00C for ; Tue, 29 Nov 2005 17:35:55 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08174-05 for ; Tue, 29 Nov 2005 17:35:51 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 0914B9C00B for ; Tue, 29 Nov 2005 17:35:51 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 29 Nov 2005 17:26:38 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F4D@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcXyuPo2sNCIig3uRNCs82ECmHzrnACOBjow From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris & WG, > > #5 Character encoding in MSG: due to my proof-of-concept > > implementation, I have raised the (ugly) question if we need > > to allow encodings other than UTF-8. Please note that this > > question arises from needs introduced by e.g. POSIX. So we > > can't easily argue them away by whishful thinking ;) > > > > Not even discussed yet. >=20 > I haven't reviewed that yet. However, I'll note that=20 > allowing different=20 > encoding can be accomplished in the future as long as we establish a=20 > default encoding and a way to identify it in our current work. I have read a little in the mailing archive. Please note that in 2000 it was consensus that the MSG part may contain encodings other then US-ASCII. Follow this threat: http://www.syslog.cc/ietf/autoarc/msg00127.html This discussion lead to RFC 3164 saying "other encodings MAY be used". While this was observed behaviour, we need still to be aware that the POSIX (and glibc) API places the restrictions on us that we simply do not know the character encoding used by the application. As such, no *nix syslogd can be programmed to be compliant to syslog-protocol if we demand UTF-8 exclusively. I propose that we RECOMMEND UTF-8 that MUST start with the Unicode Byte Order Mask (BOM) if used. If the MSG part does not start with the BOM, it may be any encoding just as in RFC 3164. I do not see any alternative to this. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 12:13:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh939-0002BE-VZ; Tue, 29 Nov 2005 12:13:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh92x-00027h-A8 for syslog@megatron.ietf.org; Tue, 29 Nov 2005 12:13:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05601 for ; Tue, 29 Nov 2005 12:12:53 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh9N4-0003bR-92 for syslog@ietf.org; Tue, 29 Nov 2005 12:34:26 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 9A6A49C00C for ; Tue, 29 Nov 2005 18:22:25 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08246-09 for ; Tue, 29 Nov 2005 18:22:22 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 01FF29C00B for ; Tue, 29 Nov 2005 18:22:21 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 29 Nov 2005 18:13:42 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F53@grfint2.intern.adiscon.com> Thread-Topic: Consensus on Charter? Thread-Index: AcX1CD/Lc5uZxXHvT2Oac63XOuQSBA== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] Consensus on Charter? X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, WG: as you are probably aware, Sam's deadline for comments about the future of this WG is quickly approaching (it is December, 1st). I plan to formally update my comment. To do so, I would like to know if we have reached consensus on the charter. I have taken the liberty to merge some changes discussed on-list into v2 of Chris' charter proposal. Is this the charter we are looking for? I would appreciate quick feedback because I have to write my mail to Sam tomorrow. Rainer =3D=3D=3D=3D MODIFIED Version of Chris's v2 of proposed charter = =3D=3D=3D Syslog is a de-facto standard for logging system events. However, the=20 protocol component of this event logging system has not been formally=20 documented. While the protocol has been very useful and scalable, it has=20 some known security problems which were documented in RFC 3164. The goal of this working group is to address the security and integrity=20 problems, and to standardize the syslog protocol, transport, and a select=20 set of mechanisms in a manner that considers the ease of migration between=20 and the co-existence of existing versions and the standard. syslog has traditionally been transported over UDP and this WG has already=20 defined RFC 3195 for the reliable transport for the syslog messages. The=20 WG will separate the UDP transport from the protocol so that others may=20 define additional transports in the future. - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. While compatability with existing syslog systems is desirable, research shows that these are so diverse that there is nothing in common amongst them apart from so that whilst that field will be retained, other fields may not be. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. - A MIB definition for syslog will be produced. =3D=3D=3D =3D=3D=3D _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 12:41:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh9Tm-0000xs-CL; Tue, 29 Nov 2005 12:41:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh9Tk-0000v6-P2 for syslog@megatron.ietf.org; Tue, 29 Nov 2005 12:41:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10153 for ; Tue, 29 Nov 2005 12:40:35 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh9ns-0004uv-9h for syslog@ietf.org; Tue, 29 Nov 2005 13:02:08 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 29 Nov 2005 09:41:11 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jATHf9eT014322; Tue, 29 Nov 2005 09:41:10 -0800 (PST) Date: Tue, 29 Nov 2005 09:41:09 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: Re: [Syslog] Consensus on Charter? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F53@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3F53@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, I've already sent my comments to Sam including the v2 of the charter. I'm still waiting on feedback from him. The proposed charter below looks good. Please do send your comments to him. As he said, it's good to send them to the WG list as well. Thanks, Chris On Tue, 29 Nov 2005, Rainer Gerhards wrote: > Chris, WG: > > as you are probably aware, Sam's deadline for comments about the future > of this WG is quickly approaching (it is December, 1st). I plan to > formally update my comment. To do so, I would like to know if we have > reached consensus on the charter. > > I have taken the liberty to merge some changes discussed on-list into v2 > of Chris' charter proposal. > > Is this the charter we are looking for? I would appreciate quick > feedback because I have to write my mail to Sam tomorrow. > > Rainer > > ==== MODIFIED Version of Chris's v2 of proposed charter === > > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it > has > some known security problems which were documented in RFC 3164. > > The goal of this working group is to address the security and integrity > problems, and to standardize the syslog protocol, transport, and a > select > set of mechanisms in a manner that considers the ease of migration > between > and the co-existence of existing versions and the standard. > > syslog has traditionally been transported over UDP and this WG has > already > defined RFC 3195 for the reliable transport for the syslog messages. > The > WG will separate the UDP transport from the protocol so that others may > define additional transports in the future. > > > - A document will be produced that describes a standardized syslog > protocol. A mechanism will also be defined in this document > that will provide a means to convey structured data. While compatability > with existing syslog systems is desirable, research shows > that these are so diverse that there is nothing in common amongst them > apart > from so that whilst that field will be retained, other fields may > not be. > > - A document will be produced that describes a standardized UDP > transport for syslog. > > - A document will be produced that describes a standardized mechanism > to sign syslog messages to provide integrity checking and source > authentication. > > - A MIB definition for syslog will be produced. > === === > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 13:22:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhA7m-0003Xx-IO; Tue, 29 Nov 2005 13:22:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhA7k-0003Xs-GN for syslog@megatron.ietf.org; Tue, 29 Nov 2005 13:22:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15336 for ; Tue, 29 Nov 2005 13:21:54 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhARr-0006SK-4o for syslog@ietf.org; Tue, 29 Nov 2005 13:43:28 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 29 Nov 2005 10:22:30 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jATIMSs3012424; Tue, 29 Nov 2005 10:22:28 -0800 (PST) Date: Tue, 29 Nov 2005 10:22:28 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F4D@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3F4D@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, Why don't we look at it from the other direction? We could state that any encoding is acceptable - for ease-of-use/migration with existing syslog implementations. It is RECOMMENDED that UTF-8 be used. When it is used, an SD-ID element will be REQUIRED. e.g. - [enc="utf-8" lang="en"] Thoughts? All: Let's discuss this and close this issue. Thanks, Chris On Tue, 29 Nov 2005, Rainer Gerhards wrote: > Chris & WG, > >>> #5 Character encoding in MSG: due to my proof-of-concept >>> implementation, I have raised the (ugly) question if we need >>> to allow encodings other than UTF-8. Please note that this >>> question arises from needs introduced by e.g. POSIX. So we >>> can't easily argue them away by whishful thinking ;) >>> >>> Not even discussed yet. >> >> I haven't reviewed that yet. However, I'll note that >> allowing different >> encoding can be accomplished in the future as long as we establish a >> default encoding and a way to identify it in our current work. > > I have read a little in the mailing archive. Please note that in 2000 it > was consensus that the MSG part may contain encodings other then > US-ASCII. Follow this threat: > > http://www.syslog.cc/ietf/autoarc/msg00127.html > > This discussion lead to RFC 3164 saying "other encodings MAY be used". > While this was observed behaviour, we need still to be aware that the > POSIX (and glibc) API places the restrictions on us that we simply do > not know the character encoding used by the application. As such, no > *nix syslogd can be programmed to be compliant to syslog-protocol if we > demand UTF-8 exclusively. > > I propose that we RECOMMEND UTF-8 that MUST start with the Unicode Byte > Order Mask (BOM) if used. If the MSG part does not start with the BOM, > it may be any encoding just as in RFC 3164. I do not see any alternative > to this. > > Rainer > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 13:45:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhATr-00089r-HN; Tue, 29 Nov 2005 13:45:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhATq-00088n-7L for syslog@megatron.ietf.org; Tue, 29 Nov 2005 13:45:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18474 for ; Tue, 29 Nov 2005 13:44:43 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhAnv-0007JT-E6 for syslog@ietf.org; Tue, 29 Nov 2005 14:06:17 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jATIipmN017345; Wed, 30 Nov 2005 05:44:51 +1100 (EST) From: Darren Reed Message-Id: <200511291844.jATIihFG018602@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #5 - character encoding (was: Consensus?) In-Reply-To: To: Chris Lonvick Date: Wed, 30 Nov 2005 05:44:43 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Hi Rainer, > > Why don't we look at it from the other direction? We could state that any > encoding is acceptable - for ease-of-use/migration with existing syslog > implementations. It is RECOMMENDED that UTF-8 be used. When it is > used, an SD-ID element will be REQUIRED. e.g. - [enc="utf-8" lang="en"] > > Thoughts? I think this is a very sensible approach. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 13:46:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAV4-0000M6-Iq; Tue, 29 Nov 2005 13:46:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAV3-0000Ly-1m for syslog@megatron.ietf.org; Tue, 29 Nov 2005 13:46:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18644 for ; Tue, 29 Nov 2005 13:45:59 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhAp9-0007NE-Ki for syslog@ietf.org; Tue, 29 Nov 2005 14:07:33 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jATIkPdS025731; Wed, 30 Nov 2005 05:46:25 +1100 (EST) From: Darren Reed Message-Id: <200511291845.jATIjvkV024933@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Consensus on Charter? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F53@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Wed, 30 Nov 2005 05:45:57 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Are we happy to recharter when these are done to cover TCP ? Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 15:00:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBeb-00016v-MR; Tue, 29 Nov 2005 15:00:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBea-00016o-9o for syslog@megatron.ietf.org; Tue, 29 Nov 2005 15:00:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28003 for ; Tue, 29 Nov 2005 14:59:55 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhByh-0001fa-M2 for syslog@ietf.org; Tue, 29 Nov 2005 15:21:29 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 71CE49C00C; Tue, 29 Nov 2005 21:09:25 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08383-06; Tue, 29 Nov 2005 21:09:18 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 79C3E9C00B; Tue, 29 Nov 2005 21:09:18 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Nov 2005 21:00:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABAB6AC@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcX1Ed5eXo/PSwufTGKLGOu1vmtp7AADW97g From: "Rainer Gerhards" To: "Chris Lonvick" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, I think that is a good compromise. It would also enable us to convey the enconding information if we have it (anyhow, in that case it would be more smarter to convert to UTF-8, but that's not yet important). Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Tuesday, November 29, 2005 7:22 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) >=20 >=20 > Hi Rainer, >=20 > Why don't we look at it from the other direction? We could=20 > state that any=20 > encoding is acceptable - for ease-of-use/migration with=20 > existing syslog=20 > implementations. It is RECOMMENDED that UTF-8 be used. When it is=20 > used, an SD-ID element will be REQUIRED. e.g. - [enc=3D"utf-8"=20 > lang=3D"en"] >=20 > Thoughts? >=20 > All: Let's discuss this and close this issue. >=20 > Thanks, > Chris >=20 > On Tue, 29 Nov 2005, Rainer Gerhards wrote: >=20 > > Chris & WG, > > > >>> #5 Character encoding in MSG: due to my proof-of-concept > >>> implementation, I have raised the (ugly) question if we need > >>> to allow encodings other than UTF-8. Please note that this > >>> question arises from needs introduced by e.g. POSIX. So we > >>> can't easily argue them away by whishful thinking ;) > >>> > >>> Not even discussed yet. > >> > >> I haven't reviewed that yet. However, I'll note that allowing=20 > >> different encoding can be accomplished in the future as long as we=20 > >> establish a default encoding and a way to identify it in=20 > our current=20 > >> work. > > > > I have read a little in the mailing archive. Please note=20 > that in 2000=20 > > it was consensus that the MSG part may contain encodings other then=20 > > US-ASCII. Follow this threat: > > > > http://www.syslog.cc/ietf/autoarc/msg00127.html > > > > This discussion lead to RFC 3164 saying "other encodings=20 > MAY be used".=20 > > While this was observed behaviour, we need still to be=20 > aware that the=20 > > POSIX (and glibc) API places the restrictions on us that we=20 > simply do=20 > > not know the character encoding used by the application. As=20 > such, no=20 > > *nix syslogd can be programmed to be compliant to=20 > syslog-protocol if=20 > > we demand UTF-8 exclusively. > > > > I propose that we RECOMMEND UTF-8 that MUST start with the Unicode=20 > > Byte Order Mask (BOM) if used. If the MSG part does not=20 > start with the=20 > > BOM, it may be any encoding just as in RFC 3164. I do not see any=20 > > alternative to this. > > > > Rainer > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 15:04:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBhq-0004uO-1q; Tue, 29 Nov 2005 15:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBhp-0004s5-47 for syslog@megatron.ietf.org; Tue, 29 Nov 2005 15:04:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28156 for ; Tue, 29 Nov 2005 15:03:16 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhC1x-0001ks-TD for syslog@ietf.org; Tue, 29 Nov 2005 15:24:50 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 6C8949C00C; Tue, 29 Nov 2005 21:12:48 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08383-07; Tue, 29 Nov 2005 21:12:45 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 04E179C00B; Tue, 29 Nov 2005 21:12:45 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] Consensus on Charter? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Nov 2005 21:03:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABAB6AD@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Consensus on Charter? Thread-Index: AcX1FTkcq7s9byxFTjy7uNJdz6jj0AACoWzA From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, I am not long enough with the IETF to know how much trouble it is to recharter - but I think whatever it is, it is acceptable. You very correctly said that we need to do baby steps. And as a matter of past discussions, it seems to be necessary to explicitely exclude some things to get the first steps done. So, yes, I would accept it. Rainer > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Tuesday, November 29, 2005 7:46 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] Consensus on Charter? >=20 >=20 >=20 > Are we happy to recharter when these are done to cover TCP ? >=20 > Darren >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 15:50:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCQW-00089x-PQ; Tue, 29 Nov 2005 15:50:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCQN-00085w-AH; Tue, 29 Nov 2005 15:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03532; Tue, 29 Nov 2005 15:49:18 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhCkV-0003SY-Vx; Tue, 29 Nov 2005 16:10:52 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhCQM-0006nm-3d; Tue, 29 Nov 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 29 Nov 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-sign-17.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Signed syslog Messages Author(s) : J. Kelsey, et al. Filename : draft-ietf-syslog-sign-17.txt Pages : 33 Date : 2005-11-29 This document describes a mechanism to add origin authentication, message integrity, replay-resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification draws upon the work defined in RFC xxx, "The syslog Protocol", however it may be used atop any message delivery mechanism, even that defined in RFC 3164, "The BSD syslog Protocol", or in the RAW mode of "RFC 3195, "The Reliable Delivery of syslog". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-17.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-sign-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-sign-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-29151550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-sign-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-sign-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-29151550.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Tue Nov 29 15:56:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCWA-0001Gu-IO; Tue, 29 Nov 2005 15:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCW9-0001Gp-Ge for syslog@megatron.ietf.org; Tue, 29 Nov 2005 15:56:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04504 for ; Tue, 29 Nov 2005 15:55:16 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhCqH-0003mj-JK for syslog@ietf.org; Tue, 29 Nov 2005 16:16:51 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2005 12:55:50 -0800 X-IronPort-AV: i="3.97,389,1125903600"; d="scan'208"; a="371665173:sNHT27113236" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jATKt5f4012003; Tue, 29 Nov 2005 12:55:47 -0800 (PST) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 12:55:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Nov 2005 12:55:41 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FBEFD828@xmb-sjc-236.amer.cisco.com> Thread-Topic: Syslog sign - draft 17 (draft-ietf-syslog-sign-17.txt) Thread-Index: AcX1J0IxQpkM46WpS16sOUIm0qLVXQ== From: "Alexander Clemm \(alex\)" To: X-OriginalArrivalTime: 29 Nov 2005 20:55:42.0512 (UTC) FILETIME=[42EA7B00:01C5F527] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] Syslog sign - draft 17 (draft-ietf-syslog-sign-17.txt) X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hello, I just wanted to let you all know that I have submitted a new draft of syslog sign, as the old one was about to expire. The new draft should appear shortly if it hasn't already; here is a summary of the changes and updates that were made. =20 The changes were along the lines of what was presented at the Vancouver meeting, the most important of which concerns utilizing structured data to capture the fields of Signature and Certificate Blocks - a prudent use of structured data which avoids having a payload that is essentially "binary". Of course, unfortunately syslog-protocol now appears to be further away from completion than it did earlier, and really we would like syslog protocol to be stable to that respect before basing further work on that. However, at the same time, the consensus of the group by and large seems to be to retain structured data, so this provides perhaps a view of how it can be utilized. At the same time, please note that syslog sign as currently worded is actually not dependent on a specific syslog protocol syntax - if you will, you could send syslog messages with a message body that happens to be formatted respectively conform to the syntax as set forth in syslog-sign. =20 Note that the Payload Block format was not changed. Payload Blocks are essentially carried as part of Certificate Blocks; those utilize structured data, but as Payload Blocks are not associated with an actual syslog message directly it seems as if it is not necessary to change the way Payload Blocks are encoded. Quite possibly, this will of course be subject to further discussion. =20 The cookie field was removed. Identification of a Signature Block respectively Certificate Block can occur through use of an according SD-ID. =20 Another modification that was made, which will surely require more discussion, concerns the reboot session ID. For devices to be able to conform to this, they would need to be able to persist the reboot session ID such that it survives reboots (so to be able to increment after a reboot). The question is to allow for the possibility of allowing devices who cannot support such a feature to still support syslog-sign, with the understanding that in this case, there would be no guarantee that messages would be uniquely distinguished across reboots. It appears that this would still be useful, provided it can be easily distinguished whether or not reboot session ID is supported, which can be accomplished by the choice of ID (0 if not supported, 1 through 9999999999 otherwise). Comments or thoughts? =20 Beyond that, you will find a number of editorial updates with the goal of making the document slightly more readable. Updated sections include for example section 4.4 on Signature Group and Signature Priority. =20 There is of course more work to be done. In addition on closing on the suggested items, one aspect that is currently not addressed and requires discussion concerns any aspects about the message header of syslog messages carrying a Signature or Certificate Block - for example, assignment of a message ID, proper PRI etc. =20 Looking forward to fruitful discussions --- Alex _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 29 16:20:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCtY-0008Bk-RL; Tue, 29 Nov 2005 16:20:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCtX-0008Bc-Cc for syslog@megatron.ietf.org; Tue, 29 Nov 2005 16:20:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09809 for ; Tue, 29 Nov 2005 16:19:26 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhDDd-0005MP-Af for syslog@ietf.org; Tue, 29 Nov 2005 16:41:00 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 29 Nov 2005 13:19:59 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jATLJtOp001001 for ; Tue, 29 Nov 2005 13:19:56 -0800 (PST) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 13:19:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Date: Tue, 29 Nov 2005 13:19:31 -0800 Message-ID: <0DF8CBE327D4654F8567FD8123E328B10103441B@xmb-sjc-237.amer.cisco.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcX1EomLVMOuqmkESnmJxftdVgHobgAEhdpA From: "Shyyunn Lin \(sheranl\)" To: "Chris Lonvick \(clonvick\)" X-OriginalArrivalTime: 29 Nov 2005 21:19:34.0429 (UTC) FILETIME=[9867ACD0:01C5F52A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris: I think having SD-ID with [enc=3D"utf-8" lang=3D"English"] may be a good approach. If different language use utf-8 encoding, then "lang=3D" can distinguish it.=20 Also want to clarify that you suggest that if the message is in ASCII, it will not required SD-ID, but for all other encodings, SD-ID will be required. Note most other encoding methods already imply the language used, for example, in Chinese, there are several encoding methods, Traditional Chinese used in Taiwan and Hong Kong is Big5, and simplified Chinese used in Mainland China is GBK, so if the message is in traditional Chinese char, it will be shown as [enc=3D"Big5", lang=3D"Traditional Chinese"], a little bit redundant. The Big5 also includes all English char so it can be a mix of Chinese and English. =20 Regards, =20 Sheran -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick (clonvick) Sent: Tuesday, November 29, 2005 10:22 AM To: Rainer Gerhards Cc: syslog@ietf.org Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Hi Rainer, Why don't we look at it from the other direction? We could state that any encoding is acceptable - for ease-of-use/migration with existing syslog implementations. It is RECOMMENDED that UTF-8 be used. When it is used, an SD-ID element will be REQUIRED. e.g. - [enc=3D"utf-8" lang=3D"en"] Thoughts? All: Let's discuss this and close this issue. Thanks, Chris On Tue, 29 Nov 2005, Rainer Gerhards wrote: > Chris & WG, > >>> #5 Character encoding in MSG: due to my proof-of-concept >>> implementation, I have raised the (ugly) question if we need >>> to allow encodings other than UTF-8. Please note that this >>> question arises from needs introduced by e.g. POSIX. So we >>> can't easily argue them away by whishful thinking ;) >>> >>> Not even discussed yet. >> >> I haven't reviewed that yet. However, I'll note that allowing=20 >> different encoding can be accomplished in the future as long as we=20 >> establish a default encoding and a way to identify it in our current=20 >> work. > > I have read a little in the mailing archive. Please note that in 2000=20 > it was consensus that the MSG part may contain encodings other then=20 > US-ASCII. Follow this threat: > > http://www.syslog.cc/ietf/autoarc/msg00127.html > > This discussion lead to RFC 3164 saying "other encodings MAY be used". > While this was observed behaviour, we need still to be aware that the=20 > POSIX (and glibc) API places the restrictions on us that we simply do=20 > not know the character encoding used by the application. As such, no=20 > *nix syslogd can be programmed to be compliant to syslog-protocol if=20 > we demand UTF-8 exclusively. > > I propose that we RECOMMEND UTF-8 that MUST start with the Unicode=20 > Byte Order Mask (BOM) if used. If the MSG part does not start with the > BOM, it may be any encoding just as in RFC 3164. I do not see any=20 > alternative to this. > > Rainer > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 03:01:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhMu9-0000Jy-J1; Wed, 30 Nov 2005 03:01:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhMu9-0000Jt-20 for syslog@megatron.ietf.org; Wed, 30 Nov 2005 03:01:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11580 for ; Wed, 30 Nov 2005 03:00:43 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhNEL-0000eA-I3 for syslog@ietf.org; Wed, 30 Nov 2005 03:22:23 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 7CE6C9C00C; Wed, 30 Nov 2005 09:10:15 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08696-10; Wed, 30 Nov 2005 09:10:09 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id CC2AA9C00B; Wed, 30 Nov 2005 09:10:09 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 09:01:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F5B@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcX1EomLVMOuqmkESnmJxftdVgHobgAEhdpAABez1SA= From: "Rainer Gerhards" To: "Shyyunn Lin (sheranl)" , "Chris Lonvick (clonvick)" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sheran,=20 > Also want to clarify that you suggest that if the message is in ASCII, > it will not required SD-ID, but for all other encodings, SD-ID will be > required. Unfortunately, we can not do this. If we would know the encoding, we could translate it to UTF-8, as so far is required by syslog-protocol. However, we often do not know which encoding it is. The reason is that the POSIX syslog API does not tell us. So if we want to support POSIX (which I think we must), we must allow a syslog sender to send messages without telling the encoding - simply because it has no way to obtain that knowledge. A syslog sender embedded e.g. in a device does probably not have this restriction. So it SHOULD encode in UTF-8. That will ensure the receiver can understand it. If the sender has absolutely no idea of how to do that, but knows the encoding, then (and only then) it SHOULD specify the encoding. Rainer >=20 > Note most other encoding methods already imply the language used, for > example, in Chinese, there are several encoding methods, Traditional > Chinese used in Taiwan and Hong Kong is Big5, and simplified Chinese > used in Mainland China is GBK, so if the message is in traditional > Chinese char, it will be shown as [enc=3D"Big5", lang=3D"Traditional > Chinese"], a little bit redundant. The Big5 also includes all English > char so it can be a mix of Chinese and English. =20 >=20 >=20 >=20 > Regards, > =20 > Sheran >=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > (clonvick) > Sent: Tuesday, November 29, 2005 10:22 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) >=20 > Hi Rainer, >=20 > Why don't we look at it from the other direction? We could state that > any encoding is acceptable - for ease-of-use/migration with existing > syslog implementations. It is RECOMMENDED that UTF-8 be=20 > used. When it > is used, an SD-ID element will be REQUIRED. e.g. - [enc=3D"utf-8" > lang=3D"en"] >=20 > Thoughts? >=20 > All: Let's discuss this and close this issue. >=20 > Thanks, > Chris >=20 > On Tue, 29 Nov 2005, Rainer Gerhards wrote: >=20 > > Chris & WG, > > > >>> #5 Character encoding in MSG: due to my proof-of-concept > >>> implementation, I have raised the (ugly) question if we need > >>> to allow encodings other than UTF-8. Please note that this > >>> question arises from needs introduced by e.g. POSIX. So we > >>> can't easily argue them away by whishful thinking ;) > >>> > >>> Not even discussed yet. > >> > >> I haven't reviewed that yet. However, I'll note that allowing=20 > >> different encoding can be accomplished in the future as long as we=20 > >> establish a default encoding and a way to identify it in=20 > our current=20 > >> work. > > > > I have read a little in the mailing archive. Please note=20 > that in 2000=20 > > it was consensus that the MSG part may contain encodings other then=20 > > US-ASCII. Follow this threat: > > > > http://www.syslog.cc/ietf/autoarc/msg00127.html > > > > This discussion lead to RFC 3164 saying "other encodings=20 > MAY be used". > > While this was observed behaviour, we need still to be=20 > aware that the=20 > > POSIX (and glibc) API places the restrictions on us that we=20 > simply do=20 > > not know the character encoding used by the application. As=20 > such, no=20 > > *nix syslogd can be programmed to be compliant to=20 > syslog-protocol if=20 > > we demand UTF-8 exclusively. > > > > I propose that we RECOMMEND UTF-8 that MUST start with the Unicode=20 > > Byte Order Mask (BOM) if used. If the MSG part does not=20 > start with the >=20 > > BOM, it may be any encoding just as in RFC 3164. I do not see any=20 > > alternative to this. > > > > Rainer > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 03:11:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhN3o-00086r-RQ; Wed, 30 Nov 2005 03:11:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhN3n-00086m-P4 for syslog@megatron.ietf.org; Wed, 30 Nov 2005 03:11:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12631 for ; Wed, 30 Nov 2005 03:10:42 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhNO2-0000xx-Mq for syslog@ietf.org; Wed, 30 Nov 2005 03:32:22 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 781759C00C for ; Wed, 30 Nov 2005 09:20:17 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08825-07 for ; Wed, 30 Nov 2005 09:20:14 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 31D1C9C00B for ; Wed, 30 Nov 2005 09:20:14 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 30 Nov 2005 09:11:14 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F5D@grfint2.intern.adiscon.com> Thread-Topic: #2, max message size Thread-Index: AcX1haIb/1iiLgylSr6WDb6ox4lp5g== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] #2, max message size X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi WG, I have not heared back on this topic. So I conclude that it is consensus that the message size specification be left as it currently is in syslog-protocol-15. We might put further limits in the transport mappings. If someone objects to this view, please do it now as I plan to update the I-D in the not so distant future. Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 03:26:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNIF-0008S1-DW; Wed, 30 Nov 2005 03:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNID-0008Kv-AQ for syslog@megatron.ietf.org; Wed, 30 Nov 2005 03:26:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13693 for ; Wed, 30 Nov 2005 03:25:36 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhNcS-0001OE-9b for syslog@ietf.org; Wed, 30 Nov 2005 03:47:16 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 03A8D9C00C for ; Wed, 30 Nov 2005 09:35:11 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09044-04 for ; Wed, 30 Nov 2005 09:35:07 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 85FBD9C00B for ; Wed, 30 Nov 2005 09:35:07 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 30 Nov 2005 09:26:04 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F5E@grfint2.intern.adiscon.com> Thread-Topic: #3 NUL octets, #4 binary data, #8 octet-counting Thread-Index: AcX1h7SbI1UpQR5YSI2HS+Fx0fm/aw== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi WG, I have received notes via private mail telling me there seem to be some existing (and eventually soon upcoming) valid use cases for binary data in syslog. I think there is no point in arguing whether that's fortunate or not. It simply looks like that's the way it is. I do not like the idea of breaking existing use cases for syslog (because that will only lead to implementors ignoring the spec and the story of syslog inconsistencies continues...). As such, I think we need to provide at least some minimal support for it (aka "not outlaw it"). At first, this implies that NUL octets may be present in the message. I propose that we write text that discourages the use of NUL, but allows it if needed. That text should also allow, but discourage, a receiver to modify messages containing NUL. With that, we allow the use case, but do not make it a "show stopper" for implementing compliant software. This would also be pretty much in sync with what we currently find in practice, so it is already expected behaviour. Finally, such text would caution implementors that when NUL octets are present, chancs are high that eventually present digitial signatures will be broken. In my point of view, that's fair and efficient. Chris proposal for #5 (character encoding) also provides an elegant solution for binary data. We can use something like: [enc=3D"binary"] or [enc=3D"base-64"] I do NOT intend to specify this - I think it should be in the scope of a separate document specifying the use of binary data. Then would also be the right time to discuss all issues that arise out of it. For now, I just would like to keep the door open. Finally, I propose to extend Chris format so that the message size can be conveyed. This has been brought up several times and I think a clean solution is now obvious: [enc=3D"utf-8" lang=3D"en" size=3D"MSG-size-in-octets"] MSG-size-in-octets would be the size of the MSG part (just that!) in octets. Counting just the MSG part is sufficient, as the rest of the message consists of fields properly delimited. The size is probably most useful for binary data. Please comment. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 03:30:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNLw-0002Y5-Fj; Wed, 30 Nov 2005 03:30:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNLv-0002WG-MY for syslog@megatron.ietf.org; Wed, 30 Nov 2005 03:30:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14141 for ; Wed, 30 Nov 2005 03:29:26 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhNgA-0001Ua-NU for syslog@ietf.org; Wed, 30 Nov 2005 03:51:07 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 824969C00C for ; Wed, 30 Nov 2005 09:39:01 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09044-05 for ; Wed, 30 Nov 2005 09:38:58 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 171C49C00B for ; Wed, 30 Nov 2005 09:38:58 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 30 Nov 2005 09:29:54 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F5F@grfint2.intern.adiscon.com> Thread-Topic: #9, learnings from proof-of-concept Thread-Index: AcX1iD2pR9uDLASqR4eeUcSWrEsMUQ== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] #9, learnings from proof-of-concept X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org WG, one discussion topic were the minor things I discovered during my proof-of-concept implementation. If there is no objection, I will address them in the next update of the I-D. So we could discuss them once that is out. The reason is that I want to save some effort by not posting each and every of them as seperate topics. Of course, if you would like to comment now, that would be even more appreciated. If so, please have a look at http://www.rsyslog.com/index.php?module=3DStatic_Docs&func=3Dview&f=3D/sy= slog- protocol.html Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 03:36:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNSJ-0006ee-Sp; Wed, 30 Nov 2005 03:36:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNSH-0006eZ-TP for syslog@megatron.ietf.org; Wed, 30 Nov 2005 03:36:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14805 for ; Wed, 30 Nov 2005 03:36:00 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhNmU-0001fo-5I for syslog@ietf.org; Wed, 30 Nov 2005 03:57:41 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAU8a5o0016707; Wed, 30 Nov 2005 19:36:05 +1100 (EST) From: Darren Reed Message-Id: <200511300836.jAU8a4ti025233@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #2, max message size In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F5D@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Wed, 30 Nov 2005 19:36:04 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Hi WG, > > I have not heared back on this topic. So I conclude that it is consensus > that the message size specification be left as it currently is in > syslog-protocol-15. We might put further limits in the transport > mappings. > If someone objects to this view, please do it now as I plan to update > the I-D in the not so distant future. The only place a message size limit should be specified is in a transport mapping. If it's in -15 then it should be removed. Limits of all sizes and types do nothing but contribute to aging of a protocol. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 03:37:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNSn-0006vp-AD; Wed, 30 Nov 2005 03:37:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNSm-0006tD-7c for syslog@megatron.ietf.org; Wed, 30 Nov 2005 03:37:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14835 for ; Wed, 30 Nov 2005 03:36:31 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhNn1-0001gi-Ll for syslog@ietf.org; Wed, 30 Nov 2005 03:58:11 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 679109C00C for ; Wed, 30 Nov 2005 09:46:06 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09044-07 for ; Wed, 30 Nov 2005 09:46:02 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id EC4CE9C00B for ; Wed, 30 Nov 2005 09:46:02 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 30 Nov 2005 09:36:58 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F60@grfint2.intern.adiscon.com> Thread-Topic: #7 field order Thread-Index: AcX1iTpD7pwwhkTLSMipCRN0B0n0/g== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] #7 field order X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org WG, there has not been much discussion about the header fields and their order recently. I think this is a sign the issue has been settled. To make sure I got the right understanding of the resulting consensus, I propose that we use the following format: VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP [SD-ID]s SP MSG That is the format that also proven to be quite useful during my proof-of-concept implementation. If somebody objects, please do that now. Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 03:42:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNYC-0003G9-EB; Wed, 30 Nov 2005 03:42:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNYB-0003G4-7B for syslog@megatron.ietf.org; Wed, 30 Nov 2005 03:42:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15326 for ; Wed, 30 Nov 2005 03:42:06 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhNsQ-0001xo-C9 for syslog@ietf.org; Wed, 30 Nov 2005 04:03:46 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 1958A9C00C; Wed, 30 Nov 2005 09:51:41 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09103-04; Wed, 30 Nov 2005 09:51:37 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 9EFBC9C00B; Wed, 30 Nov 2005 09:51:37 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #2, max message size MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 09:42:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F61@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #2, max message size Thread-Index: AcX1iSqtutMabPRKS8yYxw41jv3vcQAAGyhA From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, > The only place a message size limit should be specified is in=20 > a transport > mapping. If it's in -15 then it should be removed. Limits=20 > of all sizes > and types do nothing but contribute to aging of a protocol. -protocol-15 is a compromise after a very long discussion. It says: ----- A receiver MUST be able to accept messages up to and including 480 octets in length. For interoperability reasons, all receiver implementations SHOULD be able to accept messages up to and including 2,048 octets in length. If a receiver receives a message with a length larger than 2,048 octets, or larger than it supports, the receiver MAY discard the message or truncate the payload. ----- I think this text is useful. It keeps the door open for any size messages while still allowing it to be restricted by the transport mappings and individual implementations (e.g. on low-end embedded devices). It cautions implementors against being too verbose but also sets a lower limit that each implementation can assume to be received. I think we should continue to use this text. Do you agree? Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 03:48:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNdS-0006D3-Rh; Wed, 30 Nov 2005 03:48:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNdR-0006Au-KD for syslog@megatron.ietf.org; Wed, 30 Nov 2005 03:48:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15934 for ; Wed, 30 Nov 2005 03:47:32 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhNxf-0002Ac-V4 for syslog@ietf.org; Wed, 30 Nov 2005 04:09:13 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAU8lxlQ023080; Wed, 30 Nov 2005 19:47:59 +1100 (EST) From: Darren Reed Message-Id: <200511300847.jAU8lgWE020586@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F5E@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Wed, 30 Nov 2005 19:47:42 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Hi WG, > > I have received notes via private mail telling me there seem to be some > existing (and eventually soon upcoming) valid use cases for binary data > in syslog. I think there is no point in arguing whether that's fortunate > or not. It simply looks like that's the way it is. I do not like the > idea of breaking existing use cases for syslog (because that will only > lead to implementors ignoring the spec and the story of syslog > inconsistencies continues...). As such, I think we need to provide at > least some minimal support for it (aka "not outlaw it"). .. This is the wrong approach to take. Furthermore, if 3164 is anything to go by, conveying of control characters by the existing protocol is not well documented at present. I think it is incumbant upon the WG to convey the message to implementors that while it will listen to their needs and plans for implementation, it is not up to them to choose which way this group proceeds merely because they decide to provide a particular implementation. .. > Chris proposal for #5 (character encoding) also provides an elegant > solution for binary data. We can use something like: > > [enc="binary"] > > or > > [enc="base-64"] > > I do NOT intend to specify this - I think it should be in the scope of a > separate document specifying the use of binary data. Then would also be > the right time to discuss all issues that arise out of it. For now, I > just would like to keep the door open. > > Finally, I propose to extend Chris format so that the message size can > be conveyed. This has been brought up several times and I think a clean > solution is now obvious: > > [enc="utf-8" lang="en" size="MSG-size-in-octets"] > > MSG-size-in-octets would be the size of the MSG part (just that!) in > octets. Counting just the MSG part is sufficient, as the rest of the > message consists of fields properly delimited. The size is probably most > useful for binary data. What happens if the message is truncated? What value is the message size really providing here? If we have a natural EOR marker, LF, what do we need the size for? Given that a syslog message is a single record, I don't believe that it makes any sense to include a "size" parameter. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 04:05:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNuK-0000W4-RH; Wed, 30 Nov 2005 04:05:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNuJ-0000V9-QY for syslog@megatron.ietf.org; Wed, 30 Nov 2005 04:05:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17657 for ; Wed, 30 Nov 2005 04:04:58 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhOEY-0002gQ-Lq for syslog@ietf.org; Wed, 30 Nov 2005 04:26:39 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 838579C00C; Wed, 30 Nov 2005 10:14:32 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09103-08; Wed, 30 Nov 2005 10:14:29 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id EC9A99C00B; Wed, 30 Nov 2005 10:14:28 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 10:05:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F63@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Thread-Index: AcX1is+a2HRNwbNiSO6xCtwayEm9FAAADzTQ From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren,=20 > > I have received notes via private mail telling me there=20 > seem to be some > > existing (and eventually soon upcoming) valid use cases for=20 > binary data > > in syslog. I think there is no point in arguing whether=20 > that's fortunate > > or not. It simply looks like that's the way it is. I do not like the > > idea of breaking existing use cases for syslog (because=20 > that will only > > lead to implementors ignoring the spec and the story of syslog > > inconsistencies continues...). As such, I think we need to=20 > provide at > > least some minimal support for it (aka "not outlaw it"). > .. >=20 > This is the wrong approach to take. >=20 > Furthermore, if 3164 is anything to go by, conveying of=20 > control characters > by the existing protocol is not well documented at present. That is right, RFC 3164 does NOT well document existing behaviour. Maybe that's why it is titled "the BSD syslog protocol" - just kidding. I have made considerable effort the past days to see why there is such a bad mapping between RFC 3164 and reality. In fact, I consider this to be a major problem that surfaces often during discussions. I myself based lots of assumptions on RFC 3164 and now testing has shown that these are invalid. If I only had gone to the lab earlier... I've read through the full mailing list archive yesterday. I have seen that there was put a lot of effort in RFC 3164, Chris has even talked several times with Eric Allman, who unquestionable knows pretty well about syslog ;) So why this gap between 3164 and practice? I have come to the conclusion that after Eric invented it, other folks have redone his work on other platforms (e.g. Linux, Windows and of course embedded devices). While all of these implementors had Eric's ideas on their mind, there was no spec to follow. Thus, each one introduced subtle differences and finally even BSD syslogd was modified in subtle ways. At the time 3164 was defined, nobody went to the lab and verified the results. Nor did I when I started with syslog-protocol. We all were so convinced that when Eric agreed to the document, it must be right. I think we do not need to put finger at anyone. In fact, 3164 is a fine piece of work. Even if the format specification can not be considered to be universally, it describes the security issues inherent with syslog. As far as I understand, that was the primary goal of that document. But now that we know practice is different, we should apply that knowledge to new documents. >=20 > I think it is incumbant upon the WG to convey the message to=20 > implementors > that while it will listen to their needs and plans for=20 > implementation, it > is not up to them to choose which way this group proceeds=20 > merely because > they decide to provide a particular implementation. In general, I agree. But I think we should support the currently existing use cases for syslog. After all, was this effort not put on hold because it was said it is not backwards-compatible enough? I do not intend to encourage that, that's also why I suggest wording on the restrictions (like no signatures) it comes with. >=20 > .. > > Chris proposal for #5 (character encoding) also provides an elegant > > solution for binary data. We can use something like: > >=20 > > [enc=3D"binary"] > >=20 > > or > >=20 > > [enc=3D"base-64"] > >=20 > > I do NOT intend to specify this - I think it should be in=20 > the scope of a > > separate document specifying the use of binary data. Then=20 > would also be > > the right time to discuss all issues that arise out of it.=20 > For now, I > > just would like to keep the door open. > >=20 > > Finally, I propose to extend Chris format so that the=20 > message size can > > be conveyed. This has been brought up several times and I=20 > think a clean > > solution is now obvious: > >=20 > > [enc=3D"utf-8" lang=3D"en" size=3D"MSG-size-in-octets"] > >=20 > > MSG-size-in-octets would be the size of the MSG part (just that!) in > > octets. Counting just the MSG part is sufficient, as the rest of the > > message consists of fields properly delimited. The size is=20 > probably most > > useful for binary data. >=20 > What happens if the message is truncated? Good question. I'd say the size would need to be adjusted. > What value is the message size really providing here? > If we have a natural EOR marker, LF, what do we need the size for? We do NOT have a EOR marker. As of the current draft, LF is just a regular character like any other. We explicitely wanted the capability to surface, now we have it. I even think its not bad to have it. I do NOT like the idea to re-iterate that long discussion of whether or not full UTF-8 should be supported. Please review the mailing list archive for that. If you violently object, please do so. In this case, I would ask Chris how we can proceed in such a case. I myself violently object restricting to printable characters only because of the multiple reasons found in the archive (and I don't intend to re-iterate that for the 6th time...). Sorry to be blunt, be if we always re-iterate everything, we will never arrive somewhere. >=20 > Given that a syslog message is a single record, I don't=20 > believe that it > makes any sense to include a "size" parameter. >=20 > Darren >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 04:07:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNvd-0000vt-Jn; Wed, 30 Nov 2005 04:07:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNvc-0000vj-7K for syslog@megatron.ietf.org; Wed, 30 Nov 2005 04:07:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17714 for ; Wed, 30 Nov 2005 04:06:19 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhOFr-0002iQ-R2 for syslog@ietf.org; Wed, 30 Nov 2005 04:28:00 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 6A4B59C00C for ; Wed, 30 Nov 2005 10:15:54 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09103-09 for ; Wed, 30 Nov 2005 10:15:51 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 18E689C00B for ; Wed, 30 Nov 2005 10:15:51 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Syslog] #7 field order Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 30 Nov 2005 10:06:52 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F65@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #7 field order Thread-Index: AcX1iTpD7pwwhkTLSMipCRN0B0n0/gABBErA From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I just got private mail if a missing field is denoted by "-". This is the case. Optional fields should be all but VERSION. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, November 30, 2005 9:37 AM > To: syslog@ietf.org > Subject: [Syslog] #7 field order >=20 > WG, >=20 > there has not been much discussion about the header fields and their > order recently. I think this is a sign the issue has been settled. To > make sure I got the right understanding of the resulting consensus, I > propose that we use the following format: >=20 > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID=20 > SP MSGID SP > [SD-ID]s SP MSG >=20 > That is the format that also proven to be quite useful during my > proof-of-concept implementation. >=20 > If somebody objects, please do that now. >=20 > Thanks, > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 06:19:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQ07-0006tw-KV; Wed, 30 Nov 2005 06:19:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQ06-0006qF-NW for syslog@megatron.ietf.org; Wed, 30 Nov 2005 06:19:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01031 for ; Wed, 30 Nov 2005 06:19:04 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhQKL-0006nE-Lx for syslog@ietf.org; Wed, 30 Nov 2005 06:40:47 -0500 Received: (qmail 91301 invoked from network); 30 Nov 2005 11:19:39 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 30 Nov 2005 11:19:39 -0000 X-pair-Authenticated: 222.153.48.254 From: "Andrew Ross" To: "'Chris Lonvick'" , "'Rainer Gerhards'" Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Date: Thu, 1 Dec 2005 00:19:37 +1300 Organization: Kiwi Enterprises Message-ID: <001001c5f59f$f4113220$d9a8a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >Hi Rainer, > >Why don't we look at it from the other direction? We could state that = any=20 >encoding is acceptable - for ease-of-use/migration with existing syslog = >implementations. It is RECOMMENDED that UTF-8 be used. When it is=20 >used, an SD-ID element will be REQUIRED. e.g. - [enc=3D"utf-8" = lang=3D"en"] I like that idea too. So, if no SD-ID encoding element is specified, then we must assume = US-ASCII and deal with it accordingly?? Cheers Andrew _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 06:24:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQ4K-0003bb-6v; Wed, 30 Nov 2005 06:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQ4J-0003a8-4S for syslog@megatron.ietf.org; Wed, 30 Nov 2005 06:24:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01269 for ; Wed, 30 Nov 2005 06:23:22 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhQOV-0006tu-UO for syslog@ietf.org; Wed, 30 Nov 2005 06:45:05 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 212199C00C; Wed, 30 Nov 2005 12:32:57 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09172-10; Wed, 30 Nov 2005 12:32:53 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 787079C00B; Wed, 30 Nov 2005 12:32:53 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 12:23:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F67@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcX1n/hCxo/FM+IYRu6ZqnHm5OQh9AAAClew From: "Rainer Gerhards" To: , "Chris Lonvick" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Andrew, > >Hi Rainer, > > > >Why don't we look at it from the other direction? We could=20 > state that any=20 > >encoding is acceptable - for ease-of-use/migration with=20 > existing syslog=20 > >implementations. It is RECOMMENDED that UTF-8 be used. When it is=20 > >used, an SD-ID element will be REQUIRED. e.g. -=20 > [enc=3D"utf-8" lang=3D"en"] >=20 > I like that idea too. >=20 > So, if no SD-ID encoding element is specified, then we must=20 > assume US-ASCII > and deal with it accordingly?? I think not. If it is not present, we known that we do not know it. If it is US-ASCII, I would expect something like [enc=3D"us-ascii" lang=3D"en"] Of course, we could also say if it is non-present, we can assume US-ASCII. But then we would need to introduce [enc=3D"unknown"] for the (common) case where we simply do not know it (again: think POSIX). I find this somehwat confusing. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 06:49:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQSc-0004fC-7R; Wed, 30 Nov 2005 06:49:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQSa-0004eY-Ex for syslog@megatron.ietf.org; Wed, 30 Nov 2005 06:49:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04283 for ; Wed, 30 Nov 2005 06:48:30 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhQmo-0007kT-I5 for syslog@ietf.org; Wed, 30 Nov 2005 07:10:13 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 161C99C00C; Wed, 30 Nov 2005 12:58:04 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09211-08; Wed, 30 Nov 2005 12:57:58 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id B09019C00B; Wed, 30 Nov 2005 12:57:58 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] formal Consultation prior to concluding the working group MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 12:49:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F68@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] formal Consultation prior to concluding the working group Thread-Index: AcXrtz/FQD0PhQ+MQKG4Tdfa7IcGDQAWPdmwAmPE/SA= From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org, housley@vigilsec.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Sam, with this, I am updating my formal reply from November, 18th. Since them, positive signs have emerged. I agree with Chris on that. We have had a discussion on a new charter and I think we have consensus and/or are very close to it. Also, a lot of technical discussion has been going on. That shows the ability of the WG to look at technical issues and work towards a solution. If I am not totally wrong, rough consensus can be reached soon. Also, I have done a proof-of-concept implementation in the mean time which revealed some other important issues and also serves as proof for some technical arguments. With the post-Vancouver changes, the implementation was relatively effortless. Lab testing has been done, a thing the WG as whole did not do enough before Vancouver. This lab testing has revealed that compatibility with RFC 3164 is not extremely important (except for PRI, which is vital). More implementors have joined the list and Chris has managed to motiviate some reviewers. Finally, the candidate format for the next revision has shown in lab testing that it provides adequate backwards compatibility. I have summarized all of this on http://www.syslog.cc/ietf/protocol.html#200511 which I invite you to at least quickly review. It also has extended reasoning why RFC 3164 does not tell the "real" truth, a fact that probably is important for any further decisions. So far the good news. On the negative side, the consensus still seems to be very fragile. Also, some issues are re-itereated ever and ever again. While WG list participation has increased, there are currently still only 15 voices heared, 3 of them only once (I have counted posters in the mailing list archive - mails send after the Vancouver meeting). The actual discussion is still limited to few people, but that might be acceptable. As Anton mentioned, there are few experts in syslog logging and the overall interest is low. I have also seen the NETCONF WG discussing a syslog replacement after the Vancouver meeting. I see they struggle with a set of similar questions. There seem to be more participants. If NETCONF redos event logging, the advantage is that the do not need to look at any backwards compatibility at all. Should the syslog WG fail to complete its work, NETCONF event notifications could be the alternative in the long term. However, given the wide-spread use of syslog, I doubt that syslog will ever be totally replaced by something else. In an ideal world, I would like to see a revived syslog WG work together with NETCONF on this issue. To be honest, I have not yet tried to influence the NETCONF discussion because I am unsure about the state of the syslog WG. If I weigh pros and cons, I think that the WG should be allowed to try to complete its work. Especially the fact that lab testing has revealed such large incompatibilities of existing deployed technology, together with the relative ease of fixing it, provides reasoning enough for it being alive. HOWEVER, I also think we need to deliver documents, not just arguments. So my proposal is that the WG be rechartered based on the soon-to-be reached consensus of the charter. Then, a challenging milestone (no later than the next IETF meeting) should be set for deliverying syslog-protocol and syslog-transport-udp. If that milestone can not be reached, I suggest concluding the WG because of its inability to deliver results. We are discussing this for roughly 3 years now, I and others have spent considerable time in trying to solve it and it does not make sense to continue if we can not reach consensus. What concerns me in this regard is that I still do not know how we can avoid such an "out of the sudden" discrepancy between IETF meeting and list consensus. Not meeting, I think, is not an option. The feedback from Vancouver was important. I just would like to see this on-list, too. Let me close my conclusion with the reminder that all what I have said is my personal view. The WG may or may not agree with this - I haven't even tried to reach consensus on it. I hope it is useful in your decision process, but that's all it is about. I personally commit to try to finish syslog-protocol, but I will definitely drop out of this effort mid-next year at latest, no matter what the overall route then might be. I hope we can finish things quickly and then focus on other small documents. There is lots that could be done and should be done in syslog. Just we need to do small steps, small documents as Darren rightly proposed. We need to iron them out within a few month and not years. I am positive about all this and think Chris has already guided the WG into the right direction. My best regards, Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Friday, November 18, 2005 10:01 AM > To: syslog@ietf.org; hartmans-ietf@mit.edu > Cc: housley@vigilsec.com; Darren Reed > Subject: RE: [Syslog] formal Consultation prior to concluding=20 > the working group >=20 > Sam & WG: >=20 > This is a long mail. It is both my answer to Sam's formal request for > input on the future of the WG as well my suggestion for=20 > rechartering and > mile stones. I consider it to be important. I know that reading long > mails sometimes is annoying. I also know that people=20 > (including me) tend > to not read long mails in detail. However, I have taken considerable > effort in creating it and would appreciate if it were actually read > thouroughly. I am telling this bluntly because out of past=20 > experience I > know that postings, especially larger ones, are not always handled > properly (which might be one of the causes for our current dilemma). I > think it is unavoidable to sometimes post a longer message. >=20 > My proposal in regard to the charter is based on the meeting=20 > minutes and > the discussion with Darren and Chris on this list (sorry,=20 > nobody else is > discussing...). The "list consensus" (that is between Darren,=20 > Chris and > me ;)) seems to be >=20 > - syslog-protocol in its current form is objected because we > fear it won't be implemented (though we don't have any=20 > "hard facts" on that) > - syslog is important and it should be standardized > - it is better to do small steps than a single big one > - having a layered approach for syslog (with transport mappings, > protocol description and application-layer add-ons) seems to > be benefitial > - in order to gain acceptance, the protocol format document > should be backwards compatible to existing syslogds > - *once* we have achieved creating initial transport mappings > and format specification, *then* we can look at things like > structured data > - a secure transport is needed (no consensus so far on SSL/TLS, > SSH or whatever else) >=20 > It is questionable if there is consensus on the following (though I > wouldn't outrule it): >=20 > - plain tcp syslog as currently being widely implemented and > deployed should no longer be ignored by the WG >=20 > These bullet points could probably be used to create a new=20 > charter. The > main issue they boil down to is that whatever we do should not break > existing receivers. There are some subleties involved with that. > Syslog-protocol-15 solved them by deliberately changing the header so > that a previous syslogd would not try to interpret it. This tool has > been rejected and is no loger available. On closer look at=20 > existing code > bases, I also have to admit that it might not have worked as designed. > We now head toward keeping the header and looking like=20 > old-style syslog. > So we need to be very careful that we do not break existing, deployed > technology. I would like to outline a few of the issues (those I know > out of my head), so that they can become part of our decision process. > This list is not necessarily complete. >=20 > - PRI MUST stay as it is currently defined. Adding more facilities > causes considerable problems to many=20 > existing/widely-deployed syslogd > implementation. > - MSG MUST NOT allow NUL octets. This would breaks almost all syslogd > implementations I know (because of the C/C++ string terminator) > - it is questionable if UTF-8 can be used inside MSG, because many > syslogds do not expect this neither can they handle it. UTF-7 might > be an alternative (this is no proposal!). > - in real-world syslogds, the US-ASCII requirement specified=20 > in RFC 3164 > for MSG is NOT honored, not even known. Actually, I have=20 > not yet seen > a single code base that restricts the character set in MSG. In Asia, > syslog > messages routinely contain DBCS character sets, like=20 > shift-JIS or EUC. > This > might imply that NUL characters are currently part of MSG,=20 > even though > I have not yet noticed it. In Europe, MSG routinely contains octets > with > values between 128 and 255. So if we want to keep consistent with > deployed syslog technology, we can not place any further requirement > on MSG as that it might contain any octet value (I know this > contradicts > with the non-NUL requirement I made immediately above -=20 > this would be > a topic for discussion). Most importantly, we MUST not require > anything > in regard to internationalization (this might be the topic of a > follow-up, > small, other document). > - while real-world syslogds default to 1K message size, they can be > configured to larger message sizes. This ability MUST be retained > in a spec. > - real-world syslogds already accept and emit FQDNs (as well as > hostname-only) in the HOSTNAME field. > - BUT: not all real-world syslogds support HOSTNAME at all. If we > standardize a header, we must provide instructions on how to detect > if there is a HOSTNAME in the message or not (it's doable, I and=20 > others have done it in our implementations). It remains as a > problem that an older syslogd not expecting a HOSTNAME will > misinterpret it as a TAG. This can cause major problems in existing > analysis scripts. That problem can probably only be solved by > adding an additional hostname field inside the current MSG part. > - a similar issue exists for the TIMESTAMP. Many existing syslogds > check if the punctuation inside the TIMESTAMP matches their > expectations. If so, it is accepted as valid TIMESTAMP, if not > it isn't. So we can NOT create the much asked-for TIMESTAMP with > year (and timezone) in it without loosing backwards compatibility=20 > (note that it does NOT help to keep the current format and just add > the year). Again, the only workable solution might be to=20 > add an extra > TIMESTAMP field inside MSG. >=20 > In my point of view, the thoughest issues are HOSTNAME and=20 > TIMESTAMP. If > we relax the backwards compatibility needs and accept that an older > syslogd misinterprets the header, we could solve them. Please keep in > mind that with current technology header misintrepretation is a common > problem, so we would not add any new evil. But it will definitely be a > big issue for sites in the migration process. Currently, a site > typically goes for a single syslog implementation and has put > workarounds for the few non-conforming senders. Similar workarounds > would be needed during a migration. This might be an acceptable extra > effort - or not (to be discussed). >=20 > Duplicating TIMESTAMP and HEADER comes at the cost of being=20 > chatty and I > also think it looks silly and - by doing so - discourages their > acceptance. If we discuss this issue seriously, we might also come up > with another solution. If we re-charter, the charter should=20 > specify the > priority in regard to backwards compatibility, so that we can base the > needed though decision on charter priorities. >=20 > On the issue whether we should standardize the header or just=20 > recommend > it, I am of the strong position that we must standardize it.=20 > If we just > recommend things, we can simply promote RFC 3164 to standard,=20 > because it > already tells us that a syslog message is a syslog message no matter > what it contains. The only requirement it must fullfil is that it is > sent to a syslog listener. I do not find this definition=20 > useful. But if > we keep with that spirit, there is no need for any further work. Just > recommending a new header, probably one that does not solve the > backward-compatibility issues that raised this discussion, does NOT do > any good. It just creates a fake impression of having solved=20 > the problem > while in practice it complicates things (old receivers will=20 > still not be > able to understand the format and would not have a proper way of > handling it). So if we take that route, I suggest we conclude this WG > because it has no power to find useful solutions above what is already > published. >=20 > Besides these comments in regard to the charter, I am still deeply > concerned about the ability of this WG to do any=20 > representative work at > all. From those voices in the meeting minutes, only Darren has said > *anything* at all in the current discussion. I think I am not > exaggerating if I say that this discussion is extremely important for > the work and future of the WG. Still no voices heared. How can we > achieve any stable consensus if nobody cares? I don't find it=20 > productive > if a handful people ew discuss about a draft, then go to the meeting, > where another handful few object it. I find some valuable=20 > wisdom in the > outcome of the last meeting. This, together with the need to=20 > standardize > logging, is my primary motivation for carrying on. However, it is > neither productive, nor justifiable, to continue working on=20 > the issue if > there is such a large des-interest in the WG. Eventually, the IETF is > the wrong forum for syslog standardization. For example, there already > is a industry-standard on plain tcp syslog, which is supported by most > major implementations. This is in place for several years now. >=20 > If the current rate of feedback continues, I strongly suggest to > conclude this WG. This is independent from the point if we could find > another charter. I simply do not find it acceptable to put any more > considerable effort into an activity whose outcome has prooven to be > very questionable. When thinking about this, please also keep in mind > that the current state of charter discussion roughly=20 > resembles what was > discussed for syslog-protocol in 2003 and the begining of 2004 (see > mailing list archive if you do not believe me - I already posted some > pointers;)). >=20 > A compromise might be to re-charter with a *very* restrictive charter > and *very challenging* mile stones and conclude the WG as soon as the > first milestone is missed. In my point of view, that first mile stone > should be for an I-D specifying the protocol format (together with > Anton's -transport-UDP draft). I propose we do not start any new work > but change syslog-protocol in the spirit of the new charter.=20 > What should > be reached is >=20 > - achived consensus (both on-list AND off-list!) > - successful last call > - AD review > - AD acceptance of publishing this I-D >=20 > This mile stone should be reached at the next IETF meeting. The WG > should meet at it. The AD should participate in that meeting=20 > and decide > on concluding the WG or moving the draft forward for=20 > publishing shortly > after the meeting. >=20 > I know this milestone is challenging. Anyhow, it should be doable > (thinking about all the discussions we had). If we really need to sort > out just minor issues, we can handle it. I object any later=20 > mile stone. > The reason is that we would invest too much effort into something that > still is very questionable. We have been working on this (if I look at > the pre-protocol discussion on -sign and -interntional) since=20 > roughly 3 > years now. If we can't finish it in another 5 months, we have no right > to remain active. >=20 > Of course, that was the compromise suggestion. I am still thinking it > might be more appropriate to conclude the WG immediately. >=20 > As a side-note to Sam, I am not sure if the inability to=20 > specify Unicode > inside MSG (outlined in my bullet points at the top) would prevent an > I-D from becoming a standards-track RFC. If so, we can not=20 > recharter in > the spirit of the last meeting. I this case, I recommend immediate > termination of the WG. >=20 > Rainer >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > > Sent: Thursday, November 17, 2005 9:40 PM > > To: syslog@ietf.org > > Cc: hartmans-ietf@mit.edu; housley@vigilsec.com; Darren Reed > > Subject: Re: [Syslog] formal Consultation prior to concluding=20 > > the working group > >=20 > > Hi, > >=20 > > Apologies for the silence. I'm busy with the day job today=20 > > and tomorrow. > >=20 > > Very briefly, I'd suggest that we can work towards a charter that=20 > > formalizes syslog but does not break existing syslog=20 > recievers. Once=20 > > there, we can add in the Structured Data parts that can be=20 > > used for higher=20 > > level functions such as signing the messages. > >=20 > > Does that approach make sense? If so, I can start working=20 > > out a draft=20 > > charter that says that we will do just that. > >=20 > > I would like to hear from more people on this. > >=20 > > Thanks, > > Chris > >=20 > > On Thu, 17 Nov 2005, Sam Hartman wrote: > >=20 > > >>>>>> "Darren" =3D=3D Darren Reed = writes: > > > > > > >> 2) Is there another charter under which the working group > > > >> would better be able to make progress? > > > > > > Darren> I believe the answer to this is yes. > > > > > > Darren> There is very relevant work this group could do=20 > > and should > > > Darren> do. > > > > > > In that case I'd recommend that you see if you can get=20 > consensus on > > > such a charter. > > > > > > --Sam > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 07:19:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQvk-0007h6-BX; Wed, 30 Nov 2005 07:19:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQvi-0007dm-Us for syslog@megatron.ietf.org; Wed, 30 Nov 2005 07:19:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06859 for ; Wed, 30 Nov 2005 07:18:36 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhRG0-00007h-6D for syslog@ietf.org; Wed, 30 Nov 2005 07:40:20 -0500 Received: (qmail 583 invoked from network); 30 Nov 2005 12:19:21 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 30 Nov 2005 12:19:21 -0000 X-pair-Authenticated: 222.153.48.254 From: "Andrew Ross" To: Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Date: Thu, 1 Dec 2005 01:19:18 +1300 Organization: Kiwi Enterprises Message-ID: <001901c5f5a8$4a730550$d9a8a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer, That sounds good to me at this stage, and it keeps the door open. I = would prefer to see all binary data encoded in some "safe" format like base64. = It just makes logging the data to file much easier. For instance, if the = binary data contained a LF character, when it was logged to disk, it would end = up as two separate messages when opened in notepad etc. Also, if we are to transport syslog over TCP at some stage, we need to = keep a delimiter character free from use in the message. Again, a LF would be = a good choice for this delimiter. Cheers Andrew -----Original Message----- From: syslog-bounces@lists.ietf.org = [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards Sent: Wednesday, 30 November 2005 9:26 p.m. To: syslog@ietf.org Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Hi WG, I have received notes via private mail telling me there seem to be some existing (and eventually soon upcoming) valid use cases for binary data in syslog. I think there is no point in arguing whether that's fortunate or not. It simply looks like that's the way it is. I do not like the idea of breaking existing use cases for syslog (because that will only lead to implementors ignoring the spec and the story of syslog inconsistencies continues...). As such, I think we need to provide at least some minimal support for it (aka "not outlaw it"). At first, this implies that NUL octets may be present in the message. I propose that we write text that discourages the use of NUL, but allows it if needed. That text should also allow, but discourage, a receiver to modify messages containing NUL. With that, we allow the use case, but do not make it a "show stopper" for implementing compliant software. This would also be pretty much in sync with what we currently find in practice, so it is already expected behaviour. Finally, such text would caution implementors that when NUL octets are present, chancs are high that eventually present digitial signatures will be broken. In my point of view, that's fair and efficient. Chris proposal for #5 (character encoding) also provides an elegant solution for binary data. We can use something like: [enc=3D"binary"] or [enc=3D"base-64"] I do NOT intend to specify this - I think it should be in the scope of a separate document specifying the use of binary data. Then would also be the right time to discuss all issues that arise out of it. For now, I just would like to keep the door open. Finally, I propose to extend Chris format so that the message size can be conveyed. This has been brought up several times and I think a clean solution is now obvious: [enc=3D"utf-8" lang=3D"en" size=3D"MSG-size-in-octets"] MSG-size-in-octets would be the size of the MSG part (just that!) in octets. Counting just the MSG part is sufficient, as the rest of the message consists of fields properly delimited. The size is probably most useful for binary data. Please comment. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 08:05:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRef-0002Yw-KI; Wed, 30 Nov 2005 08:05:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRee-0002Yq-Nn for syslog@megatron.ietf.org; Wed, 30 Nov 2005 08:05:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11767 for ; Wed, 30 Nov 2005 08:05:02 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhRyw-0001qd-5D for syslog@ietf.org; Wed, 30 Nov 2005 08:26:46 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 30 Nov 2005 05:05:39 -0800 X-IronPort-AV: i="3.99,195,1131350400"; d="scan'208"; a="372024383:sNHT70137526" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAUD5bs3019118; Wed, 30 Nov 2005 05:05:37 -0800 (PST) Date: Wed, 30 Nov 2005 05:05:37 -0800 (PST) From: Chris Lonvick To: "Shyyunn Lin (sheranl)" Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) In-Reply-To: <0DF8CBE327D4654F8567FD8123E328B10103441B@xmb-sjc-237.amer.cisco.com> Message-ID: References: <0DF8CBE327D4654F8567FD8123E328B10103441B@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Sheran, On Tue, 29 Nov 2005, Shyyunn Lin (sheranl) wrote: > Chris: > > I think having SD-ID with [enc="utf-8" lang="English"] may be a good > approach. If different language use utf-8 encoding, then "lang=" can > distinguish it. We _should_ be using language codes from RFC 3066. That specifies ISO 639 language tags. 639-1 has 2 character codes ("en" is English) and 639-2 has 3 characters ("eng" is English). RFC 3066 will likely be replaced by the works of the Language Tag Registry Update (ltru) Working Group. http://www.ietf.org/html.charters/ltru-charter.html They have IDs in the works. Until those become RFCs we should continue to reference RFC 3066. > > Also want to clarify that you suggest that if the message is in ASCII, > it will not required SD-ID, but for all other encodings, SD-ID will be > required. Yes - that's my suggestion. > > Note most other encoding methods already imply the language used, for > example, in Chinese, there are several encoding methods, Traditional > Chinese used in Taiwan and Hong Kong is Big5, and simplified Chinese > used in Mainland China is GBK, so if the message is in traditional > Chinese char, it will be shown as [enc="Big5", lang="Traditional > Chinese"], a little bit redundant. The Big5 also includes all English > char so it can be a mix of Chinese and English. Good point. As far as I can tell, "Big5" is not recognized by any accredited standards developing organization. It is recognized by the Ideographic Rapporteur Group (IRG) which reports to the Unicode consortium. The recognized way to represent Chinese characters, traditional and simplified, is through ISO 639-2 with the subcodes to indicate traditional and simplified for the "zh" _language_. The ID on "Tags for Identifying Languages" http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt identifies simplified Chinese as "zh-Hans" and traditional Chinese as "zh-Hant". Additional subtags could identify a locale such as "zh-Hant-TW" for Taiwan Chinese in traditional script. This is from the "Initial Language Subtag Registry" ID. http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-06.txt I think that we should specify encoding and language tags as striaghtforward as possible and let others augment syslog-protocol (in the future) with other encoding mechanisms. We can RECOMMEND that encoding be in UTF-8 and language tags come from RFC 3066. We can allow that other encoding and language identifications are acceptable. In the worst case, a vendor will have the option of [enc@9="something" lang@9="piglatin"]. Does this work for you? Thanks, Chris > > > > Regards, > > Sheran > > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > (clonvick) > Sent: Tuesday, November 29, 2005 10:22 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) > > Hi Rainer, > > Why don't we look at it from the other direction? We could state that > any encoding is acceptable - for ease-of-use/migration with existing > syslog implementations. It is RECOMMENDED that UTF-8 be used. When it > is used, an SD-ID element will be REQUIRED. e.g. - [enc="utf-8" > lang="en"] > > Thoughts? > > All: Let's discuss this and close this issue. > > Thanks, > Chris > > On Tue, 29 Nov 2005, Rainer Gerhards wrote: > >> Chris & WG, >> >>>> #5 Character encoding in MSG: due to my proof-of-concept >>>> implementation, I have raised the (ugly) question if we need >>>> to allow encodings other than UTF-8. Please note that this >>>> question arises from needs introduced by e.g. POSIX. So we >>>> can't easily argue them away by whishful thinking ;) >>>> >>>> Not even discussed yet. >>> >>> I haven't reviewed that yet. However, I'll note that allowing >>> different encoding can be accomplished in the future as long as we >>> establish a default encoding and a way to identify it in our current >>> work. >> >> I have read a little in the mailing archive. Please note that in 2000 >> it was consensus that the MSG part may contain encodings other then >> US-ASCII. Follow this threat: >> >> http://www.syslog.cc/ietf/autoarc/msg00127.html >> >> This discussion lead to RFC 3164 saying "other encodings MAY be used". >> While this was observed behaviour, we need still to be aware that the >> POSIX (and glibc) API places the restrictions on us that we simply do >> not know the character encoding used by the application. As such, no >> *nix syslogd can be programmed to be compliant to syslog-protocol if >> we demand UTF-8 exclusively. >> >> I propose that we RECOMMEND UTF-8 that MUST start with the Unicode >> Byte Order Mask (BOM) if used. If the MSG part does not start with the > >> BOM, it may be any encoding just as in RFC 3164. I do not see any >> alternative to this. >> >> Rainer >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 08:14:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRnB-0002QL-Md; Wed, 30 Nov 2005 08:14:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRnA-0002QG-UD for syslog@megatron.ietf.org; Wed, 30 Nov 2005 08:14:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12873 for ; Wed, 30 Nov 2005 08:13:50 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhS7S-0002Aj-OK for syslog@ietf.org; Wed, 30 Nov 2005 08:35:35 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id A99DF9C00C; Wed, 30 Nov 2005 14:23:27 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09342-07; Wed, 30 Nov 2005 14:23:24 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4D16C9C00B; Wed, 30 Nov 2005 14:23:24 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 14:14:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F6C@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcX1rviI1qmc8kRURMWacwdkBhB72gAAICvQ From: "Rainer Gerhards" To: "Chris Lonvick" , "Shyyunn Lin (sheranl)" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, I agree to all but one point - only that one quoted here... > > Also want to clarify that you suggest that if the message=20 > is in ASCII, > > it will not required SD-ID, but for all other encodings,=20 > SD-ID will be > > required. >=20 > Yes - that's my suggestion. I am sorry, we can not do this. The whole issue is rooted in POSIX APIs. You need to look at it why it is such a problem. On Windows, you know what character encodings you are dealing with. On Unix, you actually just get a bunch of octets - and nobody tells you what it is. So the poor Unix syslogd actually has no idea of what it handles and likewise does not know what to place in that field ;) If it knew it were this or that encoding, I would be very tempted to request it to convert to UTF-8. But the need behind this encoding is *NOT* to allow the multitude of whatever currently is in existence but rather provide a way to let a syslogd that needs to omit a "bunch of octets" do that. Does this clarify? I can provide code if that would be helpful... Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 08:18:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRqf-0003rq-8Y; Wed, 30 Nov 2005 08:18:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRqd-0003qM-NF for syslog@megatron.ietf.org; Wed, 30 Nov 2005 08:18:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13628 for ; Wed, 30 Nov 2005 08:17:25 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhSAv-0002KZ-AV for syslog@ietf.org; Wed, 30 Nov 2005 08:39:09 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 7AD8D9C00D; Wed, 30 Nov 2005 14:27:02 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09392-05; Wed, 30 Nov 2005 14:26:58 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 8D2309C00C; Wed, 30 Nov 2005 14:26:58 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 30 Nov 2005 14:17:55 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F6E@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Thread-Index: AcX1qE/ovxR0p+mYR4CYA/9+bdIUogAB9CpQ From: "Rainer Gerhards" To: , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Andrew, > That sounds good to me at this stage, and it keeps the door=20 > open. I would > prefer to see all binary data encoded in some "safe" format=20 > like base64. It > just makes logging the data to file much easier. For=20 > instance, if the binary > data contained a LF character, when it was logged to disk, it=20 > would end up > as two separate messages when opened in notepad etc. While I too prefer a "safe" format, I would not like to outrule another one. Maybe later... (we *need* to finish this I-D...). How it is handled when writing to disk is beyond IETF. I would escape it then - but that's up to the implementation. > Also, if we are to transport syslog over TCP at some stage,=20 > we need to keep > a delimiter character free from use in the message. Again, a=20 > LF would be a > good choice for this delimiter. Here, I disagree. I think we can not set aside a character for this. If we go for TCP, let's do octet-couting. Its reliable, efficient and proven. Anyhow, we are not yet doing a TCP mapping, so I suggest we save this discussion until later. Rainer PS: sorry for trying to focus on the immediate needs. But I think we really need to finish something... > Cheers >=20 > Andrew >=20 >=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Rainer Gerhards > Sent: Wednesday, 30 November 2005 9:26 p.m. > To: syslog@ietf.org > Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting >=20 >=20 > Hi WG, >=20 > I have received notes via private mail telling me there seem=20 > to be some > existing (and eventually soon upcoming) valid use cases for=20 > binary data > in syslog. I think there is no point in arguing whether=20 > that's fortunate > or not. It simply looks like that's the way it is. I do not like the > idea of breaking existing use cases for syslog (because that will only > lead to implementors ignoring the spec and the story of syslog > inconsistencies continues...). As such, I think we need to provide at > least some minimal support for it (aka "not outlaw it"). >=20 > At first, this implies that NUL octets may be present in the message. >=20 > I propose that we write text that discourages the use of NUL,=20 > but allows > it if needed. That text should also allow, but discourage, a=20 > receiver to > modify messages containing NUL. With that, we allow the use=20 > case, but do > not make it a "show stopper" for implementing compliant software. This > would also be pretty much in sync with what we currently find in > practice, so it is already expected behaviour. Finally, such=20 > text would > caution implementors that when NUL octets are present, chancs are high > that eventually present digitial signatures will be broken.=20 > In my point > of view, that's fair and efficient. >=20 > Chris proposal for #5 (character encoding) also provides an elegant > solution for binary data. We can use something like: >=20 > [enc=3D"binary"] >=20 > or >=20 > [enc=3D"base-64"] >=20 > I do NOT intend to specify this - I think it should be in the=20 > scope of a > separate document specifying the use of binary data. Then=20 > would also be > the right time to discuss all issues that arise out of it. For now, I > just would like to keep the door open. >=20 > Finally, I propose to extend Chris format so that the message size can > be conveyed. This has been brought up several times and I=20 > think a clean > solution is now obvious: >=20 > [enc=3D"utf-8" lang=3D"en" size=3D"MSG-size-in-octets"] >=20 > MSG-size-in-octets would be the size of the MSG part (just that!) in > octets. Counting just the MSG part is sufficient, as the rest of the > message consists of fields properly delimited. The size is=20 > probably most > useful for binary data. >=20 > Please comment. >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 08:18:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRqj-0003tp-JO; Wed, 30 Nov 2005 08:18:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRqi-0003sm-9v for syslog@megatron.ietf.org; Wed, 30 Nov 2005 08:18:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13638 for ; Wed, 30 Nov 2005 08:17:29 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhSAy-0002Kz-Ta for syslog@ietf.org; Wed, 30 Nov 2005 08:39:14 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 30 Nov 2005 05:18:05 -0800 X-IronPort-AV: i="3.99,195,1131350400"; d="scan'208"; a="679717701:sNHT25442464" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAUDI3eT000233; Wed, 30 Nov 2005 05:18:03 -0800 (PST) Date: Wed, 30 Nov 2005 05:18:03 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F67@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3F67@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: andrew@kiwisyslog.com, syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, Let's use this email as an example. :) There is no indication that I'm using US-ASCII encoding or that I'm writing in English. However, you're able to recieve this and read it. Similarly, you could write an email in German and send it to me. I would still be able to recieve it but I'd have a difficult time parsing the meaning. I'm suggesting that same approach for the transmission of the syslog content. If I really wanted you to know what encoding and language I'm using in an email, I would specify a mime header. syslog senders will continue to pump out whatever encoding and language they've been using and recievers will continue to do their best to parse them. If a vendor wants to get very specific about that, then they will have to use an SD-ID to identify the contents of the message. Mit Aufrichtigkeit, Chris On Wed, 30 Nov 2005, Rainer Gerhards wrote: > Andrew, > >>> Hi Rainer, >>> >>> Why don't we look at it from the other direction? We could >> state that any >>> encoding is acceptable - for ease-of-use/migration with >> existing syslog >>> implementations. It is RECOMMENDED that UTF-8 be used. When it is >>> used, an SD-ID element will be REQUIRED. e.g. - >> [enc="utf-8" lang="en"] >> >> I like that idea too. >> >> So, if no SD-ID encoding element is specified, then we must >> assume US-ASCII >> and deal with it accordingly?? > > I think not. If it is not present, we known that we do not know it. If > it is US-ASCII, I would expect something like > > [enc="us-ascii" lang="en"] > > Of course, we could also say if it is non-present, we can assume > US-ASCII. But then we would need to introduce > > [enc="unknown"] > > for the (common) case where we simply do not know it (again: think > POSIX). I find this somehwat confusing. > > Rainer > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 08:27:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRzy-0001YI-9S; Wed, 30 Nov 2005 08:27:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRzw-0001Xz-UZ for syslog@megatron.ietf.org; Wed, 30 Nov 2005 08:27:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15060 for ; Wed, 30 Nov 2005 08:27:02 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhSKE-0002kr-K0 for syslog@ietf.org; Wed, 30 Nov 2005 08:48:47 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id D61769C00C; Wed, 30 Nov 2005 14:36:39 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09392-07; Wed, 30 Nov 2005 14:36:36 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4636F9C00B; Wed, 30 Nov 2005 14:36:36 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 14:27:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F6F@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcX1sIZliCWBoEv/RYyKzANfcueRYQAADVqA From: "Rainer Gerhards" To: "Chris Lonvick" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: andrew@kiwisyslog.com, syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, > Let's use this email as an example. :) There is no=20 > indication that I'm=20 > using US-ASCII encoding or that I'm writing in English. =20 I think there actually is. If I am right, the SMTP RFCs require mail = text to be US-ASCII. Only via MIME and/or escape characters you can = include 8-bit data. For example M=FCller and M=F6ller might create some = problems in some mailers (But I guess my Mail system will encode them = with =3D). Dropping messages with octets > 127 in the subject is = a common spam protection setting... > However, you're=20 > able to recieve this and read it. Similarly, you could write=20 > an email in=20 > German and send it to me. I would still be able to recieve=20 > it but I'd=20 > have a difficult time parsing the meaning. >=20 > I'm suggesting that same approach for the transmission of the syslog=20 > content. If I really wanted you to know what encoding and=20 > language I'm=20 > using in an email, I would specify a mime header. syslog=20 > senders will=20 > continue to pump out whatever encoding and language they've=20 > been using=20 > and recievers will continue to do their best to parse them. =20 > If a vendor=20 > wants to get very specific about that, then they will have to=20 > use an SD-ID=20 > to identify the contents of the message. Here I agree with you. What I was saying is that IF the header says it = is US-ASCII, only then we should assume it actually is. If there is no = "enc" SD-ID, then we do not know what it is but can assume ... whatever = we assume. Let me phrase it that way: If the message contains [enc=3D"us-ascii" lang=3D"en"] then the receiver can honestly expect it to be US-ASCII. But if it does = not contain any "enc" the receiver does not know exactly and assume = anything it finds useful (may be ASCII, may not). Does this clarify? I somehow have the impression we mean the same thing = and I simply do not manage to convey what I intend to ;) Rainer >=20 > Mit Aufrichtigkeit, > Chris >=20 >=20 >=20 >=20 > On Wed, 30 Nov 2005, Rainer Gerhards wrote: >=20 > > Andrew, > > > >>> Hi Rainer, > >>> > >>> Why don't we look at it from the other direction? We could > >> state that any > >>> encoding is acceptable - for ease-of-use/migration with > >> existing syslog > >>> implementations. It is RECOMMENDED that UTF-8 be used. =20 > When it is > >>> used, an SD-ID element will be REQUIRED. e.g. - > >> [enc=3D"utf-8" lang=3D"en"] > >> > >> I like that idea too. > >> > >> So, if no SD-ID encoding element is specified, then we must > >> assume US-ASCII > >> and deal with it accordingly?? > > > > I think not. If it is not present, we known that we do not=20 > know it. If > > it is US-ASCII, I would expect something like > > > > [enc=3D"us-ascii" lang=3D"en"] > > > > Of course, we could also say if it is non-present, we can assume > > US-ASCII. But then we would need to introduce > > > > [enc=3D"unknown"] > > > > for the (common) case where we simply do not know it (again: think > > POSIX). I find this somehwat confusing. > > > > Rainer > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 08:38:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSAe-0000dM-4C; Wed, 30 Nov 2005 08:38:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSAb-0000d5-Ql for syslog@megatron.ietf.org; Wed, 30 Nov 2005 08:38:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16190 for ; Wed, 30 Nov 2005 08:38:03 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhSUt-00036J-Qj for syslog@ietf.org; Wed, 30 Nov 2005 08:59:48 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 30 Nov 2005 05:38:40 -0800 X-IronPort-AV: i="3.99,195,1131350400"; d="scan'208"; a="372039354:sNHT26343864" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAUDcceT009529; Wed, 30 Nov 2005 05:38:39 -0800 (PST) Date: Wed, 30 Nov 2005 05:38:38 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F6F@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3F6F@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-342241519-1133357918=:22303" X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: andrew@kiwisyslog.com, syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-342241519-1133357918=:22303 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Rainer, I believe that we are saying the same thing. :) If there is no indicator of encoding or language then a reciever will not= =20 know what it is receiving - just like receivers don't know what they are=20 receiving today. They MAY make an assumption that it is something in=20 US-ASCII (but may be disappointed). If there is an indicator of the encoding and language then the receiver=20 will know exactly what it is. Having an indicator should be RECOMMENDED=20 but not REQUIRED for ease of migration. Is that what we're all saying? Thanks, Chris On Wed, 30 Nov 2005, Rainer Gerhards wrote: > Chris, > >> Let's use this email as an example. :) There is no >> indication that I'm >> using US-ASCII encoding or that I'm writing in English. > > I think there actually is. If I am right, the SMTP RFCs require mail text= to be US-ASCII. Only via MIME and/or escape characters you can include 8-b= it data. For example M=FCller and M=F6ller might create some problems in so= me mailers (But I guess my Mail system will encode them with =3D). = Dropping messages with octets > 127 in the subject is a common spam protect= ion setting... > >> However, you're >> able to recieve this and read it. Similarly, you could write >> an email in >> German and send it to me. I would still be able to recieve >> it but I'd >> have a difficult time parsing the meaning. >> >> I'm suggesting that same approach for the transmission of the syslog >> content. If I really wanted you to know what encoding and >> language I'm >> using in an email, I would specify a mime header. syslog >> senders will >> continue to pump out whatever encoding and language they've >> been using >> and recievers will continue to do their best to parse them. >> If a vendor >> wants to get very specific about that, then they will have to >> use an SD-ID >> to identify the contents of the message. > > Here I agree with you. What I was saying is that IF the header says it is= US-ASCII, only then we should assume it actually is. If there is no "enc" = SD-ID, then we do not know what it is but can assume ... whatever we assume= =2E Let me phrase it that way: > > If the message contains > > [enc=3D"us-ascii" lang=3D"en"] > > then the receiver can honestly expect it to be US-ASCII. But if it does n= ot contain any "enc" the receiver does not know exactly and assume anything= it finds useful (may be ASCII, may not). > > Does this clarify? I somehow have the impression we mean the same thing a= nd I simply do not manage to convey what I intend to ;) > > Rainer > >> >> Mit Aufrichtigkeit, >> Chris >> >> >> >> >> On Wed, 30 Nov 2005, Rainer Gerhards wrote: >> >>> Andrew, >>> >>>>> Hi Rainer, >>>>> >>>>> Why don't we look at it from the other direction? We could >>>> state that any >>>>> encoding is acceptable - for ease-of-use/migration with >>>> existing syslog >>>>> implementations. It is RECOMMENDED that UTF-8 be used. >> When it is >>>>> used, an SD-ID element will be REQUIRED. e.g. - >>>> [enc=3D"utf-8" lang=3D"en"] >>>> >>>> I like that idea too. >>>> >>>> So, if no SD-ID encoding element is specified, then we must >>>> assume US-ASCII >>>> and deal with it accordingly?? >>> >>> I think not. If it is not present, we known that we do not >> know it. If >>> it is US-ASCII, I would expect something like >>> >>> [enc=3D"us-ascii" lang=3D"en"] >>> >>> Of course, we could also say if it is non-present, we can assume >>> US-ASCII. But then we would need to introduce >>> >>> [enc=3D"unknown"] >>> >>> for the (common) case where we simply do not know it (again: think >>> POSIX). I find this somehwat confusing. >>> >>> Rainer >>> >> > ---559023410-342241519-1133357918=:22303 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ---559023410-342241519-1133357918=:22303-- From syslog-bounces@lists.ietf.org Wed Nov 30 08:48:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSKL-0008Sx-3I; Wed, 30 Nov 2005 08:48:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSKI-0008Sr-Am for syslog@megatron.ietf.org; Wed, 30 Nov 2005 08:48:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17535 for ; Wed, 30 Nov 2005 08:48:03 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhSea-0003T6-2W for syslog@ietf.org; Wed, 30 Nov 2005 09:09:48 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 286D29C00C; Wed, 30 Nov 2005 14:57:41 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09392-10; Wed, 30 Nov 2005 14:57:37 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id A69C29C00B; Wed, 30 Nov 2005 14:57:37 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 14:48:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F72@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcX1s2n+dhkorRh/Q5q2a5nff54MjQAAVAUg From: "Rainer Gerhards" To: "Chris Lonvick" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Cc: andrew@kiwisyslog.com, syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, I fully agree - thanks ;) Rainer=20 > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Wednesday, November 30, 2005 2:39 PM > To: Rainer Gerhards > Cc: andrew@kiwisyslog.com; syslog@ietf.org > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) >=20 > Hi Rainer, >=20 > I believe that we are saying the same thing. :) >=20 > If there is no indicator of encoding or language then a=20 > reciever will not=20 > know what it is receiving - just like receivers don't know=20 > what they are=20 > receiving today. They MAY make an assumption that it is something in=20 > US-ASCII (but may be disappointed). >=20 > If there is an indicator of the encoding and language then=20 > the receiver=20 > will know exactly what it is. Having an indicator should be=20 > RECOMMENDED=20 > but not REQUIRED for ease of migration. >=20 > Is that what we're all saying? >=20 > Thanks, > Chris >=20 >=20 >=20 > On Wed, 30 Nov 2005, Rainer Gerhards wrote: >=20 > > Chris, > > > >> Let's use this email as an example. :) There is no > >> indication that I'm > >> using US-ASCII encoding or that I'm writing in English. > > > > I think there actually is. If I am right, the SMTP RFCs=20 > require mail text to be US-ASCII. Only via MIME and/or escape=20 > characters you can include 8-bit data. For example M=FCller and=20 > M=F6ller might create some problems in some mailers (But I=20 > guess my Mail system will encode them with =3D).=20 > Dropping messages with octets > 127 in the subject is a=20 > common spam protection setting... > > > >> However, you're > >> able to recieve this and read it. Similarly, you could write > >> an email in > >> German and send it to me. I would still be able to recieve > >> it but I'd > >> have a difficult time parsing the meaning. > >> > >> I'm suggesting that same approach for the transmission of=20 > the syslog > >> content. If I really wanted you to know what encoding and > >> language I'm > >> using in an email, I would specify a mime header. syslog > >> senders will > >> continue to pump out whatever encoding and language they've > >> been using > >> and recievers will continue to do their best to parse them. > >> If a vendor > >> wants to get very specific about that, then they will have to > >> use an SD-ID > >> to identify the contents of the message. > > > > Here I agree with you. What I was saying is that IF the=20 > header says it is US-ASCII, only then we should assume it=20 > actually is. If there is no "enc" SD-ID, then we do not know=20 > what it is but can assume ... whatever we assume. Let me=20 > phrase it that way: > > > > If the message contains > > > > [enc=3D"us-ascii" lang=3D"en"] > > > > then the receiver can honestly expect it to be US-ASCII.=20 > But if it does not contain any "enc" the receiver does not=20 > know exactly and assume anything it finds useful (may be=20 > ASCII, may not). > > > > Does this clarify? I somehow have the impression we mean=20 > the same thing and I simply do not manage to convey what I=20 > intend to ;) > > > > Rainer > > > >> > >> Mit Aufrichtigkeit, > >> Chris > >> > >> > >> > >> > >> On Wed, 30 Nov 2005, Rainer Gerhards wrote: > >> > >>> Andrew, > >>> > >>>>> Hi Rainer, > >>>>> > >>>>> Why don't we look at it from the other direction? We could > >>>> state that any > >>>>> encoding is acceptable - for ease-of-use/migration with > >>>> existing syslog > >>>>> implementations. It is RECOMMENDED that UTF-8 be used. > >> When it is > >>>>> used, an SD-ID element will be REQUIRED. e.g. - > >>>> [enc=3D"utf-8" lang=3D"en"] > >>>> > >>>> I like that idea too. > >>>> > >>>> So, if no SD-ID encoding element is specified, then we must > >>>> assume US-ASCII > >>>> and deal with it accordingly?? > >>> > >>> I think not. If it is not present, we known that we do not > >> know it. If > >>> it is US-ASCII, I would expect something like > >>> > >>> [enc=3D"us-ascii" lang=3D"en"] > >>> > >>> Of course, we could also say if it is non-present, we can assume > >>> US-ASCII. But then we would need to introduce > >>> > >>> [enc=3D"unknown"] > >>> > >>> for the (common) case where we simply do not know it (again: think > >>> POSIX). I find this somehwat confusing. > >>> > >>> Rainer > >>> > >> > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 09:08:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSdL-0003tj-2T; Wed, 30 Nov 2005 09:08:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSdJ-0003rD-GQ for syslog@megatron.ietf.org; Wed, 30 Nov 2005 09:08:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20161 for ; Wed, 30 Nov 2005 09:07:44 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhSxb-0004C0-OX for syslog@ietf.org; Wed, 30 Nov 2005 09:29:28 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 30 Nov 2005 06:08:20 -0800 X-IronPort-AV: i="3.99,195,1131350400"; d="scan'208"; a="372053874:sNHT28594176" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAUE8HeT024764; Wed, 30 Nov 2005 06:08:18 -0800 (PST) Date: Wed, 30 Nov 2005 06:08:17 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F6E@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3F6E@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: andrew@kiwisyslog.com, syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Let's keep in mind that syslog-sign will transport binary signatures. In that, the authors are proposing to use base-64 encoding. I agree with Rainer that we've provided enough means in syslog-protocol so that may be accomplished. As Rainer says, let's focus on getting syslog-protocol finished. :) Thanks, Chris On Wed, 30 Nov 2005, Rainer Gerhards wrote: > Andrew, > >> That sounds good to me at this stage, and it keeps the door >> open. I would >> prefer to see all binary data encoded in some "safe" format >> like base64. It >> just makes logging the data to file much easier. For >> instance, if the binary >> data contained a LF character, when it was logged to disk, it >> would end up >> as two separate messages when opened in notepad etc. > > While I too prefer a "safe" format, I would not like to outrule another > one. Maybe later... (we *need* to finish this I-D...). How it is handled > when writing to disk is beyond IETF. I would escape it then - but that's > up to the implementation. > >> Also, if we are to transport syslog over TCP at some stage, >> we need to keep >> a delimiter character free from use in the message. Again, a >> LF would be a >> good choice for this delimiter. > > Here, I disagree. I think we can not set aside a character for this. If > we go for TCP, let's do octet-couting. Its reliable, efficient and > proven. Anyhow, we are not yet doing a TCP mapping, so I suggest we save > this discussion until later. > > Rainer > PS: sorry for trying to focus on the immediate needs. But I think we > really need to finish something... > >> Cheers >> >> Andrew >> >> >> -----Original Message----- >> From: syslog-bounces@lists.ietf.org >> [mailto:syslog-bounces@lists.ietf.org] >> On Behalf Of Rainer Gerhards >> Sent: Wednesday, 30 November 2005 9:26 p.m. >> To: syslog@ietf.org >> Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting >> >> >> Hi WG, >> >> I have received notes via private mail telling me there seem >> to be some >> existing (and eventually soon upcoming) valid use cases for >> binary data >> in syslog. I think there is no point in arguing whether >> that's fortunate >> or not. It simply looks like that's the way it is. I do not like the >> idea of breaking existing use cases for syslog (because that will only >> lead to implementors ignoring the spec and the story of syslog >> inconsistencies continues...). As such, I think we need to provide at >> least some minimal support for it (aka "not outlaw it"). >> >> At first, this implies that NUL octets may be present in the message. >> >> I propose that we write text that discourages the use of NUL, >> but allows >> it if needed. That text should also allow, but discourage, a >> receiver to >> modify messages containing NUL. With that, we allow the use >> case, but do >> not make it a "show stopper" for implementing compliant software. This >> would also be pretty much in sync with what we currently find in >> practice, so it is already expected behaviour. Finally, such >> text would >> caution implementors that when NUL octets are present, chancs are high >> that eventually present digitial signatures will be broken. >> In my point >> of view, that's fair and efficient. >> >> Chris proposal for #5 (character encoding) also provides an elegant >> solution for binary data. We can use something like: >> >> [enc="binary"] >> >> or >> >> [enc="base-64"] >> >> I do NOT intend to specify this - I think it should be in the >> scope of a >> separate document specifying the use of binary data. Then >> would also be >> the right time to discuss all issues that arise out of it. For now, I >> just would like to keep the door open. >> >> Finally, I propose to extend Chris format so that the message size can >> be conveyed. This has been brought up several times and I >> think a clean >> solution is now obvious: >> >> [enc="utf-8" lang="en" size="MSG-size-in-octets"] >> >> MSG-size-in-octets would be the size of the MSG part (just that!) in >> octets. Counting just the MSG part is sufficient, as the rest of the >> message consists of fields properly delimited. The size is >> probably most >> useful for binary data. >> >> Please comment. >> >> Rainer >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 10:48:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUBp-0003xp-Ax; Wed, 30 Nov 2005 10:48:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUBn-0003xb-WF for syslog@megatron.ietf.org; Wed, 30 Nov 2005 10:48:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02315 for ; Wed, 30 Nov 2005 10:47:25 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhUW4-0007g0-MD for syslog@ietf.org; Wed, 30 Nov 2005 11:09:10 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAUFlhIP028391; Thu, 1 Dec 2005 02:47:43 +1100 (EST) From: Darren Reed Message-Id: <200511301547.jAUFlagC027535@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F6E@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Thu, 1 Dec 2005 02:47:36 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: andrew@kiwisyslog.com, syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Andrew, > > > Also, if we are to transport syslog over TCP at some stage, > > we need to keep > > a delimiter character free from use in the message. Again, a > > LF would be a > > good choice for this delimiter. > > Here, I disagree. I think we can not set aside a character for this. If > we go for TCP, let's do octet-couting. Its reliable, efficient and > proven. Anyhow, we are not yet doing a TCP mapping, so I suggest we save > this discussion until later. Why not use LF? It will work. There are syslogd implementations about that use LF as a record delimeter. In other emails you're saying "we must support binary because some people are going to use this". Now we've got people that support LF as a record delimeter already but you don't want to take this into account. Why does what one vendor is going to do mean more than what other vendors are already doing ? Is there bias here somewhere ? Do you have any particular preference based on work you've done or through some sort of affiliation ? If you want to discount use of LF as a record delimeter then there is no reason we must support use of binary because what vendors are doing is obviously irrelevant. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 10:49:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUCa-0004Nq-IE; Wed, 30 Nov 2005 10:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUCZ-0004K7-L3 for syslog@megatron.ietf.org; Wed, 30 Nov 2005 10:48:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02472 for ; Wed, 30 Nov 2005 10:48:11 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhUWm-0007hM-3X for syslog@ietf.org; Wed, 30 Nov 2005 11:09:56 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAUFmlTj025417; Thu, 1 Dec 2005 02:48:47 +1100 (EST) From: Darren Reed Message-Id: <200511301548.jAUFmkVj009593@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #2, max message size In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F61@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Thu, 1 Dec 2005 02:48:46 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Darren, > > > The only place a message size limit should be specified is in > > a transport > > mapping. If it's in -15 then it should be removed. Limits > > of all sizes > > and types do nothing but contribute to aging of a protocol. > > -protocol-15 is a compromise after a very long discussion. It says: > > ----- > A receiver MUST be able to accept messages up to and including 480 > octets in length. For interoperability reasons, all receiver > implementations SHOULD be able to accept messages up to and including > 2,048 octets in length. > > If a receiver receives a message with a length larger than 2,048 > octets, or larger than it supports, the receiver MAY discard the > message or truncate the payload. > ----- > > I think this text is useful. It keeps the door open for any size > messages while still allowing it to be restricted by the transport > mappings and individual implementations (e.g. on low-end embedded > devices). It cautions implementors against being too verbose but also > sets a lower limit that each implementation can assume to be received. > > I think we should continue to use this text. Do you agree? No. That text doesn't belong in this draft. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 11:59:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVJA-0005t3-Fk; Wed, 30 Nov 2005 11:59:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVJ8-0005sy-SB for syslog@megatron.ietf.org; Wed, 30 Nov 2005 11:59:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10675 for ; Wed, 30 Nov 2005 11:59:04 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhVdR-0001f2-4Z for syslog@ietf.org; Wed, 30 Nov 2005 12:20:50 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAUGxB3j021525; Thu, 1 Dec 2005 03:59:11 +1100 (EST) From: Darren Reed Message-Id: <200511301658.jAUGwvUW022131@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F63@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Thu, 1 Dec 2005 03:58:57 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Darren, .. > So why this gap between 3164 and practice? I have come > to the conclusion that after Eric invented it, other folks have redone > his work on other platforms (e.g. Linux, Windows and of course embedded > devices). While all of these implementors had Eric's ideas on their > mind, there was no spec to follow. Thus, each one introduced subtle > differences and finally even BSD syslogd was modified in subtle ways. At > the time 3164 was defined, nobody went to the lab and verified the > results. Nor did I when I started with syslog-protocol. We all were so > convinced that when Eric agreed to the document, it must be right. I > think we do not need to put finger at anyone. .. I agree with the summary here. > In general, I agree. But I think we should support the currently > existing use cases for syslog. After all, was this effort not put on > hold because it was said it is not backwards-compatible enough? Indeed. But I think there were (or are) protocol subtlties that many people are unaware of. Maybe in your testing of syslog messages you should include sending a message that is 255 characters long 0x1 - 0xff and see what comes out the other end. I'd also recommend that you include Solaris (preferably Solaris 10) in your test suite if you can't include any of HP-UX or AIX. It's probably the most common commercial Unix and people who deploy it are loathe to replace system components with open source bits. Solaris 10 for x86 is a free download. > > > MSG-size-in-octets would be the size of the MSG part (just that!) in > > > octets. Counting just the MSG part is sufficient, as the rest of the > > > message consists of fields properly delimited. The size is > > probably most > > > useful for binary data. > > > > What happens if the message is truncated? > > Good question. I'd say the size would need to be adjusted. What happens if/when the SD data is truncated and either the MSG size is lost or truncated half way through ? I believe there is very little added value of having the message size as part of SD data - or at least not enough to warrant it being treated as a mandatory/required field to include. > > What value is the message size really providing here? > > If we have a natural EOR marker, LF, what do we need the size for? > > We do NOT have a EOR marker. As of the current draft, LF is just a > regular character like any other. We explicitely wanted the capability > to surface, now we have it. I even think its not bad to have it. I do > NOT like the idea to re-iterate that long discussion of whether or not > full UTF-8 should be supported. Please review the mailing list archive > for that. Allowing LF inside a native message is bad, now that I think of it. Supporting UTF-8 doesn't impact what we use as an EOR marker unless we are going to say that the wire format must not be changed from the message supplied by the application. If we're going to be backwards compatible with the use of ^ (and I think we should and continue to use this) then this already points to the on-wire content of the message being different to what is supplied by an application. I can't see any reason why the on-wire format of the message needs to be the same as that supplied by the application. It's not like we use tcpdump or ethereal to do our loging. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 12:01:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVKK-00062o-Hh; Wed, 30 Nov 2005 12:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVKI-00062e-JE for syslog@megatron.ietf.org; Wed, 30 Nov 2005 12:01:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10767 for ; Wed, 30 Nov 2005 12:00:16 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhVec-0001gT-2d for syslog@ietf.org; Wed, 30 Nov 2005 12:22:02 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id F12D99C00C; Wed, 30 Nov 2005 18:09:48 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09778-03; Wed, 30 Nov 2005 18:09:45 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 2F11A9C00B; Wed, 30 Nov 2005 18:09:45 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #2, max message size MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 18:00:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F80@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #2, max message size Thread-Index: AcX1xZE95BTFntBwQVmhyc5qaIfGMQACE1gQ From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, I violently object your argument and leave it up to the rest of the WG what should be done. I respect your argument, but I do not like to re-iterate this forever. One time we have discussed this was in October 2004: http://www.syslog.cc/ietf/autoarc/msg01289.html If you browse the archive, you will find several other ocasions where this was discussed. What's your actual recommendation? Do not say anything and leave it the implementor to guess what is OK? After all, its the implementor's problem if the message can not be transmitted. Or do you prefer to define an API where the lower layer tells the upper layer what capabilities it has? Maybe MTU discovery? Or an app-level ack? I think all of these options have already been discussed during the past years. What is now in is a (fragile) consensus, but if only you do not like it, I think we should go ahead and leave an unhappy Darren behind. If only I insist on it, we can also go ahead and leave an unhappy Rainer behind. But we need to go ahead! Rainer=20 > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Wednesday, November 30, 2005 4:49 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] #2, max message size >=20 > > Darren, > >=20 > > > The only place a message size limit should be specified is in=20 > > > a transport > > > mapping. If it's in -15 then it should be removed. Limits=20 > > > of all sizes > > > and types do nothing but contribute to aging of a protocol. > >=20 > > -protocol-15 is a compromise after a very long discussion. It says: > >=20 > > ----- > > A receiver MUST be able to accept messages up to and=20 > including 480 > > octets in length. For interoperability reasons, all receiver > > implementations SHOULD be able to accept messages up to=20 > and including > > 2,048 octets in length. > >=20 > > If a receiver receives a message with a length larger than 2,048 > > octets, or larger than it supports, the receiver MAY discard the > > message or truncate the payload. > > ----- > >=20 > > I think this text is useful. It keeps the door open for any size > > messages while still allowing it to be restricted by the transport > > mappings and individual implementations (e.g. on low-end embedded > > devices). It cautions implementors against being too=20 > verbose but also > > sets a lower limit that each implementation can assume to=20 > be received. > >=20 > > I think we should continue to use this text. Do you agree? >=20 > No. That text doesn't belong in this draft. >=20 > Darren >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 12:13:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVWD-0007Vl-ML; Wed, 30 Nov 2005 12:13:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVWC-0007VZ-Jx for syslog@megatron.ietf.org; Wed, 30 Nov 2005 12:13:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12069 for ; Wed, 30 Nov 2005 12:12:34 -0500 (EST) Received: from ext-nj2ut-11.online-age.net ([64.14.54.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhVqV-00022Q-Cm for syslog@ietf.org; Wed, 30 Nov 2005 12:34:20 -0500 Received: from int-nj2ut-5.online-age.net (int-nj2ut-5.online-age.net [3.159.237.74]) by ext-nj2ut-11.online-age.net (8.13.5/8.13.5/20051114-SVVS-TLS-DNSBL) with ESMTP id jAUHD9Jr025359 for ; Wed, 30 Nov 2005 12:13:10 -0500 Received: from cinmlef06.e2k.ad.ge.com (localhost.localdomain [127.0.0.1]) by int-nj2ut-5.online-age.net (8.11.6/8.11.6/20050510-SVVS) with ESMTP id jAUHD9C27751 for ; Wed, 30 Nov 2005 12:13:09 -0500 Received: from MKEMLVEM07.e2k.ad.ge.com ([3.159.176.54]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 12:13:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #2, max message size Date: Wed, 30 Nov 2005 11:13:05 -0600 Message-ID: <45A5295FFA1CBE4D9BF44E8534D2686C09BB7709@MKEMLVEM07.e2k.ad.ge.com> Thread-Topic: [Syslog] #2, max message size Thread-Index: AcX1xZE95BTFntBwQVmhyc5qaIfGMQACE1gQAADWXWA= From: "Moehrke, John \(GE Healthcare\)" To: "Rainer Gerhards" , "Darren Reed" X-OriginalArrivalTime: 30 Nov 2005 17:13:05.0789 (UTC) FILETIME=[541A0AD0:01C5F5D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Shouldn't the MTU be defined by the binding to the transport? I fail to see why the protocol, unbound to a transport, needs to have a limit.=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, November 30, 2005 11:01 AM > To: Darren Reed > Cc: syslog@ietf.org > Subject: RE: [Syslog] #2, max message size >=20 > Darren, >=20 > I violently object your argument and leave it up to the rest of the WG > what should be done. I respect your argument, but I do not like to > re-iterate this forever. >=20 > One time we have discussed this was in October 2004: >=20 > http://www.syslog.cc/ietf/autoarc/msg01289.html >=20 > If you browse the archive, you will find several other ocasions where > this was discussed. >=20 > What's your actual recommendation? Do not say anything and=20 > leave it the > implementor to guess what is OK? After all, its the implementor's > problem if the message can not be transmitted. Or do you prefer to > define an API where the lower layer tells the upper layer what > capabilities it has? Maybe MTU discovery? Or an app-level ack? I think > all of these options have already been discussed during the=20 > past years. > What is now in is a (fragile) consensus, but if only you do=20 > not like it, > I think we should go ahead and leave an unhappy Darren=20 > behind. If only I > insist on it, we can also go ahead and leave an unhappy Rainer behind. > But we need to go ahead! >=20 > Rainer=20 >=20 > > -----Original Message----- > > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > > Sent: Wednesday, November 30, 2005 4:49 PM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] #2, max message size > >=20 > > > Darren, > > >=20 > > > > The only place a message size limit should be specified is in=20 > > > > a transport > > > > mapping. If it's in -15 then it should be removed. Limits=20 > > > > of all sizes > > > > and types do nothing but contribute to aging of a protocol. > > >=20 > > > -protocol-15 is a compromise after a very long=20 > discussion. It says: > > >=20 > > > ----- > > > A receiver MUST be able to accept messages up to and=20 > > including 480 > > > octets in length. For interoperability reasons, all receiver > > > implementations SHOULD be able to accept messages up to=20 > > and including > > > 2,048 octets in length. > > >=20 > > > If a receiver receives a message with a length larger=20 > than 2,048 > > > octets, or larger than it supports, the receiver MAY=20 > discard the > > > message or truncate the payload. > > > ----- > > >=20 > > > I think this text is useful. It keeps the door open for any size > > > messages while still allowing it to be restricted by the transport > > > mappings and individual implementations (e.g. on low-end embedded > > > devices). It cautions implementors against being too=20 > > verbose but also > > > sets a lower limit that each implementation can assume to=20 > > be received. > > >=20 > > > I think we should continue to use this text. Do you agree? > >=20 > > No. That text doesn't belong in this draft. > >=20 > > Darren > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 12:16:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVZj-0000gD-T7; Wed, 30 Nov 2005 12:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVZj-0000f8-5l for syslog@megatron.ietf.org; Wed, 30 Nov 2005 12:16:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12449 for ; Wed, 30 Nov 2005 12:16:13 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhVu2-0002C2-PF for syslog@ietf.org; Wed, 30 Nov 2005 12:37:59 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id B8A699C00C; Wed, 30 Nov 2005 18:25:50 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09778-05; Wed, 30 Nov 2005 18:25:47 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 243AE9C00B; Wed, 30 Nov 2005 18:25:47 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 18:16:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F83@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Thread-Index: AcX1xW+MQ3Yy54YrTaO0j495D+fjnAACFdZw From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, sorry, but this one calls for a very blunt and direct answer... All others, this is flamish, but I can no longer stand it. Enough is enough. Complaints and flames please to me personally. Rainer > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Wednesday, November 30, 2005 4:48 PM > To: Rainer Gerhards > Cc: andrew@kiwisyslog.com; syslog@ietf.org > Subject: Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting >=20 > > Andrew, > >=20 > > > Also, if we are to transport syslog over TCP at some stage,=20 > > > we need to keep > > > a delimiter character free from use in the message. Again, a=20 > > > LF would be a > > > good choice for this delimiter. > >=20 > > Here, I disagree. I think we can not set aside a character=20 > for this. If > > we go for TCP, let's do octet-couting. Its reliable, efficient and > > proven. Anyhow, we are not yet doing a TCP mapping, so I=20 > suggest we save > > this discussion until later. >=20 > Why not use LF? Because we - the WG!!!! - have said we want to have the full character set available in the message. Search the archive. Read the drafts. I am tired of doing (re)search for you. I have better things to do than to support your lazyness. The past days, you've brought up a lot of arguments, declined proper queries on your own research (which seems to be non-existing, by the way), thrown in vaporware and shown that you do not know the contents of the drafts. Can you tell me a single reason why I should take your seriously? Ignorance is not a good replacement for evidence. > It will work. There are syslogd implementations about that use LF as > a record delimeter. In other emails you're saying "we must support > binary because some people are going to use this". Now we've=20 > got people > that support LF as a record delimeter already but you don't want to > take this into account. If we change that, we need to change the whole idea. Tell me a single implementation that relies on LF as terminator. On UDP. I know it is done in TCP, but that's a different story, because there it is not part of the message but part of the framing (I guess you understand the difference?). TCP needs to be redefined in any way. So, once again, would you please come up at least once with evidence for your claims? >=20 > Why does what one vendor is going to do mean more than what other > vendors are already doing ? Is there bias here somewhere ? Do you > have any particular preference based on work you've done or through > some sort of affiliation ? My preference is to finish *this* work. It doesn't help to restart this discussion. May I provide a quote from Marshall T. Rose in a similar situation in this WG: ### to carry your argument to its logical conclusion, no working group would ever actually produce any final document, because someone would always be free to introduce additional requirements for a just and noble cause. the ietf is about engineering, not perfection. engineering is about bounding a problem, looking at the tradeoffs, and coming up with a solution. the ietf is about fairness, not perfection. fairness is about providing an process that has transparency and closure. the time to raise these issues was when the group was developing the charter and negotiating it with the iesg... /mtr ### (see http://www.syslog.cc/ietf/autoarc/msg00336.html, Jan, 6 2001) Rergarding my affiliation and past experience: I have actually *implemented* EVERYTHING that currently exists in syslog. Even RFC 3195. Both on Windows and Linux. How about you and your experience and affiliation? [you even quote code without knowing how the iov[] is handled later on in F_FORW... poor guy...] > If you want to discount use of LF as a record delimeter then there > is no reason we must support use of binary because what vendors are > doing is obviously irrelevant. >=20 > Darren >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 12:37:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVtW-0005DV-DB; Wed, 30 Nov 2005 12:37:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVtV-0005DQ-Jy for syslog@megatron.ietf.org; Wed, 30 Nov 2005 12:37:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15283 for ; Wed, 30 Nov 2005 12:36:39 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhWDm-0002u3-K6 for syslog@ietf.org; Wed, 30 Nov 2005 12:58:23 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 8BCDA9C00C; Wed, 30 Nov 2005 18:46:14 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09778-09; Wed, 30 Nov 2005 18:46:10 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id D3FBD9C00B; Wed, 30 Nov 2005 18:46:10 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #2, max message size MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 18:37:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F87@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #2, max message size Thread-Index: AcX1xZE95BTFntBwQVmhyc5qaIfGMQACE1gQAADWXWAAAKm8YA== From: "Rainer Gerhards" To: "Moehrke, John (GE Healthcare)" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org John, the issue is the simplex nature of syslog. With syslog (other than with almost all other protocols), you send a message and need to *hope* that the recipient can receive it. There is also no negotiation phase. So you need to send it blindly. For example, if you send an IHE 2K message, but the receiver does just support 1K, you will loose 1K without knowing it. As such, it is vital to know at least a "safe size" that you can use and know that it can be processed (if it makes it to the recipient). We selected 480 octets because that fits into an unfragmented UDP packet in any case. I know that's too few for IHE, but for network management - an important use case for syslog - this is very often sufficient. This is the reason why a simplex protocol like syslog (send it and forget it ;)) should provide some guidance about lower limits. Keep in mind that there is NO upper limit - this is done in the transport mappings and the implementations. So if you need 32K for IHE, that is perfectly well (-transport-UDP, I think, suppport 64K - but you know the practical limits). Does this clarify? Rainer > -----Original Message----- > From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com]=20 > Sent: Wednesday, November 30, 2005 6:13 PM > To: Rainer Gerhards; Darren Reed > Cc: syslog@ietf.org > Subject: RE: [Syslog] #2, max message size >=20 > Shouldn't the MTU be defined by the binding to the transport?=20 > I fail to > see why the protocol, unbound to a transport, needs to have a limit.=20 >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Wednesday, November 30, 2005 11:01 AM > > To: Darren Reed > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] #2, max message size > >=20 > > Darren, > >=20 > > I violently object your argument and leave it up to the=20 > rest of the WG > > what should be done. I respect your argument, but I do not like to > > re-iterate this forever. > >=20 > > One time we have discussed this was in October 2004: > >=20 > > http://www.syslog.cc/ietf/autoarc/msg01289.html > >=20 > > If you browse the archive, you will find several other=20 > ocasions where > > this was discussed. > >=20 > > What's your actual recommendation? Do not say anything and=20 > > leave it the > > implementor to guess what is OK? After all, its the implementor's > > problem if the message can not be transmitted. Or do you prefer to > > define an API where the lower layer tells the upper layer what > > capabilities it has? Maybe MTU discovery? Or an app-level=20 > ack? I think > > all of these options have already been discussed during the=20 > > past years. > > What is now in is a (fragile) consensus, but if only you do=20 > > not like it, > > I think we should go ahead and leave an unhappy Darren=20 > > behind. If only I > > insist on it, we can also go ahead and leave an unhappy=20 > Rainer behind. > > But we need to go ahead! > >=20 > > Rainer=20 > >=20 > > > -----Original Message----- > > > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > > > Sent: Wednesday, November 30, 2005 4:49 PM > > > To: Rainer Gerhards > > > Cc: syslog@ietf.org > > > Subject: Re: [Syslog] #2, max message size > > >=20 > > > > Darren, > > > >=20 > > > > > The only place a message size limit should be specified is in=20 > > > > > a transport > > > > > mapping. If it's in -15 then it should be removed. Limits=20 > > > > > of all sizes > > > > > and types do nothing but contribute to aging of a protocol. > > > >=20 > > > > -protocol-15 is a compromise after a very long=20 > > discussion. It says: > > > >=20 > > > > ----- > > > > A receiver MUST be able to accept messages up to and=20 > > > including 480 > > > > octets in length. For interoperability reasons, all receiver > > > > implementations SHOULD be able to accept messages up to=20 > > > and including > > > > 2,048 octets in length. > > > >=20 > > > > If a receiver receives a message with a length larger=20 > > than 2,048 > > > > octets, or larger than it supports, the receiver MAY=20 > > discard the > > > > message or truncate the payload. > > > > ----- > > > >=20 > > > > I think this text is useful. It keeps the door open for any size > > > > messages while still allowing it to be restricted by=20 > the transport > > > > mappings and individual implementations (e.g. on=20 > low-end embedded > > > > devices). It cautions implementors against being too=20 > > > verbose but also > > > > sets a lower limit that each implementation can assume to=20 > > > be received. > > > >=20 > > > > I think we should continue to use this text. Do you agree? > > >=20 > > > No. That text doesn't belong in this draft. > > >=20 > > > Darren > > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 13:28:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWh2-00079i-4O; Wed, 30 Nov 2005 13:28:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWh1-00079b-3o for syslog@megatron.ietf.org; Wed, 30 Nov 2005 13:28:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22570 for ; Wed, 30 Nov 2005 13:27:48 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhX1K-00056Q-Jn for syslog@ietf.org; Wed, 30 Nov 2005 13:49:36 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 30 Nov 2005 10:28:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,196,1131350400"; d="scan'208"; a="16251721:sNHT23494416" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAUIRnmH006307; Wed, 30 Nov 2005 13:28:22 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 13:28:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Date: Wed, 30 Nov 2005 13:28:19 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C8624F@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Thread-Index: AcX1h7SbI1UpQR5YSI2HS+Fx0fm/awAU+I2A From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 30 Nov 2005 18:28:20.0660 (UTC) FILETIME=[D72CAF40:01C5F5DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Specifying the encoding makes sense to me. This way we can state that = only certain encoding support is required, but not preclude other = options. =20 We are still ok with always having UTF-8 in SD values, right?=20 We need this for foreign usernames. We have discussed this before. Thanks, Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, November 30, 2005 3:26 AM > To: syslog@ietf.org > Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting >=20 > Hi WG, >=20 > I have received notes via private mail telling me there seem=20 > to be some existing (and eventually soon upcoming) valid use=20 > cases for binary data in syslog. I think there is no point in=20 > arguing whether that's fortunate or not. It simply looks like=20 > that's the way it is. I do not like the idea of breaking=20 > existing use cases for syslog (because that will only lead to=20 > implementors ignoring the spec and the story of syslog=20 > inconsistencies continues...). As such, I think we need to=20 > provide at least some minimal support for it (aka "not outlaw it"). >=20 > At first, this implies that NUL octets may be present in the message. >=20 > I propose that we write text that discourages the use of NUL,=20 > but allows it if needed. That text should also allow, but=20 > discourage, a receiver to modify messages containing NUL.=20 > With that, we allow the use case, but do not make it a "show=20 > stopper" for implementing compliant software. This would also=20 > be pretty much in sync with what we currently find in=20 > practice, so it is already expected behaviour. Finally, such=20 > text would caution implementors that when NUL octets are=20 > present, chancs are high that eventually present digitial=20 > signatures will be broken. In my point of view, that's fair=20 > and efficient. >=20 > Chris proposal for #5 (character encoding) also provides an=20 > elegant solution for binary data. We can use something like: >=20 > [enc=3D"binary"] >=20 > or >=20 > [enc=3D"base-64"] >=20 > I do NOT intend to specify this - I think it should be in the=20 > scope of a separate document specifying the use of binary=20 > data. Then would also be the right time to discuss all issues=20 > that arise out of it. For now, I just would like to keep the=20 > door open. >=20 > Finally, I propose to extend Chris format so that the message=20 > size can be conveyed. This has been brought up several times=20 > and I think a clean solution is now obvious: >=20 > [enc=3D"utf-8" lang=3D"en" size=3D"MSG-size-in-octets"] >=20 > MSG-size-in-octets would be the size of the MSG part (just=20 > that!) in octets. Counting just the MSG part is sufficient,=20 > as the rest of the message consists of fields properly=20 > delimited. The size is probably most useful for binary data. >=20 > Please comment. >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 13:37:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWpP-0002II-Fg; Wed, 30 Nov 2005 13:37:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWpN-0002Hi-Qu for syslog@megatron.ietf.org; Wed, 30 Nov 2005 13:37:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24210 for ; Wed, 30 Nov 2005 13:36:27 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhX9e-0005XK-9z for syslog@ietf.org; Wed, 30 Nov 2005 13:58:14 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAUIanYX024092; Thu, 1 Dec 2005 05:36:49 +1100 (EST) From: Darren Reed Message-Id: <200511301836.jAUIagtm026610@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #2, max message size In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F87@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Thu, 1 Dec 2005 05:36:42 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > John, > > the issue is the simplex nature of syslog. With syslog (other than with > almost all other protocols), you send a message and need to *hope* that > the recipient can receive it. There is also no negotiation phase. So you > need to send it blindly. What you're failing to grasp here is that syslog-protocol, by itself, does not define how it is to be used. All it is doing is defining a message format. With a layered approach to defining syslog we need to split out documentation that is specific to an implementation (such as the maximum message size) from the definition of the protocol messages themselves. In your charter you have a "syslog-protocol over UDP". So any talk in syslog-protocol about maximum message size is going to be redundant for UDP. Using syslog-protocol over TCP is not yet on the radar so anyone making assumptions about maximum size is doing so at their own risk. If they choose 4K or 8K or 1K as the maximum size, that's up to them. If you really want to get back to basics, I'd not accept any maximum message size that was bigger than 490 bytes (576-14-64-8) as this is the largest frame size that IPv4 is *required* to reassemble. Either you remove the maximum message size from syslog-protocol or drop it to 490 but leave it open to refining by transport definitions. Yes, I'm well aware of 490 being "too small" for some practical purposes but you're not thinking clearly if you want any sort of maximum size in syslog-protocol and this needs to be reinforced. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 13:38:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWqy-00039O-2L; Wed, 30 Nov 2005 13:38:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhWqw-00039C-M8 for syslog@megatron.ietf.org; Wed, 30 Nov 2005 13:38:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24364 for ; Wed, 30 Nov 2005 13:38:04 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhXBH-0005ap-8A for syslog@ietf.org; Wed, 30 Nov 2005 13:59:51 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 30 Nov 2005 10:38:41 -0800 X-IronPort-AV: i="3.99,196,1131350400"; d="scan'208"; a="679833243:sNHT28375088" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAUIc6es012045; Wed, 30 Nov 2005 10:38:39 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 13:38:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Date: Wed, 30 Nov 2005 13:38:29 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C8625D@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Thread-Index: AcX1qHalJRZd2U7zR0qHnJArmh5mWAANK/Yg From: "Anton Okmianski \(aokmians\)" To: , X-OriginalArrivalTime: 30 Nov 2005 18:38:30.0546 (UTC) FILETIME=[42B1E720:01C5F5DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I think for TCP mapping a transport header with message size would be = more appropriate framing than termination character.=20 Thanks, Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Andrew Ross > Sent: Wednesday, November 30, 2005 7:19 AM > To: syslog@ietf.org > Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting >=20 >=20 > Rainer, >=20 > That sounds good to me at this stage, and it keeps the door=20 > open. I would prefer to see all binary data encoded in some=20 > "safe" format like base64. It just makes logging the data to=20 > file much easier. For instance, if the binary data contained=20 > a LF character, when it was logged to disk, it would end up=20 > as two separate messages when opened in notepad etc. >=20 > Also, if we are to transport syslog over TCP at some stage,=20 > we need to keep a delimiter character free from use in the=20 > message. Again, a LF would be a good choice for this delimiter. >=20 > Cheers >=20 > Andrew >=20 >=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Rainer Gerhards > Sent: Wednesday, 30 November 2005 9:26 p.m. > To: syslog@ietf.org > Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting >=20 >=20 > Hi WG, >=20 > I have received notes via private mail telling me there seem=20 > to be some existing (and eventually soon upcoming) valid use=20 > cases for binary data in syslog. I think there is no point in=20 > arguing whether that's fortunate or not. It simply looks like=20 > that's the way it is. I do not like the idea of breaking=20 > existing use cases for syslog (because that will only lead to=20 > implementors ignoring the spec and the story of syslog=20 > inconsistencies continues...). As such, I think we need to=20 > provide at least some minimal support for it (aka "not outlaw it"). >=20 > At first, this implies that NUL octets may be present in the message. >=20 > I propose that we write text that discourages the use of NUL,=20 > but allows it if needed. That text should also allow, but=20 > discourage, a receiver to modify messages containing NUL.=20 > With that, we allow the use case, but do not make it a "show=20 > stopper" for implementing compliant software. This would also=20 > be pretty much in sync with what we currently find in=20 > practice, so it is already expected behaviour. Finally, such=20 > text would caution implementors that when NUL octets are=20 > present, chancs are high that eventually present digitial=20 > signatures will be broken. In my point of view, that's fair=20 > and efficient. >=20 > Chris proposal for #5 (character encoding) also provides an=20 > elegant solution for binary data. We can use something like: >=20 > [enc=3D"binary"] >=20 > or >=20 > [enc=3D"base-64"] >=20 > I do NOT intend to specify this - I think it should be in the=20 > scope of a separate document specifying the use of binary=20 > data. Then would also be the right time to discuss all issues=20 > that arise out of it. For now, I just would like to keep the=20 > door open. >=20 > Finally, I propose to extend Chris format so that the message=20 > size can be conveyed. This has been brought up several times=20 > and I think a clean solution is now obvious: >=20 > [enc=3D"utf-8" lang=3D"en" size=3D"MSG-size-in-octets"] >=20 > MSG-size-in-octets would be the size of the MSG part (just=20 > that!) in octets. Counting just the MSG part is sufficient,=20 > as the rest of the message consists of fields properly=20 > delimited. The size is probably most useful for binary data. >=20 > Please comment. >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 13:51:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhX39-0008SN-GI; Wed, 30 Nov 2005 13:51:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhX38-0008S8-2w for syslog@megatron.ietf.org; Wed, 30 Nov 2005 13:51:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25828 for ; Wed, 30 Nov 2005 13:50:39 -0500 (EST) Received: from ext-nj2ut-3.online-age.net ([64.14.54.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhXNR-00063E-5I for syslog@ietf.org; Wed, 30 Nov 2005 14:12:27 -0500 Received: from int-nj2ut-1.online-age.net (int-nj2ut-1.online-age.net [3.159.237.70]) by ext-nj2ut-3.online-age.net (8.13.5/8.13.5/20051114-SVVS-TLS-DNSBL) with ESMTP id jAUIpEBG003563 for ; Wed, 30 Nov 2005 13:51:14 -0500 Received: from cinmlef03.e2k.ad.ge.com (localhost.localdomain [127.0.0.1]) by int-nj2ut-1.online-age.net (8.11.6/8.11.6/20050510-SVVS) with ESMTP id jAUIpEx16124 for ; Wed, 30 Nov 2005 13:51:14 -0500 Received: from MKEMLVEM07.e2k.ad.ge.com ([3.159.176.54]) by cinmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 13:51:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #2, max message size Date: Wed, 30 Nov 2005 12:51:12 -0600 Message-ID: <45A5295FFA1CBE4D9BF44E8534D2686C09BB7971@MKEMLVEM07.e2k.ad.ge.com> Thread-Topic: [Syslog] #2, max message size Thread-Index: AcX1xZE95BTFntBwQVmhyc5qaIfGMQACE1gQAADWXWAAAKm8YAACXlDw From: "Moehrke, John \(GE Healthcare\)" To: "Rainer Gerhards" X-OriginalArrivalTime: 30 Nov 2005 18:51:13.0133 (UTC) FILETIME=[093B71D0:01C5F5DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I understand the arguments that have been used, yes. I understand that in the end there will be a small practical MTU when transmitting over UDP (I would like it to be the 4k that your experiments determined, not 2K, or worse 480). I don't argue with that truth. I very simply fail to see why this is a syslog-protocol layer and not a transport-binding specification.=20 Side comment, not necessary for the document at hand: I also don't understand what I would do different if I could determine (in your words negotiate) what the MTU actually was. I have a message that needs to be sent, it will either make it or not. Knowing a dynamically determined MTU is of no value as I can't make my message smaller, it is what it is. If it gets fragmented, I hope it will be reassembled. If it is big, I hope that the receiver offers up a big enough buffer to it's socket library. It is all hope at this point. I am ok with hope, I just don't want you to limit my ability to hope. John > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Wednesday, November 30, 2005 11:37 AM > To: Moehrke, John (GE Healthcare) > Cc: syslog@ietf.org > Subject: RE: [Syslog] #2, max message size >=20 > John, >=20 > the issue is the simplex nature of syslog. With syslog (other=20 > than with > almost all other protocols), you send a message and need to=20 > *hope* that > the recipient can receive it. There is also no negotiation=20 > phase. So you > need to send it blindly. For example, if you send an IHE 2K=20 > message, but > the receiver does just support 1K, you will loose 1K without=20 > knowing it. > As such, it is vital to know at least a "safe size" that you=20 > can use and > know that it can be processed (if it makes it to the recipient). We > selected 480 octets because that fits into an unfragmented=20 > UDP packet in > any case. I know that's too few for IHE, but for network=20 > management - an > important use case for syslog - this is very often sufficient. This is > the reason why a simplex protocol like syslog (send it and=20 > forget it ;)) > should provide some guidance about lower limits. Keep in mind=20 > that there > is NO upper limit - this is done in the transport mappings and the > implementations. So if you need 32K for IHE, that is perfectly well > (-transport-UDP, I think, suppport 64K - but you know the practical > limits). >=20 > Does this clarify? >=20 > Rainer >=20 > > -----Original Message----- > > From: Moehrke, John (GE Healthcare)=20 > [mailto:John.Moehrke@med.ge.com]=20 > > Sent: Wednesday, November 30, 2005 6:13 PM > > To: Rainer Gerhards; Darren Reed > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] #2, max message size > >=20 > > Shouldn't the MTU be defined by the binding to the transport?=20 > > I fail to > > see why the protocol, unbound to a transport, needs to have=20 > a limit.=20 > >=20 > > > -----Original Message----- > > > From: syslog-bounces@lists.ietf.org=20 > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of=20 > Rainer Gerhards > > > Sent: Wednesday, November 30, 2005 11:01 AM > > > To: Darren Reed > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] #2, max message size > > >=20 > > > Darren, > > >=20 > > > I violently object your argument and leave it up to the=20 > > rest of the WG > > > what should be done. I respect your argument, but I do not like to > > > re-iterate this forever. > > >=20 > > > One time we have discussed this was in October 2004: > > >=20 > > > http://www.syslog.cc/ietf/autoarc/msg01289.html > > >=20 > > > If you browse the archive, you will find several other=20 > > ocasions where > > > this was discussed. > > >=20 > > > What's your actual recommendation? Do not say anything and=20 > > > leave it the > > > implementor to guess what is OK? After all, its the implementor's > > > problem if the message can not be transmitted. Or do you prefer to > > > define an API where the lower layer tells the upper layer what > > > capabilities it has? Maybe MTU discovery? Or an app-level=20 > > ack? I think > > > all of these options have already been discussed during the=20 > > > past years. > > > What is now in is a (fragile) consensus, but if only you do=20 > > > not like it, > > > I think we should go ahead and leave an unhappy Darren=20 > > > behind. If only I > > > insist on it, we can also go ahead and leave an unhappy=20 > > Rainer behind. > > > But we need to go ahead! > > >=20 > > > Rainer=20 > > >=20 > > > > -----Original Message----- > > > > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > > > > Sent: Wednesday, November 30, 2005 4:49 PM > > > > To: Rainer Gerhards > > > > Cc: syslog@ietf.org > > > > Subject: Re: [Syslog] #2, max message size > > > >=20 > > > > > Darren, > > > > >=20 > > > > > > The only place a message size limit should be=20 > specified is in=20 > > > > > > a transport > > > > > > mapping. If it's in -15 then it should be removed. Limits=20 > > > > > > of all sizes > > > > > > and types do nothing but contribute to aging of a protocol. > > > > >=20 > > > > > -protocol-15 is a compromise after a very long=20 > > > discussion. It says: > > > > >=20 > > > > > ----- > > > > > A receiver MUST be able to accept messages up to and=20 > > > > including 480 > > > > > octets in length. For interoperability reasons,=20 > all receiver > > > > > implementations SHOULD be able to accept messages up to=20 > > > > and including > > > > > 2,048 octets in length. > > > > >=20 > > > > > If a receiver receives a message with a length larger=20 > > > than 2,048 > > > > > octets, or larger than it supports, the receiver MAY=20 > > > discard the > > > > > message or truncate the payload. > > > > > ----- > > > > >=20 > > > > > I think this text is useful. It keeps the door open=20 > for any size > > > > > messages while still allowing it to be restricted by=20 > > the transport > > > > > mappings and individual implementations (e.g. on=20 > > low-end embedded > > > > > devices). It cautions implementors against being too=20 > > > > verbose but also > > > > > sets a lower limit that each implementation can assume to=20 > > > > be received. > > > > >=20 > > > > > I think we should continue to use this text. Do you agree? > > > >=20 > > > > No. That text doesn't belong in this draft. > > > >=20 > > > > Darren > > > >=20 > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 14:02:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXDf-00066Y-Fm; Wed, 30 Nov 2005 14:02:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXDe-000659-24 for syslog@megatron.ietf.org; Wed, 30 Nov 2005 14:02:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27259 for ; Wed, 30 Nov 2005 14:01:30 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhXXv-0006Tf-R1 for syslog@ietf.org; Wed, 30 Nov 2005 14:23:18 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAUJ26AD000383; Thu, 1 Dec 2005 06:02:06 +1100 (EST) From: Darren Reed Message-Id: <200511301901.jAUJ1m7O026787@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F83@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Thu, 1 Dec 2005 06:01:48 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Darren, > > > > > Also, if we are to transport syslog over TCP at some stage, > > > > we need to keep > > > > a delimiter character free from use in the message. Again, a > > > > LF would be a > > > > good choice for this delimiter. > > > > > > Here, I disagree. I think we can not set aside a character > > for this. If > > > we go for TCP, let's do octet-couting. Its reliable, efficient and > > > proven. Anyhow, we are not yet doing a TCP mapping, so I > > suggest we save > > > this discussion until later. > > > > Why not use LF? > > Because we - the WG!!!! - have said we want to have the full character > set available in the message. Search the archive. Read the drafts. I am > tired of doing (re)search for you. I have better things to do than to > support your lazyness. I don't see why having a full character set available in a message means that you can't chose to select a particular character for an EOR marker. Protocols everywhere use special characters for this or that yet there are no restrictions on what messages they convey. Maybe I'm confusing implementation detail with protocol specification by asking for LF be used as a EOR marker. So, you're right, we shouldn't set aside any particular character to mean EOR in syslog-protocol, that should be left up to the construction of syslog over each protocol. Do you agree on that? > My preference is to finish *this* work. It doesn't help to restart this > discussion. May I provide a quote from Marshall T. Rose in a similar > situation in this WG: Marshall T Rose is responsible for 3195 and that could be considered to be a failure by many. > How about you and your experience and affiliation? I was the focal point of a lot of people wanting to do work on the syslog protocol before the WG formed. At the first syslog IETF BOF I gave a small presentation on the work I'd done to implement syslog over TCP, including using SSL as the transport with the transfer of hashes and storing them on disk. At the first BOF there was a large room full of a lot of people, a far cry from the numbers in Vancouver. The syslog replacement I wrote over 5 years ago was the basis of the work that has resulted in syslog-ng for Linux, even though today it no longer even closely resembles what I did originally. I, like many I suspect, became disenchanted with the direction of the group when it started to go down the road that led to 3195 and I just lost interest for a long time because I did not have the energy to put into fighitng it. In this group, I represent myself. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 14:07:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXJ3-0007xD-IB; Wed, 30 Nov 2005 14:07:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXJ2-0007x2-9P for syslog@megatron.ietf.org; Wed, 30 Nov 2005 14:07:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27829 for ; Wed, 30 Nov 2005 14:07:05 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhXdM-0006fw-53 for syslog@ietf.org; Wed, 30 Nov 2005 14:28:53 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 30 Nov 2005 11:07:42 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAUJ7es3005578 for ; Wed, 30 Nov 2005 11:07:40 -0800 (PST) Date: Wed, 30 Nov 2005 11:07:40 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org In-Reply-To: <200511301836.jAUIagtm026610@firewall.reed.wattle.id.au> Message-ID: References: <200511301836.jAUIagtm026610@firewall.reed.wattle.id.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Syslog] #2, max message size - Need to resolve this X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Folks, We need to resolve this one. I've heard from Rainer and a very few others. I'd like to hear from more people on this. Choose one: __ The maximum message length needs to be defined in syslog-protocol. __ The maximum message length should be defined in the transport documents. __ I have a different idea.... Please VOTE NOW! Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 14:13:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXOM-0002O6-If; Wed, 30 Nov 2005 14:13:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXOL-0002Mw-Ci for syslog@megatron.ietf.org; Wed, 30 Nov 2005 14:13:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28678 for ; Wed, 30 Nov 2005 14:12:34 -0500 (EST) Received: from dsl254-102-222.nyc1.dsl.speakeasy.net ([216.254.102.222] helo=gandalf.taltos.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhXie-0006uK-TM for syslog@ietf.org; Wed, 30 Nov 2005 14:34:22 -0500 Received: from gandalf.taltos.org (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id 4FD7F21B75 for ; Wed, 30 Nov 2005 14:13:07 -0500 (EST) Received: from localhost.localdomain (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id 266B121B70 for ; Wed, 30 Nov 2005 14:13:07 -0500 (EST) Date: Wed, 30 Nov 2005 14:13:06 -0500 From: Carson Gaspar To: syslog@ietf.org Subject: Re: [Syslog] #2, max message size - Need to resolve this Message-ID: <9066DD6A742B54DE85B88C6F@gaspac.ny.ficc.gs.com> In-Reply-To: References: <200511301836.jAUIagtm026610@firewall.reed.wattle.id.au> X-Mailer: Mulberry/4.0.0b4 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on gandalf.taltos.org X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org --On Wednesday, November 30, 2005 11:07:40 AM -0800 Chris Lonvick wrote: > Hi Folks, > > We need to resolve this one. I've heard from Rainer and a very few > others. I'd like to hear from more people on this. Choose one: ... > __ The maximum message length should be defined in the transport > documents. ... It's a transport issue. We may want to specify a "minimum maximum" - i.e. a syslog receiver MUST be able to handle messages of at least n octets, but that probably also belongs in the transport doc. -- Carson _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 14:26:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXbL-0000E9-2l; Wed, 30 Nov 2005 14:26:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXbJ-0000E4-C7 for syslog@megatron.ietf.org; Wed, 30 Nov 2005 14:26:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00230 for ; Wed, 30 Nov 2005 14:25:58 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhXvc-0007Ob-Mb for syslog@ietf.org; Wed, 30 Nov 2005 14:47:46 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jAUJQVDC026850; Thu, 1 Dec 2005 06:26:31 +1100 (EST) From: Darren Reed Message-Id: <200511301926.jAUJQI65021936@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #7 field order In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F60@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Thu, 1 Dec 2005 06:26:18 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > WG, > > there has not been much discussion about the header fields and their > order recently. I think this is a sign the issue has been settled. To > make sure I got the right understanding of the resulting consensus, I > propose that we use the following format: > > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP > [SD-ID]s SP MSG > > That is the format that also proven to be quite useful during my > proof-of-concept implementation. > > If somebody objects, please do that now. In your other email, you say that "-" is for a missing field - I was curious about whether all fields were mandatory or what was to be done if you wanted to miss one out, but you've answered that. The "HOSTNAME" field should be constrained, in its definition, to match that accepted for FQDNs. "PRINTUSASCII" is too wide. I believe you need to read RFC 1035. Similarly, I'd like to see APP-NAME, PROCID and MSGID refined to be less than the entire character set. A contradiction in syslog-protocol is allowing PRINTUSASCII for fields but a field of "-" is used to indicate it is not there. The only thing I would like to see considered is keeping a ':' to mark end of headers and start of message. Or is this pointless ? I'm thinking from a perspective of parsing them with awk/grep. If, for example, I can search for either ']: ' or '-: ' and know that what follows would be the message....is that sensible ? Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 14:28:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXcs-0000sm-AH; Wed, 30 Nov 2005 14:28:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXcq-0000sS-Pm for syslog@megatron.ietf.org; Wed, 30 Nov 2005 14:28:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00470 for ; Wed, 30 Nov 2005 14:27:33 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhXxB-0007Sd-DD for syslog@ietf.org; Wed, 30 Nov 2005 14:49:21 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 30 Nov 2005 11:28:11 -0800 X-IronPort-AV: i="3.99,196,1131350400"; d="scan'208"; a="372214907:sNHT808528922" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAUJS9CP000899; Wed, 30 Nov 2005 11:28:10 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 14:28:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #2, max message size Date: Wed, 30 Nov 2005 14:28:02 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C8629C@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] #2, max message size Thread-Index: AcX1xZE95BTFntBwQVmhyc5qaIfGMQACE1gQAARF+0A= From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , "Darren Reed" X-OriginalArrivalTime: 30 Nov 2005 19:28:03.0499 (UTC) FILETIME=[2EB687B0:01C5F5E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org The draft text does not set a limit on maximum size. It sets a minimum = support boundary, which simplifies the basic interop. Is it a problem?=20 The reason for the minimum size to be specified in message protocol and = not the transport was to sets the basic expectation for minimum support = from transport mappings.=20 For example, if I have a system that fires messages to a sender = sub-system and the sender-subsystem can be configured to use a number of = transport binding... What is the minimum message I am guaranteed that = all receivers will support regardless of the transport used? This = information can be critical when you design some important messages.=20 Of course, specifying a minimum required support in each transport = mapping is also appropriate. In fact, syslog-transport-udp sets two = separate minimums: for IPv4 and IPv6. If we did not specify a minimum in = syslog-protocol, one can infer the minimum based on the least common = denominator of transport protocol used. That's fair. But I just don't = see a harm in what was done in the current draft (after very long = discussions I might add). I can only a see a very hypothetical scenario = where some future transport protocol has MTU smaller than the what IPv4 = and IPv6 uses. In this case a minimum requirement may be problematic. = How much lower than 480 octets can it go with a ~100-octet syslog = header? =20 Thanks, Anton.=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, November 30, 2005 12:01 PM > To: Darren Reed > Cc: syslog@ietf.org > Subject: RE: [Syslog] #2, max message size >=20 > Darren, >=20 > I violently object your argument and leave it up to the rest=20 > of the WG what should be done. I respect your argument, but I=20 > do not like to re-iterate this forever. >=20 > One time we have discussed this was in October 2004: >=20 > http://www.syslog.cc/ietf/autoarc/msg01289.html >=20 > If you browse the archive, you will find several other=20 > ocasions where this was discussed. >=20 > What's your actual recommendation? Do not say anything and=20 > leave it the implementor to guess what is OK? After all, its=20 > the implementor's problem if the message can not be=20 > transmitted. Or do you prefer to define an API where the=20 > lower layer tells the upper layer what capabilities it has?=20 > Maybe MTU discovery? Or an app-level ack? I think all of=20 > these options have already been discussed during the past years. > What is now in is a (fragile) consensus, but if only you do=20 > not like it, I think we should go ahead and leave an unhappy=20 > Darren behind. If only I insist on it, we can also go ahead=20 > and leave an unhappy Rainer behind. > But we need to go ahead! >=20 > Rainer=20 >=20 > > -----Original Message----- > > From: Darren Reed [mailto:darrenr@reed.wattle.id.au] > > Sent: Wednesday, November 30, 2005 4:49 PM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] #2, max message size > >=20 > > > Darren, > > >=20 > > > > The only place a message size limit should be specified is in a=20 > > > > transport mapping. If it's in -15 then it should be removed. =20 > > > > Limits of all sizes and types do nothing but contribute=20 > to aging=20 > > > > of a protocol. > > >=20 > > > -protocol-15 is a compromise after a very long=20 > discussion. It says: > > >=20 > > > ----- > > > A receiver MUST be able to accept messages up to and > > including 480 > > > octets in length. For interoperability reasons, all receiver > > > implementations SHOULD be able to accept messages up to > > and including > > > 2,048 octets in length. > > >=20 > > > If a receiver receives a message with a length larger=20 > than 2,048 > > > octets, or larger than it supports, the receiver MAY=20 > discard the > > > message or truncate the payload. > > > ----- > > >=20 > > > I think this text is useful. It keeps the door open for any size=20 > > > messages while still allowing it to be restricted by the=20 > transport=20 > > > mappings and individual implementations (e.g. on low-end embedded=20 > > > devices). It cautions implementors against being too > > verbose but also > > > sets a lower limit that each implementation can assume to > > be received. > > >=20 > > > I think we should continue to use this text. Do you agree? > >=20 > > No. That text doesn't belong in this draft. > >=20 > > Darren > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 15:07:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYEV-0006Rc-96; Wed, 30 Nov 2005 15:07:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYET-0006R6-BH for syslog@megatron.ietf.org; Wed, 30 Nov 2005 15:07:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05767 for ; Wed, 30 Nov 2005 15:06:26 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhYXO-0000nT-W9 for syslog@ietf.org; Wed, 30 Nov 2005 15:26:48 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2005 12:05:36 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAUK4c7E020431; Wed, 30 Nov 2005 12:05:33 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 15:05:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #2, max message size Date: Wed, 30 Nov 2005 15:05:31 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C862DC@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] #2, max message size Thread-Index: AcX13Un62ZeXtQ+AT8GD7ARZPsdQWAACOLFg From: "Anton Okmianski \(aokmians\)" To: "Darren Reed" , "Rainer Gerhards" X-OriginalArrivalTime: 30 Nov 2005 20:05:32.0673 (UTC) FILETIME=[6B533F10:01C5F5E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren: > If you really want to get back to basics, I'd not accept any=20 > maximum message size that was bigger than 490 bytes=20 > (576-14-64-8) as this is the largest frame size that IPv4 is=20 > *required* to reassemble. Either you remove the maximum=20 > message size from syslog-protocol or drop it to 490 but leave=20 > it open to refining by transport definitions. Yes, I'm well=20 > aware of 490 being "too small" for some practical purposes=20 > but you're not thinking clearly if you want any sort of=20 > maximum size in syslog-protocol and this needs to be reinforced. Before saying that somebody is not thinking clearly you should read what = they sent you (if not the draft that is being discussed). =20 There is NO maximum message size defined in syslog-protocol draft! = Rainer sent you a copy of relevant text as part of this thread too. It = only defined a minimum size receivers must be able to process. That's = all. =20 A lot of your remarks come across very inflammatory, especially when = they reflect that you are have not read the drafts. Could you calm down = the rhetoric maybe and do some home work? Every email from you seems to = scream that we are bunch of morons who don't know what they are doing, = and you have come to save us from our misery. I don't think it is the = most productive way to get your arguments across. There are a lot of = knowledgeable people in this WG.=20 And thanks for the re-education about the minimum MTU. If you paid any = attention to what this WG has done over the last two years or cared to = read the archives (which even Rainer has done when discussing issues = with you), you would have known that all these issues have been = discussed at length here. How about read the syslog-protocol-udp draft = (sec 3.2)? Anton.=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 15:12:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYJX-0007km-AT; Wed, 30 Nov 2005 15:12:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYJW-0007iA-75 for syslog@megatron.ietf.org; Wed, 30 Nov 2005 15:12:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06823 for ; Wed, 30 Nov 2005 15:11:39 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhYdq-0001EJ-Ck for syslog@ietf.org; Wed, 30 Nov 2005 15:33:28 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2005 12:12:16 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAUKBePH026766 for ; Wed, 30 Nov 2005 12:12:13 -0800 (PST) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 12:12:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Date: Wed, 30 Nov 2005 12:12:07 -0800 Message-ID: <0DF8CBE327D4654F8567FD8123E328B1010A4D02@xmb-sjc-237.amer.cisco.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcX1rsL49xfl95orTnizHijWuBf+FgAOlsFQ From: "Shyyunn Lin \(sheranl\)" To: "Chris Lonvick \(clonvick\)" X-OriginalArrivalTime: 30 Nov 2005 20:12:08.0468 (UTC) FILETIME=[573CC540:01C5F5EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris: I agree with all your points. Recommend an encoding and standard lang tag, and accept all other encoding and lang specification. Regards, =20 Sheran -----Original Message----- From: Chris Lonvick (clonvick)=20 Sent: Wednesday, November 30, 2005 5:06 AM To: Shyyunn Lin (sheranl) Cc: syslog@ietf.org Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Hi Sheran, On Tue, 29 Nov 2005, Shyyunn Lin (sheranl) wrote: > Chris: > > I think having SD-ID with [enc=3D"utf-8" lang=3D"English"] may be a = good=20 > approach. If different language use utf-8 encoding, then "lang=3D" can = > distinguish it. We _should_ be using language codes from RFC 3066. That specifies ISO 639 language tags. 639-1 has 2 character codes ("en" is English) and 639-2 has 3 characters ("eng" is English). RFC 3066 will likely be replaced by the works of the Language Tag Registry Update (ltru) Working Group. http://www.ietf.org/html.charters/ltru-charter.html They have IDs in the works. Until those become RFCs we should continue to reference RFC 3066. > > Also want to clarify that you suggest that if the message is in ASCII, > it will not required SD-ID, but for all other encodings, SD-ID will be > required. Yes - that's my suggestion. > > Note most other encoding methods already imply the language used, for=20 > example, in Chinese, there are several encoding methods, Traditional=20 > Chinese used in Taiwan and Hong Kong is Big5, and simplified Chinese=20 > used in Mainland China is GBK, so if the message is in traditional=20 > Chinese char, it will be shown as [enc=3D"Big5", lang=3D"Traditional=20 > Chinese"], a little bit redundant. The Big5 also includes all English=20 > char so it can be a mix of Chinese and English. Good point. As far as I can tell, "Big5" is not recognized by any accredited standards developing organization. It is recognized by the Ideographic Rapporteur Group (IRG) which reports to the Unicode consortium. The recognized way to represent Chinese characters, traditional and simplified, is through ISO 639-2 with the subcodes to indicate traditional and simplified for the "zh" _language_. The ID on "Tags for Identifying Languages" http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt identifies simplified Chinese as "zh-Hans" and traditional Chinese as "zh-Hant". Additional subtags could identify a locale such as "zh-Hant-TW" for Taiwan Chinese in traditional script. This is from the "Initial Language Subtag Registry" ID. http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-06.txt I think that we should specify encoding and language tags as striaghtforward as possible and let others augment syslog-protocol (in the future) with other encoding mechanisms. We can RECOMMEND that encoding be in UTF-8 and language tags come from RFC 3066. We can allow that other encoding and language identifications are acceptable. In the worst case, a vendor will have the option of [enc@9=3D"something" lang@9=3D"piglatin"]. Does this work for you? Thanks, Chris > > > > Regards, > > Sheran > > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > (clonvick) > Sent: Tuesday, November 29, 2005 10:22 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) > > Hi Rainer, > > Why don't we look at it from the other direction? We could state that > any encoding is acceptable - for ease-of-use/migration with existing=20 > syslog implementations. It is RECOMMENDED that UTF-8 be used. When=20 > it is used, an SD-ID element will be REQUIRED. e.g. - [enc=3D"utf-8" > lang=3D"en"] > > Thoughts? > > All: Let's discuss this and close this issue. > > Thanks, > Chris > > On Tue, 29 Nov 2005, Rainer Gerhards wrote: > >> Chris & WG, >> >>>> #5 Character encoding in MSG: due to my proof-of-concept >>>> implementation, I have raised the (ugly) question if we need >>>> to allow encodings other than UTF-8. Please note that this >>>> question arises from needs introduced by e.g. POSIX. So we >>>> can't easily argue them away by whishful thinking ;) >>>> >>>> Not even discussed yet. >>> >>> I haven't reviewed that yet. However, I'll note that allowing=20 >>> different encoding can be accomplished in the future as long as we=20 >>> establish a default encoding and a way to identify it in our current >>> work. >> >> I have read a little in the mailing archive. Please note that in 2000 >> it was consensus that the MSG part may contain encodings other then=20 >> US-ASCII. Follow this threat: >> >> http://www.syslog.cc/ietf/autoarc/msg00127.html >> >> This discussion lead to RFC 3164 saying "other encodings MAY be used". >> While this was observed behaviour, we need still to be aware that the >> POSIX (and glibc) API places the restrictions on us that we simply do >> not know the character encoding used by the application. As such, no=20 >> *nix syslogd can be programmed to be compliant to syslog-protocol if=20 >> we demand UTF-8 exclusively. >> >> I propose that we RECOMMEND UTF-8 that MUST start with the Unicode=20 >> Byte Order Mask (BOM) if used. If the MSG part does not start with=20 >> the > >> BOM, it may be any encoding just as in RFC 3164. I do not see any=20 >> alternative to this. >> >> Rainer >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 15:13:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYKI-0007sG-7x; Wed, 30 Nov 2005 15:13:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYKG-0007sB-CN for syslog@megatron.ietf.org; Wed, 30 Nov 2005 15:13:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06966 for ; Wed, 30 Nov 2005 15:12:25 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhYeb-0001Gx-Bp for syslog@ietf.org; Wed, 30 Nov 2005 15:34:14 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id E96F19C00C; Wed, 30 Nov 2005 21:22:03 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10073-07; Wed, 30 Nov 2005 21:22:00 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 3C8E79C00B; Wed, 30 Nov 2005 21:22:00 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 30 Nov 2005 21:12:57 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABAB6B2@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Thread-Index: AcX1h7SbI1UpQR5YSI2HS+Fx0fm/awAU+I2AAAOtZvA= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton: > Specifying the encoding makes sense to me. This way we can=20 > state that only certain encoding support is required, but not=20 > preclude other options. =20 >=20 > We are still ok with always having UTF-8 in SD values, right?=20 Yes, I was talking exclusively about MSG. I expect SD values to be written by newer software only. There is no POSIX API for it, so we can't have an issue with that API ;) Rainer > We need this for foreign usernames. We have discussed this before. >=20 > Thanks, > Anton. =20 >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Wednesday, November 30, 2005 3:26 AM > > To: syslog@ietf.org > > Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting > >=20 > > Hi WG, > >=20 > > I have received notes via private mail telling me there seem > > to be some existing (and eventually soon upcoming) valid use=20 > > cases for binary data in syslog. I think there is no point in=20 > > arguing whether that's fortunate or not. It simply looks like=20 > > that's the way it is. I do not like the idea of breaking=20 > > existing use cases for syslog (because that will only lead to=20 > > implementors ignoring the spec and the story of syslog=20 > > inconsistencies continues...). As such, I think we need to=20 > > provide at least some minimal support for it (aka "not outlaw it"). > >=20 > > At first, this implies that NUL octets may be present in=20 > the message. > >=20 > > I propose that we write text that discourages the use of NUL, > > but allows it if needed. That text should also allow, but=20 > > discourage, a receiver to modify messages containing NUL.=20 > > With that, we allow the use case, but do not make it a "show=20 > > stopper" for implementing compliant software. This would also=20 > > be pretty much in sync with what we currently find in=20 > > practice, so it is already expected behaviour. Finally, such=20 > > text would caution implementors that when NUL octets are=20 > > present, chancs are high that eventually present digitial=20 > > signatures will be broken. In my point of view, that's fair=20 > > and efficient. > >=20 > > Chris proposal for #5 (character encoding) also provides an > > elegant solution for binary data. We can use something like: > >=20 > > [enc=3D"binary"] > >=20 > > or > >=20 > > [enc=3D"base-64"] > >=20 > > I do NOT intend to specify this - I think it should be in the > > scope of a separate document specifying the use of binary=20 > > data. Then would also be the right time to discuss all issues=20 > > that arise out of it. For now, I just would like to keep the=20 > > door open. > >=20 > > Finally, I propose to extend Chris format so that the message > > size can be conveyed. This has been brought up several times=20 > > and I think a clean solution is now obvious: > >=20 > > [enc=3D"utf-8" lang=3D"en" size=3D"MSG-size-in-octets"] > >=20 > > MSG-size-in-octets would be the size of the MSG part (just > > that!) in octets. Counting just the MSG part is sufficient,=20 > > as the rest of the message consists of fields properly=20 > > delimited. The size is probably most useful for binary data. > >=20 > > Please comment. > >=20 > > Rainer > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 15:15:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYMC-0008Ll-Vk; Wed, 30 Nov 2005 15:15:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYMB-0008Kg-1f for syslog@megatron.ietf.org; Wed, 30 Nov 2005 15:15:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07200 for ; Wed, 30 Nov 2005 15:14:24 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhYgV-0001Km-Hv for syslog@ietf.org; Wed, 30 Nov 2005 15:36:12 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2005 12:15:00 -0800 X-IronPort-AV: i="3.99,196,1131350400"; d="scan'208"; a="235790059:sNHT25733368" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAUKE870026694 for ; Wed, 30 Nov 2005 12:14:58 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 15:14:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #2, max message size - Need to resolve this Date: Wed, 30 Nov 2005 15:14:57 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122C862EB@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] #2, max message size - Need to resolve this Thread-Index: AcX14ZBvC/XEWoUTRLG4KK/Ap4gAOgACNMRA From: "Anton Okmianski \(aokmians\)" To: "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 30 Nov 2005 20:14:57.0744 (UTC) FILETIME=[BC223D00:01C5F5EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I vote for a different idea... As in latest syslog-protocol, define only = the minimum message size the receivers is required to accept. I vote for = defining it in both. Syslog-protocol defines the least common agreed = upon denominator. Transport defines the minimum that is appropriate for = the transport, which can be higher if needed. Thus, if a receiver = implements a syslog protocol and a given transport, it has to meet both = requirements.=20 Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris=20 > Lonvick (clonvick) > Sent: Wednesday, November 30, 2005 2:08 PM > To: syslog@ietf.org > Subject: [Syslog] #2, max message size - Need to resolve this >=20 > Hi Folks, >=20 > We need to resolve this one. I've heard from Rainer and a=20 > very few others. I'd like to hear from more people on this. =20 > Choose one: >=20 > __ The maximum message length needs to be defined in syslog-protocol. >=20 >=20 > __ The maximum message length should be defined in the transport > documents. >=20 >=20 > __ I have a different idea.... >=20 >=20 > Please VOTE NOW! >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 15:46:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYqW-0007q7-El; Wed, 30 Nov 2005 15:46:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYqV-0007q1-JL for syslog@megatron.ietf.org; Wed, 30 Nov 2005 15:46:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10900 for ; Wed, 30 Nov 2005 15:45:46 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZAq-0002Um-BM for syslog@ietf.org; Wed, 30 Nov 2005 16:07:33 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 30 Nov 2005 12:46:21 -0800 X-IronPort-AV: i="3.99,196,1131350400"; d="scan'208"; a="679867657:sNHT27648884" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAUKjnew015857 for ; Wed, 30 Nov 2005 12:46:19 -0800 (PST) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 12:46:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #2, max message size - Need to resolve this Date: Wed, 30 Nov 2005 12:46:02 -0800 Message-ID: Thread-Topic: [Syslog] #2, max message size - Need to resolve this Thread-Index: AcX14ZBvC/XEWoUTRLG4KK/Ap4gAOgACNMRAAAEMexA= From: "Steve Chang \(schang99\)" To: "Anton Okmianski \(aokmians\)" , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 30 Nov 2005 20:46:02.0251 (UTC) FILETIME=[13776DB0:01C5F5EF] X-Spam-Score: 0.9 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I agree with Anton's wording and view. Instead of capping the size maximally that a syslog receiver is to support, it should be the minimum size that it should support. Steve > -----Original Message----- > From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Anton Okmianski (aokmians) > Sent: Wednesday, November 30, 2005 12:15 PM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] #2, max message size - Need to resolve this >=20 > I vote for a different idea... As in latest syslog-protocol, define only > the minimum message size the receivers is required to accept. I vote for > defining it in both. Syslog-protocol defines the least common agreed upon > denominator. Transport defines the minimum that is appropriate for the > transport, which can be higher if needed. Thus, if a receiver implements > a syslog protocol and a given transport, it has to meet both requirements. >=20 > Anton. >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris > > Lonvick (clonvick) > > Sent: Wednesday, November 30, 2005 2:08 PM > > To: syslog@ietf.org > > Subject: [Syslog] #2, max message size - Need to resolve this > > > > Hi Folks, > > > > We need to resolve this one. I've heard from Rainer and a > > very few others. I'd like to hear from more people on this. > > Choose one: > > > > __ The maximum message length needs to be defined in syslog-protocol. > > > > > > __ The maximum message length should be defined in the transport > > documents. > > > > > > __ I have a different idea.... > > > > > > Please VOTE NOW! > > > > Thanks, > > Chris > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 15:48:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYsD-0008Tj-1U; Wed, 30 Nov 2005 15:48:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYs9-0008Sj-7G for syslog@megatron.ietf.org; Wed, 30 Nov 2005 15:48:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11085 for ; Wed, 30 Nov 2005 15:47:28 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZCU-0002ZN-Gq for syslog@ietf.org; Wed, 30 Nov 2005 16:09:15 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 7FF149C00C; Wed, 30 Nov 2005 21:57:05 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10153-07; Wed, 30 Nov 2005 21:56:59 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id B2FAE9C00B; Wed, 30 Nov 2005 21:56:59 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #2, max message size MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 21:47:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABAB6B3@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #2, max message size Thread-Index: AcX1xZE95BTFntBwQVmhyc5qaIfGMQACE1gQAADWXWAAAKm8YAACXlDwAARY/3A= From: "Rainer Gerhards" To: "Moehrke, John (GE Healthcare)" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org John, > I understand the arguments that have been used, yes. I=20 > understand that in the end there will be a small practical=20 > MTU when transmitting over UDP (I would like it to be the 4k=20 > that your experiments determined, not 2K, or worse 480). I=20 > don't argue with that truth. I very simply fail to see why=20 > this is a syslog-protocol layer and not a transport-binding=20 > specification.=20 >=20 > Side comment, not necessary for the document at hand: I also=20 > don't understand what I would do different if I could=20 > determine (in your words > negotiate) what the MTU actually was. At least three options - abbreviate things (in human-readable text) - truncate things you know to be less important - do application level segmentation > I have a message that=20 > needs to be sent, it will either make it or not. Knowing a=20 > dynamically determined MTU is of no value as I can't make my=20 > message smaller, it is what it is. If it gets fragmented, I=20 > hope it will be reassembled. If it is big, I hope that the=20 > receiver offers up a big enough buffer to it's socket=20 > library. It is all hope at this point. I am ok with hope, I=20 > just don't want you to limit my ability to hope. -protocol-15 does not limit your abilit to hope. It limits your worst case, because you know what minimum length support you can expect. ;) Rainer > John >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Wednesday, November 30, 2005 11:37 AM > > To: Moehrke, John (GE Healthcare) > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] #2, max message size > >=20 > > John, > >=20 > > the issue is the simplex nature of syslog. With syslog (other > > than with > > almost all other protocols), you send a message and need to=20 > > *hope* that > > the recipient can receive it. There is also no negotiation=20 > > phase. So you > > need to send it blindly. For example, if you send an IHE 2K=20 > > message, but > > the receiver does just support 1K, you will loose 1K without=20 > > knowing it. > > As such, it is vital to know at least a "safe size" that you=20 > > can use and > > know that it can be processed (if it makes it to the recipient). We > > selected 480 octets because that fits into an unfragmented=20 > > UDP packet in > > any case. I know that's too few for IHE, but for network=20 > > management - an > > important use case for syslog - this is very often=20 > sufficient. This is > > the reason why a simplex protocol like syslog (send it and=20 > > forget it ;)) > > should provide some guidance about lower limits. Keep in mind=20 > > that there > > is NO upper limit - this is done in the transport mappings and the > > implementations. So if you need 32K for IHE, that is perfectly well > > (-transport-UDP, I think, suppport 64K - but you know the practical > > limits). > >=20 > > Does this clarify? > >=20 > > Rainer > >=20 > > > -----Original Message----- > > > From: Moehrke, John (GE Healthcare) > > [mailto:John.Moehrke@med.ge.com] > > > Sent: Wednesday, November 30, 2005 6:13 PM > > > To: Rainer Gerhards; Darren Reed > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] #2, max message size > > >=20 > > > Shouldn't the MTU be defined by the binding to the transport? > > > I fail to > > > see why the protocol, unbound to a transport, needs to have=20 > > a limit. > > >=20 > > > > -----Original Message----- > > > > From: syslog-bounces@lists.ietf.org > > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of=20 > > Rainer Gerhards > > > > Sent: Wednesday, November 30, 2005 11:01 AM > > > > To: Darren Reed > > > > Cc: syslog@ietf.org > > > > Subject: RE: [Syslog] #2, max message size > > > >=20 > > > > Darren, > > > >=20 > > > > I violently object your argument and leave it up to the > > > rest of the WG > > > > what should be done. I respect your argument, but I do=20 > not like to=20 > > > > re-iterate this forever. > > > >=20 > > > > One time we have discussed this was in October 2004: > > > >=20 > > > > http://www.syslog.cc/ietf/autoarc/msg01289.html > > > >=20 > > > > If you browse the archive, you will find several other > > > ocasions where > > > > this was discussed. > > > >=20 > > > > What's your actual recommendation? Do not say anything and > > > > leave it the > > > > implementor to guess what is OK? After all, its the=20 > implementor's > > > > problem if the message can not be transmitted. Or do=20 > you prefer to > > > > define an API where the lower layer tells the upper layer what > > > > capabilities it has? Maybe MTU discovery? Or an app-level=20 > > > ack? I think > > > > all of these options have already been discussed during the > > > > past years. > > > > What is now in is a (fragile) consensus, but if only you do=20 > > > > not like it, > > > > I think we should go ahead and leave an unhappy Darren=20 > > > > behind. If only I > > > > insist on it, we can also go ahead and leave an unhappy=20 > > > Rainer behind. > > > > But we need to go ahead! > > > >=20 > > > > Rainer > > > >=20 > > > > > -----Original Message----- > > > > > From: Darren Reed [mailto:darrenr@reed.wattle.id.au] > > > > > Sent: Wednesday, November 30, 2005 4:49 PM > > > > > To: Rainer Gerhards > > > > > Cc: syslog@ietf.org > > > > > Subject: Re: [Syslog] #2, max message size > > > > >=20 > > > > > > Darren, > > > > > >=20 > > > > > > > The only place a message size limit should be > > specified is in > > > > > > > a transport > > > > > > > mapping. If it's in -15 then it should be=20 > removed. Limits > > > > > > > of all sizes > > > > > > > and types do nothing but contribute to aging of a=20 > protocol. > > > > > >=20 > > > > > > -protocol-15 is a compromise after a very long > > > > discussion. It says: > > > > > >=20 > > > > > > ----- > > > > > > A receiver MUST be able to accept messages up to and > > > > > including 480 > > > > > > octets in length. For interoperability reasons, > > all receiver > > > > > > implementations SHOULD be able to accept messages up to > > > > > and including > > > > > > 2,048 octets in length. > > > > > >=20 > > > > > > If a receiver receives a message with a length larger > > > > than 2,048 > > > > > > octets, or larger than it supports, the receiver MAY > > > > discard the > > > > > > message or truncate the payload. > > > > > > ----- > > > > > >=20 > > > > > > I think this text is useful. It keeps the door open > > for any size > > > > > > messages while still allowing it to be restricted by > > > the transport > > > > > > mappings and individual implementations (e.g. on > > > low-end embedded > > > > > > devices). It cautions implementors against being too > > > > > verbose but also > > > > > > sets a lower limit that each implementation can assume to > > > > > be received. > > > > > >=20 > > > > > > I think we should continue to use this text. Do you agree? > > > > >=20 > > > > > No. That text doesn't belong in this draft. > > > > >=20 > > > > > Darren > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org=20 > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 15:51:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYvV-0002Dk-BZ; Wed, 30 Nov 2005 15:51:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYvT-0002DS-By for syslog@megatron.ietf.org; Wed, 30 Nov 2005 15:51:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11695 for ; Wed, 30 Nov 2005 15:50:54 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZFo-0002kz-Og for syslog@ietf.org; Wed, 30 Nov 2005 16:12:41 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 9E81C9C00C; Wed, 30 Nov 2005 22:00:31 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10153-08; Wed, 30 Nov 2005 22:00:28 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 0F26D9C00B; Wed, 30 Nov 2005 22:00:28 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Syslog] #2, max message size - Need to resolve this Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 30 Nov 2005 21:51:25 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABAB6B4@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #2, max message size - Need to resolve this Thread-Index: AcX14ZBvC/XEWoUTRLG4KK/Ap4gAOgACNMRAAAEMexAAAEi+8A== From: "Rainer Gerhards" To: "Steve Chang (schang99)" , "Anton Okmianski (aokmians)" , "Chris Lonvick (clonvick)" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org For obvious reasons, I agree with Steve and Anton. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Steve=20 > Chang (schang99) > Sent: Wednesday, November 30, 2005 9:46 PM > To: Anton Okmianski (aokmians); Chris Lonvick (clonvick);=20 > syslog@ietf.org > Subject: RE: [Syslog] #2, max message size - Need to resolve this >=20 >=20 > I agree with Anton's wording and view. >=20 > Instead of capping the size maximally that a syslog receiver=20 > is to support, it should be the minimum size that it should support. >=20 > Steve >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] > > On Behalf Of Anton Okmianski (aokmians) > > Sent: Wednesday, November 30, 2005 12:15 PM > > To: Chris Lonvick (clonvick); syslog@ietf.org > > Subject: RE: [Syslog] #2, max message size - Need to resolve this > >=20 > > I vote for a different idea... As in latest syslog-protocol, define > only > > the minimum message size the receivers is required to accept. I vote > for > > defining it in both. Syslog-protocol defines the least=20 > common agreed > upon > > denominator. Transport defines the minimum that is appropriate for > the > > transport, which can be higher if needed. Thus, if a receiver > implements > > a syslog protocol and a given transport, it has to meet both > requirements. > >=20 > > Anton. > >=20 > > > -----Original Message----- > > > From: syslog-bounces@lists.ietf.org=20 > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick=20 > > > (clonvick) > > > Sent: Wednesday, November 30, 2005 2:08 PM > > > To: syslog@ietf.org > > > Subject: [Syslog] #2, max message size - Need to resolve this > > > > > > Hi Folks, > > > > > > We need to resolve this one. I've heard from Rainer and=20 > a very few=20 > > > others. I'd like to hear from more people on this. Choose one: > > > > > > __ The maximum message length needs to be defined in > syslog-protocol. > > > > > > > > > __ The maximum message length should be defined in the transport > > > documents. > > > > > > > > > __ I have a different idea.... > > > > > > > > > Please VOTE NOW! > > > > > > Thanks, > > > Chris > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org=20 > https://www1.ietf.org/mailman/listinfo/syslog > > > > >=20 > >=20 > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 16:33:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhZaQ-0004dV-AZ; Wed, 30 Nov 2005 16:33:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhZaO-0004be-Jf for syslog@megatron.ietf.org; Wed, 30 Nov 2005 16:33:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01267 for ; Wed, 30 Nov 2005 16:33:11 -0500 (EST) Received: from ext-ch1gw-8.online-age.net ([64.37.194.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZug-000145-3y for syslog@ietf.org; Wed, 30 Nov 2005 16:54:58 -0500 Received: from int-ch1gw-4.online-age.net (int-ch1gw-4 [3.159.232.68]) by ext-ch1gw-8.online-age.net (8.13.4/8.13.5/20051111-SVVS-TLS-DNSBL) with ESMTP id jAULXgPi025090 for ; Wed, 30 Nov 2005 16:33:42 -0500 Received: from cinmlef03.e2k.ad.ge.com (localhost [127.0.0.1]) by int-ch1gw-4.online-age.net (8.12.9/8.12.3/990426-RLH) with ESMTP id jAULXewL003246 for ; Wed, 30 Nov 2005 16:33:41 -0500 (EST) Received: from MKEMLVEM07.e2k.ad.ge.com ([3.159.176.54]) by cinmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 16:33:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #2, max message size Date: Wed, 30 Nov 2005 15:33:39 -0600 Message-ID: <45A5295FFA1CBE4D9BF44E8534D2686C09C35B96@MKEMLVEM07.e2k.ad.ge.com> Thread-Topic: [Syslog] #2, max message size Thread-Index: AcX1xZE95BTFntBwQVmhyc5qaIfGMQACE1gQAADWXWAAAKm8YAACXlDwAARY/3AAAFx7MA== From: "Moehrke, John \(GE Healthcare\)" To: "Rainer Gerhards" X-OriginalArrivalTime: 30 Nov 2005 21:33:40.0352 (UTC) FILETIME=[BB070800:01C5F5F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer, Are you suggesting that these 'options' be done in real-time, or at my-application design time?=20 At my-application design time, I don't necessarily know what size strings will come out For example: I might want to have a simple string that indicates that a specified user logged in at a specified workstation. For things like "username", I might have quite a long dn (1024), and the workstation might also have a very long FQDN (255). Am I to not have this type of a string because it might very clearly be more than 480 characters? The likelihood of these two values being this big is low, so I will probably go ahead.=20 Even during real-time, why should I preemptively truncate. I figure send it. It just might make it through normal (Section 8.3). Trying to add the logic to more intelligently truncate seems unlikely. The instructions in section 6.1 seem to have more to do with internal design than any interoperability. Section 8.3 even says go ahead and try to send the packet, making it even more clear this has little to do with interoperability. It is this 'instructions on how to design your syslog receiver' that I object to being normative. There is no such instructions in other protocols that I have reviewed, and I will readily admit that although I am intimate with dozens there are millions of protocols that I don't know at all. It is these reasons why I recommend that the content of section 6.1/8.3 be moved to the udp-protocol binding, and be included as guidelines and not normative text. Yes, I understand that if it is in this layer, the application writer may never see it. That is just as likely of a risk as any of the others mentioned in this string of emails. All that said, I will bow to the will of the more committed. I really am a very interested observer, far more interested in this standard being written and implemented than I am worried about the standard being written in any specific way.=20 John >=20 > John, >=20 > > I understand the arguments that have been used, yes. I=20 > > understand that in the end there will be a small practical=20 > > MTU when transmitting over UDP (I would like it to be the 4k=20 > > that your experiments determined, not 2K, or worse 480). I=20 > > don't argue with that truth. I very simply fail to see why=20 > > this is a syslog-protocol layer and not a transport-binding=20 > > specification.=20 > >=20 > > Side comment, not necessary for the document at hand: I also=20 > > don't understand what I would do different if I could=20 > > determine (in your words > > negotiate) what the MTU actually was. >=20 > At least three options > - abbreviate things (in human-readable text) > - truncate things you know to be less important > - do application level segmentation >=20 >=20 > > I have a message that=20 > > needs to be sent, it will either make it or not. Knowing a=20 > > dynamically determined MTU is of no value as I can't make my=20 > > message smaller, it is what it is. If it gets fragmented, I=20 > > hope it will be reassembled. If it is big, I hope that the=20 > > receiver offers up a big enough buffer to it's socket=20 > > library. It is all hope at this point. I am ok with hope, I=20 > > just don't want you to limit my ability to hope. >=20 > -protocol-15 does not limit your abilit to hope. It limits your worst > case, because you know what minimum length support you can expect. ;) >=20 > Rainer > > John > >=20 > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Wednesday, November 30, 2005 11:37 AM > > > To: Moehrke, John (GE Healthcare) > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] #2, max message size > > >=20 > > > John, > > >=20 > > > the issue is the simplex nature of syslog. With syslog (other > > > than with > > > almost all other protocols), you send a message and need to=20 > > > *hope* that > > > the recipient can receive it. There is also no negotiation=20 > > > phase. So you > > > need to send it blindly. For example, if you send an IHE 2K=20 > > > message, but > > > the receiver does just support 1K, you will loose 1K without=20 > > > knowing it. > > > As such, it is vital to know at least a "safe size" that you=20 > > > can use and > > > know that it can be processed (if it makes it to the=20 > recipient). We > > > selected 480 octets because that fits into an unfragmented=20 > > > UDP packet in > > > any case. I know that's too few for IHE, but for network=20 > > > management - an > > > important use case for syslog - this is very often=20 > > sufficient. This is > > > the reason why a simplex protocol like syslog (send it and=20 > > > forget it ;)) > > > should provide some guidance about lower limits. Keep in mind=20 > > > that there > > > is NO upper limit - this is done in the transport mappings and the > > > implementations. So if you need 32K for IHE, that is=20 > perfectly well > > > (-transport-UDP, I think, suppport 64K - but you know the=20 > practical > > > limits). > > >=20 > > > Does this clarify? > > >=20 > > > Rainer > > >=20 > > > > -----Original Message----- > > > > From: Moehrke, John (GE Healthcare) > > > [mailto:John.Moehrke@med.ge.com] > > > > Sent: Wednesday, November 30, 2005 6:13 PM > > > > To: Rainer Gerhards; Darren Reed > > > > Cc: syslog@ietf.org > > > > Subject: RE: [Syslog] #2, max message size > > > >=20 > > > > Shouldn't the MTU be defined by the binding to the transport? > > > > I fail to > > > > see why the protocol, unbound to a transport, needs to have=20 > > > a limit. > > > >=20 > > > > > -----Original Message----- > > > > > From: syslog-bounces@lists.ietf.org > > > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of=20 > > > Rainer Gerhards > > > > > Sent: Wednesday, November 30, 2005 11:01 AM > > > > > To: Darren Reed > > > > > Cc: syslog@ietf.org > > > > > Subject: RE: [Syslog] #2, max message size > > > > >=20 > > > > > Darren, > > > > >=20 > > > > > I violently object your argument and leave it up to the > > > > rest of the WG > > > > > what should be done. I respect your argument, but I do=20 > > not like to=20 > > > > > re-iterate this forever. > > > > >=20 > > > > > One time we have discussed this was in October 2004: > > > > >=20 > > > > > http://www.syslog.cc/ietf/autoarc/msg01289.html > > > > >=20 > > > > > If you browse the archive, you will find several other > > > > ocasions where > > > > > this was discussed. > > > > >=20 > > > > > What's your actual recommendation? Do not say anything and > > > > > leave it the > > > > > implementor to guess what is OK? After all, its the=20 > > implementor's > > > > > problem if the message can not be transmitted. Or do=20 > > you prefer to > > > > > define an API where the lower layer tells the upper layer what > > > > > capabilities it has? Maybe MTU discovery? Or an app-level=20 > > > > ack? I think > > > > > all of these options have already been discussed during the > > > > > past years. > > > > > What is now in is a (fragile) consensus, but if only you do=20 > > > > > not like it, > > > > > I think we should go ahead and leave an unhappy Darren=20 > > > > > behind. If only I > > > > > insist on it, we can also go ahead and leave an unhappy=20 > > > > Rainer behind. > > > > > But we need to go ahead! > > > > >=20 > > > > > Rainer > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Darren Reed [mailto:darrenr@reed.wattle.id.au] > > > > > > Sent: Wednesday, November 30, 2005 4:49 PM > > > > > > To: Rainer Gerhards > > > > > > Cc: syslog@ietf.org > > > > > > Subject: Re: [Syslog] #2, max message size > > > > > >=20 > > > > > > > Darren, > > > > > > >=20 > > > > > > > > The only place a message size limit should be > > > specified is in > > > > > > > > a transport > > > > > > > > mapping. If it's in -15 then it should be=20 > > removed. Limits > > > > > > > > of all sizes > > > > > > > > and types do nothing but contribute to aging of a=20 > > protocol. > > > > > > >=20 > > > > > > > -protocol-15 is a compromise after a very long > > > > > discussion. It says: > > > > > > >=20 > > > > > > > ----- > > > > > > > A receiver MUST be able to accept messages up to and > > > > > > including 480 > > > > > > > octets in length. For interoperability reasons, > > > all receiver > > > > > > > implementations SHOULD be able to accept messages up to > > > > > > and including > > > > > > > 2,048 octets in length. > > > > > > >=20 > > > > > > > If a receiver receives a message with a length larger > > > > > than 2,048 > > > > > > > octets, or larger than it supports, the receiver MAY > > > > > discard the > > > > > > > message or truncate the payload. > > > > > > > ----- > > > > > > >=20 > > > > > > > I think this text is useful. It keeps the door open > > > for any size > > > > > > > messages while still allowing it to be restricted by > > > > the transport > > > > > > > mappings and individual implementations (e.g. on > > > > low-end embedded > > > > > > > devices). It cautions implementors against being too > > > > > > verbose but also > > > > > > > sets a lower limit that each implementation can assume to > > > > > > be received. > > > > > > >=20 > > > > > > > I think we should continue to use this text. Do you agree? > > > > > >=20 > > > > > > No. That text doesn't belong in this draft. > > > > > >=20 > > > > > > Darren > > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > Syslog@lists.ietf.org=20 > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 17:41:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhaeD-0003pd-UJ; Wed, 30 Nov 2005 17:41:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhaeC-0003pL-Hj for syslog@megatron.ietf.org; Wed, 30 Nov 2005 17:41:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09421 for ; Wed, 30 Nov 2005 17:41:10 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ehay8-0004nj-De for syslog@ietf.org; Wed, 30 Nov 2005 18:02:33 -0500 Received: (qmail 99279 invoked from network); 30 Nov 2005 22:41:18 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 30 Nov 2005 22:41:18 -0000 X-pair-Authenticated: 202.137.242.74 From: "Andrew Ross" To: "'Chris Lonvick'" , Subject: RE: [Syslog] #2, max message size - Need to resolve this Date: Thu, 1 Dec 2005 11:41:16 +1300 Organization: Kiwi Enterprises Message-ID: <001001c5f5ff$2db9e3f0$d901a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org My vote is for the way Rainer has worded it now. Specify the minimum msg size in syslog-protocol and define max message size in the transport documents. Cheers Andrew Hi Folks, We need to resolve this one. I've heard from Rainer and a very few others. I'd like to hear from more people on this. Choose one: __ The maximum message length needs to be defined in syslog-protocol. __ The maximum message length should be defined in the transport documents. __ I have a different idea.... Please VOTE NOW! Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 18:06:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehb1t-0002oU-NB; Wed, 30 Nov 2005 18:06:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehb10-0002BZ-Mp for syslog@megatron.ietf.org; Wed, 30 Nov 2005 18:05:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12759 for ; Wed, 30 Nov 2005 17:59:41 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ehb52-000646-NN for syslog@ietf.org; Wed, 30 Nov 2005 18:09:42 -0500 Received: (qmail 1438 invoked from network); 30 Nov 2005 22:48:35 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 30 Nov 2005 22:48:35 -0000 X-pair-Authenticated: 202.137.242.74 From: "Andrew Ross" To: "'Anton Okmianski \(aokmians\)'" , "'Rainer Gerhards'" , Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Date: Thu, 1 Dec 2005 11:48:32 +1300 Organization: Kiwi Enterprises Message-ID: <001201c5f600$31f3eeb0$d901a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122C8624F@xmb-rtp-20d.amer.cisco.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org >We are still ok with always having UTF-8 in SD values, right? >We need this for foreign usernames. We have discussed this before. Yes, this would work for me. We need to ensure that the SD-IDs are always going to be encoded in a known format. UTF-8 is a good choice. Cheers Andrew _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 18:11:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehb6m-0004xB-KJ; Wed, 30 Nov 2005 18:11:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehb29-0002BZ-Ui for syslog@megatron.ietf.org; Wed, 30 Nov 2005 18:06:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12858 for ; Wed, 30 Nov 2005 17:59:48 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ehb2Y-0005mn-3N for syslog@ietf.org; Wed, 30 Nov 2005 18:07:06 -0500 Received: (qmail 685 invoked from network); 30 Nov 2005 22:46:01 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 30 Nov 2005 22:46:01 -0000 X-pair-Authenticated: 202.137.242.74 From: "Andrew Ross" To: "'Anton Okmianski \(aokmians\)'" , Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Date: Thu, 1 Dec 2005 11:45:58 +1300 Organization: Kiwi Enterprises Message-ID: <001101c5f5ff$d6090c70$d901a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122C8625D@xmb-rtp-20d.amer.cisco.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Either solution would work, I have no preference either way. :) Cheers Andrew -----Original Message----- From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] Sent: Thursday, 1 December 2005 7:38 a.m. To: andrew@kiwisyslog.com; syslog@ietf.org Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting I think for TCP mapping a transport header with message size would be more appropriate framing than termination character. Thanks, Anton. > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Andrew Ross > Sent: Wednesday, November 30, 2005 7:19 AM > To: syslog@ietf.org > Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting > > > Rainer, > > That sounds good to me at this stage, and it keeps the door > open. I would prefer to see all binary data encoded in some > "safe" format like base64. It just makes logging the data to > file much easier. For instance, if the binary data contained > a LF character, when it was logged to disk, it would end up > as two separate messages when opened in notepad etc. > > Also, if we are to transport syslog over TCP at some stage, > we need to keep a delimiter character free from use in the > message. Again, a LF would be a good choice for this delimiter. > > Cheers > > Andrew > > > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] > On Behalf Of Rainer Gerhards > Sent: Wednesday, 30 November 2005 9:26 p.m. > To: syslog@ietf.org > Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting > > > Hi WG, > > I have received notes via private mail telling me there seem > to be some existing (and eventually soon upcoming) valid use > cases for binary data in syslog. I think there is no point in > arguing whether that's fortunate or not. It simply looks like > that's the way it is. I do not like the idea of breaking > existing use cases for syslog (because that will only lead to > implementors ignoring the spec and the story of syslog > inconsistencies continues...). As such, I think we need to > provide at least some minimal support for it (aka "not outlaw it"). > > At first, this implies that NUL octets may be present in the message. > > I propose that we write text that discourages the use of NUL, > but allows it if needed. That text should also allow, but > discourage, a receiver to modify messages containing NUL. > With that, we allow the use case, but do not make it a "show > stopper" for implementing compliant software. This would also > be pretty much in sync with what we currently find in > practice, so it is already expected behaviour. Finally, such > text would caution implementors that when NUL octets are > present, chancs are high that eventually present digitial > signatures will be broken. In my point of view, that's fair > and efficient. > > Chris proposal for #5 (character encoding) also provides an > elegant solution for binary data. We can use something like: > > [enc="binary"] > > or > > [enc="base-64"] > > I do NOT intend to specify this - I think it should be in the > scope of a separate document specifying the use of binary > data. Then would also be the right time to discuss all issues > that arise out of it. For now, I just would like to keep the > door open. > > Finally, I propose to extend Chris format so that the message > size can be conveyed. This has been brought up several times > and I think a clean solution is now obvious: > > [enc="utf-8" lang="en" size="MSG-size-in-octets"] > > MSG-size-in-octets would be the size of the MSG part (just > that!) in octets. Counting just the MSG part is sufficient, > as the rest of the message consists of fields properly > delimited. The size is probably most useful for binary data. > > Please comment. > > Rainer > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 21:12:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhdwD-0004oY-2L; Wed, 30 Nov 2005 21:12:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhdwA-0004oN-W9 for syslog@megatron.ietf.org; Wed, 30 Nov 2005 21:12:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04384 for ; Wed, 30 Nov 2005 21:11:55 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EheGY-0001Wc-D8 for syslog@ietf.org; Wed, 30 Nov 2005 21:33:47 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 30 Nov 2005 18:12:32 -0800 X-IronPort-AV: i="3.99,197,1131350400"; d="scan'208"; a="372393491:sNHT35550548" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB12CIsC004273; Wed, 30 Nov 2005 18:12:29 -0800 (PST) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 18:12:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #2, max message size - Need to resolve this Date: Wed, 30 Nov 2005 18:12:26 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FBF7A606@xmb-sjc-236.amer.cisco.com> Thread-Topic: [Syslog] #2, max message size - Need to resolve this Thread-Index: AcX1/2j1I7XqD/eBQhCPqw8UgAE+BgAHDZOw From: "Alexander Clemm \(alex\)" To: , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 01 Dec 2005 02:12:27.0306 (UTC) FILETIME=[AD11A8A0:01C5F61C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I think there is general agreement to specify minimum msg size, not maximum msg size in syslog-protocol. =20 Concerning the transport, the same should hold true. I could see that there may be cases in which a transport might specify a minimum msg size that is larger than the one in syslog protocol (so, if syslog protocol is used over a certain transport, message size may be larger than what would be mandated by syslog protocol itself). I don't see that you should mandate to define a max message size for the same reasons we wouldn't define it in syslog-protocol itself. Why unnecessarily impose constraints when you don't have to? In other words, just define min sizes that implementations are obliged to support, but don't prevent them from supporting more if they want to. Just my $0.02. =20 --- Alex -----Original Message----- From: syslog-bounces@lists.ietf.org [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Andrew Ross Sent: Wednesday, November 30, 2005 2:41 PM To: Chris Lonvick (clonvick); syslog@ietf.org Subject: RE: [Syslog] #2, max message size - Need to resolve this My vote is for the way Rainer has worded it now. Specify the minimum msg size in syslog-protocol and define max message size in the transport documents. Cheers Andrew Hi Folks, We need to resolve this one. I've heard from Rainer and a very few others. I'd like to hear from more people on this. Choose one: __ The maximum message length needs to be defined in syslog-protocol. __ The maximum message length should be defined in the transport documents. __ I have a different idea.... Please VOTE NOW! Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 23:37:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhgBu-00031X-Jc; Wed, 30 Nov 2005 23:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhgBs-00030x-Gc for syslog@megatron.ietf.org; Wed, 30 Nov 2005 23:37:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16595 for ; Wed, 30 Nov 2005 23:36:14 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhgWC-0005bZ-DU for syslog@ietf.org; Wed, 30 Nov 2005 23:58:06 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jB14aeju022308; Thu, 1 Dec 2005 15:36:40 +1100 (EST) From: Darren Reed Message-Id: <200512010436.jB14aFD2000440@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #2, max message size - Need to resolve this In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FBF7A606@xmb-sjc-236.amer.cisco.com> To: "Alexander Clemm (alex)" Date: Thu, 1 Dec 2005 15:36:15 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > I think there is general agreement to specify minimum msg size, not > maximum msg size in syslog-protocol. FWIW, I think this is a much better idea. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 23:43:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhgIZ-0005wF-5F; Wed, 30 Nov 2005 23:43:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhgIY-0005vD-83 for syslog@megatron.ietf.org; Wed, 30 Nov 2005 23:43:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17141 for ; Wed, 30 Nov 2005 23:43:12 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehgcx-0005xx-8b for syslog@ietf.org; Thu, 01 Dec 2005 00:05:04 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jB14hqNf024693; Thu, 1 Dec 2005 15:43:52 +1100 (EST) From: Darren Reed Message-Id: <200512010443.jB14heRt027340@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #2, max message size In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122C8629C@xmb-rtp-20d.amer.cisco.com> To: "Anton Okmianski (aokmians)" Date: Thu, 1 Dec 2005 15:43:40 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org [ Charset ISO-8859-1 unsupported, converting... ] > > Of course, specifying a minimum required support in each transport > mapping is also appropriate. In fact, syslog-transport-udp sets two > separate minimums: for IPv4 and IPv6. If we did not specify a minimum > in syslog-protocol, one can infer the minimum based on the least > common denominator of transport protocol used. That's fair. But I just > don't see a harm in what was done in the current draft (after very > long discussions I might add). I can only a see a very hypothetical > scenario where some future transport protocol has MTU smaller than the > what IPv4 and IPv6 uses. In this case a minimum requirement may be > problematic. How much lower than 480 octets can it go with a > ~100-octet syslog header? I think you mean network protocol, not transport protocol. IPv6 has a larger minimum packet size than IPv4 and unless there is a new IETF backed network layer protocol that has a smaller protocol header than IPv4, I can't see the minimum MTU getting any smaller. Are you suggeting something like syslog over ATM or syslog over PPP as an example ? Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 30 23:50:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhgOY-0000AC-VZ; Wed, 30 Nov 2005 23:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhgOY-00009l-1k for syslog@megatron.ietf.org; Wed, 30 Nov 2005 23:50:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17679 for ; Wed, 30 Nov 2005 23:49:24 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehgix-00069Q-Ct for syslog@ietf.org; Thu, 01 Dec 2005 00:11:16 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jB14o4UD028067; Thu, 1 Dec 2005 15:50:05 +1100 (EST) From: Darren Reed Message-Id: <200512010449.jB14nlUT028694@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #2, max message size In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122C862DC@xmb-rtp-20d.amer.cisco.com> To: "Anton Okmianski (aokmians)" Date: Thu, 1 Dec 2005 15:49:47 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton, Please look into getting your email program to do word wrapping before 80 columns. Everyone else on the list seems to be able to do this. Replying to an email where you have to manually reformat every line of quoted text is no fun. Thanks. > There is NO maximum message size defined in syslog-protocol draft! .. Then why has there been any discussion, at all, on a maximum message size ? Seems like a waste of time and effort on everyone's behalf, including Rainer's for listing it in the first place. Cheers, Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog