From MAILER-DAEMON Mon Nov 28 10:54:02 2005 Date: 28 Nov 2005 10:54:02 -0600 From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Message-ID: <1133196842@linux.local> X-IMAP: 1132853534 0000000045 Status: RO This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. From syslog-sec-bounces@willers.employees.org Tue May 31 11:25:55 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id DD05D1C342 for ; Tue, 31 May 2005 11:25:54 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:54 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 09:01:11 -0700 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 08:59:57 -0700 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 03 May 2005 02:10:54 +1000 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j42FwKLW007168; Tue, 3 May 2005 01:59:18 +1000 (EST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 02 May 2005 08:59:31 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,145,1112598000"; d="scan'208"; a="59945337:sNHT48743512" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 012C05C7E1; Mon, 2 May 2005 08:59:25 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by willers.employees.org (Postfix) with ESMTP id E2A7D5C79D for ; Mon, 2 May 2005 08:47:30 -0700 (PDT) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 02 May 2005 08:47:30 -0700 Received: from alexw2k01 (sjc-vpn2-360.cisco.com [10.21.113.104]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j42FlSpR012776 for ; Mon, 2 May 2005 08:47:28 -0700 (PDT) Message-Id: <200505021547.j42FlSpR012776@sj-core-4.cisco.com> From: "Alexander Clemm (alex)" To: Date: Mon, 2 May 2005 08:47:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcVPLjscyr/d4PdXSzepv63+MMkaSQ== X-Mailman-Approved-At: Mon, 02 May 2005 08:59:24 -0700 Cc: Subject: [Syslog-sec] Syslog protocol draft (draft-ietf-syslog-protocol-11.txt) X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: alex@cisco.com List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 02 May 2005 15:59:57.0945 (UTC) FILETIME=[FD2B2E90:01C54F2F] Status: RO X-Status: X-Keywords: X-UID: 1 Resending due to apparent mailer problems, apologies if you receive multiple copies Hello, I am currently going through the syslog protocol draft, draft-ietf-syslog-protocol-11.txt. A couple of thoughts, suggestions, topics for discussion: Basic principles (section 4): May want to clarify: Will relays be allowed to send messages to multiple receivers? (Not listed as one of the scenarios.) May relays alter a message? (Currently, yes, at least with regards to truncation; should be explicit in discussing what aspects of a message may and what aspects may not be altered.) Required syslog format: There are essentially 3 parts of the message which identify the originator of the message, not even counting the host name: Facility, App-Name, Proc-ID. - Should they be grouped together - why separate them for example with the truncate field - may want to take a look at the order of the fields. I would think that the truncate field should in fact either appear after the version field, or right before the structured data field. - Why would facility consist only of digits, not alphanumeric characters - Are three fields really needed? It seems that it makes sense to allow to identify the type of the subsystem or application that generates the syslog message, as well as the particular instance in case there are several. This makes two fields. Why a third field? Concerning message length: would it make sense to allow for a means by which messages could be fragmented, as an option in addition to truncating? This could be addressed by having standard structured data elements that specify a message as part 1 of 2, for example. Of course, with regards to relays it may imply that messages may need to be altered by relays accordingly. Relationship to Alarm MIB (Section 6.2.3.1 )- suggest adding a table that lists the corresponding relation. Also, really the proper reference to use is probably the ITU specification, X.733. The structured data is an extremely important concept, as this provides for extensibility and separates the "core" fields from the "extension" fields. For the structured data, would it make sense considering to reserve a prefix character (for example, the underscore character) for the SD-name that should not be used for vendor-defined SD elements, so that if later extensions to the syslog protocol are standardized in form of new SD elements there won't be conflicts - or vice versa, to require vendor extensions to start with it? --- Alex _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:25:56 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 025331C342 for ; Tue, 31 May 2005 11:25:56 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:56 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 10:57:35 -0700 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 10:57:34 -0700 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 02 May 2005 19:57:31 +0200 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j42HvF56005977; Mon, 2 May 2005 19:57:24 +0200 (MEST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 02 May 2005 10:57:10 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,146,1112598000"; d="scan'208"; a="70869087:sNHT27795196" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id A4DF95C7C4; Mon, 2 May 2005 10:57:07 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from loutre.ath.cx (AReims-151-1-42-246.w83-192.abo.wanadoo.fr [83.192.150.246]) by willers.employees.org (Postfix) with ESMTP id 1FEC65C79B for ; Mon, 2 May 2005 10:57:04 -0700 (PDT) Received: from d83-177-163-113.cust.tele2.fr (d83-177-163-113.cust.tele2.fr [83.177.163.113]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by loutre.ath.cx (Postfix) with ESMTP id 4077517405D; Mon, 2 May 2005 19:58:23 +0200 (CEST) Subject: Re: [Syslog-sec] Syslog protocol draft (draft-ietf-syslog-protocol-11.txt) From: Clement MATHIEU To: syslog-sec@employees.org In-Reply-To: <200505021547.j42FlSpR012776@sj-core-4.cisco.com> References: <200505021547.j42FlSpR012776@sj-core-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 02 May 2005 19:56:49 +0200 Message-Id: <1115056609.4211.14.camel@ragondin.ath.cx> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 8bit Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 02 May 2005 17:57:34.0308 (UTC) FILETIME=[6B16BA40:01C54F40] Status: RO X-Status: X-Keywords: X-UID: 2 Le lundi 02 mai 2005 à 08:47 -0700, Alexander Clemm (alex) a écrit : > The structured data is an extremely important concept, as this provides for > extensibility and separates the "core" fields from the "extension" fields. > For the structured data, would it make sense considering to reserve a prefix > character (for example, the underscore character) for the SD-name that > should not be used for vendor-defined SD elements, so that if later > extensions to the syslog protocol are standardized in form of new SD > elements there won't be conflicts - or vice versa, to require vendor > extensions to start with it? Please correct me if I am wrong but i think this issue is already addressed. >From grammar: STRUCTURED-DATA = *SD-ELEMENT / "-" SD-ELEMENT = "[" SD-ID 0*(1*SP SD-PARAM) "]" SD-ID = SD-NAME SD-NAME = 1*32OCTET ; VALID UTF-8 String ; except '=', SP, ']', %d34 (") ---------------- draft 11 ------------------- 6.3.2 SD-ID IANA controls ALL SD-IDs without a hyphen ('-') in the second character position. SD-IDs are case-sensitive and uniquely identify the type and purpose of the SD-ELEMENT. Experimental or vendor- specific SD-ID MUST start with "x-". Anything that doesn't is managed by IANA. The same SD-ID MUST NOT exist more than once in a message. ---------------------------------------------- To my understanding a vendor-defined SD-ID can not conflict with a standardize one. BTW, i find 6.3.2 quite unclear. Firstly we say that IANA controls all SD-ID without a - in second position. IANA controlled: plop foo-bar 42 (probably) Not IANA controlled: z-yyyy a-b-c Then we add "Anything that doesn't is managed by IANA.". So, finally, "z-yyyy" and "a-b-c" are controlled by IANA... Confusing isn't it ? Theses two sentences are not contradictory; the second one defines a larger set of SD-ID. Am I wrong ? Clément MATHIEU _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:25:57 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id F3F211C342 for ; Tue, 31 May 2005 11:25:56 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:57 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 14:17:24 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 14:17:23 -0700 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 03 May 2005 17:17:23 -0400 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j43LEvS0022465; Tue, 3 May 2005 17:17:16 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 03 May 2005 14:17:05 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,152,1112598000"; d="scan'208"; a="71298818:sNHT26145096" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id AAA3A5C7EF; Tue, 3 May 2005 14:17:00 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from loutre.ath.cx (AReims-151-1-69-66.w83-198.abo.wanadoo.fr [83.198.91.66]) by willers.employees.org (Postfix) with ESMTP id C674E5C7AC for ; Tue, 3 May 2005 14:16:58 -0700 (PDT) Received: from d213-103-13-204.cust.tele2.fr (d213-103-13-204.cust.tele2.fr [213.103.13.204]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by loutre.ath.cx (Postfix) with ESMTP id 0C56717405D for ; Tue, 3 May 2005 23:18:21 +0200 (CEST) Subject: Re: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-11.txt From: =?ISO-8859-1?Q?Cl=E9ment?= MATHIEU To: syslog-sec@employees.org In-Reply-To: <200504191939.PAA13012@ietf.org> References: <200504191939.PAA13012@ietf.org> Content-Type: text/plain; charset=ISO-8859-15 Date: Tue, 03 May 2005 23:16:48 +0200 Message-Id: <1115155008.4731.39.camel@ragondin.ath.cx> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 8bit Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 03 May 2005 21:17:23.0605 (UTC) FILETIME=[7FAE0450:01C55025] Status: RO X-Status: X-Keywords: X-UID: 3 Hi, After some other reading of syslog-protocol-11 I have encountered some new problematic items. Let me start with minor issues -------------- 6.2.8 PROCID The PROCID field MAY by used to provide the sender's process ID. -------------- s/by/be/ -------------- 7.3.1 sequenceId 7.2.2 enterpriseID -------------- Should not we use a consistent PARAM-NAME naming scheme ? Id or ID for both. -------------- (from grammar) HOSTNAME = 1*255PRINTUSASCII ; a FQDN -------------- According to "6.2.6 HOSTNAME", the HOSTNAME field does not always contain a FQDN. Now more important issues to my point of view -------------- In the case that truncation cannot result in a valid message then the message SHOULD be dropped. As the MSG part of the message is free- form and receivers MUST be able to accept messages up to and including 480 octets in length, truncation according to 3) should always be possible and as such no dropping SHOULD actually occur. -------------- Why put a requirement on an impossible situation ? A syslog message can always be truncated, and the result is always a valid syslog message. I can't understand why this SHOULD is in the draft. -------------- SD-ELEMENT = "[" SD-ID 0*(1*SP SD-PARAM) "]" -------------- I am seeing two problems in this line. The first one is trivial, according to RFC 2234 "0*" is redundant, * is sufficient. By removing the '0', notation is more homogeneous (think about *SD-ELEMENT for example). Secondly we can see that more than one SP is allowed between SD-PARAM. In all other places of this draft, fields are delimited by one and only one SP. Why are we allowed to put any number of SP character we want here ? IMHO, to be consistent, one and only one SP character must be allowed. That's all for today :-) I am hopping that this post will be useful to improve syslog-protocol Clément MATHIEU _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:25:58 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id CF5261C342 for ; Tue, 31 May 2005 11:25:57 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:57 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 14:52:46 -0700 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 14:52:46 -0700 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 04 May 2005 08:03:56 +1000 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j43LnZLs022029; Wed, 4 May 2005 07:51:53 +1000 (EST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 03 May 2005 14:52:13 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,152,1112598000"; d="scan'208"; a="68178861:sNHT32886180" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id C2DEF5C7B0; Tue, 3 May 2005 14:52:10 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by willers.employees.org (Postfix) with ESMTP id AC5945C732 for ; Tue, 3 May 2005 14:52:09 -0700 (PDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 03 May 2005 14:52:09 -0700 Received: from alexw2k01 (dhcp-171-69-70-251.cisco.com [171.69.70.251]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j43Lq5Kx013609; Tue, 3 May 2005 14:52:05 -0700 (PDT) Message-Id: <200505032152.j43Lq5Kx013609@sj-core-2.cisco.com> From: "Alexander Clemm (alex)" To: "'Clement MATHIEU'" , Subject: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) Date: Tue, 3 May 2005 14:52:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcVPQS5oPThFUNhmTq6EKojrI8h2jwA5+QEQ In-Reply-To: <1115056609.4211.14.camel@ragondin.ath.cx> Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: alex@cisco.com List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 03 May 2005 21:52:46.0671 (UTC) FILETIME=[71202DF0:01C5502A] Status: RO X-Status: X-Keywords: X-UID: 4 Hi,=20 please see my response below, at the bottom of the message --- Alex -----Original Message----- From: Clement MATHIEU [mailto:mathieuc@echo.unice.fr]=20 Sent: Monday, May 02, 2005 10:57 AM To: syslog-sec@employees.org Cc: alex@cisco.com Subject: Re: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) Le lundi 02 mai 2005 =E0 08:47 -0700, Alexander Clemm (alex) a =E9crit : [...] ---------------- draft 11 ------------------- 6.3.2 SD-ID IANA controls ALL SD-IDs without a hyphen ('-') in the second character position. SD-IDs are case-sensitive and uniquely identify the type and purpose of the SD-ELEMENT. Experimental or vendor- specific SD-ID MUST start with "x-". Anything that doesn't is managed by IANA. The same SD-ID MUST NOT exist more than once in a message. ---------------------------------------------- To my understanding a vendor-defined SD-ID can not conflict with a standardize one.=20 BTW, i find 6.3.2 quite unclear. Firstly we say that IANA controls all = SD-ID without a - in second position. IANA controlled: plop foo-bar 42 (probably) Not IANA controlled: z-yyyy a-b-c Then we add "Anything that doesn't is managed by IANA.". So, finally, "z-yyyy" and "a-b-c" are controlled by IANA... Confusing isn't it ? Theses two sentences are not contradictory; the second one defines a = larger set of SD-ID. Am I wrong ? =09 Cl=E9ment MATHIEU **** Response Alex Clement, thanks for clarifying. The "hypen" part of the specification escaped = me. Yes, I agree the wording needs to be clarified. Specifically, what is = it that IANA controls - everything without a hyphen in the second character position, or anything that doesn't start with "x-"? I would think the second one is too restrictive. That is, everything with hyphen in the second position is proprietary, everything that is not, is not. If you = want to reserve further characters such as "x" for experimental purposes, = then so be it, but not ALL characters except one should be reserved. Otherwise, this may result in a a tendency of proprietary SD IDs to get longer than otherwise necessary, and there is probably value in keeping things = compact. _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:25:59 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id CF76F1C342 for ; Tue, 31 May 2005 11:25:58 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:58 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 15:50:39 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 15:50:39 -0700 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 03 May 2005 19:04:04 -0400 X-IronPort-AV: i="3.92,152,1112587200"; d="scan'208"; a="47353612:sNHT52582622" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j43Mn8Rs024170; Tue, 3 May 2005 18:50:32 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 03 May 2005 15:50:20 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,152,1112598000"; d="scan'208"; a="60670289:sNHT20152008" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 46DC35C766; Tue, 3 May 2005 15:50:17 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from loutre.ath.cx (AReims-151-1-69-66.w83-198.abo.wanadoo.fr [83.198.91.66]) by willers.employees.org (Postfix) with ESMTP id 244EC5C722 for ; Tue, 3 May 2005 15:50:14 -0700 (PDT) Received: from d213-103-13-204.cust.tele2.fr (d213-103-13-204.cust.tele2.fr [213.103.13.204]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by loutre.ath.cx (Postfix) with ESMTP id AE36217405D for ; Wed, 4 May 2005 00:51:40 +0200 (CEST) Subject: Re: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-11.txt From: =?ISO-8859-1?Q?Cl=E9ment?= MATHIEU To: syslog-sec@employees.org In-Reply-To: <1115155008.4731.39.camel@ragondin.ath.cx> References: <200504191939.PAA13012@ietf.org> <1115155008.4731.39.camel@ragondin.ath.cx> Content-Type: text/plain; charset=ISO-8859-15 Date: Wed, 04 May 2005 00:50:07 +0200 Message-Id: <1115160607.4731.66.camel@ragondin.ath.cx> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 8bit Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 03 May 2005 22:50:39.0183 (UTC) FILETIME=[86E775F0:01C55032] Status: RO X-Status: X-Keywords: X-UID: 5 Le mardi 03 mai 2005 à 23:16 +0200, Clément MATHIEU a écrit : I am sorry but i have forgotten one item ---------- STRUCTURED-DATA = *SD-ELEMENT / "-" ---------- The grammar is saying that this message is valid : "1 888 4 3 2003-10-11T22:14:15Z metalog.unice.fr prog - - " It has zero SD-ELEMENT and no MSG. Section 6.3 says that if there is no SD-ELEMENT a "-" must be put; finally the previous message is invalid. A correct grammar would be ----------- STRUCTURED-DATA = 1*SD-ELEMENT / "-" ----------- Clément MATHIEU _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:00 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 28D871C342 for ; Tue, 31 May 2005 11:26:00 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:00 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 03:32:08 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 03:32:06 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 06 May 2005 06:45:39 -0400 X-IronPort-AV: i="3.92,159,1112587200"; d="scan'208"; a="48000022:sNHT1008879768" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j46AU2dx019432; Fri, 6 May 2005 06:31:34 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 06 May 2005 03:30:53 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,159,1112598000"; d="scan'208"; a="105353623:sNHT21342172" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id CBB615C83A; Fri, 6 May 2005 03:27:41 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id E31875C78B for ; Fri, 6 May 2005 03:27:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 2442A1B00AB for ; Fri, 6 May 2005 12:27:44 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23477-03 for ; Fri, 6 May 2005 12:27:38 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id DC23D1B0065 for ; Fri, 6 May 2005 12:27:37 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 May 2005 12:27:18 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 May 2005 12:27:16 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA062073@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] RE: protocol-11.txt - sysUpTime Thread-Index: AcVH9Mhras47Lth3T3u33x50tSOuDAACH4QQAJDlLoAB+RircA== From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 06 May 2005 10:27:18.0811 (UTC) FILETIME=[2E4006B0:01C55226] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.204 Status: RO X-Status: X-Keywords: X-UID: 6 Hi all, I have not received any objection to my post below, so I now define sysUpTime as follows: #### 7.3.2 sysUpTime The "sysUpTime" parameter MAY be used to include the SNMP "sysUpTime" parameter in the message. Its syntax and semantics are as defined in RFC 3418 [12]. As syslog does not support the SNMP "integer" syntax directly, the value MUST be represented as a string of digits. #### Rainer=20 > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Rainer Gerhards > Sent: Tuesday, April 26, 2005 12:04 PM > To: syslog > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime >=20 > Hi all, >=20 > please let me elaborate a little on my experience with syslog=20 > use cases. > As far as I have seen, there are two major use cases: >=20 > #1 trouble shooting/setup > This is an activity done close to real-time. Here, the raw syslog > messages are reviewed by the administrator. The most important part in > this use case is the free-form message. It tells the=20 > administrator which > problems the device is experiencing or other status data that is > valuable at that very instant. Common scenarios are setting up or > troubleshooting router filter settings or firewall rule sets.=20 > Here, the > device is telling via syslog which rules fired and which ones not. So > the administrator can check his setup. Also, this use case=20 > often applies > if a new application/device/whatever is being setup in a=20 > network and the > admin checks messages from the new device and/or existing devices - > especially if it doesn't work as it should. This use case might be > called the "tail -f /var/log/messages" case - just to stress=20 > my point... >=20 > The common thing about this scenario is that the administrator reviews > raw message in more or less real time. >=20 > #2 reporting/analysis > In this use case, consolidated syslog data is viewed. Raw data is NOT > viewed. Typically, the analysis is not real-time but acting=20 > on past data > (though there are some analysis tools which work in real-time or > close-to-real-time and then issue alerts based on the result of their > ongoing analysis). In this use case, a program/script/whatever > programmatically reads the syslog entries and somehow transforms them > into a format that is more understandable by a human. The=20 > administrator > views the (transformed) end result. >=20 > Of course, these use cases do not exclude each other. For example, it > might very well be that an administrator detects an anomaly in a > consolidated report (use case #2) and then investigates its cause via > real-time trouble shooting (use case #1). Eventually, he will generate > other reports on the fly before he looks at the raw data. Eventually > he'll never look at any raw data because it is not required for that > troubleshooting purpose. >=20 > Obviously, there are a lot of different use cases. But based on my > experience the two above apply to the majority of cases. >=20 > Now if I look at what the administrator actually does, I would expect > that in use case #1 sysUpTime will be of little to no help. The reason > is that the administrator either has recently set up / rebooted the > device and so he knows how long it is up. Or he might have come from a > transformed report which included the information. In any=20 > case, I think > sysUpTime will not be the admins prime focus. In fact, I'd say that > he'll probably ignore STRUCTURED-DATA at all and just focus on the > human-readble part of the message (MSG). >=20 > In case #2, sysUpTime will be helpful, but primarily to the report > logic. I assume that a decent reporting engine will convert any > user-unfriendly data type into information that the admin can easily > make sense of. >=20 > Again, there are more use cases than the two outlined above.=20 > Also, I do > not claim to have absolute knowledge about what users do with their > syslogs. However, I am working for a long time in this field=20 > and this is > honestly what I have seen in practice. >=20 > If (and only if) my observations are true, that would mean we=20 > could use > the "user-unfriendly" SNMP integer and only need to specify=20 > that it must > be represented in string form (because syslog does not support binary > fields). >=20 > Any feedback is highly appreciated. >=20 > Rainer >=20 > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org=20 > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > > David B Harrington > > Sent: Saturday, April 23, 2005 2:28 PM > > To: 'Tom Petch'; 'syslog' > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > >=20 > > If the expectation is that syslog messages will be read in=20 > syslog raw > > format by humans more than by programs, then I agree it=20 > should be done > > in a presentation format in the message. Under those conditions, I > > suggest breaking out the days, hours, minutes, etc.=20 > >=20 > > If the expectation is that this field will be used by prgrams more > > than humans, then the raw format woul dbe better. > >=20 > > Of course, if there are suitable use-cases for each, you could also > > achieve both a human-friendly and a machine-friendly approach: > > "142days:2hr:8min:13sec:9 (123456789)". > >=20 > > David Harrington > > dbharrington@comcast.net > >=20 > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > > Sent: Saturday, April 23, 2005 6:03 AM > > > To: ietfdbh@comcast.net; syslog > > > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > >=20 > > > David > > >=20 > > > Yes, your wish to clarify the intended users of syslog=20 > > > messages is best done > > > first. I assume it is humans like myself (even though I have=20 > > > coded log > > > analysers). > > >=20 > > > Having clarified the users, then I will press again for a=20 > > > defined presentation > > > format. In syslog, sysUpTime is an SD-ID so it is encoded in=20 > > > UTF8 and as far as > > > I know, UCS only has the concept of characters, not of=20 > > > integers, so if the > > > presentation format is > > > to be standardised, we must do it. > > >=20 > > > Tom Petch > > > ----- Original Message ----- > > > From: "David B Harrington" > > > To: "'Tom Petch'" ; "'Rainer Gerhards'" > > > ; > > > Sent: Thursday, April 21, 2005 11:48 PM > > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > >=20 > > >=20 > > > > Hi Tom, > > > > > > > > Thank you for the good desacription of your concerns. > > > > You are correct; RFC3418 does not have a DISPLAY-HINT. > > > > > > > > SNMP is designed to be a programmatic interface, not a=20 > > > human-friendly > > > > interface; SNMP management applications often convert the > > unfriendly > > > > sysUpTime into days: hours: minutes: seconds, and so on, as you > > > > suggest. > > > > > > > > Syslog is designed to be more user-friendly. Syslog=20 > certainly can > > > > convert the sysUpTime value into something more readily=20 > > > understood by > > > > humans. One concern I have with that approach is that,=20 > in the SNMP > > > > world, we try to keep all unnecessary processing out of the=20 > > > agent and > > > > in the management application, so the device being managed can > > focus > > > > on forwarding packets or whatever, and not on converting=20 > > > raw data into > > > > friendlier forms. While minimizing the management processing of > > > > internetworking devices was critically important in 1980,=20 > > > and is stil > > > > important in resource-limited devices such as set-top=20 > boxes, many > > > > systems now have at least some capability to spare. > > > > > > > > So my question is, do the bulk of syslog users read the=20 > raw syslog > > > > messages without any automation, or do the bulk of operators now > > use > > > > tools to help filter syslogs, given the tremendous amount of > > > > information available in the logs? I'm sure there are multiple > > > > use-cases. [I do not know the answer to the question; it is not > > > > rhetorical.] > > > > > > > > If they are already using tools to view (and possibly correlate) > > the > > > > messages, could those tools do the conversions of the raw > > sysUptime, > > > > or is it really necessary for the originator to do the=20 > conversion > > of > > > > sysuptime when logging the message? > > > > > > > > Do operators view the raw messages under certain circumstances, > > such > > > > as when they are troubleshooting in real-time? Are they=20 > > > likely to also > > > > be looking at the raw SNMP as well, say as an Ethereal=20 > > > packet capture > > > > of both syslog and SNMP messages? If so, then having the syslng > > raw > > > > sysUptime match the SNMP raw sysUptime might be useful; if they > > are > > > > comparing syslog and SNMP traffic, and SNMP gives them an=20 > > > integer, and > > > > syslog gives them a formatted string in > > > > days:hours:minutes:seconds:hundredths format, that would make it > > > > harder for them rather than easier. > > > > > > > > This WG seems to be working toward improving the ability to=20 > > > correlate > > > > syslog and SNMP events. What are the use-cases that this WG=20 > > > is trying > > > > to target with this effort at consistency between=20 > syslog and SNMP? > > > > What are we trying to achieve by having the SNMP=20 > sysUptime in the > > > > syslog message? > > > > > > > > Is there a real goal here, or is consistency with SNMP just > > > > feature-creep? > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > > > > > > -----Original Message----- > > > > > From: syslog-sec-bounces@www.employees.org > > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf=20 > > > Of Tom Petch > > > > > Sent: Thursday, April 21, 2005 4:12 PM > > > > > To: Rainer Gerhards; syslog-sec@employees.org > > > > > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > > I will try again. > > > > > > > > > > I believe we need a specification of how sysUpTime is > > > > > displayed in the syslog > > > > > message and I do not believe the I-D gives it. ( I am happy > > > > > to use the concept > > > > > of sysUpTime as defined in RFC 3418). > > > > > > > > > > The I-D refers to syntax and I see a problem here.When SNMP, > > > > > as in RFC3418, > > > > > says it has a syntax of TimeTicks by this it means a data > > > > > type, an object type, > > > > > in this case a integer of up to 32 bit (which can be encoded > > > > > in one or two or > > > > > three or four octet) and not much more. Elsewhere in the > > > > > IETF I find syntax > > > > > used in a different, wider sense. So I was, and I am sorry I > > > > > did not spell it > > > > > out more, suggesting that using syntax in the context of > > > > > syslog when referring > > > > > to SNMP was likely to lead to confusion. In which sense is > > > > > the word being used? > > > > > > > > > > Some definitions in SNMP have display hints associated with > > > > > them; as far as I > > > > > know, there is none for sysUpTime (ie TimeTicks) - David will > > > > > put me right if I > > > > > am wrong - and I struggle to think of a useful one. 378 is > > > > > fine when I am > > > > > analysing the log of the early stages of a reboot; 1576800000 > > > > > is not very > > > > > friendly when the server has been up for six months. (And > > > > > even if there is a > > > > > display hint somewhere in tthe RFC, you might need the help > > > > > of a MIB doctor to > > > > > find it:-). > > > > > > > > > > So I see the reference to RFC 3418 as leaving the field wide > > > > > open for any > > > > > representation of a time interval which could be as large as > > > > > 2**32 - 1 /100 > > > > > second or as small as 0.01. I know of nothing in SNMP to > > > > > stop it being > > > > > represented in days:hours:minutes:sec.onds. And this feels > > > > > right; sysUpTime is > > > > > not a user-friendly concept, rather something that a low cost > > > > > agent can cheaply > > > > > handle; different SNMP managers present it differently (and > > > > > yes, some do it in > > > > > days etc).. > > > > > > > > > > I think we should nail the representation down. I do not have > > > > > a good suggestion > > > > > for what that should be. Probably ddddddd.hh in seconds; > > > > > having an integer in > > > > > units of hundredths of seconds is more architecturally pure > > > > > but will confuse > > > > > those not familiar with SNMP, which I suspect will be the > > > > > majority of syslog > > > > > users. > > > > > > > > > > Tom Petch > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rainer Gerhards" > > > > > To: > > > > > Sent: Thursday, April 21, 2005 8:59 PM > > > > > Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > > > > > > > David, > > > > > > > > > > I did specify this based on Tom's comment that the SNMP > > > > > definition could > > > > > not be used for syslog. I reviewed the SNMP RFCs once again > > > > > and thought > > > > > the point was proved. As it looks, that was wrong. So I will > > > > > revert back > > > > > to the previous definition which simply states that it=20 > > > should be RFC > > > > > 3418 compliant. Thanks for pointing this out. > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > > > > Sent: Thursday, April 21, 2005 7:51 PM > > > > > > To: Rainer Gerhards; 'syslog' > > > > > > Subject: protocol-11.txt - sysUpTime > > > > > > > > > > > > Hi, > > > > > > > > > > > > You state that semantics and syntax are as defined in RFC > > 3418, > > > > then > > > > > > proceed to define a different syntax. It is a bad=20 > practice to > > > > claim > > > > > > consistency with something, and then reinvent it but=20 > > > keep calling > > > > it > > > > > > the same thing. We should decide what we want here. > > > > > > > > > > > > If the goal is consistency with SNMP, then we should use the > > > > syntax > > > > > > used for the SNMPv2-MIB sysUpTime [RFC 3418]. That=20 > syntax is a > > > > > > TimeTicks value (INTEGER 0..4294967295 hundredths of a > > > > > second, with no > > > > > > decimal points) since reinitialization of the (SNMP) > > management > > > > > > system. > > > > > > > > > > > > If the goal is to define a syslog-specific version of > > > > > sysUpTime, then > > > > > > we should skip the reference to RFC 3418, call it something > > > > > else, and > > > > > > define it fully as a syslog field. If we go this route, > > > > > then we should > > > > > > discuss what re-initialization of the management system=20 > > > means - is > > > > > > this re-initialization of the SNMP management system,=20 > > > or is it the > > > > > > re-initialization of (a particular part of) the syslog=20 > > > system? We > > > > > > might also want to document rollover behavior. > > > > > > > > > > > > David Harrington > > > > > > dbharrington@comcast.net > > > > > > > > > > > > > #### > > > > > > > 7.3.2 sysUpTime > > > > > > > > > > > > > > The "sysUpTime" parameter MAY be used to=20 > include the SNMP > > > > > > > "sysUpTime" > > > > > > > parameter in the message. Its syntax and semantics are > > as > > > > > > > defined in > > > > > > > RFC 3418 [12]. > > > > > > > > > > > > > > In syslog, it is represented as a decimal string with a > > > > maximum > > > > > > of > > > > > > > two digits for fractional seconds. Full seconds and > > > > fractional > > > > > > > seconds MUST be delimited by a period ("."). Leading > > > > > > > zeros MUST NOT > > > > > > > be used for full seconds. For example, a=20 > > > "sysUpTime" of one > > > > > > minute > > > > > > > MAY be represented as "60", "60.0", or "60.00", but > > > > > not as "060" > > > > > > or > > > > > > > "60.000". > > > > > > > #### > > > > > > > > > > > > > > I am not so proficient with SNMP, but I think (as=20 > you said) > > > > > > > TimeTicks is > > > > > > > actually integer. So we should have a maximum value=20 > > > defined plus > > > > a > > > > > > > rollover behaviour. Or does this mean we also need to > > include > > > > > > > an epoch? > > > > > > > ;) > > > > > > > > > > > > > > Rainer > > > > > > > _______________________________________________ > > > > > > > Syslog-sec mailing list > > > > > > > Syslog-sec@www.employees.org > > > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Syslog-sec mailing list > > > > > Syslog-sec@www.employees.org > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > > _______________________________________________ > > > > > Syslog-sec mailing list > > > > > Syslog-sec@www.employees.org > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > > > > > > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > >=20 > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:01 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 1F9591C342 for ; Tue, 31 May 2005 11:26:01 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:01 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 09:07:52 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 09:07:51 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 06 May 2005 12:21:24 -0400 X-IronPort-AV: i="3.92,162,1112587200"; d="scan'208"; a="48055180:sNHT6882893196" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j46G6FeO027553; Fri, 6 May 2005 12:07:20 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 06 May 2005 09:07:10 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,162,1112598000"; d="scan'208"; a="61984933:sNHT18041040" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id C21E55C832; Fri, 6 May 2005 09:07:06 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 9909D5C7F4 for ; Fri, 6 May 2005 09:07:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 4B9BD1B0074 for ; Fri, 6 May 2005 18:07:26 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26389-10 for ; Fri, 6 May 2005 18:07:20 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id A7AB61B0065 for ; Fri, 6 May 2005 18:07:19 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 May 2005 18:06:57 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-11.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 May 2005 18:06:53 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA06207C@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-11.txt Thread-Index: AcVQJYeJRYtuGtu1Rnaqqy7mAL/W1ACLzGJA From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 06 May 2005 16:06:57.0267 (UTC) FILETIME=[A0C1A430:01C55255] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 Status: RO X-Status: X-Keywords: X-UID: 7 Comments inline... Rainer=20 > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Cl=E9ment MATHIEU > Sent: Tuesday, May 03, 2005 11:17 PM > To: syslog-sec@employees.org > Subject: Re: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-11.txt >=20 > Hi, >=20 > After some other reading of syslog-protocol-11 I have encountered some > new problematic items. >=20 > Let me start with minor issues >=20 > -------------- > 6.2.8 PROCID >=20 > The PROCID field MAY by used to provide the sender's process ID. > -------------- >=20 > s/by/be/ changed >=20 >=20 > -------------- > 7.3.1 sequenceId > 7.2.2 enterpriseID > -------------- >=20 > Should not we use a consistent PARAM-NAME naming scheme ? Id or ID for > both. >=20 based on some previous discussion already changed to enterpriseId :) >=20 > -------------- > (from grammar) > HOSTNAME =3D 1*255PRINTUSASCII ; a FQDN > -------------- >=20 > According to "6.2.6 HOSTNAME", the HOSTNAME field does not always > contain a FQDN. removed comment >=20 >=20 >=20 > Now more important issues to my point of view >=20 > -------------- > In the case that truncation cannot result in a valid=20 > message then the > message SHOULD be dropped. As the MSG part of the message is free- > form and receivers MUST be able to accept messages up to and > including 480 octets in length, truncation according to 3) should > always be possible and as such no dropping SHOULD actually occur. > -------------- >=20 > Why put a requirement on an impossible situation ? A syslog=20 > message can > always be truncated, and the result is always a valid syslog=20 > message. I > can't understand why this SHOULD is in the draft. >=20 I've removed that text. Those that would like to see it in, please = provide arguments (previous discussion indicated there should be a rule, = but I agree, I can not see any case where this rule might be needed). >=20 > -------------- > SD-ELEMENT =3D "[" SD-ID 0*(1*SP SD-PARAM) "]" > -------------- >=20 > I am seeing two problems in this line. The first one is trivial, > according to RFC 2234 "0*" is redundant, * is sufficient. By removing > the '0', notation is more homogeneous (think about *SD-ELEMENT for > example). >=20 > Secondly we can see that more than one SP is allowed between SD-PARAM. > In all other places of this draft, fields are delimited by=20 > one and only > one SP. Why are we allowed to put any number of SP character we want > here ?=20 >=20 > IMHO, to be consistent, one and only one SP character must be allowed. I agree and changed to it SD-ELEMENT =3D "[" SD-ID *(SP SD-PARAM) "] >=20 >=20 >=20 > That's all for today :-) > I am hopping that this post will be useful to improve syslog-protocol >=20 > Cl=E9ment MATHIEU _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:02 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 084AD1C342 for ; Tue, 31 May 2005 11:26:02 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:02 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 09:15:32 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 09:15:30 -0700 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 May 2005 09:15:29 -0700 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j46GDWrq020363; Fri, 6 May 2005 09:15:21 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 06 May 2005 09:15:15 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,162,1112598000"; d="scan'208"; a="62610570:sNHT16430868" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id D95F45C7CA; Fri, 6 May 2005 09:15:12 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id CC6835C77C for ; Fri, 6 May 2005 09:15:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 1639A1B0074 for ; Fri, 6 May 2005 18:15:32 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26774-02 for ; Fri, 6 May 2005 18:15:25 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 6B0461B0065 for ; Fri, 6 May 2005 18:15:25 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 May 2005 18:14:58 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 May 2005 18:14:54 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA06207D@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) Thread-Index: AcVPQGnb0sKFXF9OQTaL8b5Bful5LgDFY6KA From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 06 May 2005 16:14:58.0515 (UTC) FILETIME=[BF9A4230:01C55256] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.205 Status: RO X-Status: X-Keywords: X-UID: 8 Cl=E9ment, you are right, vendor extensions are covered by the "x-" rule. I have = changed the confusing text as follows: #### 6.3.2 SD-ID IANA controls ALL SD-IDs without a hyphen ('-') in the second character position. SD-IDs are case-sensitive and uniquely identify the type and purpose of the SD-ELEMENT. Experimental or vendor- specific SD-ID MUST start with "x-". The first character MUST NOT be anything other than "x" if the second character is a hyphen ('-'). The same SD-ID MUST NOT exist more than once in a message. #### This text reserves all names with a hyphen in the second position and = declares everything invalid, except those that have a "x" in front of = the hyphen. We could alternatively say that the full name space can be used and is = controlled by IANA, with the exception of SD-IDs starting with "x-", = which are reserved for vendor use. In this case, the "x-" header would = delegate part of the name space. Any comments on this? Many thanks, Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Clement MATHIEU > Sent: Monday, May 02, 2005 7:57 PM > To: syslog-sec@employees.org > Subject: Re: [Syslog-sec] Syslog protocol=20 > draft(draft-ietf-syslog-protocol-11.txt) >=20 > Le lundi 02 mai 2005 =E0 08:47 -0700, Alexander Clemm (alex) a =E9crit = : >=20 > > The structured data is an extremely important concept, as=20 > this provides for > > extensibility and separates the "core" fields from the=20 > "extension" fields. > > For the structured data, would it make sense considering to=20 > reserve a prefix > > character (for example, the underscore character) for the=20 > SD-name that > > should not be used for vendor-defined SD elements, so that if later > > extensions to the syslog protocol are standardized in form of new SD > > elements there won't be conflicts - or vice versa, to require vendor > > extensions to start with it? =20 >=20 > Please correct me if I am wrong but i think this issue is already > addressed. >=20 > >From grammar: > STRUCTURED-DATA =3D *SD-ELEMENT / "-" > SD-ELEMENT =3D "[" SD-ID 0*(1*SP SD-PARAM) "]" > SD-ID =3D SD-NAME > SD-NAME =3D 1*32OCTET ; VALID UTF-8 String > ; except '=3D', SP, ']', %d34 (") >=20 > ---------------- draft 11 ------------------- > 6.3.2 SD-ID >=20 > IANA controls ALL SD-IDs without a hyphen ('-') in the second > character position. SD-IDs are case-sensitive and=20 > uniquely identify > the type and purpose of the SD-ELEMENT. Experimental or vendor- > specific SD-ID MUST start with "x-". Anything that doesn't is > managed by IANA. The same SD-ID MUST NOT exist more than once in a > message. > ---------------------------------------------- >=20 > To my understanding a vendor-defined SD-ID can not conflict with a > standardize one.=20 >=20 > BTW, i find 6.3.2 quite unclear. Firstly we say that IANA controls all > SD-ID without a - in second position. >=20 > IANA controlled: > plop > foo-bar > 42 >=20 > (probably) Not IANA controlled: > z-yyyy > a-b-c >=20 > Then we add "Anything that doesn't is managed by IANA.". So, finally, > "z-yyyy" and "a-b-c" are controlled by IANA... >=20 > Confusing isn't it ? >=20 > Theses two sentences are not contradictory; the second one defines a > larger set of SD-ID. >=20 > Am I wrong ? > =09 > Cl=E9ment MATHIEU >=20 > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:03 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id DB84B1C342 for ; Tue, 31 May 2005 11:26:02 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:02 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 09:39:01 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 09:39:00 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 06 May 2005 22:20:58 +0530 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,162,1112553000"; d="scan'208"; a="33259688:sNHT33318992" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j46M5CL5027834; Fri, 6 May 2005 22:07:20 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 06 May 2005 09:38:11 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,162,1112598000"; d="scan'208"; a="105504441:sNHT19643412" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 67C7C5C7C7; Fri, 6 May 2005 09:38:09 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id C77D75C77C for ; Fri, 6 May 2005 09:38:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 03AC31B00AB for ; Fri, 6 May 2005 18:38:29 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26774-07 for ; Fri, 6 May 2005 18:38:24 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 4F1BB1B0065 for ; Fri, 6 May 2005 18:38:24 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 May 2005 18:38:01 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 May 2005 18:37:57 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA06207E@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) Thread-Index: AcVPLjscyr/d4PdXSzepv63+MMkaSQDKNZCw From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 06 May 2005 16:38:01.0477 (UTC) FILETIME=[F7E98350:01C55259] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.204 Status: RO X-Status: X-Keywords: X-UID: 9 Alexander, Many thanks for the good points. Please see my comments inline below.=20 Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Alexander Clemm (alex) > Sent: Monday, May 02, 2005 5:47 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Syslog protocol=20 > draft(draft-ietf-syslog-protocol-11.txt) >=20 > Resending due to apparent mailer problems, apologies if you=20 > receive multiple > copies >=20 > Hello, > =20 > I am currently going through the syslog protocol draft, > draft-ietf-syslog-protocol-11.txt. A couple of thoughts, suggestions, > topics for discussion: > =20 > Basic principles (section 4): May want to clarify: Will=20 > relays be allowed > to send messages to multiple receivers? (Not listed as one of the > scenarios.) May relays alter a message? (Currently, yes, at=20 > least with > regards to truncation; should be explicit in discussing what=20 > aspects of a > message may and what aspects may not be altered.) Relay operations were explicitely excluded from the -protocol draft. = There might come up a specific ID just for this. The list in section 4 = is not meant to cover all potential scenarios, just to give an idea. Of = course, I can add the scenario you mentioned if you think that would = make it easier to grasp. > =20 > Required syslog format: There are essentially 3 parts of the=20 > message which > identify the originator of the message, not even counting the=20 > host name: > Facility, App-Name, Proc-ID. =20 > - Should they be grouped together - why separate them for=20 > example with the > truncate field - may want to take a look at the order of the=20 > fields. I > would think that the truncate field should in fact either=20 > appear after the > version field, or right before the structured data field. =20 The order of fields was initially kept as consistent with RFC 3164 as = possible. Over time, the value in this is actually becoming very weak. = If there is support, we could move some fields to make them look "more = natural". > - Why would facility consist only of digits, not alphanumeric=20 > characters This was done for historical reasons, too. Numeric facilities worked = well. However, the format has much been modified since it was initially = introduced. I stil think numeric facilites help us preserve some of the = momentum that syslog has (it makes it look somewhat more similar to = folks used to current syslog). But I wouldn't object if there is really = strong support for alphanumeric facilities. > - Are three fields really needed? It seems that it makes=20 > sense to allow to > identify the type of the subsystem or application that=20 > generates the syslog > message, as well as the particular instance in case there are=20 > several. This > makes two fields. Why a third field? =20 This has been discussed many times. For a recent discussion please see http://www.syslog.cc/ietf/autoarc/msg01406.html Some pointers can also be found here (I didn't manage to keep the web = page updated through all the discussions): http://www.syslog.cc/ietf/protocol/issue16.html > =20 > Concerning message length: would it make sense to allow for a=20 > means by which > messages could be fragmented, as an option in addition to=20 > truncating? This > could be addressed by having standard structured data=20 > elements that specify > a message as part 1 of 2, for example. Of course, with=20 > regards to relays it > may imply that messages may need to be altered by relays=20 > accordingly. =20 This was discussed in great length over the past month. A pointer to the = early discussion is here: http://www.syslog.cc/ietf/protocol/issue11.html If you search the archive (http://www.syslog.cc/search/search.html) for = "message size", "multi-part messages" and "fragmentation" you will find = plenty of reading. The -03 draft had a complete section on those messages: = http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-protocol-03.txt Further discussion indicated the concensus that = fragementation/multi-part messaging should not be done at this layer. = Even further discussion indicated no interest in messages with a larger = size. > =20 > Relationship to Alarm MIB (Section 6.2.3.1 )- suggest adding=20 > a table that > lists the corresponding relation. Also, really the proper=20 > reference to use > is probably the ITU specification, X.733. =20 I have to admit that I have not good enough knowledge to suggest = anything in this regard. I see the utility of defining the relationship, = but the text was thankfully provided by Sharon Chisholm.=20 Sharon, can you comment on this? > =20 > The structured data is an extremely important concept, as=20 > this provides for > extensibility and separates the "core" fields from the=20 > "extension" fields. > For the structured data, would it make sense considering to=20 > reserve a prefix > character (for example, the underscore character) for the SD-name that > should not be used for vendor-defined SD elements, so that if later > extensions to the syslog protocol are standardized in form of new SD > elements there won't be conflicts - or vice versa, to require vendor > extensions to start with it? =20 Cl=E9ment commented correctly that "x-" is reserved for vendor = extensions. Please see separate post. > =20 > --- Alex > =20 > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:04 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 1A9201C342 for ; Tue, 31 May 2005 11:26:04 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:04 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 11:09:29 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 11:09:29 -0700 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 10 May 2005 11:09:27 -0700 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4AI96rG023400; Tue, 10 May 2005 11:09:21 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 10 May 2005 11:09:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,172,1112598000"; d="scan'208"; a="107314710:sNHT21918220" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id D8BCC5C7E5; Tue, 10 May 2005 11:06:53 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by willers.employees.org (Postfix) with ESMTP id 6977C5C7E3 for ; Tue, 10 May 2005 11:06:52 -0700 (PDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 May 2005 11:06:52 -0700 X-IronPort-AV: i="3.92,172,1112598000"; d="scan'208"; a="263042816:sNHT35088316" 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 j4AI6VO9003576; Tue, 10 May 2005 11:06:44 -0700 (PDT) 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, 10 May 2005 11:06:42 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: SD IDs (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt)) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 10 May 2005 11:06:42 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB23258F@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SD IDs (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt)) Thread-Index: AcVPQGnb0sKFXF9OQTaL8b5Bful5LgDFY6KAAMzzebA= From: "Alexander Clemm (alex)" To: "Rainer Gerhards" , "syslog" X-OriginalArrivalTime: 10 May 2005 18:06:42.0905 (UTC) FILETIME=[0561FC90:01C5558B] Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.204 Status: RO X-Status: X-Keywords: X-UID: 10 Hi, please see my 2 cents on this issue below, at the bottom. Thanks --- Alex=20 -----Original Message----- From: syslog-sec-bounces@willers.employees.org = [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Rainer = Gerhards Sent: Friday, May 06, 2005 9:15 AM To: syslog Subject: RE: [Syslog-sec] Syslog = protocoldraft(draft-ietf-syslog-protocol-11.txt) Cl=E9ment, you are right, vendor extensions are covered by the "x-" rule. I have = changed the confusing text as follows: #### 6.3.2 SD-ID IANA controls ALL SD-IDs without a hyphen ('-') in the second character position. SD-IDs are case-sensitive and uniquely identify the type and purpose of the SD-ELEMENT. Experimental or vendor- specific SD-ID MUST start with "x-". The first character MUST NOT be anything other than "x" if the second character is a hyphen ('-'). The same SD-ID MUST NOT exist more than once in a message. #### This text reserves all names with a hyphen in the second position and = declares everything invalid, except those that have a "x" in front of = the hyphen. We could alternatively say that the full name space can be used and is = controlled by IANA, with the exception of SD-IDs starting with "x-", = which are reserved for vendor use. In this case, the "x-" header would = delegate part of the name space. Any comments on this? Many thanks, Rainer ***ALEX: I think this is expressed a bit awkward. Also, why require = vendor extensions to use 2 extra characters ("x-") to designate them as = such? You could say that IANA SD-IDs will have no hyphen in the second = position, whereas vendor extensions always need one (but then why = restrict it to the letter "x"?) Or, to make it even more compact, you = could say that IANA SD-IDs will start with any letter other than "x", = while vendor extensions always MUST start with the letter "x". I don't = think the extra hyphen is needed. Given that we may see multiple = SD-Elements in syslog messages and there are length restrictions, it = seems prudent to be very economical with requiring additional positions. = =20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:05 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 308D51C342 for ; Tue, 31 May 2005 11:26:05 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:05 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 16:57:09 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 16:57:08 -0700 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 10 May 2005 20:11:50 -0400 X-IronPort-AV: i="3.93,94,1115006400"; d="scan'208"; a="48706203:sNHT67591568" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4ANurnL012364; Tue, 10 May 2005 19:57:01 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 10 May 2005 16:56:35 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,94,1115017200"; d="scan'208"; a="70572593:sNHT20591124" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 07C0B5C7EA; Tue, 10 May 2005 16:56:32 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by willers.employees.org (Postfix) with ESMTP id EDFAD5C793 for ; Tue, 10 May 2005 16:56:29 -0700 (PDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 May 2005 16:56:30 -0700 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 j4ANtrQM027029 for ; Tue, 10 May 2005 16:56:27 -0700 (PDT) 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); Tue, 10 May 2005 16:56:24 -0700 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 Subject: Facility (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)) Date: Tue, 10 May 2005 16:56:23 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB23261B@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Facility (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)) Thread-Index: AcVPLjscyr/d4PdXSzepv63+MMkaSQGihf3A From: "Alexander Clemm (alex)" To: , X-OriginalArrivalTime: 10 May 2005 23:56:24.0561 (UTC) FILETIME=[DF6C9E10:01C555BB] Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 Status: RO X-Status: X-Keywords: X-UID: 11 Hi, I wanted to again bring up the concept of facility. Perhaps the working group has gone through this many times before already, in which case I apologize as I'm still "new to the party". Is there any specific strong reason why facility should be restricted to a number in the range 0..2147483647? If not, my preference would be that facility not be restricted to a numeric identifier, but that alphanumeric characters be permissible. =20 Now, taking this further, section 6.2.2 indicates that facility may be "operator assigned" and may be utilized for some "grouping of messages" by receivers. This appears to be pretty application specific, and I am wondering if this type of semantics really belongs in the "core" of the protocol, or if (since it may essentially involve application-specific semantics) it it would not be more appropriate to put such a facility into SD elements. It would appear that the "core" should only include fields that will be used widely across by pretty much any implementation, with very precisely defined semantics, while SDs are more intended for things that are optional, or things whose use depends on certain conditions. As facility is currently defined in section 6.2.2, it appears more a candidate for the latter. Any comments? =20 =20 Thanks --- Alex -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Alexander Clemm (alex) Sent: Monday, May 02, 2005 8:47 AM To: syslog-sec@employees.org Subject: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) [...] Required syslog format: There are essentially 3 parts of the message which identify the originator of the message, not even counting the host name: Facility, App-Name, Proc-ID. =20 - Should they be grouped together - why separate them for example with the truncate field - may want to take a look at the order of the fields. I would think that the truncate field should in fact either appear after the version field, or right before the structured data field. =20 - Why would facility consist only of digits, not alphanumeric characters - Are three fields really needed? It seems that it makes sense to allow to identify the type of the subsystem or application that generates the syslog message, as well as the particular instance in case there are several. This makes two fields. Why a third field? =20 =20 [...] _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:06 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 0FAA51C342 for ; Tue, 31 May 2005 11:26:06 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:06 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 17:27:04 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 17:27:03 -0700 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 10 May 2005 17:27:03 -0700 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4B0QUnO012381; Tue, 10 May 2005 17:26:58 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 10 May 2005 17:26:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,94,1115017200"; d="scan'208"; a="73673457:sNHT22542396" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id EDE615C82D; Tue, 10 May 2005 17:26:55 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by willers.employees.org (Postfix) with ESMTP id E71545C77E for ; Tue, 10 May 2005 17:26:53 -0700 (PDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 May 2005 17:26:54 -0700 X-IronPort-AV: i="3.93,94,1115017200"; d="scan'208"; a="263196787:sNHT41366568" 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 j4B0QFOV014575 for ; Tue, 10 May 2005 17:26:44 -0700 (PDT) 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); Tue, 10 May 2005 17:26:50 -0700 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 Subject: X.733 (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)) Date: Tue, 10 May 2005 17:26:49 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB232627@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: X.733 (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)) Thread-Index: AcVPLjscyr/d4PdXSzepv63+MMkaSQGj2gDA From: "Alexander Clemm (alex)" To: , X-OriginalArrivalTime: 11 May 2005 00:26:50.0206 (UTC) FILETIME=[1F97EFE0:01C555C0] Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 Status: RO X-Status: X-Keywords: X-UID: 12 =20 Hi, I also have the following additional comment on section 6.2.3.1 - Relation to Alarm MIB. X.733 defines a critical severity as that a service impacting event has occurred and immediate corrective action is required. This appears to correspond to a syslog severity of "Alert", not "Critical" (unfortunately, both X.733 and syslog use the term critical, but their semantics is not exactly the same).=20 X.733 severity of "minor" corresponds to syslog severity of "Error", agree. =20 However, X.733 severity of "major" is in X.733 defined quite different from "minor" and requires "urgent" corrective action. It would appear appropriate to map it into syslog "Critical", not "Error" as well, which would make it indistinguishable from "minor". Finally, it would be nice if X.733 "Cleared" and "Indeterminate" would not both be mapped to the same syslog severity. Yes, it is possible to use "Notice" for both, but why not map "Cleared" to "Informational" instead (since it really indicates that a condition has gone away)? =20 That would result in the following table: X.733 - Syslog -------------- X.733 Critical - Syslog Alert X.733 Major - Syslog Critical X.733 Minor - Syslog Error X.733 Warning - Syslog Warning X.733 Indeterminate - Syslog Notice X.733 Cleared - Syslog Informational --- Alex -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Alexander Clemm (alex) Sent: Monday, May 02, 2005 8:47 AM To: syslog-sec@employees.org Subject: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) Resending due to apparent mailer problems, apologies if you receive multiple copies Hello, =20 I am currently going through the syslog protocol draft, draft-ietf-syslog-protocol-11.txt. A couple of thoughts, suggestions, topics for discussion: =20 Basic principles (section 4): May want to clarify: Will relays be allowed to send messages to multiple receivers? (Not listed as one of the scenarios.) May relays alter a message? (Currently, yes, at least with regards to truncation; should be explicit in discussing what aspects of a message may and what aspects may not be altered.) =20 Required syslog format: There are essentially 3 parts of the message which identify the originator of the message, not even counting the host name: Facility, App-Name, Proc-ID. =20 - Should they be grouped together - why separate them for example with the truncate field - may want to take a look at the order of the fields. I would think that the truncate field should in fact either appear after the version field, or right before the structured data field. =20 - Why would facility consist only of digits, not alphanumeric characters - Are three fields really needed? It seems that it makes sense to allow to identify the type of the subsystem or application that generates the syslog message, as well as the particular instance in case there are several. This makes two fields. Why a third field? =20 =20 Concerning message length: would it make sense to allow for a means by which messages could be fragmented, as an option in addition to truncating? This could be addressed by having standard structured data elements that specify a message as part 1 of 2, for example. Of course, with regards to relays it may imply that messages may need to be altered by relays accordingly. =20 =20 Relationship to Alarm MIB (Section 6.2.3.1 )- suggest adding a table that lists the corresponding relation. Also, really the proper reference to use is probably the ITU specification, X.733. =20 =20 The structured data is an extremely important concept, as this provides for extensibility and separates the "core" fields from the "extension" fields. For the structured data, would it make sense considering to reserve a prefix character (for example, the underscore character) for the SD-name that should not be used for vendor-defined SD elements, so that if later extensions to the syslog protocol are standardized in form of new SD elements there won't be conflicts - or vice versa, to require vendor extensions to start with it? =20 =20 --- Alex =20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:07 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 272171C342 for ; Tue, 31 May 2005 11:26:07 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:07 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 18:14:08 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 18:14:07 -0700 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 10 May 2005 18:14:08 -0700 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4B1DhnN025283; Tue, 10 May 2005 18:14:02 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 10 May 2005 18:13:55 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,94,1115017200"; d="scan'208"; a="63715114:sNHT23703568" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id A159E5C823; Tue, 10 May 2005 18:13:52 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by willers.employees.org (Postfix) with ESMTP id 978195C828 for ; Tue, 10 May 2005 18:13:51 -0700 (PDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 10 May 2005 18:13:52 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4B1DWEX009794 for ; Tue, 10 May 2005 18:13:42 -0700 (PDT) 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); Tue, 10 May 2005 18:13:41 -0700 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 Subject: Syslog message fragmentation (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)) Date: Tue, 10 May 2005 18:13:41 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB232634@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Syslog message fragmentation (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)) Thread-Index: AcVPLjscyr/d4PdXSzepv63+MMkaSQGlRfiQ From: "Alexander Clemm (alex)" To: X-OriginalArrivalTime: 11 May 2005 01:13:41.0736 (UTC) FILETIME=[AB655E80:01C555C6] Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.205 Status: RO X-Status: X-Keywords: X-UID: 13 Hi, one more topic, concerning message fragmentation. I believe Anton Okmianski may also have brought this up in the past. =20 While it is possible to address multi-part messages as part of additional SD elements, possibly defined in an add-on specification, it appears it would make sense to incorporate this capability into the syslog protocol itself, specifically since truncating is defined also. This concerns the ability to "break up" a message into multiple fragments, example part 1 of 3, part 2 of 3, and part 3 of 3, if the message would otherwise be too long. Such a fragmentation COULD be carried out by an sender, including interim systems (relays). =20 The following is a sketch what this would look like. Clearly, if it were decided to incorporate, more detailed specification is required. In essence, fragmentation would require an additional field, possibly a standard SD element. The field would consist of the following components, delimited per a to be determined convention:=20 - A message identifier. (This is not the same as the MSG-ID, as it would refer to a particular message instance, not to a message type.)=20 - Which part of the message this is (first, second, third, and so on) - How many parts there are in total. =20 Subsequent messages that are different parts would all reiterate the header of the message, probably also the structured data (this aspect could be discussed). It would be the message part itself that would be subjected to fragmentation. =20 As it is not permitted to have multiple instances of the same SD Element, recursive multiple fragmentations would curently be prohibited. This would mean it is NOT permitted to have a part 2 of 2 of a part 1 of 3. If this constraint shall be maintained, it should also be specified that IF fragmentation should occur, that the fragments should be small for each of the fragments not to include 480 octets including header and SD data. =20 Anyway, if there is interest in this the details can be worked out for sure. Again, I believe this would be a very useful feature to incorporate. Comments? Regards --- Alex -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Alexander Clemm (alex) Sent: Monday, May 02, 2005 8:47 AM To: syslog-sec@employees.org Subject: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) [...]=20 =20 Concerning message length: would it make sense to allow for a means by which messages could be fragmented, as an option in addition to truncating? This could be addressed by having standard structured data elements that specify a message as part 1 of 2, for example. Of course, with regards to relays it may imply that messages may need to be altered by relays accordingly. =20 =20 [...] _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:08 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 3F7DD1C342 for ; Tue, 31 May 2005 11:26:08 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:08 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 00:54:41 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 00:54:40 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 11 May 2005 13:32:45 +0530 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,94,1114972200"; d="scan'208"; a="34097762:sNHT41973195656" Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4BDKtL4011021; Wed, 11 May 2005 13:22:54 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 11 May 2005 00:53:49 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,94,1115017200"; d="scan'208"; a="73766902:sNHT21839172" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 93FA35C763; Wed, 11 May 2005 00:53:44 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from mail.hq.adiscon.com (unknown [84.245.151.34]) by willers.employees.org (Postfix) with ESMTP id EA3705C733 for ; Wed, 11 May 2005 00:53:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id AEA229C757 for ; Wed, 11 May 2005 11:16:43 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19969-07 for ; Wed, 11 May 2005 11:16:31 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 973DF9C755 for ; Wed, 11 May 2005 11:16:31 +0200 (CEST) Content-class: urn:content-classes:message Subject: RE: Syslog message fragmentation (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt)) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2005 09:53:20 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0620B1@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Syslog message fragmentation (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt)) Thread-Index: AcVPLjscyr/d4PdXSzepv63+MMkaSQGlRfiQAA3DALA= From: "Rainer Gerhards" To: "syslog" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 11 May 2005 07:54:40.0579 (UTC) FILETIME=[AF957930:01C555FE] Status: RO X-Status: X-Keywords: X-UID: 14 Alex, thanks for the suggestion. However, a very similar scheme was already proposed in -protocol-03. Please see section 6 in http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-protocol-03.txt=20 It has been removed from the spec because it was concensus - after month-long discussions - that this should not be in the spec. For similar reasons, a similar approach was removed from Anton's I-D. While I personally still feel it would be worth having it in the draft, I do not like the idea to re-spawn the long, long discussion we had on this topic. I think it would be time to get -protocol close to finish and re-itereating that discussion will probably cause us another very long delay. I also think the arguments are the same that already were exchanged. For some past discussion, please review these threads: http://www.mail-archive.com/syslog-sec@www.employees.org/msg00056.html http://www.syslog.cc/ietf/autoarc/msg01109.html http://www.syslog.cc/ietf/autoarc/msg01294.html http://www.syslog.cc/ietf/autoarc/msg01299.html To get a better view of our current concensus, I would like to ask all those that would like to see a fragmentation scheme back in the syslog protocol to speak up now. Thanks, Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Alexander Clemm (alex) > Sent: Wednesday, May 11, 2005 3:14 AM > To: syslog-sec@employees.org > Subject: Syslog message fragmentation (was: RE: [Syslog-sec]=20 > Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt)) >=20 > Hi, >=20 > one more topic, concerning message fragmentation. I believe Anton > Okmianski may also have brought this up in the past. =20 >=20 > While it is possible to address multi-part messages as part of > additional SD elements, possibly defined in an add-on=20 > specification, it > appears it would make sense to incorporate this capability into the > syslog protocol itself, specifically since truncating is defined also. > This concerns the ability to "break up" a message into multiple > fragments, example part 1 of 3, part 2 of 3, and part 3 of 3, if the > message would otherwise be too long. Such a fragmentation COULD be > carried out by an sender, including interim systems (relays). =20 >=20 > The following is a sketch what this would look like. Clearly, if it > were decided to incorporate, more detailed specification is required. > In essence, fragmentation would require an additional field,=20 > possibly a > standard SD element. The field would consist of the following > components, delimited per a to be determined convention:=20 > - A message identifier. (This is not the same as the MSG-ID, as it > would refer to a particular message instance, not to a message type.)=20 > - Which part of the message this is (first, second, third, and so on) > - How many parts there are in total. =20 >=20 > Subsequent messages that are different parts would all reiterate the > header of the message, probably also the structured data (this aspect > could be discussed). It would be the message part itself=20 > that would be > subjected to fragmentation. =20 >=20 > As it is not permitted to have multiple instances of the same SD > Element, recursive multiple fragmentations would curently be=20 > prohibited. > This would mean it is NOT permitted to have a part 2 of 2 of=20 > a part 1 of > 3. If this constraint shall be maintained, it should also be specified > that IF fragmentation should occur, that the fragments should be small > for each of the fragments not to include 480 octets including=20 > header and > SD data. =20 >=20 > Anyway, if there is interest in this the details can be worked out for > sure. Again, I believe this would be a very useful feature to > incorporate. Comments? >=20 > Regards > --- Alex >=20 >=20 > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf=20 > Of Alexander > Clemm (alex) > Sent: Monday, May 02, 2005 8:47 AM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Syslog protocol > draft(draft-ietf-syslog-protocol-11.txt) >=20 > [...]=20 > =20 > Concerning message length: would it make sense to allow for a means by > which messages could be fragmented, as an option in addition to > truncating? This could be addressed by having standard=20 > structured data > elements that specify a message as part 1 of 2, for example. =20 > Of course, > with regards to relays it may imply that messages may need to=20 > be altered > by relays accordingly. =20 > =20 > [...] > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:09 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 359F81C342 for ; Tue, 31 May 2005 11:26:09 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:09 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 00:59:26 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 00:59:25 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 May 2005 00:59:24 -0700 X-IronPort-AV: i="3.93,94,1115017200"; d="scan'208"; a="635492504:sNHT64860196" Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4B7w6QG019638; Wed, 11 May 2005 00:59:17 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 11 May 2005 00:59:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,94,1115017200"; d="scan'208"; a="63799071:sNHT21270708" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 0FAB85C7EC; Wed, 11 May 2005 00:58:10 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from mail.hq.adiscon.com (unknown [84.245.151.34]) by willers.employees.org (Postfix) with ESMTP id 643635C7AC for ; Wed, 11 May 2005 00:58:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id CB82A9C757 for ; Wed, 11 May 2005 11:21:19 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19969-08 for ; Wed, 11 May 2005 11:21:07 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id B67029C755 for ; Wed, 11 May 2005 11:21:07 +0200 (CEST) Content-class: urn:content-classes:message Subject: RE: Facility (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt)) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2005 09:57:57 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0620B2@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Facility (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt)) Thread-Index: AcVPLjscyr/d4PdXSzepv63+MMkaSQGihf3AABGmc5A= From: "Rainer Gerhards" To: "syslog" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.205 X-OriginalArrivalTime: 11 May 2005 07:59:25.0675 (UTC) FILETIME=[5983ABB0:01C555FF] Status: RO X-Status: X-Keywords: X-UID: 15 Alex, please go through=20 http://www.syslog.cc/ietf/autoarc/msg01406.html It was not about facility, but the other similar fields. Based on that discussion, I think it would still make sense to retain facility as it is (especially because it is a key concept know to the syslog community). Rainer=20 > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Alexander Clemm (alex) > Sent: Wednesday, May 11, 2005 1:56 AM > To: alex@cisco.com; syslog-sec@employees.org > Subject: Facility (was: RE: [Syslog-sec] Syslog=20 > protocoldraft(draft-ietf-syslog-protocol-11.txt)) >=20 > Hi, >=20 > I wanted to again bring up the concept of facility. Perhaps=20 > the working > group has gone through this many times before already, in which case I > apologize as I'm still "new to the party". Is there any specific > strong reason why facility should be restricted to a number=20 > in the range > 0..2147483647? If not, my preference would be that facility not be > restricted to a numeric identifier, but that alphanumeric=20 > characters be > permissible. =20 >=20 > Now, taking this further, section 6.2.2 indicates that facility may be > "operator assigned" and may be utilized for some "grouping of=20 > messages" > by receivers. This appears to be pretty application=20 > specific, and I am > wondering if this type of semantics really belongs in the=20 > "core" of the > protocol, or if (since it may essentially involve application-specific > semantics) it it would not be more appropriate to put such a facility > into SD elements. It would appear that the "core" should only include > fields that will be used widely across by pretty much any > implementation, with very precisely defined semantics, while SDs are > more intended for things that are optional, or things whose=20 > use depends > on certain conditions. As facility is currently defined in section > 6.2.2, it appears more a candidate for the latter. Any comments? =20 > =20 > Thanks > --- Alex >=20 >=20 > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf=20 > Of Alexander > Clemm (alex) > Sent: Monday, May 02, 2005 8:47 AM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Syslog protocol > draft(draft-ietf-syslog-protocol-11.txt) >=20 > [...] >=20 > Required syslog format: There are essentially 3 parts of the message > which identify the originator of the message, not even=20 > counting the host > name: > Facility, App-Name, Proc-ID. =20 > - Should they be grouped together - why separate them for example with > the truncate field - may want to take a look at the order of=20 > the fields. > I would think that the truncate field should in fact either=20 > appear after > the version field, or right before the structured data field. =20 > - Why would facility consist only of digits, not alphanumeric=20 > characters > - Are three fields really needed? It seems that it makes=20 > sense to allow > to identify the type of the subsystem or application that=20 > generates the > syslog message, as well as the particular instance in case there are > several. This makes two fields. Why a third field? =20 > =20 > [...] > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:10 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 1D8331C342 for ; Tue, 31 May 2005 11:26:10 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:10 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 07:54:06 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 07:54:06 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 May 2005 07:54:04 -0700 X-IronPort-AV: i="3.93,96,1115017200"; d="scan'208"; a="263474680:sNHT59288556" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4BEqtQU009985; Wed, 11 May 2005 07:53:58 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 11 May 2005 07:53:53 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,96,1115017200"; d="scan'208"; a="63262964:sNHT30971338" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id DAB125C8AF; Wed, 11 May 2005 07:53:47 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 6BFBF5C843 for ; Wed, 11 May 2005 07:53:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 20B281B00AC for ; Wed, 11 May 2005 16:53:32 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11163-06 for ; Wed, 11 May 2005 16:53:25 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id C83431B0007 for ; Wed, 11 May 2005 16:53:23 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 May 2005 16:53:13 +0200 Subject: RE: SD IDs (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt)) Date: Wed, 11 May 2005 16:53:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0620C5@grfint2.intern.adiscon.com> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-TNEF-Correlator: Thread-Topic: SD IDs (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt)) Thread-Index: AcVPQGnb0sKFXF9OQTaL8b5Bful5LgDFY6KAAMzzebAAK7mFcA== From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 11 May 2005 14:53:13.0588 (UTC) FILETIME=[281A8B40:01C55639] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 Status: RO X-Status: X-Keywords: X-UID: 16 Hi WG, Alex suggestion (below) sounds good to me. I tend to reserve the first character "x" for vendor extension and skip the part about the hyphen. So everything is managed by IANA, except those SD-IDs starting with "x". Are there any concerns? Rainer > ***ALEX: I think this is expressed a bit awkward. Also, why=20 > require vendor extensions to use 2 extra characters ("x-") to=20 > designate them as such? You could say that IANA SD-IDs will=20 > have no hyphen in the second position, whereas vendor=20 > extensions always need one (but then why restrict it to the=20 > letter "x"?) Or, to make it even more compact, you could say=20 > that IANA SD-IDs will start with any letter other than "x",=20 > while vendor extensions always MUST start with the letter=20 > "x". I don't think the extra hyphen is needed. Given that=20 > we may see multiple SD-Elements in syslog messages and there=20 > are length restrictions, it seems prudent to be very=20 > economical with requiring additional positions. =20 >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:11 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 39ED01C342 for ; Tue, 31 May 2005 11:26:11 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:11 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 06:11:52 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 06:11:51 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 12 May 2005 09:11:29 -0400 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4CD9Xee027656; Thu, 12 May 2005 09:11:22 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 12 May 2005 06:11:11 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,99,1115017200"; d="scan'208"; a="64181144:sNHT21135432" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 87FB95C7A3; Thu, 12 May 2005 06:11:06 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by willers.employees.org (Postfix) with ESMTP id 1F55C5C796 for ; Thu, 12 May 2005 06:11:04 -0700 (PDT) Received: from pc6 (1Cust58.tnt108.lnd4.gbr.da.uu.net [62.188.170.58]) by blaster.systems.pipex.net (Postfix) with SMTP id 8083BE00013D; Thu, 12 May 2005 14:10:57 +0100 (BST) Message-ID: <03f601c556eb$159f6c80$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , "syslog" References: <577465F99B41C842AAFBE9ED71E70ABA0620C5@grfint2.intern.adiscon.com> Subject: Re: SD IDs (was: RE: [Syslog-sec] Syslogprotocoldraft(draft-ietf-syslog-protocol-11.txt)) Date: Thu, 12 May 2005 08:57:42 +0200 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 Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Tom Petch List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.205 X-OriginalArrivalTime: 12 May 2005 13:11:51.0710 (UTC) FILETIME=[296F5BE0:01C556F4] Status: RO X-Status: X-Keywords: X-UID: 17 The argument for x- as opposed to x is a) already widely used in SMTP (and elsewhere?) b) a bit more unusual - we may want to start something with x one day, or have - in position two ie of the 1000 or so possible combinations of two characters, we are keeping 999 to ourselves for future expansion and leaving one to enterprise, which in this context, seems reasonable. The general idea is a good one and we may want to expand it in future in directions we cannot currently anticipate so let's keep our options open. As to how to word it, how does SMTP? (In RFC0822, I found "The prefatory string "X-" will never be used in the names of Extension-fields. This provides user-defined fields with a protected set of names.") Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "syslog" Sent: Wednesday, May 11, 2005 4:53 PM Subject: RE: SD IDs (was: RE: [Syslog-sec] Syslogprotocoldraft(draft-ietf-syslog-protocol-11.txt)) Hi WG, Alex suggestion (below) sounds good to me. I tend to reserve the first character "x" for vendor extension and skip the part about the hyphen. So everything is managed by IANA, except those SD-IDs starting with "x". Are there any concerns? Rainer > ***ALEX: I think this is expressed a bit awkward. Also, why > require vendor extensions to use 2 extra characters ("x-") to > designate them as such? You could say that IANA SD-IDs will > have no hyphen in the second position, whereas vendor > extensions always need one (but then why restrict it to the > letter "x"?) Or, to make it even more compact, you could say > that IANA SD-IDs will start with any letter other than "x", > while vendor extensions always MUST start with the letter > "x". I don't think the extra hyphen is needed. Given that > we may see multiple SD-Elements in syslog messages and there > are length restrictions, it seems prudent to be very > economical with requiring additional positions. > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:12 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 586501C342 for ; Tue, 31 May 2005 11:26:12 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:12 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 06:12:24 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 06:12:22 -0700 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 12 May 2005 06:12:18 -0700 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4CDAxre028714; Thu, 12 May 2005 06:12:13 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 12 May 2005 06:11:49 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,99,1115017200"; d="scan'208"; a="71119973:sNHT27619988" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 8E1CF5C7A6; Thu, 12 May 2005 06:11:07 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by willers.employees.org (Postfix) with ESMTP id C1C8D5C784 for ; Thu, 12 May 2005 06:11:03 -0700 (PDT) Received: from pc6 (1Cust58.tnt108.lnd4.gbr.da.uu.net [62.188.170.58]) by blaster.systems.pipex.net (Postfix) with SMTP id BE195E0000C9; Thu, 12 May 2005 14:10:49 +0100 (BST) Message-ID: <03f501c556eb$12ef40a0$0601a8c0@pc6> From: "Tom Petch" To: , "'Rainer Gerhards'" , "'syslog'" References: <20050506131126.47F455C75E@willers.employees.org> Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime Date: Thu, 12 May 2005 08:43:16 +0200 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 Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Tom Petch List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 12 May 2005 13:12:22.0981 (UTC) FILETIME=[3C12EF50:01C556F4] Status: RO X-Status: X-Keywords: X-UID: 18 A belated but partial agreement with David ie specify that there is no decimal point. This, for me, helps to reinforce the point(:-) that this is in TimeTicks units and not seconds. ASCII I don't think belongs there. I see that as specifying a transfer syntax and we already say that that is UTF8. What's the right term for the graphic representation (as opposed to the encoding)? glyph? character? Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Rainer Gerhards'" ; "'syslog'" Sent: Friday, May 06, 2005 3:11 PM Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > Is that decimal digits? Hexadecimal? > Is there a decimal point? > Are the digits represented in ASCII characters? EBCDIC? UTF-8? > > Suggested text: > "value MUST be represented as a decimal integer (no decimal point) > using only the ASCII characters for the range 0..9." > > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > Rainer Gerhards > > Sent: Friday, May 06, 2005 6:27 AM > > To: syslog > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > Hi all, > > > > I have not received any objection to my post below, so I now define > > sysUpTime as follows: > > > > #### > > 7.3.2 sysUpTime > > > > The "sysUpTime" parameter MAY be used to include the SNMP > > "sysUpTime" > > parameter in the message. Its syntax and semantics are as > > defined in > > RFC 3418 [12]. > > > > As syslog does not support the SNMP "integer" syntax directly, > the > > value MUST be represented as a string of digits. > > #### > > > > Rainer > > > > > -----Original Message----- > > > From: syslog-sec-bounces@www.employees.org > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > Rainer Gerhards > > > Sent: Tuesday, April 26, 2005 12:04 PM > > > To: syslog > > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > Hi all, > > > > > > please let me elaborate a little on my experience with syslog > > > use cases. > > > As far as I have seen, there are two major use cases: > > > > > > #1 trouble shooting/setup > > > This is an activity done close to real-time. Here, the raw syslog > > > messages are reviewed by the administrator. The most > > important part in > > > this use case is the free-form message. It tells the > > > administrator which > > > problems the device is experiencing or other status data that is > > > valuable at that very instant. Common scenarios are setting up or > > > troubleshooting router filter settings or firewall rule sets. > > > Here, the > > > device is telling via syslog which rules fired and which > > ones not. So > > > the administrator can check his setup. Also, this use case > > > often applies > > > if a new application/device/whatever is being setup in a > > > network and the > > > admin checks messages from the new device and/or existing devices > - > > > especially if it doesn't work as it should. This use case might be > > > called the "tail -f /var/log/messages" case - just to stress > > > my point... > > > > > > The common thing about this scenario is that the > > administrator reviews > > > raw message in more or less real time. > > > > > > #2 reporting/analysis > > > In this use case, consolidated syslog data is viewed. Raw > > data is NOT > > > viewed. Typically, the analysis is not real-time but acting > > > on past data > > > (though there are some analysis tools which work in real-time or > > > close-to-real-time and then issue alerts based on the > > result of their > > > ongoing analysis). In this use case, a program/script/whatever > > > programmatically reads the syslog entries and somehow > > transforms them > > > into a format that is more understandable by a human. The > > > administrator > > > views the (transformed) end result. > > > > > > Of course, these use cases do not exclude each other. For > > example, it > > > might very well be that an administrator detects an anomaly in a > > > consolidated report (use case #2) and then investigates its > > cause via > > > real-time trouble shooting (use case #1). Eventually, he > > will generate > > > other reports on the fly before he looks at the raw data. > Eventually > > > he'll never look at any raw data because it is not required for > that > > > troubleshooting purpose. > > > > > > Obviously, there are a lot of different use cases. But based on my > > > experience the two above apply to the majority of cases. > > > > > > Now if I look at what the administrator actually does, I > > would expect > > > that in use case #1 sysUpTime will be of little to no help. > > The reason > > > is that the administrator either has recently set up / rebooted > the > > > device and so he knows how long it is up. Or he might have > > come from a > > > transformed report which included the information. In any > > > case, I think > > > sysUpTime will not be the admins prime focus. In fact, I'd say > that > > > he'll probably ignore STRUCTURED-DATA at all and just focus on the > > > human-readble part of the message (MSG). > > > > > > In case #2, sysUpTime will be helpful, but primarily to the report > > > logic. I assume that a decent reporting engine will convert any > > > user-unfriendly data type into information that the admin can > easily > > > make sense of. > > > > > > Again, there are more use cases than the two outlined above. > > > Also, I do > > > not claim to have absolute knowledge about what users do with > their > > > syslogs. However, I am working for a long time in this field > > > and this is > > > honestly what I have seen in practice. > > > > > > If (and only if) my observations are true, that would mean we > > > could use > > > the "user-unfriendly" SNMP integer and only need to specify > > > that it must > > > be represented in string form (because syslog does not > > support binary > > > fields). > > > > > > Any feedback is highly appreciated. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: syslog-sec-bounces@www.employees.org > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > > David B Harrington > > > > Sent: Saturday, April 23, 2005 2:28 PM > > > > To: 'Tom Petch'; 'syslog' > > > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > If the expectation is that syslog messages will be read in > > > syslog raw > > > > format by humans more than by programs, then I agree it > > > should be done > > > > in a presentation format in the message. Under those conditions, > I > > > > suggest breaking out the days, hours, minutes, etc. > > > > > > > > If the expectation is that this field will be used by prgrams > more > > > > than humans, then the raw format woul dbe better. > > > > > > > > Of course, if there are suitable use-cases for each, you > > could also > > > > achieve both a human-friendly and a machine-friendly approach: > > > > "142days:2hr:8min:13sec:9 (123456789)". > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > > > > > > -----Original Message----- > > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > > > Sent: Saturday, April 23, 2005 6:03 AM > > > > > To: ietfdbh@comcast.net; syslog > > > > > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > > David > > > > > > > > > > Yes, your wish to clarify the intended users of syslog > > > > > messages is best done > > > > > first. I assume it is humans like myself (even though I have > > > > > coded log > > > > > analysers). > > > > > > > > > > Having clarified the users, then I will press again for a > > > > > defined presentation > > > > > format. In syslog, sysUpTime is an SD-ID so it is encoded in > > > > > UTF8 and as far as > > > > > I know, UCS only has the concept of characters, not of > > > > > integers, so if the > > > > > presentation format is > > > > > to be standardised, we must do it. > > > > > > > > > > Tom Petch > > > > > ----- Original Message ----- > > > > > From: "David B Harrington" > > > > > To: "'Tom Petch'" ; "'Rainer > > Gerhards'" > > > > > ; > > > > > Sent: Thursday, April 21, 2005 11:48 PM > > > > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > Thank you for the good desacription of your concerns. > > > > > > You are correct; RFC3418 does not have a DISPLAY-HINT. > > > > > > > > > > > > SNMP is designed to be a programmatic interface, not a > > > > > human-friendly > > > > > > interface; SNMP management applications often convert the > > > > unfriendly > > > > > > sysUpTime into days: hours: minutes: seconds, and so > > on, as you > > > > > > suggest. > > > > > > > > > > > > Syslog is designed to be more user-friendly. Syslog > > > certainly can > > > > > > convert the sysUpTime value into something more readily > > > > > understood by > > > > > > humans. One concern I have with that approach is that, > > > in the SNMP > > > > > > world, we try to keep all unnecessary processing out of the > > > > > agent and > > > > > > in the management application, so the device being managed > can > > > > focus > > > > > > on forwarding packets or whatever, and not on converting > > > > > raw data into > > > > > > friendlier forms. While minimizing the management > > processing of > > > > > > internetworking devices was critically important in 1980, > > > > > and is stil > > > > > > important in resource-limited devices such as set-top > > > boxes, many > > > > > > systems now have at least some capability to spare. > > > > > > > > > > > > So my question is, do the bulk of syslog users read the > > > raw syslog > > > > > > messages without any automation, or do the bulk of > > operators now > > > > use > > > > > > tools to help filter syslogs, given the tremendous amount of > > > > > > information available in the logs? I'm sure there are > multiple > > > > > > use-cases. [I do not know the answer to the question; > > it is not > > > > > > rhetorical.] > > > > > > > > > > > > If they are already using tools to view (and possibly > > correlate) > > > > the > > > > > > messages, could those tools do the conversions of the raw > > > > sysUptime, > > > > > > or is it really necessary for the originator to do the > > > conversion > > > > of > > > > > > sysuptime when logging the message? > > > > > > > > > > > > Do operators view the raw messages under certain > > circumstances, > > > > such > > > > > > as when they are troubleshooting in real-time? Are they > > > > > likely to also > > > > > > be looking at the raw SNMP as well, say as an Ethereal > > > > > packet capture > > > > > > of both syslog and SNMP messages? If so, then having > > the syslng > > > > raw > > > > > > sysUptime match the SNMP raw sysUptime might be > > useful; if they > > > > are > > > > > > comparing syslog and SNMP traffic, and SNMP gives them an > > > > > integer, and > > > > > > syslog gives them a formatted string in > > > > > > days:hours:minutes:seconds:hundredths format, that > > would make it > > > > > > harder for them rather than easier. > > > > > > > > > > > > This WG seems to be working toward improving the ability to > > > > > correlate > > > > > > syslog and SNMP events. What are the use-cases that this WG > > > > > is trying > > > > > > to target with this effort at consistency between > > > syslog and SNMP? > > > > > > What are we trying to achieve by having the SNMP > > > sysUptime in the > > > > > > syslog message? > > > > > > > > > > > > Is there a real goal here, or is consistency with SNMP just > > > > > > feature-creep? > > > > > > > > > > > > David Harrington > > > > > > dbharrington@comcast.net > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: syslog-sec-bounces@www.employees.org > > > > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf > > > > > Of Tom Petch > > > > > > > Sent: Thursday, April 21, 2005 4:12 PM > > > > > > > To: Rainer Gerhards; syslog-sec@employees.org > > > > > > > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > > > > > > I will try again. > > > > > > > > > > > > > > I believe we need a specification of how sysUpTime is > > > > > > > displayed in the syslog > > > > > > > message and I do not believe the I-D gives it. ( I am > happy > > > > > > > to use the concept > > > > > > > of sysUpTime as defined in RFC 3418). > > > > > > > > > > > > > > The I-D refers to syntax and I see a problem here.When > SNMP, > > > > > > > as in RFC3418, > > > > > > > says it has a syntax of TimeTicks by this it means a data > > > > > > > type, an object type, > > > > > > > in this case a integer of up to 32 bit (which can be > encoded > > > > > > > in one or two or > > > > > > > three or four octet) and not much more. Elsewhere in the > > > > > > > IETF I find syntax > > > > > > > used in a different, wider sense. So I was, and I am sorry > I > > > > > > > did not spell it > > > > > > > out more, suggesting that using syntax in the context of > > > > > > > syslog when referring > > > > > > > to SNMP was likely to lead to confusion. In which sense > is > > > > > > > the word being used? > > > > > > > > > > > > > > Some definitions in SNMP have display hints associated > with > > > > > > > them; as far as I > > > > > > > know, there is none for sysUpTime (ie TimeTicks) - > > David will > > > > > > > put me right if I > > > > > > > am wrong - and I struggle to think of a useful one. 378 > is > > > > > > > fine when I am > > > > > > > analysing the log of the early stages of a reboot; > > 1576800000 > > > > > > > is not very > > > > > > > friendly when the server has been up for six months. (And > > > > > > > even if there is a > > > > > > > display hint somewhere in tthe RFC, you might need the > help > > > > > > > of a MIB doctor to > > > > > > > find it:-). > > > > > > > > > > > > > > So I see the reference to RFC 3418 as leaving the field > wide > > > > > > > open for any > > > > > > > representation of a time interval which could be as large > as > > > > > > > 2**32 - 1 /100 > > > > > > > second or as small as 0.01. I know of nothing in SNMP to > > > > > > > stop it being > > > > > > > represented in days:hours:minutes:sec.onds. And this > feels > > > > > > > right; sysUpTime is > > > > > > > not a user-friendly concept, rather something that > > a low cost > > > > > > > agent can cheaply > > > > > > > handle; different SNMP managers present it differently > (and > > > > > > > yes, some do it in > > > > > > > days etc).. > > > > > > > > > > > > > > I think we should nail the representation down. I > > do not have > > > > > > > a good suggestion > > > > > > > for what that should be. Probably ddddddd.hh in seconds; > > > > > > > having an integer in > > > > > > > units of hundredths of seconds is more architecturally > pure > > > > > > > but will confuse > > > > > > > those not familiar with SNMP, which I suspect will be the > > > > > > > majority of syslog > > > > > > > users. > > > > > > > > > > > > > > Tom Petch > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Rainer Gerhards" > > > > > > > To: > > > > > > > Sent: Thursday, April 21, 2005 8:59 PM > > > > > > > Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > > > > > > > > > > > > > David, > > > > > > > > > > > > > > I did specify this based on Tom's comment that the SNMP > > > > > > > definition could > > > > > > > not be used for syslog. I reviewed the SNMP RFCs once > again > > > > > > > and thought > > > > > > > the point was proved. As it looks, that was wrong. So I > will > > > > > > > revert back > > > > > > > to the previous definition which simply states that it > > > > > should be RFC > > > > > > > 3418 compliant. Thanks for pointing this out. > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > > > > > > Sent: Thursday, April 21, 2005 7:51 PM > > > > > > > > To: Rainer Gerhards; 'syslog' > > > > > > > > Subject: protocol-11.txt - sysUpTime > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > You state that semantics and syntax are as defined in > RFC > > > > 3418, > > > > > > then > > > > > > > > proceed to define a different syntax. It is a bad > > > practice to > > > > > > claim > > > > > > > > consistency with something, and then reinvent it but > > > > > keep calling > > > > > > it > > > > > > > > the same thing. We should decide what we want here. > > > > > > > > > > > > > > > > If the goal is consistency with SNMP, then we > > should use the > > > > > > syntax > > > > > > > > used for the SNMPv2-MIB sysUpTime [RFC 3418]. That > > > syntax is a > > > > > > > > TimeTicks value (INTEGER 0..4294967295 hundredths of a > > > > > > > second, with no > > > > > > > > decimal points) since reinitialization of the (SNMP) > > > > management > > > > > > > > system. > > > > > > > > > > > > > > > > If the goal is to define a syslog-specific version of > > > > > > > sysUpTime, then > > > > > > > > we should skip the reference to RFC 3418, call it > > something > > > > > > > else, and > > > > > > > > define it fully as a syslog field. If we go this route, > > > > > > > then we should > > > > > > > > discuss what re-initialization of the management system > > > > > means - is > > > > > > > > this re-initialization of the SNMP management system, > > > > > or is it the > > > > > > > > re-initialization of (a particular part of) the syslog > > > > > system? We > > > > > > > > might also want to document rollover behavior. > > > > > > > > > > > > > > > > David Harrington > > > > > > > > dbharrington@comcast.net > > > > > > > > > > > > > > > > > #### > > > > > > > > > 7.3.2 sysUpTime > > > > > > > > > > > > > > > > > > The "sysUpTime" parameter MAY be used to > > > include the SNMP > > > > > > > > > "sysUpTime" > > > > > > > > > parameter in the message. Its syntax and > > semantics are > > > > as > > > > > > > > > defined in > > > > > > > > > RFC 3418 [12]. > > > > > > > > > > > > > > > > > > In syslog, it is represented as a decimal > > string with a > > > > > > maximum > > > > > > > > of > > > > > > > > > two digits for fractional seconds. Full seconds > and > > > > > > fractional > > > > > > > > > seconds MUST be delimited by a period ("."). > Leading > > > > > > > > > zeros MUST NOT > > > > > > > > > be used for full seconds. For example, a > > > > > "sysUpTime" of one > > > > > > > > minute > > > > > > > > > MAY be represented as "60", "60.0", or "60.00", but > > > > > > > not as "060" > > > > > > > > or > > > > > > > > > "60.000". > > > > > > > > > #### > > > > > > > > > > > > > > > > > > I am not so proficient with SNMP, but I think (as > > > you said) > > > > > > > > > TimeTicks is > > > > > > > > > actually integer. So we should have a maximum value > > > > > defined plus > > > > > > a > > > > > > > > > rollover behaviour. Or does this mean we also need to > > > > include > > > > > > > > > an epoch? > > > > > > > > > ;) > > > > > > > > > > > > > > > > > > Rainer > > > > > > > > > _______________________________________________ > > > > > > > > > Syslog-sec mailing list > > > > > > > > > Syslog-sec@www.employees.org > > > > > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Syslog-sec mailing list > > > > > > > Syslog-sec@www.employees.org > > > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Syslog-sec mailing list > > > > > > > Syslog-sec@www.employees.org > > > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Syslog-sec mailing list > > > > Syslog-sec@www.employees.org > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > _______________________________________________ > > > Syslog-sec mailing list > > > Syslog-sec@www.employees.org > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:13 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 5D9611C342 for ; Tue, 31 May 2005 11:26:13 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:13 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 06:48:13 -0700 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 06:48:12 -0700 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 May 2005 15:48:08 +0200 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4CDjiW9006696; Thu, 12 May 2005 15:48:00 +0200 (MEST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 12 May 2005 06:47:48 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,99,1115017200"; d="scan'208"; a="74226396:sNHT20543924" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 4917E5C85D; Thu, 12 May 2005 06:47:45 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by willers.employees.org (Postfix) with ESMTP id 041BE5C793 for ; Thu, 12 May 2005 06:47:43 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005051213474201300hh48ke>; Thu, 12 May 2005 13:47:42 +0000 From: "David B Harrington" To: "'Tom Petch'" , "'Rainer Gerhards'" , "'syslog'" Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime Date: Thu, 12 May 2005 09:47:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <03f501c556eb$12ef40a0$0601a8c0@pc6> Thread-Index: AcVW9AjTPuyxFGN5SKKjdbraFZnQ9wABQT6Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050512134743.041BE5C793@willers.employees.org> Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 12 May 2005 13:48:12.0448 (UTC) FILETIME=[3D419200:01C556F9] Status: RO X-Status: X-Keywords: X-UID: 19 UTF-8 is fine by me, and since it is already specified doesn't need to be mentioned here. dbh > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Thursday, May 12, 2005 2:43 AM > To: ietfdbh@comcast.net; 'Rainer Gerhards'; 'syslog' > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > A belated but partial agreement with David ie specify that > there is no decimal > point. This, for me, helps to reinforce the point(:-) that > this is in TimeTicks > units and not seconds. > > ASCII I don't think belongs there. I see that as specifying > a transfer syntax > and we already say that that is UTF8. What's the right term > for the graphic > representation (as opposed to the encoding)? glyph? character? > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" > To: "'Rainer Gerhards'" ; "'syslog'" > > Sent: Friday, May 06, 2005 3:11 PM > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > Is that decimal digits? Hexadecimal? > > Is there a decimal point? > > Are the digits represented in ASCII characters? EBCDIC? UTF-8? > > > > Suggested text: > > "value MUST be represented as a decimal integer (no decimal point) > > using only the ASCII characters for the range 0..9." > > > > David Harrington > > dbharrington@comcast.net > > > > > -----Original Message----- > > > From: syslog-sec-bounces@www.employees.org > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > Rainer Gerhards > > > Sent: Friday, May 06, 2005 6:27 AM > > > To: syslog > > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > Hi all, > > > > > > I have not received any objection to my post below, so I > now define > > > sysUpTime as follows: > > > > > > #### > > > 7.3.2 sysUpTime > > > > > > The "sysUpTime" parameter MAY be used to include the SNMP > > > "sysUpTime" > > > parameter in the message. Its syntax and semantics are as > > > defined in > > > RFC 3418 [12]. > > > > > > As syslog does not support the SNMP "integer" syntax directly, > > the > > > value MUST be represented as a string of digits. > > > #### > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: syslog-sec-bounces@www.employees.org > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > > Rainer Gerhards > > > > Sent: Tuesday, April 26, 2005 12:04 PM > > > > To: syslog > > > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > Hi all, > > > > > > > > please let me elaborate a little on my experience with syslog > > > > use cases. > > > > As far as I have seen, there are two major use cases: > > > > > > > > #1 trouble shooting/setup > > > > This is an activity done close to real-time. Here, the > raw syslog > > > > messages are reviewed by the administrator. The most > > > important part in > > > > this use case is the free-form message. It tells the > > > > administrator which > > > > problems the device is experiencing or other status data that is > > > > valuable at that very instant. Common scenarios are > setting up or > > > > troubleshooting router filter settings or firewall rule sets. > > > > Here, the > > > > device is telling via syslog which rules fired and which > > > ones not. So > > > > the administrator can check his setup. Also, this use case > > > > often applies > > > > if a new application/device/whatever is being setup in a > > > > network and the > > > > admin checks messages from the new device and/or > existing devices > > - > > > > especially if it doesn't work as it should. This use > case might be > > > > called the "tail -f /var/log/messages" case - just to stress > > > > my point... > > > > > > > > The common thing about this scenario is that the > > > administrator reviews > > > > raw message in more or less real time. > > > > > > > > #2 reporting/analysis > > > > In this use case, consolidated syslog data is viewed. Raw > > > data is NOT > > > > viewed. Typically, the analysis is not real-time but acting > > > > on past data > > > > (though there are some analysis tools which work in real-time or > > > > close-to-real-time and then issue alerts based on the > > > result of their > > > > ongoing analysis). In this use case, a program/script/whatever > > > > programmatically reads the syslog entries and somehow > > > transforms them > > > > into a format that is more understandable by a human. The > > > > administrator > > > > views the (transformed) end result. > > > > > > > > Of course, these use cases do not exclude each other. For > > > example, it > > > > might very well be that an administrator detects an anomaly in a > > > > consolidated report (use case #2) and then investigates its > > > cause via > > > > real-time trouble shooting (use case #1). Eventually, he > > > will generate > > > > other reports on the fly before he looks at the raw data. > > Eventually > > > > he'll never look at any raw data because it is not required for > > that > > > > troubleshooting purpose. > > > > > > > > Obviously, there are a lot of different use cases. But > based on my > > > > experience the two above apply to the majority of cases. > > > > > > > > Now if I look at what the administrator actually does, I > > > would expect > > > > that in use case #1 sysUpTime will be of little to no help. > > > The reason > > > > is that the administrator either has recently set up / rebooted > > the > > > > device and so he knows how long it is up. Or he might have > > > come from a > > > > transformed report which included the information. In any > > > > case, I think > > > > sysUpTime will not be the admins prime focus. In fact, I'd say > > that > > > > he'll probably ignore STRUCTURED-DATA at all and just > focus on the > > > > human-readble part of the message (MSG). > > > > > > > > In case #2, sysUpTime will be helpful, but primarily to > the report > > > > logic. I assume that a decent reporting engine will convert any > > > > user-unfriendly data type into information that the admin can > > easily > > > > make sense of. > > > > > > > > Again, there are more use cases than the two outlined above. > > > > Also, I do > > > > not claim to have absolute knowledge about what users do with > > their > > > > syslogs. However, I am working for a long time in this field > > > > and this is > > > > honestly what I have seen in practice. > > > > > > > > If (and only if) my observations are true, that would mean we > > > > could use > > > > the "user-unfriendly" SNMP integer and only need to specify > > > > that it must > > > > be represented in string form (because syslog does not > > > support binary > > > > fields). > > > > > > > > Any feedback is highly appreciated. > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: syslog-sec-bounces@www.employees.org > > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > > > David B Harrington > > > > > Sent: Saturday, April 23, 2005 2:28 PM > > > > > To: 'Tom Petch'; 'syslog' > > > > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > > If the expectation is that syslog messages will be read in > > > > syslog raw > > > > > format by humans more than by programs, then I agree it > > > > should be done > > > > > in a presentation format in the message. Under those > conditions, > > I > > > > > suggest breaking out the days, hours, minutes, etc. > > > > > > > > > > If the expectation is that this field will be used by prgrams > > more > > > > > than humans, then the raw format woul dbe better. > > > > > > > > > > Of course, if there are suitable use-cases for each, you > > > could also > > > > > achieve both a human-friendly and a machine-friendly approach: > > > > > "142days:2hr:8min:13sec:9 (123456789)". > > > > > > > > > > David Harrington > > > > > dbharrington@comcast.net > > > > > > > > > > > -----Original Message----- > > > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > > > > Sent: Saturday, April 23, 2005 6:03 AM > > > > > > To: ietfdbh@comcast.net; syslog > > > > > > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > > > > David > > > > > > > > > > > > Yes, your wish to clarify the intended users of syslog > > > > > > messages is best done > > > > > > first. I assume it is humans like myself (even > though I have > > > > > > coded log > > > > > > analysers). > > > > > > > > > > > > Having clarified the users, then I will press again for a > > > > > > defined presentation > > > > > > format. In syslog, sysUpTime is an SD-ID so it is > encoded in > > > > > > UTF8 and as far as > > > > > > I know, UCS only has the concept of characters, not of > > > > > > integers, so if the > > > > > > presentation format is > > > > > > to be standardised, we must do it. > > > > > > > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > > > > From: "David B Harrington" > > > > > > To: "'Tom Petch'" ; "'Rainer > > > Gerhards'" > > > > > > ; > > > > > > Sent: Thursday, April 21, 2005 11:48 PM > > > > > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > Thank you for the good desacription of your concerns. > > > > > > > You are correct; RFC3418 does not have a DISPLAY-HINT. > > > > > > > > > > > > > > SNMP is designed to be a programmatic interface, not a > > > > > > human-friendly > > > > > > > interface; SNMP management applications often convert the > > > > > unfriendly > > > > > > > sysUpTime into days: hours: minutes: seconds, and so > > > on, as you > > > > > > > suggest. > > > > > > > > > > > > > > Syslog is designed to be more user-friendly. Syslog > > > > certainly can > > > > > > > convert the sysUpTime value into something more readily > > > > > > understood by > > > > > > > humans. One concern I have with that approach is that, > > > > in the SNMP > > > > > > > world, we try to keep all unnecessary processing > out of the > > > > > > agent and > > > > > > > in the management application, so the device being managed > > can > > > > > focus > > > > > > > on forwarding packets or whatever, and not on converting > > > > > > raw data into > > > > > > > friendlier forms. While minimizing the management > > > processing of > > > > > > > internetworking devices was critically important in 1980, > > > > > > and is stil > > > > > > > important in resource-limited devices such as set-top > > > > boxes, many > > > > > > > systems now have at least some capability to spare. > > > > > > > > > > > > > > So my question is, do the bulk of syslog users read the > > > > raw syslog > > > > > > > messages without any automation, or do the bulk of > > > operators now > > > > > use > > > > > > > tools to help filter syslogs, given the > tremendous amount of > > > > > > > information available in the logs? I'm sure there are > > multiple > > > > > > > use-cases. [I do not know the answer to the question; > > > it is not > > > > > > > rhetorical.] > > > > > > > > > > > > > > If they are already using tools to view (and possibly > > > correlate) > > > > > the > > > > > > > messages, could those tools do the conversions of the raw > > > > > sysUptime, > > > > > > > or is it really necessary for the originator to do the > > > > conversion > > > > > of > > > > > > > sysuptime when logging the message? > > > > > > > > > > > > > > Do operators view the raw messages under certain > > > circumstances, > > > > > such > > > > > > > as when they are troubleshooting in real-time? Are they > > > > > > likely to also > > > > > > > be looking at the raw SNMP as well, say as an Ethereal > > > > > > packet capture > > > > > > > of both syslog and SNMP messages? If so, then having > > > the syslng > > > > > raw > > > > > > > sysUptime match the SNMP raw sysUptime might be > > > useful; if they > > > > > are > > > > > > > comparing syslog and SNMP traffic, and SNMP gives them an > > > > > > integer, and > > > > > > > syslog gives them a formatted string in > > > > > > > days:hours:minutes:seconds:hundredths format, that > > > would make it > > > > > > > harder for them rather than easier. > > > > > > > > > > > > > > This WG seems to be working toward improving the > ability to > > > > > > correlate > > > > > > > syslog and SNMP events. What are the use-cases > that this WG > > > > > > is trying > > > > > > > to target with this effort at consistency between > > > > syslog and SNMP? > > > > > > > What are we trying to achieve by having the SNMP > > > > sysUptime in the > > > > > > > syslog message? > > > > > > > > > > > > > > Is there a real goal here, or is consistency with > SNMP just > > > > > > > feature-creep? > > > > > > > > > > > > > > David Harrington > > > > > > > dbharrington@comcast.net > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: syslog-sec-bounces@www.employees.org > > > > > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf > > > > > > Of Tom Petch > > > > > > > > Sent: Thursday, April 21, 2005 4:12 PM > > > > > > > > To: Rainer Gerhards; syslog-sec@employees.org > > > > > > > > Subject: Re: [Syslog-sec] RE: protocol-11.txt - > sysUpTime > > > > > > > > > > > > > > > > I will try again. > > > > > > > > > > > > > > > > I believe we need a specification of how sysUpTime is > > > > > > > > displayed in the syslog > > > > > > > > message and I do not believe the I-D gives it. ( I am > > happy > > > > > > > > to use the concept > > > > > > > > of sysUpTime as defined in RFC 3418). > > > > > > > > > > > > > > > > The I-D refers to syntax and I see a problem here.When > > SNMP, > > > > > > > > as in RFC3418, > > > > > > > > says it has a syntax of TimeTicks by this it > means a data > > > > > > > > type, an object type, > > > > > > > > in this case a integer of up to 32 bit (which can be > > encoded > > > > > > > > in one or two or > > > > > > > > three or four octet) and not much more. > Elsewhere in the > > > > > > > > IETF I find syntax > > > > > > > > used in a different, wider sense. So I was, and > I am sorry > > I > > > > > > > > did not spell it > > > > > > > > out more, suggesting that using syntax in the context of > > > > > > > > syslog when referring > > > > > > > > to SNMP was likely to lead to confusion. In which sense > > is > > > > > > > > the word being used? > > > > > > > > > > > > > > > > Some definitions in SNMP have display hints associated > > with > > > > > > > > them; as far as I > > > > > > > > know, there is none for sysUpTime (ie TimeTicks) - > > > David will > > > > > > > > put me right if I > > > > > > > > am wrong - and I struggle to think of a useful > one. 378 > > is > > > > > > > > fine when I am > > > > > > > > analysing the log of the early stages of a reboot; > > > 1576800000 > > > > > > > > is not very > > > > > > > > friendly when the server has been up for six > months. (And > > > > > > > > even if there is a > > > > > > > > display hint somewhere in tthe RFC, you might need the > > help > > > > > > > > of a MIB doctor to > > > > > > > > find it:-). > > > > > > > > > > > > > > > > So I see the reference to RFC 3418 as leaving the field > > wide > > > > > > > > open for any > > > > > > > > representation of a time interval which could > be as large > > as > > > > > > > > 2**32 - 1 /100 > > > > > > > > second or as small as 0.01. I know of nothing > in SNMP to > > > > > > > > stop it being > > > > > > > > represented in days:hours:minutes:sec.onds. And this > > feels > > > > > > > > right; sysUpTime is > > > > > > > > not a user-friendly concept, rather something that > > > a low cost > > > > > > > > agent can cheaply > > > > > > > > handle; different SNMP managers present it differently > > (and > > > > > > > > yes, some do it in > > > > > > > > days etc).. > > > > > > > > > > > > > > > > I think we should nail the representation down. I > > > do not have > > > > > > > > a good suggestion > > > > > > > > for what that should be. Probably ddddddd.hh > in seconds; > > > > > > > > having an integer in > > > > > > > > units of hundredths of seconds is more architecturally > > pure > > > > > > > > but will confuse > > > > > > > > those not familiar with SNMP, which I suspect > will be the > > > > > > > > majority of syslog > > > > > > > > users. > > > > > > > > > > > > > > > > Tom Petch > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Rainer Gerhards" > > > > > > > > To: > > > > > > > > Sent: Thursday, April 21, 2005 8:59 PM > > > > > > > > Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > > > > > > > > > > > > > > > > David, > > > > > > > > > > > > > > > > I did specify this based on Tom's comment that the SNMP > > > > > > > > definition could > > > > > > > > not be used for syslog. I reviewed the SNMP RFCs once > > again > > > > > > > > and thought > > > > > > > > the point was proved. As it looks, that was wrong. So I > > will > > > > > > > > revert back > > > > > > > > to the previous definition which simply states that it > > > > > > should be RFC > > > > > > > > 3418 compliant. Thanks for pointing this out. > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > > > > > > > Sent: Thursday, April 21, 2005 7:51 PM > > > > > > > > > To: Rainer Gerhards; 'syslog' > > > > > > > > > Subject: protocol-11.txt - sysUpTime > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > You state that semantics and syntax are as defined in > > RFC > > > > > 3418, > > > > > > > then > > > > > > > > > proceed to define a different syntax. It is a bad > > > > practice to > > > > > > > claim > > > > > > > > > consistency with something, and then reinvent it but > > > > > > keep calling > > > > > > > it > > > > > > > > > the same thing. We should decide what we want here. > > > > > > > > > > > > > > > > > > If the goal is consistency with SNMP, then we > > > should use the > > > > > > > syntax > > > > > > > > > used for the SNMPv2-MIB sysUpTime [RFC 3418]. That > > > > syntax is a > > > > > > > > > TimeTicks value (INTEGER 0..4294967295 hundredths of a > > > > > > > > second, with no > > > > > > > > > decimal points) since reinitialization of the (SNMP) > > > > > management > > > > > > > > > system. > > > > > > > > > > > > > > > > > > If the goal is to define a syslog-specific version of > > > > > > > > sysUpTime, then > > > > > > > > > we should skip the reference to RFC 3418, call it > > > something > > > > > > > > else, and > > > > > > > > > define it fully as a syslog field. If we go > this route, > > > > > > > > then we should > > > > > > > > > discuss what re-initialization of the > management system > > > > > > means - is > > > > > > > > > this re-initialization of the SNMP management system, > > > > > > or is it the > > > > > > > > > re-initialization of (a particular part of) the syslog > > > > > > system? We > > > > > > > > > might also want to document rollover behavior. > > > > > > > > > > > > > > > > > > David Harrington > > > > > > > > > dbharrington@comcast.net > > > > > > > > > > > > > > > > > > > #### > > > > > > > > > > 7.3.2 sysUpTime > > > > > > > > > > > > > > > > > > > > The "sysUpTime" parameter MAY be used to > > > > include the SNMP > > > > > > > > > > "sysUpTime" > > > > > > > > > > parameter in the message. Its syntax and > > > semantics are > > > > > as > > > > > > > > > > defined in > > > > > > > > > > RFC 3418 [12]. > > > > > > > > > > > > > > > > > > > > In syslog, it is represented as a decimal > > > string with a > > > > > > > maximum > > > > > > > > > of > > > > > > > > > > two digits for fractional seconds. Full seconds > > and > > > > > > > fractional > > > > > > > > > > seconds MUST be delimited by a period ("."). > > Leading > > > > > > > > > > zeros MUST NOT > > > > > > > > > > be used for full seconds. For example, a > > > > > > "sysUpTime" of one > > > > > > > > > minute > > > > > > > > > > MAY be represented as "60", "60.0", or > "60.00", but > > > > > > > > not as "060" > > > > > > > > > or > > > > > > > > > > "60.000". > > > > > > > > > > #### > > > > > > > > > > > > > > > > > > > > I am not so proficient with SNMP, but I think (as > > > > you said) > > > > > > > > > > TimeTicks is > > > > > > > > > > actually integer. So we should have a maximum value > > > > > > defined plus > > > > > > > a > > > > > > > > > > rollover behaviour. Or does this mean we > also need to > > > > > include > > > > > > > > > > an epoch? > > > > > > > > > > ;) > > > > > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > _______________________________________________ > > > > > > > > > > Syslog-sec mailing list > > > > > > > > > > Syslog-sec@www.employees.org > > > > > > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Syslog-sec mailing list > > > > > > > > Syslog-sec@www.employees.org > > > > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Syslog-sec mailing list > > > > > > > > Syslog-sec@www.employees.org > > > > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Syslog-sec mailing list > > > > > Syslog-sec@www.employees.org > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > _______________________________________________ > > > > Syslog-sec mailing list > > > > Syslog-sec@www.employees.org > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > _______________________________________________ > > > Syslog-sec mailing list > > > Syslog-sec@www.employees.org > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:14 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 421901C342 for ; Tue, 31 May 2005 11:26:14 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:14 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 00:17:32 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 00:17:32 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 16 May 2005 03:33:11 -0400 X-IronPort-AV: i="3.93,110,1115006400"; d="scan'208"; a="49536760:sNHT55475208" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4G7HLe0002635; Mon, 16 May 2005 03:17:25 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 16 May 2005 00:17:10 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,110,1115017200"; d="scan'208"; a="72310152:sNHT17828428" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 75ABA5C783; Mon, 16 May 2005 00:17:01 -0700 (PDT) X-Original-To: syslog-sec@willers.employees.org Delivered-To: syslog-sec@willers.employees.org Received: from imo-d22.mx.aol.com (imo-d22.mx.aol.com [205.188.144.208]) by willers.employees.org (Postfix) with ESMTP id 0C2105C728 for ; Mon, 16 May 2005 00:16:59 -0700 (PDT) Received: from SFBZH@aol.com by imo-d22.mx.aol.com (mail_out_v38_r1.7.) id j.194.3ef1183b (15889) for ; Mon, 16 May 2005 03:16:54 -0400 (EDT) Received: from aol.com (mow-d25.webmail.aol.com [205.188.139.166]) by air-id08.mx.aol.com (vx) with ESMTP id MAILINID84-3e11428848e43d8; Mon, 16 May 2005 03:16:53 -0400 Date: Mon, 16 May 2005 03:16:52 -0400 From: SFBZH@aol.com To: syslog-sec@willers.employees.org MIME-Version: 1.0 Message-ID: <6DB7A1F8.011C3082.0000F54D@aol.com> X-Mailer: Atlas Mailer 2.0 X-AOL-IP: 194.2.206.192 X-AOL-Language: french Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [Syslog-sec] cooked messages max size X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 16 May 2005 07:17:32.0578 (UTC) FILETIME=[53A84020:01C559E7] Status: RO X-Status: X-Keywords: X-UID: 20 My question is based on RFC 3195 & 3164. In those RFC, it is clearly specified that BSD & RAW messages can't be longer than 1024 characters. Otherwise, the syslog servers & relays ignore the end of the message. What about cooked messages? The part of the cooked message which could get long is the CDATA of the entry element. In RFC 3195, we can read this: The character data for the element is the unstructured syslog event message being logged. If the original device delivers the message for the first time via the COOKED profile, it may have any structure inside the CDATA. However, for maximum compatibility, the device SHOULD format the CDATA of the message in accordance with Sections 4.2.1 through 4.2.3 of [1]. [1] is RFC 3164. First, sections 4.2.1 to 4.2.3 in RFC 3164 don't exist. I assume that RFC 3195 refers to sections 4.1.1 to 4.1.3 of RFC 3164. (Since many sites have copied RFC 3195, it will probably be difficult to catch up that error.) The limit of BSD messages size is not defined in those sections. It is defined just before it, between the 4.1 title and the 4.1.1 title. The result is that, technicaly, no size limit seems to be defined for cooked messages. I suppose that, for backward compatibility reasons, cooked messages have to be shorter than 1024 characters. Could anyone confirm this, please? MC _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:15 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 324601C342 for ; Tue, 31 May 2005 11:26:15 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:15 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 05:26:55 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 05:26:54 -0700 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 16 May 2005 05:26:54 -0700 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4GCPnOM013182; Mon, 16 May 2005 05:26:42 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 16 May 2005 05:26:41 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,111,1115017200"; d="scan'208"; a="64573310:sNHT16617544" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id C5D4D5C7A7; Mon, 16 May 2005 05:26:37 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by willers.employees.org (Postfix) with ESMTP id 9DC2D5C7A7 for ; Mon, 16 May 2005 05:26:11 -0700 (PDT) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 16 May 2005 05:26:11 -0700 Received: from sjc-xdm1.cisco.com (sjc-xdm1.cisco.com [171.71.162.58]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4GCQ9nD016006 for ; Mon, 16 May 2005 05:26:10 -0700 (PDT) Date: Mon, 16 May 2005 05:26:09 -0700 (PDT) From: Chris Lonvick To: syslog-sec@employees.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Mon, 16 May 2005 05:26:37 -0700 Cc: Subject: [Syslog-sec] Wrapping up syslog-protocol and syslog-transport-udp X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 16 May 2005 12:26:54.0560 (UTC) FILETIME=[8B75EE00:01C55A12] Status: RO X-Status: X-Keywords: X-UID: 21 Hi Everyone, I've been glad to see all of the discussion on the mailing list about these documents over the past few weeks. I believe that it shows that we have received sufficient review of these documents. I've been travelling a lot recently and havn't been able to keep up fully with everything. I'd like to have Rainer and Anton provide a list of open issues to the list. Let's focus on these and get them addressed. I'd like to get these things wrapped up and sent to the IESG before the Paris IETF meeting. Speaking of which, due to some family obligations I won't be able to get to IETF 63. :( Does anyone feel that the WG needs to meet at that time? If there is a strong consensus to meet then I'll find someone to stand in for me and I'll get a slot on the agenda. Thanks, Chris _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From aokmians@cisco.com Tue May 31 11:26:16 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 9467C1C342 for ; Tue, 31 May 2005 11:26:16 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:16 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 10:30:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from xbh-rtp-211.amer.cisco.com ([64.102.31.102]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 10:30:29 -0700 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, 16 May 2005 13:30:28 -0400 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 16 May 2005 17:30:28.0164 (UTC) FILETIME=[F39D5840:01C55A3C] Subject: RE: [Syslog-sec] Wrapping up syslog-protocol and syslog-transport-udp Date: Mon, 16 May 2005 10:30:27 -0700 Message-ID: <98AE08B66FAD1742BED6CB9522B73122244D22@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Wrapping up syslog-protocol and syslog-transport-udp Thread-Index: AcVaEozyuncrS3JXRmy5rrz2xwStFwAKkLEw From: "Anton Okmianski (aokmians)" To: "Chris Lonvick (clonvick)" , Status: RO X-Status: X-Keywords: X-UID: 22 Hi! There are no open issues for syslog-transport that I am aware of. = Please submit any suggestions you may have.=20 Anton. =20 > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org=20 > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf=20 > Of Chris Lonvick (clonvick) > Sent: Monday, May 16, 2005 8:26 AM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Wrapping up syslog-protocol and=20 > syslog-transport-udp >=20 > Hi Everyone, >=20 > I've been glad to see all of the discussion on the mailing=20 > list about these documents over the past few weeks. I=20 > believe that it shows that we have received sufficient review=20 > of these documents. >=20 > I've been travelling a lot recently and havn't been able to=20 > keep up fully with everything. I'd like to have Rainer and=20 > Anton provide a list of open issues to the list. Let's focus=20 > on these and get them addressed. I'd like to get these=20 > things wrapped up and sent to the IESG before the Paris IETF meeting. >=20 > Speaking of which, due to some family obligations I won't be=20 > able to get to IETF 63. :( Does anyone feel that the WG=20 > needs to meet at that time? > If there is a strong consensus to meet then I'll find someone=20 > to stand in for me and I'll get a slot on the agenda. >=20 > Thanks, > Chris > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:19 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id ED5ED1C342 for ; Tue, 31 May 2005 11:26:18 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:18 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 06:56:36 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 06:56:36 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 18 May 2005 10:12:08 -0400 X-IronPort-AV: i="3.93,118,1115006400"; d="scan'208"; a="49943647:sNHT54265200" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4IDrtee011390; Wed, 18 May 2005 09:55:58 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 18 May 2005 06:55:34 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,118,1115017200"; d="scan'208"; a="73155741:sNHT19111552" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 929C15C75D; Wed, 18 May 2005 06:55:31 -0700 (PDT) X-Original-To: syslog-sec@willers.employees.org Delivered-To: syslog-sec@willers.employees.org Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by willers.employees.org (Postfix) with ESMTP id 6910C5C726 for ; Wed, 18 May 2005 06:55:30 -0700 (PDT) Received: from SFBZH@aol.com by imo-d04.mx.aol.com (mail_out_v38_r1.7.) id j.12f.5d74e3bd (16100) for ; Wed, 18 May 2005 09:55:22 -0400 (EDT) Received: from aol.com (mow-d18.webmail.aol.com [205.188.139.134]) by air-id11.mx.aol.com (vx) with ESMTP id MAILINID114-3ee4428b494a285; Wed, 18 May 2005 09:55:22 -0400 Date: Wed, 18 May 2005 09:55:22 -0400 From: SFBZH@aol.com To: syslog-sec@willers.employees.org Subject: RE: [Syslog-sec] cooked messages max size MIME-Version: 1.0 Message-ID: <308D09AF.7FDBC36D.0000F54D@aol.com> X-Mailer: Atlas Mailer 2.0 X-AOL-IP: 194.2.206.192 X-AOL-Language: french Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 18 May 2005 13:56:36.0201 (UTC) FILETIME=[67FEAD90:01C55BB1] Status: RO X-Status: X-Keywords: X-UID: 23 Sorry for that but I have to insist. Could anyone please have have a look on that issue? I really need to know how IETF interpret RFC 3195: Are Syslog Cooked messages allowed to be longer than 1024 characters? I have read RFC 3195 and 3164 several times and I have not found any undeniable specification about that. Best Regards MC > My question is based on RFC 3195 & 3164. In those RFC, it is clearly specified that BSD & RAW messages can't be longer than 1024 characters. Otherwise, the syslog servers & relays ignore the end of the message. What about cooked messages? The part of the cooked message which could get long is the CDATA of the entry element. In RFC 3195, we can read this: The character data for the element is the unstructured syslog event message being logged. If the original device delivers the message for the first time via the COOKED profile, it may have any structure inside the CDATA. However, for maximum compatibility, the device SHOULD format the CDATA of the message in accordance with Sections 4.2.1 through 4.2.3 of [1]. [1] is RFC 3164. First, sections 4.2.1 to 4.2.3 in RFC 3164 don't exist. I assume that RFC 3195 refers to sections 4.1.1 to 4.1.3 of RFC 3164. (Since many sites have copied RFC 3195, it will probably be difficult to catch up that error.) The limit of BSD messages size is not defined in those sections. It is defined just before it, between the 4.1 title and the 4.1.1 title. The result is that, technicaly, no size limit seems to be defined for cooked messages. I suppose that, for backward compatibility reasons, cooked messages have to be shorter than 1024 characters. Could anyone confirm this, please? MC < _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:20 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id CCC861C342 for ; Tue, 31 May 2005 11:26:19 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:19 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 07:30:51 -0700 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 07:30:49 -0700 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 18 May 2005 07:30:50 -0700 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4IETVOW019267; Wed, 18 May 2005 07:30:32 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 18 May 2005 07:30:26 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,118,1115017200"; d="scan'208"; a="111242746:sNHT23636064" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 122825C779; Wed, 18 May 2005 07:30:24 -0700 (PDT) X-Original-To: syslog-sec@willers.employees.org Delivered-To: syslog-sec@willers.employees.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by willers.employees.org (Postfix) with ESMTP id AB6D25C7B7 for ; Wed, 18 May 2005 07:30:12 -0700 (PDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 18 May 2005 07:30:12 -0700 X-IronPort-AV: i="3.93,118,1115017200"; d="scan'208"; a="637066315:sNHT28175516" Received: from sjc-xdm1.cisco.com (sjc-xdm1.cisco.com [171.71.162.58]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4IEU3O4019765; Wed, 18 May 2005 07:30:03 -0700 (PDT) Date: Wed, 18 May 2005 07:30:10 -0700 (PDT) From: Chris Lonvick To: SFBZH@aol.com Subject: RE: [Syslog-sec] cooked messages max size In-Reply-To: <308D09AF.7FDBC36D.0000F54D@aol.com> Message-ID: References: <308D09AF.7FDBC36D.0000F54D@aol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 18 May 2005 07:30:23 -0700 Cc: syslog-sec@willers.employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.204 X-OriginalArrivalTime: 18 May 2005 14:30:49.0680 (UTC) FILETIME=[2FF6B500:01C55BB6] Status: RO X-Status: X-Keywords: X-UID: 24 Hi MC, On Wed, 18 May 2005 SFBZH@aol.com wrote: > Sorry for that but I have to insist. Could anyone please have have a look > on that issue? > > I really need to know how IETF interpret RFC 3195: > Are Syslog Cooked messages allowed to be longer than 1024 characters? > I have read RFC 3195 and 3164 several times and I have not found any > undeniable specification about that. If you've looked and can't figure it out, then it must not be properly specified. The Working Group would like to hear your opnion on a resolution. The IETF process works this way: - An INFORMATIONAL document (like RFC 3164) can be used to tell how things have been done in the past. It's really not a STANDARD and shouldn't be treated as one. The most important thing about RFC 3164 was its Security Considerations part that showed most of the flaws in a "fire & forget" system. - There are three stages of a document that is on the STANDARDS TRACK. These are shown in RFC 2026. http://www.ietf.org/rfc/rfc2026.txt - RFC 3195 is currently in the Proposed Standard state. It's been out for a while and people are implementing it and coming up with concerns about it. - The problems that are seen in implementations and deployments of an RFC can be addressed by revising the document. This will "obsolete" the prior RFC. If the protocol is widely deployed and everyone seems happy with it, then it will be moved to Draft Standard. - Once someone has been out for a while and everyone is happy with it and the documents are very thorough then it can be moved to Internet Standard state. The Working Group will need to revise RFC 3195 based upon two things: - People who are developing code and deploying it need to speak up and let us know what works, and what doesn't work and how it can be resolved. - The acceptance of syslog-protocol will force some changes as a reliable transport for syslog should have mechanisms to convey the newly defined fields in a proper manner. Essentially, if you write your implementation of RFC 3195 to convey messages larger than 1024 bytes, and you convince a majority of others to do the same, then the revision of RFC 3195 will follow what you've done. This mailing list is open for people to discuss implementation problems and how things should be resolved. :) Thanks, Chris > > Best Regards > > MC > > > > My question is based on RFC 3195 & 3164. > In those RFC, it is clearly specified that BSD & RAW messages can't be > longer than 1024 characters. Otherwise, the syslog servers & relays > ignore the end of the message. What about cooked messages? > > The part of the cooked message which could get long is the CDATA of the > entry element. In RFC 3195, we can read this: > The character data for the element is the unstructured syslog event > message being logged. If the original device delivers the message > for the first time via the COOKED profile, it may have any structure > inside the CDATA. However, for maximum compatibility, the device > SHOULD format the CDATA of the message in accordance with Sections > 4.2.1 through 4.2.3 of [1]. > [1] is RFC 3164. > First, sections 4.2.1 to 4.2.3 in RFC 3164 don't exist. I assume that > RFC 3195 refers to sections 4.1.1 to 4.1.3 of RFC 3164. (Since many > sites have copied RFC 3195, it will probably be difficult to catch up > that error.) > > The limit of BSD messages size is not defined in those sections. It is > defined just before it, between the 4.1 title and the 4.1.1 title. The > result is that, technicaly, no size limit seems to be defined for cooked > messages. > I suppose that, for backward compatibility reasons, cooked messages have > to be shorter than 1024 characters. Could anyone confirm this, please? > > MC > < > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:21 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id AA0641C342 for ; Tue, 31 May 2005 11:26:20 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:20 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 08:01:38 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 08:01:37 -0700 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 May 2005 11:17:26 -0400 X-IronPort-AV: i="3.93,118,1115006400"; d="scan'208"; a="49958343:sNHT52084538" Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4IEx6o0014444; Wed, 18 May 2005 11:01:15 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 18 May 2005 08:01:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,118,1115017200"; d="scan'208"; a="76258094:sNHT16124572" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id A2E085C7F1; Wed, 18 May 2005 08:01:06 -0700 (PDT) X-Original-To: syslog-sec@willers.employees.org Delivered-To: syslog-sec@willers.employees.org Received: from smtpus.agfa.be (smtpus.agfa.be [199.221.112.6]) by willers.employees.org (Postfix) with ESMTP id 2080F5C76D; Wed, 18 May 2005 08:01:04 -0700 (PDT) Received: from wilswj55.nafta.local (wilswj55.nafta.local [10.237.64.193] (may be forged)) by smtpus.agfa.be (8.11.7p1+Sun/8.11.7) with ESMTP id j4IEsT612700; Wed, 18 May 2005 10:54:29 -0400 (EDT) Subject: Re: [Syslog-sec] cooked messages max size To: SFBZH Message-ID: From: Robert Horn Date: Wed, 18 May 2005 10:42:36 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: syslog-sec@willers.employees.org, syslog-sec-bounces@willers.employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 18 May 2005 15:01:37.0948 (UTC) FILETIME=[7D9E05C0:01C55BBA] Status: RO X-Status: X-Keywords: X-UID: 25 There are applications that are placing arbitrarily large XML encoded messages into the body of cooked messages. In practice these routinely exceed 1024 bytes but rarely exceed 64K bytes. However, the XML schema used is unconstrained in size and may generate larger messages in some situations. R Horn Agfa Healthcare _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:22 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id A77B91C342 for ; Tue, 31 May 2005 11:26:21 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:21 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 09:14:18 -0700 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 09:14:18 -0700 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 May 2005 18:13:56 +0200 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4IGBIWH017143; Wed, 18 May 2005 18:13:48 +0200 (MEST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 18 May 2005 09:13:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,118,1115017200"; d="scan'208"; a="76283301:sNHT15318472" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id F0C845C80D; Wed, 18 May 2005 09:13:21 -0700 (PDT) X-Original-To: syslog-sec@willers.employees.org Delivered-To: syslog-sec@willers.employees.org Received: from imo-d20.mx.aol.com (imo-d20.mx.aol.com [205.188.139.136]) by willers.employees.org (Postfix) with ESMTP id 301245C720 for ; Wed, 18 May 2005 09:13:11 -0700 (PDT) Received: from SFBZH@aol.com by imo-d20.mx.aol.com (mail_out_v38_r1.7.) id j.77.45c29270 (15700) for ; Wed, 18 May 2005 12:12:57 -0400 (EDT) Received: from aol.com (mow-d13.webmail.aol.com [205.188.139.129]) by air-id05.mx.aol.com (vx) with ESMTP id MAILINID52-3d54428b6988138; Wed, 18 May 2005 12:12:57 -0400 Date: Wed, 18 May 2005 12:12:56 -0400 From: SFBZH@aol.com To: syslog-sec@willers.employees.org Subject: [Syslog-sec] cooked messages max size MIME-Version: 1.0 Message-ID: <7DA3C0E2.58239624.0000F54D@aol.com> X-Mailer: Atlas Mailer 2.0 X-AOL-IP: 194.2.206.192 X-AOL-Language: french Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 18 May 2005 16:14:18.0455 (UTC) FILETIME=[A4AE9670:01C55BC4] Status: RO X-Status: X-Keywords: X-UID: 26 I thank both of you (Chris Lonvick & Robert Horn) for those interesting answers. It's more clear now. In fact, for the moment, if the server and the client are developped separately, the server developper is the one who decides how long the messages will be allowed to be and a client that produces messages longer than 1024 characters can only hope the server can handle this. I think I'll consider having critical informations at the begining on the message. MC _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:23 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id DF3821C342 for ; Tue, 31 May 2005 11:26:22 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:22 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 09:21:39 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 09:21:38 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 May 2005 09:21:29 -0700 X-IronPort-AV: i="3.93,118,1115017200"; d="scan'208"; a="266762205:sNHT1802649240" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4IGKSQG025783; Wed, 18 May 2005 09:21:24 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 18 May 2005 09:20:59 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,118,1115017200"; d="scan'208"; a="65230586:sNHT15854544" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 2EF355C793; Wed, 18 May 2005 09:20:57 -0700 (PDT) X-Original-To: syslog-sec@willers.employees.org Delivered-To: syslog-sec@willers.employees.org Received: from mail.shs.siemens.com (mail.shs.siemens.com [64.46.248.224]) by willers.employees.org (Postfix) with ESMTP id F07D55C744 for ; Wed, 18 May 2005 09:20:55 -0700 (PDT) Received: from mlvv9m1x.shs.siemens.com (mlvv9m1x.shs.siemens.com [165.226.204.11]) by mail.shs.siemens.com (Postfix) with ESMTP id 48D3038093 for ; Wed, 18 May 2005 12:20:45 -0400 (EDT) Received: from MLVV9MBA.ww005.siemens.net (mlvv9mba.smshsc.net [165.226.204.44]) by mlvv9m1x.shs.siemens.com (8.12.11/8.12.11) with ESMTP id j4IGKj3K005896 for ; Wed, 18 May 2005 12:20:45 -0400 Received: from MLVV099a.ww005.siemens.net ([165.226.248.184]) by 165.226.204.44 with InterScan Messaging Security Suite; Wed, 18 May 2005 12:20:43 -0400 Received: by mlvv099a.ww005.siemens.net with Internet Mail Service (5.5.2657.72) id <220FAJYK>; Wed, 18 May 2005 12:20:43 -0400 Message-ID: From: Marshall Glen To: syslog-sec@willers.employees.org Subject: RE: [Syslog-sec] cooked messages max size Date: Wed, 18 May 2005 12:20:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 18 May 2005 16:21:38.0735 (UTC) FILETIME=[AB1BFBF0:01C55BC5] Status: RO X-Status: X-Keywords: X-UID: 27 As a specific example of what Rob Horn mentioned, see RFC 3881. This is also incorporated in the work of multiple healthcare standards groups. Cooked reliable syslog messages are the transport. Glen Marshall ------------------------------------------------------------------------------- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to Central.SecurityOffice@shs.siemens.com Thank you _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:24 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 049DC1C342 for ; Tue, 31 May 2005 11:26:24 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:24 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 12:11:21 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 12:11:21 -0700 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 May 2005 12:11:21 -0700 X-IronPort-AV: i="3.93,121,1115017200"; d="scan'208"; a="267348384:sNHT58233916" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4JJ9EOp025820; Thu, 19 May 2005 12:11:10 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 19 May 2005 12:11:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,121,1115017200"; d="scan'208"; a="111994153:sNHT25555684" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id DAF985C784; Thu, 19 May 2005 12:11:06 -0700 (PDT) X-Original-To: syslog-sec@willers.employees.org Delivered-To: syslog-sec@willers.employees.org Received: from smtpus.agfa.be (smtpus.agfa.be [199.221.112.6]) by willers.employees.org (Postfix) with ESMTP id 9125B5C740 for ; Thu, 19 May 2005 12:11:04 -0700 (PDT) Received: from wilswj55.nafta.local (wilswj55.nafta.local [10.237.64.193] (may be forged)) by smtpus.agfa.be (8.11.7p1+Sun/8.11.7) with ESMTP id j4JJ4T617149; Thu, 19 May 2005 15:04:29 -0400 (EDT) Subject: RE: [Syslog-sec] cooked messages max size To: "Marshall Glen Message-ID: From: Robert Horn Date: Thu, 19 May 2005 15:10:08 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: syslog-sec@willers.employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.204 X-OriginalArrivalTime: 19 May 2005 19:11:21.0728 (UTC) FILETIME=[8B0F2800:01C55CA6] Status: RO X-Status: X-Keywords: X-UID: 29 Also, a refinement of the RFC 3881can be found at: ftp://medical.nema.org/medical/dicom/supps/sup95_fz.pdf This takes the general framework of RFC 3881 and further specifies requirements for how particular events are to be encoded for medical devices. One of the interesting things learned in the early work with this is that describing events in XML consumes quite a few bytes. Really simple events fit under 1024 bytes, but it does not take much complexity to push past that limit. A much more realistic limit to impose is a 64KB limit. The commonplace event that "PACS archive sent study X about patient Y to workstation A to prestage it for physician Z based on current appointment schedules" chews up a surprisingly large message if you include full details about the study, machines, and times. Since these messages are defined by multiple schema with namespaces (to manage inheritance properly) fully qualified XML tags can become quite large all on their own. The ability of the COOKED transport to indicate the schema is also useful for the receiving servers so that they can route and parse much more effectively. R Horn _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:25 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 365A51C342 for ; Tue, 31 May 2005 11:26:25 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:25 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 01:14:16 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 01:14:15 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 04:14:13 -0400 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4K8D5eE027552; Fri, 20 May 2005 04:14:07 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 20 May 2005 01:13:45 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,122,1115017200"; d="scan'208"; a="73822653:sNHT50464224" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 1A72E5C7BA; Fri, 20 May 2005 01:13:41 -0700 (PDT) X-Original-To: syslog-sec@willers.employees.org Delivered-To: syslog-sec@willers.employees.org Received: from mail.hq.adiscon.com (unknown [84.245.151.34]) by willers.employees.org (Postfix) with ESMTP id 3ED7D5C73F for ; Fri, 20 May 2005 01:13:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4E2BD9C757; Fri, 20 May 2005 11:37:31 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27809-10; Fri, 20 May 2005 11:37:14 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 00C929C755; Fri, 20 May 2005 11:37:13 +0200 (CEST) Subject: RE: [Syslog-sec] cooked messages max size Date: Fri, 20 May 2005 10:13:12 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA062143@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] cooked messages max size Content-class: urn:content-classes:message Thread-Index: AcVcppPfVHpZPqlmTZ2lTL/snVrtWgAbLLHg X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 From: "Rainer Gerhards" To: "Robert Horn" , "Marshall Glen" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: syslog-sec@willers.employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 20 May 2005 08:14:15.0954 (UTC) FILETIME=[E9E13720:01C55D13] Status: RO X-Status: X-Keywords: X-UID: 30 Hi Robert,=20 I agree on the need to support more than 1024 characters. This has been discussed in this WG in length. However, I do NOT think that RFC3195/COOKED currently supports more than 1024 characters inside the message. I am also not aware of any implementation of RFC3195/COOKED that supports this size. The only implementations of 3195 I know of are listed at: http://www.syslog.cc/ietf/rfcs/3195.html I would appreciate if you could let me know other implementation of it, especially if it supports messages > 1K. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Robert Horn > Sent: Thursday, May 19, 2005 9:10 PM > To: Marshall Glen Cc: syslog-sec@willers.employees.org > Subject: RE: [Syslog-sec] cooked messages max size >=20 >=20 > Also, a refinement of the RFC 3881can be found at: >=20 > ftp://medical.nema.org/medical/dicom/supps/sup95_fz.pdf >=20 > This takes the general framework of RFC 3881 and further specifies > requirements for how particular events are to be encoded for medical > devices. >=20 > One of the interesting things learned in the early work with=20 > this is that > describing events in XML consumes quite a few bytes. Really=20 > simple events > fit under 1024 bytes, but it does not take much complexity to=20 > push past > that limit. A much more realistic limit to impose is a 64KB=20 > limit. The > commonplace event that "PACS archive sent study X about patient Y to > workstation A to prestage it for physician Z based on current=20 > appointment > schedules" chews up a surprisingly large message if you include full > details about the study, machines, and times. Since these=20 > messages are > defined by multiple schema with namespaces (to manage=20 > inheritance properly) > fully qualified XML tags can become quite large all on their own. >=20 > The ability of the COOKED transport to indicate the schema is=20 > also useful > for the receiving servers so that they can route and parse much more > effectively. >=20 > R Horn >=20 > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:26 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 4EC751C342 for ; Tue, 31 May 2005 11:26:26 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:26 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 01:29:00 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 01:29:00 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 04:28:56 -0400 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4K8Sde1000007; Fri, 20 May 2005 04:28:50 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 20 May 2005 01:28:20 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,122,1115017200"; d="scan'208"; a="73825363:sNHT17466884" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 010E15C78D; Fri, 20 May 2005 01:28:18 -0700 (PDT) X-Original-To: syslog-sec@willers.employees.org Delivered-To: syslog-sec@willers.employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 2C7355C741 for ; Fri, 20 May 2005 01:28:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 3A5E91B00AA; Fri, 20 May 2005 10:28:01 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05184-09; Fri, 20 May 2005 10:27:56 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 858BE1B0007; Fri, 20 May 2005 10:27:55 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 May 2005 10:27:52 +0200 Subject: RE: [Syslog-sec] cooked messages max size Date: Fri, 20 May 2005 10:27:49 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA062145@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] cooked messages max size Content-class: urn:content-classes:message Thread-Index: AcVcppPfVHpZPqlmTZ2lTL/snVrtWgAbpJfQ X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 From: "Rainer Gerhards" To: "Robert Horn" , "Marshall Glen" X-OriginalArrivalTime: 20 May 2005 08:27:52.0691 (UTC) FILETIME=[D0B16430:01C55D15] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: syslog-sec@willers.employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 Status: RO X-Status: X-Keywords: X-UID: 31 Robert, a follow-up to my own message. I've searched the mail archive for past discussions and found an interesting one that specifically mentions IHE and RFC 3881. This discussion was the one that is at the core of the message size specification in syslog-protocol, which we are currently discussion. Please note that syslog-protocol will most probably influence the next version of RFC 3195, so the length restrictions made here will most likely apply to any further versions of 3195 (until -protocol is revised itself). The discussion starts around http://www.syslog.cc/ietf/autoarc/msg01297.html and mentions RFC3888 here http://www.syslog.cc/ietf/autoarc/msg01299.html I guess it is necessary to read the whole thread to fully understand it, the two links provided above are most probably not sufficient. At the bottom line, I think the concensus in the WG was that no current implementation of syslog supports more than 1K messages. I am thinking this because we discussed >1K message as something *totally new* to syslog, not as something that is already being used. *IF* it is in use, we eventually need to change the length restriction in syslog-protcol, even though I do not like the idea at this stage. Comments are deeply appreciated. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Robert Horn > Sent: Thursday, May 19, 2005 9:10 PM > To: Marshall Glen Cc: syslog-sec@willers.employees.org > Subject: RE: [Syslog-sec] cooked messages max size >=20 >=20 > Also, a refinement of the RFC 3881can be found at: >=20 > ftp://medical.nema.org/medical/dicom/supps/sup95_fz.pdf >=20 > This takes the general framework of RFC 3881 and further specifies > requirements for how particular events are to be encoded for medical > devices. >=20 > One of the interesting things learned in the early work with=20 > this is that > describing events in XML consumes quite a few bytes. Really=20 > simple events > fit under 1024 bytes, but it does not take much complexity to=20 > push past > that limit. A much more realistic limit to impose is a 64KB=20 > limit. The > commonplace event that "PACS archive sent study X about patient Y to > workstation A to prestage it for physician Z based on current=20 > appointment > schedules" chews up a surprisingly large message if you include full > details about the study, machines, and times. Since these=20 > messages are > defined by multiple schema with namespaces (to manage=20 > inheritance properly) > fully qualified XML tags can become quite large all on their own. >=20 > The ability of the COOKED transport to indicate the schema is=20 > also useful > for the receiving servers so that they can route and parse much more > effectively. >=20 > R Horn >=20 > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:27 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 5F0BA1C342 for ; Tue, 31 May 2005 11:26:27 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:27 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 09:26:18 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 09:26:18 -0700 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 20 May 2005 09:26:14 -0700 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j4KGPLrW012234; Fri, 20 May 2005 09:26:09 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 20 May 2005 09:25:53 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,123,1115017200"; d="scan'208"; a="77012786:sNHT17392880" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 3B7535C7AA; Fri, 20 May 2005 09:25:48 -0700 (PDT) X-Original-To: syslog-sec@willers.employees.org Delivered-To: syslog-sec@willers.employees.org Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by willers.employees.org (Postfix) with ESMTP id 08B845C724 for ; Fri, 20 May 2005 09:25:44 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005052016254301300pfs4de>; Fri, 20 May 2005 16:25:44 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , "'Robert Horn'" , "'Marshall Glen'" Subject: RE: [Syslog-sec] cooked messages max size Date: Fri, 20 May 2005 12:25:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA062145@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVcppPfVHpZPqlmTZ2lTL/snVrtWgAbpJfQABC0U/A= Message-Id: <20050520162544.08B845C724@willers.employees.org> Cc: syslog-sec@willers.employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 20 May 2005 16:26:18.0588 (UTC) FILETIME=[A6BDA9C0:01C55D58] Status: RO X-Status: X-Keywords: X-UID: 32 I didn't go back top read all those threads again. As I recall, we agreed that there should be a restriction to the message size, but also permitted implementations to suppport the size required for things like IHE. I don't remember whether we did this by stating that compliant implementations would support the size restriction, but implementations could always support larger sizes as an implementation choice. I think it unreasonable to expect all implementations to support the huge message sizes required by IHE, as that could joepardize the usefulness of syslog for its original purpose. dbh > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Rainer Gerhards > Sent: Friday, May 20, 2005 4:28 AM > To: Robert Horn; Marshall Glen > Cc: syslog-sec@willers.employees.org > Subject: RE: [Syslog-sec] cooked messages max size > > Robert, > > a follow-up to my own message. I've searched the mail archive for past > discussions and found an interesting one that specifically > mentions IHE > and RFC 3881. This discussion was the one that is at the core of the > message size specification in syslog-protocol, which we are currently > discussion. Please note that syslog-protocol will most probably > influence the next version of RFC 3195, so the length > restrictions made > here will most likely apply to any further versions of 3195 (until > -protocol is revised itself). > > The discussion starts around > http://www.syslog.cc/ietf/autoarc/msg01297.html > > and mentions RFC3888 here > http://www.syslog.cc/ietf/autoarc/msg01299.html > > I guess it is necessary to read the whole thread to fully > understand it, > the two links provided above are most probably not sufficient. > > At the bottom line, I think the concensus in the WG was that > no current > implementation of syslog supports more than 1K messages. I am thinking > this because we discussed >1K message as something *totally new* to > syslog, not as something that is already being used. > > *IF* it is in use, we eventually need to change the length restriction > in syslog-protcol, even though I do not like the idea at this stage. > > Comments are deeply appreciated. > > Rainer > > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Robert Horn > > Sent: Thursday, May 19, 2005 9:10 PM > > To: Marshall Glen > Cc: syslog-sec@willers.employees.org > > Subject: RE: [Syslog-sec] cooked messages max size > > > > > > Also, a refinement of the RFC 3881can be found at: > > > > ftp://medical.nema.org/medical/dicom/supps/sup95_fz.pdf > > > > This takes the general framework of RFC 3881 and further specifies > > requirements for how particular events are to be encoded for medical > > devices. > > > > One of the interesting things learned in the early work with > > this is that > > describing events in XML consumes quite a few bytes. Really > > simple events > > fit under 1024 bytes, but it does not take much complexity to > > push past > > that limit. A much more realistic limit to impose is a 64KB > > limit. The > > commonplace event that "PACS archive sent study X about > patient Y to > > workstation A to prestage it for physician Z based on current > > appointment > > schedules" chews up a surprisingly large message if you include full > > details about the study, machines, and times. Since these > > messages are > > defined by multiple schema with namespaces (to manage > > inheritance properly) > > fully qualified XML tags can become quite large all on their own. > > > > The ability of the COOKED transport to indicate the schema is > > also useful > > for the receiving servers so that they can route and parse much more > > effectively. > > > > R Horn > > > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > > > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:33 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id EFE9D1C342 for ; Tue, 31 May 2005 11:26:32 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:32 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 02:18:11 -0700 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 02:18:10 -0700 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 May 2005 11:17:54 +0200 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4I9EcWG020045; Wed, 18 May 2005 11:17:45 +0200 (MEST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 18 May 2005 02:17:22 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,117,1115017200"; d="scan'208"; a="76175438:sNHT18327576" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id DB4F95C784; Wed, 18 May 2005 02:17:13 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id A2BCA5C722 for ; Wed, 18 May 2005 02:17:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id ABB381B0066 for ; Wed, 18 May 2005 11:16:23 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15276-08 for ; Wed, 18 May 2005 11:16:01 +0200 (CEST) Received: from fmint2.intern.adiscon.com (unknown [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id D32721B005E for ; Wed, 18 May 2005 11:15:59 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 May 2005 11:15:32 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Truncate field and sender MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2005 11:15:22 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA062115@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Truncate field and sender Thread-Index: AcVWPJRxO4svKHE0QYyxZdNv8pvI3AAAM4Ag From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 18 May 2005 09:15:32.0375 (UTC) FILETIME=[245F0A70:01C55B8A] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 Status: RO X-Status: X-Keywords: X-UID: 34 list: sorry, accidently only sent via personal mail. Discovered this today... Rainer -------------------------------- Hello Didier, well... I think there are some subleties in here. >From the API perspective, you definitely have a message that is potentially truncated. From the protocol perspective, the initial sender (the syslogd in this case) does NOT truncate the message - because the initial sender is what (theoretically) generates the message. The real issue here is that what you call the sender is in reality more a relay than the originator. If you look at the message flow app calls API -A-> API writes to unix domain socket -B-> syslogd reads message from domain socket -C-> syslogd transfers message on network The truncation can happen at both A, B and C. If it is in A, I would expect the API to come back with an error or warning state. If it is at B, I would think of it as a realy operation. The same applies to C. OK, enough of these subleties... In practice, it looks like we can have APIs that pass messages longer than the syslog subsystem (or its configuration!) supports. So we can have truncation right at the sender. So, yes, it must be allowed at the initial sender, too. If we take that route, it would probably make sense to define an addition value (4) in the TRUNCATE field. That value should tell that the truncation occured at the initial sender. That information could be helpful so that the receiver might know that digital signatures (written by the inital sender) are still valid, even though the message was truncated (I am assuming signatures are always done by the syslog components and not provided as part of the API - this might NOT be a valid assumption). Are there any concerns? Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Didier DALMASSO > Sent: Wednesday, May 11, 2005 5:16 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Truncate field and sender >=20 > Hi, >=20 > Maybe this topic is a bit out of scope of the working group, but as an > implementor I'm wordering one thing about truncation. >=20 > Syslog-protocol defines use of the truncate field for relays and > collectors but says nothing about senders. In POSIX world, an userland > developer call syslog(int priority, const char *msg); libc write a > RFC 3164 message into /dev/log and then the syslog deamon catch it. >=20 > What the syslog daemon is supposed to do when a locally=20 > received message need to > be truncated. I see two possibility: >=20 > 1/ Truncate field is only used to indicate truncations=20 > occurring during > transport. The sender always put 0 a truncate value >=20 > 2/ Truncate field is also used to indicate truncation by sender >=20 > I'm thinking the second one is a better choice but I'm=20 > interested to know > your opinion. >=20 > Thanks > --=20 > Didier Dalmasso > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:34 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 12EE11C342 for ; Tue, 31 May 2005 11:26:34 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:34 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 02:23:19 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May 2005 02:23:19 -0700 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 May 2005 02:23:19 -0700 X-IronPort-AV: i="3.93,117,1115017200"; d="scan'208"; a="266629202:sNHT60854300" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4I9N7EU013520; Wed, 18 May 2005 02:23:11 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 18 May 2005 02:23:08 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,117,1115017200"; d="scan'208"; a="111124992:sNHT17528060" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 3FEA45C85B; Wed, 18 May 2005 02:23:06 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id CF0725C723 for ; Wed, 18 May 2005 02:23:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 8A75F1B00AF for ; Wed, 18 May 2005 11:22:59 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15276-10 for ; Wed, 18 May 2005 11:22:38 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 878FE1B005E for ; Wed, 18 May 2005 11:22:38 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 May 2005 11:21:55 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Wrapping up syslog-protocol and syslog-transport-udp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2005 11:21:45 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA062116@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Wrapping up syslog-protocol and syslog-transport-udp Thread-Index: AcVaEs8oxxcVBTlxSy29s0buXcLYnABeAJgg From: "Rainer Gerhards" To: X-OriginalArrivalTime: 18 May 2005 09:21:55.0138 (UTC) FILETIME=[08840A20:01C55B8B] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.204 Status: RO X-Status: X-Keywords: X-UID: 35 Hi Chris, sorry for the late reply, we had a local holliday over here on monday and I had a day off yesterday. I think there is nothing major for syslog-protocol. My list is: 1. Syntax of facility It was suggested that it should be alphanumeric, but so far there is no strong support for this - if I don't here anything else, I will not change the definition 2. Relationship to Alarm MIB It was suggested that the text for the relationship should be changed. (see http://www.syslog.cc/ietf/autoarc/msg01444.html). I would appreciate to receive further comment on this. 3. Message Size and Fragmentation This discussion re-started. My view is that we do not proceed any further in this direction (for reasoning see http://www.syslog.cc/ietf/autoarc/msg01446.html). I will NOT change the draft except when I receive very strong reasoning to do so. 4. Truncation by SENDER Implementation efforts indicate that the TRUNCATE field should also support an option to indicate truncation right at the sender (see http://www.syslog.cc/ietf/autoarc/msg01450.html). I am going to add this to the draft if there is no objection (I just re-posted a message that accidently went via private mail only). 5. IANA/vendor SD-IDs I am going to follow Tom Petch's advise in http://www.syslog.cc/ietf/autoarc/msg01451.html and will change the wording but not the actual content. All other things are resolved and merged into my local version of the draft. I think I can post the next revision pretty soon (a new one is due thanks to the recent feedback). Feedback on the mentioned issues is appreciated as are any issues newly discovered or overlooked by me. Thanks, Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Chris Lonvick > Sent: Monday, May 16, 2005 2:26 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Wrapping up syslog-protocol and=20 > syslog-transport-udp >=20 > Hi Everyone, >=20 > I've been glad to see all of the discussion on the mailing list about > these documents over the past few weeks. I believe that it=20 > shows that we > have received sufficient review of these documents. >=20 > I've been travelling a lot recently and havn't been able to=20 > keep up fully > with everything. I'd like to have Rainer and Anton provide a=20 > list of open > issues to the list. Let's focus on these and get them addressed. I'd > like to get these things wrapped up and sent to the IESG=20 > before the Paris > IETF meeting. >=20 > Speaking of which, due to some family obligations I won't be=20 > able to get > to IETF 63. :( Does anyone feel that the WG needs to meet=20 > at that time? > If there is a strong consensus to meet then I'll find someone=20 > to stand in > for me and I'll get a slot on the agenda. >=20 > Thanks, > Chris > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:40 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 9AC371C342 for ; Tue, 31 May 2005 11:26:40 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:40 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 08:45:01 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 08:45:00 -0700 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 May 2005 08:45:00 -0700 X-IronPort-AV: i="3.93,132,1115017200"; d="scan'208"; a="269030948:sNHT70104408" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4OFimc0016387; Tue, 24 May 2005 08:44:52 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 24 May 2005 08:44:48 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,132,1115017200"; d="scan'208"; a="114515640:sNHT20227772" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id E80135C77E; Tue, 24 May 2005 08:44:36 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by willers.employees.org (Postfix) with ESMTP id 4B62B5C76F for ; Mon, 23 May 2005 12:46:50 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03635; Mon, 23 May 2005 15:46:47 -0400 (EDT) Message-Id: <200505231946.PAA03635@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 23 May 2005 15:46:47 -0400 X-Mailman-Approved-At: Tue, 24 May 2005 08:44:35 -0700 X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Cc: syslog-sec@employees.org Subject: [Syslog-sec] I-D ACTION:draft-ietf-syslog-sign-16.txt X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.204 X-OriginalArrivalTime: 24 May 2005 15:45:00.0400 (UTC) FILETIME=[8B472F00:01C56077] Status: RO X-Status: X-Keywords: X-UID: 36 --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, J. Callas Filename : draft-ietf-syslog-sign-16.txt Pages : 31 Date : 2005-5-23 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-16.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-16.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-16.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: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec --NextPart-- From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:41 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 7C8CC1C342 for ; Tue, 31 May 2005 11:26:41 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:41 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 17:56:45 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 17:56:44 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 May 2005 20:56:39 -0400 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4Q0tq59023241; Wed, 25 May 2005 20:56:31 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 25 May 2005 17:56:29 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,138,1115017200"; d="scan'208"; a="67881851:sNHT19365436" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id A37B65C7F1; Wed, 25 May 2005 17:56:24 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by willers.employees.org (Postfix) with ESMTP id ECD9D5C78B for ; Wed, 25 May 2005 17:56:22 -0700 (PDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 25 May 2005 17:56:23 -0700 X-IronPort-AV: i="3.93,138,1115017200"; d="scan'208"; a="269752886:sNHT30917880" 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 j4Q0u9c6018639; Wed, 25 May 2005 17:56:18 -0700 (PDT) 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, 25 May 2005 17:56:15 -0700 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, 25 May 2005 17:56:14 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB321EC8@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Syslog protocol - UTF-8 encoding Thread-Index: AcVcp4fZfHlihyB7S629NqHmK8SfXgE4Oc5w From: "Alexander Clemm (alex)" To: "Rainer Gerhards" X-OriginalArrivalTime: 26 May 2005 00:56:15.0841 (UTC) FILETIME=[B830B510:01C5618D] Cc: syslog-sec@employees.org Subject: [Syslog-sec] Syslog protocol - UTF-8 encoding X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.205 Status: RO X-Status: X-Keywords: X-UID: 37 =20 Hi, 2 questions/ suggestions concerning the UTF-8 encoding in the syslog protocol: 1) Is the " " (white space) after the header to be encoded in ASCII or UTF-8? The spec seems currently open to that respect (although it would seem logical for it to be still in ASCII); should be clarified. =20 2) Concerning the UTF-8 encoding, depending on where you send syslog messages there are many scenarios in which it would be beneficial to have an option in which NOT to use UTF-8 encoding but to also allow for other encodings, in particular plain ASCII. Such an option would also allow for quicker adaptation of this specification, as it is eases the migration. To provide for that, it seems it would make sense to allow for a flag in the header part of the message - at the tail end (that is known to be still ASCII encoded), right before the structured data, that indicates which encoding is used - that is, whether UTF-8 is in effect, or if another encoding is used - ex. ASCII, or even proprietary. =20 (Apologies in case this aspect was discussed in the past and I am beating on a dead horse; but this appears important enough to bring up.) --- Alex _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:42 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 932641C342 for ; Tue, 31 May 2005 11:26:42 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:42 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 19:58:51 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 19:58:50 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 26 May 2005 08:30:10 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,138,1115017200"; d="scan'208"; a="36312671:sNHT26115508" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4Q8Q0rR029547; Thu, 26 May 2005 08:27:05 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 25 May 2005 19:58:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,138,1115017200"; d="scan'208"; a="67289560:sNHT16710212" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id D5EDC5C754; Wed, 25 May 2005 19:58:04 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by willers.employees.org (Postfix) with ESMTP id 3E2FF5C7EC for ; Wed, 25 May 2005 19:58:00 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <2005052602575901200a525fe>; Thu, 26 May 2005 02:58:00 +0000 From: "David B Harrington" To: "'Alexander Clemm (alex)'" , "'Rainer Gerhards'" Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding Date: Wed, 25 May 2005 22:57:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB321EC8@xmb-sjc-236.amer.cisco.com> Thread-Index: AcVcp4fZfHlihyB7S629NqHmK8SfXgE4Oc5wAAVkhjA= Message-Id: <20050526025800.3E2FF5C7EC@willers.employees.org> Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 26 May 2005 02:58:50.0683 (UTC) FILETIME=[D80488B0:01C5619E] Status: RO X-Status: X-Keywords: X-UID: 38 Hi, According to STD63, UTF-8 has the characteristic of preserving the full US-ASCII range. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Alexander Clemm (alex) > Sent: Wednesday, May 25, 2005 8:56 PM > To: Rainer Gerhards > Cc: syslog-sec@employees.org > Subject: [Syslog-sec] Syslog protocol - UTF-8 encoding > > > Hi, > > 2 questions/ suggestions concerning the UTF-8 encoding in the syslog > protocol: > > 1) Is the " " (white space) after the header to be encoded in ASCII or > UTF-8? The spec seems currently open to that respect > (although it would > seem logical for it to be still in ASCII); should be clarified. > > 2) Concerning the UTF-8 encoding, depending on where you send syslog > messages there are many scenarios in which it would be beneficial to > have an option in which NOT to use UTF-8 encoding but to also > allow for > other encodings, in particular plain ASCII. Such an option would also > allow for quicker adaptation of this specification, as it is eases the > migration. To provide for that, it seems it would make sense to allow > for a flag in the header part of the message - at the tail > end (that is > known to be still ASCII encoded), right before the structured > data, that > indicates which encoding is used - that is, whether UTF-8 is > in effect, > or if another encoding is used - ex. ASCII, or even proprietary. > > (Apologies in case this aspect was discussed in the past and I am > beating on a dead horse; but this appears important enough to > bring up.) > > > --- Alex > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:43 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 72B9E1C342 for ; Tue, 31 May 2005 11:26:43 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:43 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 20:11:18 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 20:11:17 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 May 2005 23:11:06 -0400 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4Q39X5C018574; Wed, 25 May 2005 23:11:00 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 25 May 2005 20:10:35 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,138,1115017200"; d="scan'208"; a="78776432:sNHT17252424" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 6648C5C7F7; Wed, 25 May 2005 20:10:33 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by willers.employees.org (Postfix) with ESMTP id 9056C5C776 for ; Wed, 25 May 2005 20:10:31 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <20050526031030016004v08fe>; Thu, 26 May 2005 03:10:30 +0000 From: "David B Harrington" To: , "'Alexander Clemm (alex)'" , "'Rainer Gerhards'" Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding Date: Wed, 25 May 2005 23:10:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050526025800.3E2FF5C7EC@willers.employees.org> Thread-Index: AcVcp4fZfHlihyB7S629NqHmK8SfXgE4Oc5wAAVkhjAAAHNNgA== Message-Id: <20050526031031.9056C5C776@willers.employees.org> Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 26 May 2005 03:11:17.0972 (UTC) FILETIME=[956FC940:01C561A0] Status: RO X-Status: X-Keywords: X-UID: 39 Hi, In reading my response, it seeems a bit too succinct. The relevant text from STD63 is: "UTF-8, the object of this memo, has a one-octet encoding unit. It uses all bits of an octet, but has the quality of preserving the full US-ASCII [US-ASCII] range: US-ASCII characters are encoded in one octet having the normal US-ASCII value, and any octet with such a value can only stand for a US-ASCII character, and nothing else." Hope this allays your concerns. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > David B Harrington > Sent: Wednesday, May 25, 2005 10:58 PM > To: 'Alexander Clemm (alex)'; 'Rainer Gerhards' > Cc: syslog-sec@employees.org > Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding > > Hi, > > According to STD63, UTF-8 has the characteristic of preserving the > full US-ASCII range. > > David Harrington > dbharrington@comcast.net > > > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > Alexander Clemm (alex) > > Sent: Wednesday, May 25, 2005 8:56 PM > > To: Rainer Gerhards > > Cc: syslog-sec@employees.org > > Subject: [Syslog-sec] Syslog protocol - UTF-8 encoding > > > > > > Hi, > > > > 2 questions/ suggestions concerning the UTF-8 encoding in the syslog > > protocol: > > > > 1) Is the " " (white space) after the header to be encoded in ASCII > or > > UTF-8? The spec seems currently open to that respect > > (although it would > > seem logical for it to be still in ASCII); should be clarified. > > > > 2) Concerning the UTF-8 encoding, depending on where you send > syslog > > messages there are many scenarios in which it would be beneficial to > > have an option in which NOT to use UTF-8 encoding but to also > > allow for > > other encodings, in particular plain ASCII. Such an option would > also > > allow for quicker adaptation of this specification, as it is eases > the > > migration. To provide for that, it seems it would make sense to > allow > > for a flag in the header part of the message - at the tail > > end (that is > > known to be still ASCII encoded), right before the structured > > data, that > > indicates which encoding is used - that is, whether UTF-8 is > > in effect, > > or if another encoding is used - ex. ASCII, or even proprietary. > > > > (Apologies in case this aspect was discussed in the past and I am > > beating on a dead horse; but this appears important enough to > > bring up.) > > > > > > --- Alex > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:45 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 8605B1C342 for ; Tue, 31 May 2005 11:26:44 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:44 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 01:16:21 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 01:16:34 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 27 May 2005 13:48:11 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,142,1115017200"; d="scan'208"; a="36526570:sNHT27180796" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RDibrE002715; Fri, 27 May 2005 13:44:51 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 27 May 2005 01:15:35 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,142,1115017200"; d="scan'208"; a="76089040:sNHT16868192" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 98B2C5C7C8; Fri, 27 May 2005 01:15:28 -0700 (PDT) X-Original-To: syslog-sec@willers.employees.org Delivered-To: syslog-sec@willers.employees.org Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by willers.employees.org (Postfix) with ESMTP id AD38F5C73C for ; Fri, 27 May 2005 01:15:26 -0700 (PDT) Received: from SFBZH@aol.com by imo-d04.mx.aol.com (mail_out_v38_r1.7.) id j.2b.73f5e99a (15886) for ; Fri, 27 May 2005 04:15:20 -0400 (EDT) Received: from aol.com (mow-m02.webmail.aol.com [64.12.184.130]) by air-id08.mx.aol.com (v106.2) with ESMTP id MAILINID81-3e0e4296d7172cd; Fri, 27 May 2005 04:15:20 -0400 Date: Fri, 27 May 2005 04:15:19 -0400 From: SFBZH@aol.com To: syslog-sec@willers.employees.org Subject: [Syslog-sec] cooked messages max size MIME-Version: 1.0 Message-ID: <2333D0D3.646F58F8.0000F54D@aol.com> X-Mailer: Atlas Mailer 2.0 X-AOL-IP: 194.2.206.192 X-AOL-Language: french Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 27 May 2005 08:16:35.0152 (UTC) FILETIME=[65BD6500:01C56294] Status: RO X-Status: X-Keywords: X-UID: 40 Rainer Gerhards wrote: > I am also not aware of any implementation of RFC3195/COOKED that supports this size. The only implementations of 3195 I know of are listed at: http://www.syslog.cc/ietf/rfcs/3195.html I would appreciate if you could let me know other implementation of it, especially if it supports messages > 1K. < I don't know any other implementation of RFC3195/COOKED but there is an other implementation of RFC3195/RAM only. I've found it on the beepcore's beep products and projects page. It's called roadrunner (beep beep!!!). more info here: http://rr.codefactory.se/ MC _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:26:45 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id A64771C342 for ; Tue, 31 May 2005 11:26:45 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:26:45 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 05:09:57 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 05:10:00 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 27 May 2005 17:41:41 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,143,1115017200"; d="scan'208"; a="36561227:sNHT35677976" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RHbNrQ024554; Fri, 27 May 2005 17:38:17 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 27 May 2005 05:09:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,143,1115017200"; d="scan'208"; a="67726746:sNHT23324136" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 5CE1F5C743; Fri, 27 May 2005 05:09:29 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by willers.employees.org (Postfix) with SMTP id F40855C7C8 for ; Wed, 25 May 2005 19:03:26 -0700 (PDT) Received: (qmail 80745 invoked from network); 26 May 2005 02:03:23 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 26 May 2005 02:03:23 -0000 X-pair-Authenticated: 219.88.140.76 From: "Andrew Ross" To: "'Alexander Clemm (alex)'" , "'Rainer Gerhards'" Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding Date: Thu, 26 May 2005 14:03:20 +1200 Organization: Kiwi Enterprises Message-ID: <000601c56197$18b52d90$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: <85B2F271FDF6B949B3672BA5A7BB62FB321EC8@xmb-sjc-236.amer.cisco.com> X-Mailman-Approved-At: Fri, 27 May 2005 05:09:26 -0700 Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 27 May 2005 12:10:00.0838 (UTC) FILETIME=[01C77A60:01C562B5] Status: RO X-Status: X-Keywords: X-UID: 41 Hi Alex, The way I understand it, ASCII is a subset of UTF-8 (i.e. The first 127 = chrs of UTF-8 are the same as ASCII chrs). My vote is to standardize on UTF-8 = as the encoding system. If you wanted to send ASCII (7 bit), then you are actually sending the exact same bytes on the wire as you would for = UTF-8.=20 With regard to the space chr. As far as I know, there is only one way to encode this. ASCII 32 (&h20) =3D UTF-8 32 (&20) =3D space.=20 Since UTF-8 can handle all of the Unicode characters and matches ASCII = for the first 127 chrs, I believe we should stick to that encoding system. = It also avoids having to add a header to define the character set.=20 Apart from ASCII encoding, could you see a requirement for any other encoding system? Cheers Andrew -----Original Message----- From: syslog-sec-bounces@www.employees.org [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Alexander = Clemm (alex) Sent: Thursday, 26 May 2005 12:56 p.m. To: Rainer Gerhards Cc: syslog-sec@employees.org Subject: [Syslog-sec] Syslog protocol - UTF-8 encoding =20 Hi, 2 questions/ suggestions concerning the UTF-8 encoding in the syslog protocol: 1) Is the " " (white space) after the header to be encoded in ASCII or UTF-8? The spec seems currently open to that respect (although it would seem logical for it to be still in ASCII); should be clarified. =20 2) Concerning the UTF-8 encoding, depending on where you send syslog messages there are many scenarios in which it would be beneficial to have an option in which NOT to use UTF-8 encoding but to also allow for other encodings, in particular plain ASCII. Such an option would also allow for quicker adaptation of this specification, as it is eases the migration. To provide for that, it seems it would make sense to allow for a flag in the header part of the message - at the tail end (that is known to be still ASCII encoded), right before the structured data, that indicates which encoding is used - that is, whether UTF-8 is in effect, or if another encoding is used - ex. ASCII, or even proprietary. =20 (Apologies in case this aspect was discussed in the past and I am beating on a dead horse; but this appears important enough to bring up.) --- Alex _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:33 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 8CD6B19046 for ; Mon, 22 Aug 2005 18:51:32 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:32 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 13:06:07 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 13:06:06 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 31 May 2005 13:06:06 -0700 X-IronPort-AV: i="3.93,154,1115017200"; d="scan'208"; a="639805881:sNHT118577428" Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4VK4vmG017044; Tue, 31 May 2005 13:06:00 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 31 May 2005 13:05:51 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,154,1115017200"; d="scan'208"; a="69444756:sNHT30466112" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 0B3A85C753; Tue, 31 May 2005 13:05:42 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by willers.employees.org (Postfix) with ESMTP id 695FC5C754 for ; Tue, 31 May 2005 12:59:07 -0700 (PDT) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 31 May 2005 15:59:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4VJwYlS013865 for ; Tue, 31 May 2005 15:59:05 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 15:59:02 -0400 Received: from [64.101.182.111] ([64.101.182.111]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 15:59:01 -0400 Date: Tue, 31 May 2005 14:59:01 -0500 (CDT) From: Chris Lonvick X-X-Sender: lonvick@linux.local To: syslog-sec@employees.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 31 May 2005 19:59:01.0901 (UTC) FILETIME=[30CFEBD0:01C5661B] X-Mailman-Approved-At: Tue, 31 May 2005 13:05:40 -0700 Cc: Subject: [Syslog-sec] OIF Liaison on syslog-protocol X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.205 Status: RO X-Status: X-Keywords: X-UID: 42 Hi Folks, We received a liaison letter from the OIF along with comments about the current syslog-protocol and syslog-transport-udp IDs. I've sent the liaison letter to the IETF Liaison repository and the markups to the authors. The liaison letter can also be found here: http://www.employees.org/~lonvick/attachments/liaison2_IETF.pdf Below is the markup from the IOF for the syslog-protocol ID. I'm adding it here so it can be in the email archive. Thanks, Chris ---- syslog Working Group R. Gerhards Internet-Draft Adiscon GmbH Expires: August 22, 2005 February 18, 2005 The syslog Protocol draft-ietf-syslog-protocol-10.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with * s/become/&s/ RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 22, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the syslog protocol which is used to convey *s/protocol/&,/ event notification messages. This protocol utilizes a layered architecture, which enables use of any number of transport protocols *s/enables/allows the/ for transmission of syslog messages. It also provides a message format which allows vendor-specific extensions to be provided in a *s/which/that/ structured way. *Comment: It would be good to point out, right away, why RFC 3164 is *being changed. A lot of code has been written for the "old syslog," and *people need an incentive to adopt this change. Gerhards Expires August 22, 2005 [Page 1] Internet-Draft The syslog Protocol February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Principles . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Example Deployment Scenarios . . . . . . . . . . . . . . . 7 5. Transport Layer Protocol . . . . . . . . . . . . . . . . . . . 9 5.1 Minimum Required Transport Mapping . . . . . . . . . . . . 9 6. Required syslog Format . . . . . . . . . . . . . . . . . . . . 10 6.1 Message Length . . . . . . . . . . . . . . . . . . . . . . 11 6.2 HEADER . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2.1 VERSION . . . . . . . . . . . . . . . . . . . . . . . 11 6.2.2 FACILITY . . . . . . . . . . . . . . . . . . . . . . . 11 6.2.3 SEVERITY . . . . . . . . . . . . . . . . . . . . . . . 12 6.2.4 TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 12 6.2.5 HOSTNAME . . . . . . . . . . . . . . . . . . . . . . . 14 6.2.6 SENDER-NAME . . . . . . . . . . . . . . . . . . . . . 14 6.2.7 SENDER-INST . . . . . . . . . . . . . . . . . . . . . 14 6.2.8 MSGID . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3 STRUCTURED-DATA . . . . . . . . . . . . . . . . . . . . . 15 6.3.1 SD-ELEMENT . . . . . . . . . . . . . . . . . . . . . . 15 6.3.2 SD-ID . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3.3 SD-PARAM . . . . . . . . . . . . . . . . . . . . . . . 16 6.3.4 Change Control . . . . . . . . . . . . . . . . . . . . 16 6.3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . 16 6.4 MSG . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Structured Data IDs . . . . . . . . . . . . . . . . . . . . . 20 7.1 timeQuality . . . . . . . . . . . . . . . . . . . . . . . 20 7.1.1 tzKnown . . . . . . . . . . . . . . . . . . . . . . . 20 7.1.2 isSynced . . . . . . . . . . . . . . . . . . . . . . . 20 7.1.3 syncAccuracy . . . . . . . . . . . . . . . . . . . . . 20 7.1.4 Examples . . . . . . . . . . . . . . . . . . . . . . . 21 7.2 origin . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2.1 ip . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2.2 enterpriseID . . . . . . . . . . . . . . . . . . . . . 22 7.2.3 software . . . . . . . . . . . . . . . . . . . . . . . 22 7.2.4 swVersion . . . . . . . . . . . . . . . . . . . . . . 22 7.2.5 Example . . . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8.1 Diagnostic Logging . . . . . . . . . . . . . . . . . . . . 23 8.2 Control Characters . . . . . . . . . . . . . . . . . . . . 23 8.3 More than Maximum Message Length . . . . . . . . . . . . . 24 8.4 Message Truncation . . . . . . . . . . . . . . . . . . . . 24 8.5 Single Source to a Destination . . . . . . . . . . . . . . 24 8.6 Multiple Sources to a Destination . . . . . . . . . . . . 25 8.7 Multiple Sources to Multiple Destinations . . . . . . . . 25 Gerhards Expires August 22, 2005 [Page 2] Internet-Draft The syslog Protocol February 2005 8.8 Replaying . . . . . . . . . . . . . . . . . . . . . . . . 25 8.9 Reliable Delivery . . . . . . . . . . . . . . . . . . . . 26 8.10 Message Integrity . . . . . . . . . . . . . . . . . . . . 26 8.11 Message Observation . . . . . . . . . . . . . . . . . . . 26 8.12 Misconfiguration . . . . . . . . . . . . . . . . . . . . . 27 8.13 Forwarding Loop . . . . . . . . . . . . . . . . . . . . . 27 8.14 Load Considerations . . . . . . . . . . . . . . . . . . . 27 8.15 Denial of Service . . . . . . . . . . . . . . . . . . . . 28 9. Notice to RFC Editor . . . . . . . . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 10.1 Version . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.2 SD-IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. Authors and Working Group Chair . . . . . . . . . . . . . . 31 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 13.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . 33 13.2 Informative . . . . . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 34 A. Implementor Guidelines . . . . . . . . . . . . . . . . . . . . 35 A.1 Relationship with BSD Syslog . . . . . . . . . . . . . . . 35 A.2 Message Length . . . . . . . . . . . . . . . . . . . . . . 36 A.3 HEADER Parsing . . . . . . . . . . . . . . . . . . . . . . 37 A.4 SEVERITY Values . . . . . . . . . . . . . . . . . . . . . 38 A.5 TIME-SECFRAC Precision . . . . . . . . . . . . . . . . . . 38 A.6 Case Convention for Names . . . . . . . . . . . . . . . . 38 A.7 Leap Seconds . . . . . . . . . . . . . . . . . . . . . . . 39 A.8 Syslog Senders Without Knowledge of Time . . . . . . . . . 39 A.9 Additional Information on SENDER-INST . . . . . . . . . . 39 A.10 Notes on the time SD-ID . . . . . . . . . . . . . . . . . 40 A.11 Recommendation for Diagnostic Logging . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . . 42 Gerhards Expires August 22, 2005 [Page 3] Internet-Draft The syslog Protocol February 2005 1. Introduction This document describes a layered architecture for syslog. The goal of this architecture is to separate message content from message transport while enabling easy extensibility for each layer. This document describes the standard format for syslog messages and outlines the concept of transport mappings. It also describes structured data elements, which can be used to transmit easy *s/easy/easily/ parsable, structured information and allows for vendor extensions. This document does not describe any storage format for syslog messages. This is beyond of its scope and not necessary for system *s/beyond of its scope/out of scope here/ interoperability. *Comment: Same comment as in the Abstract. I need to be motivated to *write code based on this. Gerhards Expires August 22, 2005 [Page 4] Internet-Draft The syslog Protocol February 2005 2. Conventions Used in This Document The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in RFC2119 [5]. *s/RFC/& / Gerhards Expires August 22, 2005 [Page 5] Internet-Draft The syslog Protocol February 2005 3. Definitions The following definitions will be used in this document: *s/will be/are/ o An application that can generate a syslog message will be called a *s/will be/is/ "sender". o An application that can receive a syslog message will be called a *s/will be/is/ "receiver". o An application that can receive syslog messages and forward them to another receiver will be called a relay. *s/will be/is/ *s/relay/"&"/ o An application that receives messages and does not relay them to any other receiver will be called a collector. *s/will be/is/ *s/collector/"&"/ A single application can have multiple roles at the same time. Gerhards Expires August 22, 2005 [Page 6] Internet-Draft The syslog Protocol February 2005 4. Basic Principles The following principles apply to syslog communication: o Syslog protocol does not provide for any mechanism of *s/Syslog/The &/ acknowledgement of message delivery. Though some transports may provide status information, conceptionally syslog is pure simplex *s/conceptionally syslog is/conceptionally, syslog is a/ communication. *s/communication/communications protocol/ o Senders send messages to receivers with no knowledge of whether they are collectors or relays. o Senders may be configured to send the same message to multiple receivers. o Relays may send all or some of the messages that they receive to a subsequent relay or collector. They may also store - or otherwise *s/ - /--/ locally process - some or all messages without forwarding. In *s/ - /--/ those cases, they are acting as both a collector and a relay. o Relays may also generate their own messages and send them on to subsequent relays or collectors. In that case it is acting as a *s/it is/they are/ *s/as a/as/ sender and a relay. *s/.*/senders and relays./ o Sender and receiver may reside on the same or different system. *s/Sender/The sender/ *s/system/&s/ 4.1 Example Deployment Scenarios Sample deployment scenarios are shown in Diagram 1. Other arrangements of these examples are also acceptable. As noted, in the following diagram relays may pass along all or some of the messages *s/diagram/&,/ that they receive along with passing along messages that they *s/along with passing/and also pass/ internally generate. The boxes represent syslog-enabled applications. +------+ +---------+ |Sender|---->----|Collector| +------+ +---------+ +------+ +-----+ +---------+ |Sender|---->----|Relay|---->----|Collector| +------+ +-----+ +---------+ +------+ +-----+ +-----+ +---------+ |Sender|-->--|Relay|-->--..-->--|Relay|-->--|Collector| +------+ +-----+ +-----+ +---------+ +------+ +-----+ +---------+ |Sender|---->----|Relay|---->----|Collector| | |-+ +-----+ +---------+ +------+ \ \ +-----+ +---------+ +->--|Relay|---->----|Collector| +-----+ +---------+ Gerhards Expires August 22, 2005 [Page 7] Internet-Draft The syslog Protocol February 2005 +------+ +---------+ |Sender|---->----|Collector| | |-+ +---------+ +------+ \ \ +-----+ +---------+ +->--|Relay|---->----|Collector| +-----+ +---------+ +------+ +-----+ +---------+ |Sender|---->----|Relay|---->-------|Collector| | |-+ +-----+ +---| | +------+ \ / +---------+ \ +-----+ / +->--|Relay|-->--/ +-----+ +------+ +-----+ +---------+ |Sender|---->----|Relay|---->----------|Collector| | |-+ +-----+ +--| | +------+ \ / +---------+ \ +--------+ / \ |+------+| / +->-||Relay ||->---/ |+------|| / ||Sender||->-/ |+------+| +--------+ Diagram 1. Some possible syslog deployment scenarios. Gerhards Expires August 22, 2005 [Page 8] Internet-Draft The syslog Protocol February 2005 5. Transport Layer Protocol This document does not specify any transport layer protocol. Instead, it describes the format of a syslog message in a transport layer independent way. This requires that syslog transports be defined in other documents. The first transport is defined in [11] and is consistent with the traditional UDP transport. Any syslog transport protocol MUST NOT deliberately alter the syslog message. If the transport protocol needs to perform temporary transformations, these transformations MUST be reversed by the transport protocol at the receiver, so that the upper layer will see an exact copy of the message sent from the originator. Otherwise cryptographic verifiers (like signatures) will be broken. Of course, message alteration might occur due to transmission or similar errors. Guarding against such alterations is not the scope of this *s/the scope/within the scope/ requirement. 5.1 Minimum Required Transport Mapping All syslog implementations MUST support a UDP-based transport as described in [11]. This requirement ensures interoperability between all systems implementing the protocol described in this document. Gerhards Expires August 22, 2005 [Page 9] Internet-Draft The syslog Protocol February 2005 6. Required syslog Format The syslog message has the following ABNF [7] definition: SYSLOG-MSG = HEADER SP STRUCTURED-DATA SP MSG HEADER = VERSION SP FACILITY SP SEVERITY SP TIMESTAMP SP HOSTNAME SP SENDER-NAME SP SENDER-INST SP MSGID VERSION = NONZERO-DIGIT 0*2DIGIT FACILITY = "0" / (NONZERO-DIGIT 0*9DIGIT) ; range 0..2147483647 SEVERITY = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" HOSTNAME = 1*255PRINTUSASCII ; a FQDN SENDER-NAME = 1*48PRINTUSASCII SENDER-INST = "-" / 1*16PRINTUSASCII MSGID = "-" / 1*32PRINTUSASCII TIMESTAMP = FULL-DATE "T" FULL-TIME FULL-DATE = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY DATE-FULLYEAR = 4DIGIT DATE-MONTH = 2DIGIT ; 01-12 DATE-MDAY = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year FULL-TIME = PARTIAL-TIME TIME-OFFSET PARTIAL-TIME = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND [TIME-SECFRAC] TIME-HOUR = 2DIGIT ; 00-23 TIME-MINUTE = 2DIGIT ; 00-59 TIME-SECOND = 2DIGIT ; 00-58, 00-59, 00-60 based on leap ; second rules TIME-SECFRAC = "." 1*6DIGIT TIME-OFFSET = "Z" / TIME-NUMOFFSET TIME-NUMOFFSET = ("+" / "-") TIME-HOUR ":" TIME-MINUTE STRUCTURED-DATA = *SD-ELEMENT SD-ELEMENT = "[" SD-ID 0*(1*SP SD-PARAM) "]" SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34 SD-ID = SD-NAME PARAM-NAME = SD-NAME PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and ; ']' MUST be escaped. SD-NAME = 1*32OCTET ; VALID UTF-8 String ; except '=', SP, ']', %d34 (") Gerhards Expires August 22, 2005 [Page 10] Internet-Draft The syslog Protocol February 2005 MSG = UTF-8-STRING UTF-8-STRING = *OCTET ; Any VALID UTF-8 String OCTET = %d00..255 SP = %d32 PRINTUSASCII = %d33-126 NONZERO-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" DIGIT = "0" / NONZERO-DIGIT 6.1 Message Length 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. 6.2 HEADER The character set used in the HEADER MUST be seven-bit ASCII in an eight-bit field as described in RFC 2234 [7]. These are the ASCII codes as defined in "USA Standard Code for Information Interchange" ANSI.X3-4.1968 [1]. The header format is designed to provide some interoperability with older BSD-based syslog. For details on this, see Appendix A.1. 6.2.1 VERSION The VERSION field denotes the version of the syslog protocol specification. The version number MUST be incremented for any new syslog protocol specification that changes any part of the HEADER format. This document uses a VERSION value of "1". The VERSION values are IANA-assigned (Section 10.1). VERSION "1" does only and *s/VERSION "1" does only and/VERSION "1" and only VERSION "1"/ exactly support the HEADER as described in this format. No *s/exactly support/supports exactly/ modifications to HEADER syntax or semantics can be made if VERSION 1 is used. If this is done, a new VERSION value MUST be assigned. 6.2.2 FACILITY FACILITY is an integer in the range from 0 to 2,147,483,647. It can be used for filtering by the receiver. It is RECOMMENDED that the facility reflects a type of subsystem, something that a number of *s/that/from which/ Gerhards Expires August 22, 2005 [Page 11] Internet-Draft The syslog Protocol February 2005 different messages might be issued from. So it is a kind of corase *s/ from// *s/corase/coarse/ group. There exist some traditional FACILITY code semantics for the *s/group/grouping/ codes in the range from 0 to 23. These semantics are not closely followed by all senders, and practice has shown that common semantics for message categories are hard to establish. Therefore, no specific semantics for FACILITY codes are specified or implied in this document. 6.2.3 SEVERITY The SEVERITY field is used to indicate the severity that the sender of a message assigned to it. It contains one of these values: Numerical Severity Code 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition *s/condition/&s/ 6 Informational: informational messages 7 Debug: debug-level messages 6.2.4 TIMESTAMP The TIMESTAMP field is a formalized timestamp derived from RFC 3339 [10]. While RFC 3339 [10] makes allowances for multiple syntaxes, this *s/While/Whereas/ document places further restrictions. The TIMESTAMP MUST follow *s/places/imposes/ these restrictions: o The "T" and "Z" characters in this syntax MUST be upper case. o Usage of the "T" character is REQUIRED. The sender SHOULD include TIME-SECFRAC if its clock accuracy and performance permit. The "time" SD-ID described in Section 7.1 allows *s/SD-ID/SD-ID (Structured Data Identifier)/ to specify accuracy and trustworthyness of the timestamp. *s/to specify/one to specify/ *s/trustworthyness/trustworthiness/ 6.2.4.1 Syslog Senders Without Knowledge of Time A syslog sender being incapable of obtaining system time MUST use the *s/being // following TIMESTAMP: 2000-01-01T00:00:60Z Gerhards Expires August 22, 2005 [Page 12] Internet-Draft The syslog Protocol February 2005 This TIMESTAMP is in the past and it shows a time that never existed, because 1 January 2000 had no leap second. So it can never occur in a valid syslog message of a time-aware sender. A receiver receiving this TIMESTAMP MUST treat this value as an undefined date and time. 6.2.4.2 Examples Example 1 1985-04-12T23:20:50.52Z This represents 20 minutes and 50.52 seconds after the 23rd hour of 12 April 1985 in UTC. Example 2 1985-04-12T19:20:50.52-04:00 This represents the same time as in example 1, but expressed in the eastern US time zone (daylight savings time being observed). *s/eastern/Eastern/ Example 3 2003-10-11T22:14:15.003Z This represents 11 October 2003 at 10:14:15pm, 3 milliseconds into the next second. The timestamp is in UTC. The timestamp provides millisecond resolution. The creator may have actually had a better resolution, but by providing just three digits for the fractional settings, it does not tell us. *s/settings/part of a second/ Example 4 2003-08-24T05:14:15.000003-07:00 This represents 24 August 2003 at 05:14:15am, 3 microseconds into the next second. The microsecond resolution is indicated by the additional digits in TIME-SECFRAC. The timestamp indicates that its local time is -7 hours from UTC. This timestamp might be created in the US Pacific time zone during daylight savings time. Example 5 - An Invalid TIMESTAMP 2003-08-24T05:14:15.000000003-07:00 This example is nearly the same as Example 4, but it is specifying TIME-SECFRAC in nanoseconds. This will result in TIME-SECFRAC to be *s/will result/results/ *s/to be/being/ longer than the allowed 6 digits, which invalidates it. Gerhards Expires August 22, 2005 [Page 13] Internet-Draft The syslog Protocol February 2005 6.2.5 HOSTNAME The HOSTNAME field identifies the machine that originally sent the syslog message. The HOSTNAME field SHOULD contain the host name and the domain name of the originator in the format specified in STD 13 [3]. This format will be referred to in this document as a Fully Qualified Domain Name *s/will be referred to in this document as/is called/ *s/Name/Name (FQDN) in this document./ (FQDN). *d In practice, not all senders are able to provide the FQDN. As such, *s/the FQDN/a FQDN/ other values MAY also be present in HOSTNAME. This protocol makes provisions for using other values in such situations. A sender SHOULD provide the most specific available value first. The order of preference for the contents of the HOSTNAME field is as follows: 1. FQDN 2. Static IP address 3. Hostname 4. Dynamic IP address 5. "0:0:0:0:0:0:0:0" If an IPv4 address is used, it MUST be in the format of the dotted decimal notation as used in STD 13 [4]. If an IPv6 address is used, a valid textual representation described in RFC 2373 [8], Section 2 *s/Section 2/&,/ *Note that RFC 2373 in obsoleted by RFC 3513. MUST be used. If a sender has multiple IP addresses, it SHOULD consistently use the same value in the HOSTNAME field for as long as possible. This value *Perhaps, no "if" is needed: Senders SHOULD consistently ... SHOULD be one of its actual IP addresses. If a sender is running on a machine which has both statically and dynamically assigned *s/which/that/ addresses, then that value SHOULD be from the statically assigned addresses. As an alternative, the sender MAY use the IP address of the interface that is used to send the message. 6.2.6 SENDER-NAME The SENDER-NAME SHOULD identify the device or application that generated the message. It is a string without further semantics. It is intended for filtering messages on the receiver. 6.2.7 SENDER-INST The SENDER-INST field SHOULD identify a specific instance of the sender. It is RECOMMENDED that SENDER-INST contains the operating system process ID, if that exists and is obtainable. No specific format is REQUIRED. *s/REQUIRED/required/ Gerhards Expires August 22, 2005 [Page 14] Internet-Draft The syslog Protocol February 2005 The dash ("-") is a reserved SENDER-INST field value that MUST only be used to indicate an unidentified instance. *s/only be used/be used only/ 6.2.8 MSGID The MSGID SHOULD identify the type of message. For example, a Firewall might use the MSGID "TCPIN" for incoming TCP traffic and the MSGID "TCPOUT" for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on the receiver. The dash ("-") is a reserved MSGID field value that MUST only be used *s/only be used/be used only/ to indicate that the message has no specific ID. 6.3 STRUCTURED-DATA STRUCTURED-DATA transports data in a well defined, easily parsable and interpretable format. There are multiple usage scenarios. For example, it may transport meta-information about the syslog message or application-specific information such as traffic counters or IP addresses. STRUCTURED-DATA can contain zero, one, or multiple structured data elements, which are referred to as "SD-ELEMENT" in this document. The character set used in STRUCTURED-DATA MUST be UNICODE, encoded using UTF-8 as specified in RFC 3629 [6]. A sender MAY issue any valid UTF-8 sequence. A receiver MUST accept any valid UTF-8 sequence. It MUST NOT fail if control characters are present in the STRUCTURED-DATA part. If STRUCTURED-DATA is malformed, a diagnostic entry SHOULD be logged. A receiver MAY ignore malformed STRUCTURED-DATA elements. 6.3.1 SD-ELEMENT A SD-ELEMENT consists of a name and parameter name-value pairs. The name is referred to as SD-ID. The name-value pairs are referred to as "SD-PARAM". 6.3.2 SD-ID IANA controls ALL SD-IDs without a hyphen ('-') in the second character position. SD-IDs are case-sensitive and uniquely identify the type and purpose of the SD-ELEMENT. Experimental or vendor-specific SD-ID MUST start with "x-". Anything that doesn't is managed by IANA. The same SD-ID MUST NOT exist more than once in a Gerhards Expires August 22, 2005 [Page 15] Internet-Draft The syslog Protocol February 2005 message. 6.3.3 SD-PARAM Each SD-PARAM consist of a name, referred to as PARAM-NAME, and a value, referred to as PARAM-VALUE. PARAM-NAME is case-sensitive. Inside PARAM-VALUE, the characters '"', '\' and ']' MUST be escaped. This is necessary to avoid parsing errors. Escaping ']' would not strictly be necessary but is REQUIRED by this specification to avoid parser implementation errors. Each of these three characters MUST be escaped as '\"', '\\' and '\]' respectively. A backslash ('\') followed by none of the three described characters is considered an invalid escape sequence. Upon reception of such an invalid escape sequence, the receiver SHOULD replace the two-character sequence with only the second character received. It is RECOMMENDED that the receiver logs a diagnostic in this case. A SD-PARAM MAY be repeated multiple times inside a SD-ELEMENT. 6.3.4 Change Control Once SD-IDs and PARAM-NAMEs are defined in a specification and their IANA assignment has been done, syntax and semantics of these objects *s/done/made/ MUST NOT be altered. So they begin to exist with their initial definition and are never allowed to change. Should a change to an existing object be needed, a new one MUST be created. It is advised to use a name the reflects the close relationship between the two objects. For example, if the semantics of the "tzKnown" PARAM-NAME were to be changed, a good name for the new element would be "tzKnown2". 6.3.5 Examples All examples in this section only show the structured data part of *s/only show/show only/ the message. Examples should be considered to be on one line. They are wrapped on multiple lines for readability purposes only. A description is given after each example. Example 1 - Valid [x-exampleSDID iut="3" eventSource="Application" eventID="1011"] This example is a structured data element with an experimental SD-ID Gerhards Expires August 22, 2005 [Page 16] Internet-Draft The syslog Protocol February 2005 of type "x-exampleSDID" which has three parameters. Example 2 - Valid [x-exampleSDID iut="3" eventSource="Application" eventID="1011"][x-examplePriority class="high"] This is the same example as in 1, but with a second structured data element. Please note that the structured data element immediately follows the first one (there is no SP between them). Example 3 - Invalid [x-exampleSDID iut="3" eventSource="Application" eventID="1011"] [x-examplePriority class="high"] This is nearly the same example as 2, but it has a subtle error. Please note that there is a SP character between the two structured data elements ("]SP["). This is invalid. It will cause the STRUCTURED-DATA field to end after the first element. The second element will be interpreted as part of the MSG field. Example 4 - Invalid [ x-exampleSDID iut="3" eventSource="Application" eventID="1011"][x-examplePriority class="high"] This example again is nearly the same as 2. It has another subtle error. Please note the SP character after the initial bracket. A structured data element SD-ID MUST immediately follow the beginning bracket, so the SP character invalidates the STRUCTURED-DATA. Thus, the receiver MAY discard this message. Example 5 - Valid [sigSig ver="1" rsID="1234" ... signature="......"] *Comment: Both here and above in Figure 1, it is usual to write exactly three *dots ... to indicate any amount of missing content. The three dots may *be called "ellipses," plural of "ellipsis." Example 5 is a valid example. It shows a hypothetical IANA assigned *s/IANA assigned/IANA-assigned/ SD-ID. Please note that the dots denote missing content, which has been left out for brevity. 6.4 MSG The MSG part contains a free-form message that provides information about the event. The character set used in MSG MUST be UNICODE, encoded using UTF-8 as specified in RFC 3629 [6]. A sender MAY issue any valid UTF-8 Gerhards Expires August 22, 2005 [Page 17] Internet-Draft The syslog Protocol February 2005 sequence. A receiver MUST accept any valid UTF-8 sequence. It MUST NOT fail if control characters are present in the MSG part. 6.5 Examples The following are examples of valid syslog messages. A description of each example can be found below it. The examples are based on similar examples from RFC 3164 [12] and may be familiar to readers. Example 1 1 888 4 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 'su root' failed for lonvick on /dev/pts/8 In this example, the VERSION is 1 and the FACILITY has the value of 888. The severity is 4 ("Warning" semantics). The message was created on October, 11th 2003 at 10:14:15pm UTC, 3 milliseconds into *s/October, 11th/11 October/ the next second. The message originated from a host that identifies itself as "mymachine.example.com". The SENDER-NAME is "su" and the SENDER-INST is unknown. The MSGID is "ID47". Note the two SP characters following MSGID. The second SP character is the STRUCTURED-DATA delimiter. It tells that no STRUCTURED-DATA is present in this message. The MSG is "'su root' failed for lonvick...". Example 2 1 20 6 2003-08-24T05:14:15.000003-07:00 192.0.2.1 myproc 10 - %% It's time to make the do-nuts. In this example, the VERSION is again 1. The FACILITY is within the legacy syslog range (20). The severity is 6 ("Notice" semantics). It was created on 24 August 2003 at 5:14:15am, with a -7 hour offset from UTC, 3 microseconds into the next second. The HOSTNAME is "192.0.2.1", so the sender did not know its FQDN and used the IPv4 *s/the IPv4/an IPv4/ * or *s/the IPv4 address/one of its IPv4 addresses/ address instead. The SENDER-NAME is "myproc" and the SENDER-INST is "10" (for example this could be the UNIX PID). There is no specific MSGID and this is indicated by the "-" in the MSGID field. The message is "%% It's time to make the do-nuts.". Example 3 - with STRUCTURED-DATA 1 888 4 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [x-exampleSDID iut="3" eventSource="Application" eventID="1011"] An application event log entry... This example is modeled after example 1. However, this time it contains STRUCTURED-DATA, a single element with the value Gerhards Expires August 22, 2005 [Page 18] Internet-Draft The syslog Protocol February 2005 "[x-exampleSDID iut="3" eventSource="Application" eventID="1011"]". The MSG itself is "An application event log entry..." Example 4 - STRUCTURED-DATA Only 1 888 4 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [x-exampleSDID iut="3" eventSource="Application" eventID="1011"][x-examplePriority class="high"] This example shows a message with only STRUCTURED-DATA and no MSG part. This is a valid message. *One could be picky and point out that according to the ABNF, this example MUST have *a space at the end. Gerhards Expires August 22, 2005 [Page 19] Internet-Draft The syslog Protocol February 2005 7. Structured Data IDs This section defines the initial IANA-registered SD-IDs. See Section 6.3 for a definition of structured data elements. All SD-IDs are optional. 7.1 timeQuality The SD-ID "timeQuality" MAY be used by the original sender to describe its notion of system time. This SD-ID SHOULD be written if the sender is not properly synchronized with a reliable external time source or if it does not know whether or not its time zone information is correct. The main use of this structured data element is to provide some information on the level of trust of the TIMESTAMP *s/trust of/trust it has in/ described in Section 6.2.4. *It may be helpful to say which parameters are mandatory or optional. 7.1.1 tzKnown The "tzKnown" parameter indicates if the original sender knows its *s/if/whether/ time zone. If it does so, the value "1" SHOULD be used. If the time zone information is in doubt, the value "0" SHOULD be used. If the sender knows its time zone but decides to emit time in UTC, the value "1" SHOULD be used (because the time zone is known). 7.1.2 isSynced The "isSynced" parameter indicates if the original sender is *s/if/whether/ synchronized to a reliable external time source, e.g. via NTP. If *s/e.g./&,/ the original sender is time synchronized, the value "1" SHOULD be used. If not, the value "0" SHOULD be used. 7.1.3 syncAccuracy The "syncAccuracy" parameter indicates how accurate the original sender thinks the time synchronization it participates in is. It is *s/the/its/ *s/it participates in // an integer describing the maximum number of microseconds that the *s/that the/that its/ clock may be off between synchronization intervals. If the value "0" is used for "isSynced", this parameter SHOULD NOT be specified. If the value "1" is used for "isSynced" but the "syncAccuracy" parameter is absent, a receiver SHOULD assume that the time information provided is accurate enough to be considered correct. The "syncAccuracy" parameter SHOULD ONLY be written if the s/ONLY be written/be written only/ original sender actually has knowledge of the reliability of the external time source. In practice, in most cases, it will gain this in-depth knowledge through operator configuration. Gerhards Expires August 22, 2005 [Page 20] Internet-Draft The syslog Protocol February 2005 7.1.4 Examples The following is an example of a system that knows that it does *s/ does// neither know its time zone nor if it is being synchronized: *s/neither know its time zone nor if/knows neither its time zone nor whether/ [timeQuality tzKnown="0" isSynced="0"] With this information, the sender indicates that its time information cannot be trusted. This may be a hint for the receiver to use its *s/cannot be trusted/is unreliable/ local time instead of the message-provided TIMESTAMP for correlation of multiple messages from different senders. The following is an example of a system that knows its time zone and knows that it is properly synchronized to a reliable external source: [timeQuality tzKnown="1" isSynced="1"] The following is an example of a system that knows both its time zone and that it is externally synchronized. It also knows the accuracy of the external synchronization: [timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"] The difference between this and the previous example is that the sender expects that its clock will be kept within 60 seconds of the official time. So if the sender reports it is 9:00:00, it is no earlier than 8:59:00 and no later then 9:01:00. 7.2 origin The SD-ID "origin" MAY be used to indicate the origin of a syslog message. The following parameters can be used. All parameters are optional. Specifying any of these parameter is primarily an aid to log *s/parameter/&s/ analyzers and similar applications. 7.2.1 ip The "ip" parameter denotes the IP address that the sender knows it *s/the IP/an IP/ had at the time of sending the message. It MUST contain the textual representation of an IP address as outlined in Section 6.2.5. This parameter can be used to provide additional identifying information to what is present in the HOSTNAME field. It might be especially useful if the host's IP address shall be included in the *s/shall be/is/ message while the HOSTNAME field still shall contain the FQDN. It is *s/while/and/ *s/shall contain/contains/ also useful to describe all IP addresses of a multihomed host. *s/to describe/for describing/ Gerhards Expires August 22, 2005 [Page 21] Internet-Draft The syslog Protocol February 2005 If a sender has multiple IP addresses, it MAY either use a single of *s/use a single/list one/ its IP addresses in the "ip" parameter or it MAY include multiple "ip" parameters in a single "origin" structured data element. 7.2.2 enterpriseID The "enterpriseID" parameter MUST be an 'SMI Network Management *s/an/a/ Private Enterprise Code', maintained by IANA, whose prefix is iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The number which follows is unique and may be registered by an on-line form at *s/which/that/ . Only that number MUST be specified in the "enterpriseID" parameter. The complete up-to-date list of Enterprise Numbers is maintained by IANA at . By specifying an enterpriseID, the vendor allows more specific parsing of the message. 7.2.3 software The "software" parameter uniquely identifies the software that generated the message. If it is used, "enterpriseID" SHOULD also be specified, so that a specific vendor's software can be identified. The "software" parameter is not the same as the SENDER-NAME header field. It always contains the name of the generating software while *s/software while/software, whereas/ SENDER-NAME can contain anything else, including an operator-configured value. The "software" parameter is a string. It MUST NOT be longer than 48 characters. 7.2.4 swVersion The "swVersion" parameter uniquely identifies the version of the software that generated the message. If it is used, the "software" and "enterpriseID" parameters SHOULD be provided, too. The "swVersion" parameter is a string. It MUST NOT be longer than 32 characters. 7.2.5 Example The following is an example with multiple IP addresses: [origin ip="192.0.2.1" ip="192.0.2.129"] In this example, the sender indicates that it has two ip addresses, one being 192.0.2.1 and the other one being 192.0.2.129. Gerhards Expires August 22, 2005 [Page 22] Internet-Draft The syslog Protocol February 2005 8. Security Considerations 8.1 Diagnostic Logging This document recommends that an implementation writes a diagnostic message to indicate unusual situations or other things noteworthy. Diagnostic messages are a useful tool in finding configuration issues *s/finding/discovering/ as well as a system penetration. *s/ a / instances of / Unfortunately, diagnostic logging can cause issues by itself, for example if an attacker tries to create a denial of service condition *s/example/&,/ by willingly sending malformed messages that will lead to the creation of diagnostic log entries. Due to sheer volume, the resulting diagnostic log entries may exhaust system resources, e.g. processing power, I/O capability or simply storage space. For *s/capability/&,/ example, an attacker could flood a system with messages generating diagnostic log entries after he has compromised a system. If the log entries are stored in a circular buffer, the flood of diagnostic log entries would eventually overwrite useful previous diagnostics. Besides this risk, diagnostic message, if they occur too frequently, *s/message/&s/ can become meaningless. Common practice is to turn off diagnostic logging if it is too verbose. This potentially removes important *s/removes/& a source of/ diagnostic information which could aid the operator. 8.2 Control Characters This document does not impose any restrictions on the MSG or STRUCTURED-DATA content. As such, they MAY contain control characters, including the NUL character. In some programming languages (most notably C and C++), the NUL (0x00) character traditionally has a special significance as string terminator. Most, if not all, implementations of these languages assume that a string will not extend beyond the first NUL character. This is primarily a restriction of the supporting run-time libraries. Please note that this restriction is often carried over to programs and script languages written in those languages. As such, NUL characters must be considered with great care and be properly handled. An attacker may deliberately include NUL characters to hide information after them. Incorrect handling of the NUL character may also invalidate cryptographic checksums that are transmitted inside the message. Many popular text editors are also written in languages with this restriction. This means that NUL characters should not be written to a file in an unencoded way - otherwise it would potentially render *s/ - otherwise it/. Otherwise they/ the file unreadable. Gerhards Expires August 22, 2005 [Page 23] Internet-Draft The syslog Protocol February 2005 The same is true for other control characters. For example, deliberately included backspace characters may be used by an attacker *s/.*/an attacker may deliberately include backspace characters/ to render parts of the log message unreadable. Similar approaches *s/approaches/issues/ exist for almost all control characters. Finally, invalid UTF-8 sequences may be used by an attacker to inject ASCII control characters. 8.3 More than Maximum Message Length The message length MAY exceed the RECOMMENDED maximum value specified in Section 6. Various problems may result if a sender sends messages with a greater length. Also, an attacker might deliberately introduce very large messages. As such, it is vital that each receiver performs the necessary sanity checks to ensure that it will gracefully discard or truncate messages of larger sizes than it supports. 8.4 Message Truncation Messages over the minimum to be supported size may be discarded or *s/to be // truncated by the receiver or interim systems. As such, vital log information may be lost. Even messages within that size may be lost if a non-reliable transport mapping is used. In order to prevent information loss, messages should be less then *s/should be less then/should not be longer than/ the minimum supported size outlined in Section 6.1. For best *s/minimum supported // *s/outlined in/required by/ performance and reliability, messages SHOULD be as small as possible. Important information SHOULD be placed as early in the message as possible because information at the begin of the message is less *s/begin/beginning/ likely to be discarded by a size-limited receiver. In case a sender includes user-supplied data within a syslog message, it should limit the size of that data. Otherwise, an attacker may provide large data in the hope to exploit this potential weakness. 8.5 Single Source to a Destination The syslog messages are usually presented (placed in a file, displayed on the console, etc) in the order in which they are *s/etc/etc./ received. This is not always in accordance with the sequence in which they were generated. As they are transmitted across an IP network, some out of order receipt should be expected. This may lead to some confusion as messages may be received that would indicate that a process has stopped before it was started. This is somewhat rectified by the TIMESTAMP. However, the accuracy of the TIMESTAMP may not always be sufficiently enough. *s/sufficiently enough/sufficient/ Gerhards Expires August 22, 2005 [Page 24] Internet-Draft The syslog Protocol February 2005 It is desirable to use a transport with guaranteed delivery, if one is available. *Comment: This may be controversial, especially if the transport with guaranteed *delivery imposes even more overhead. Suggest saying "may be desirable". 8.6 Multiple Sources to a Destination In syslog, there is no concept of unified event numbering. Single senders are free to include a sequence number within the structured data, but that can hardly be coordinated between multiple senders. In such cases, multiple senders may report that each one is sending message number one. Again, this may be rectified somewhat by the TIMESTAMP. As has been noted, however, even messages from a single sender to a single collector may be received out of order. This situation is compounded when there are several senders configured to send their syslog messages to a single collector. Messages from one sender may be delayed so the collector receives messages from another sender first even though the messages from the first sender were generated before the messages from the second. If there is no sufficiently-precise timestamp or coordinated sequence number, then *s/sufficiently-precise/sufficiently precise/ the messages may be presented in the order in which they were received which may give an inaccurate view of the sequence of actual events. *Comment: There is no mention here of sorting out message streams according to *HOSTNAME, SENDER-NAME, or SENDER-INST. 8.7 Multiple Sources to Multiple Destinations The plethora of configuration options available to the network administrators may further skew the perception of the order of events. It is possible to configure a group of senders to send status messages -or other informative messages- to one collector, *s/ -/--/ *s/- /--/ while sending messages of relatively higher importance to another collector. Additionally, the messages may be sent to different files on the same collector. If the messages do not contain sufficiently-precise timestamps from the source, it may be difficult *s/sufficiently-precise/sufficiently precise/ to order the messages if they are kept in different places. An *s/the // *s/if they are / administrator may not be able to determine if a record in one file *s/if/whether/ occurred before or after a record in a different file. This may be *s/occurred/was generated/ somewhat alleviated by placing marking messages with a timestamp into all destination files. If these have coordinated timestamps, then there will be some indication of the time of receipt of the individual messages. As such, it is highly recommended to use the best available precision in the TIMESTAMP and use automatic time *s/use/to use/ synchronization on each systems (as, for example, can be done via *s/systems/such system/ NTP). 8.8 Replaying Messages may be recorded and replayed at a later time. An attacker may record a set of messages that indicate normal activity of a machine. At a later time, that attacker may remove that machine from Gerhards Expires August 22, 2005 [Page 25] Internet-Draft The syslog Protocol February 2005 the network and replay the syslog messages to the collector. Even with a TIMESTAMP field in the HEADER part, an attacker may record the packets and could simply modify them to reflect the current time before retransmitting them. The administrators may find nothing unusual in the received messages and their receipt would falsely *s/messages/&,/ indicate normal activity of the machine. Cryptographically signing messages could prevent the alteration of TIMESTAMPs and thus the replay attack. 8.9 Reliable Delivery As there is no mechanism described within this document to ensure *s/As/Because/ delivery, and since the underlying transport may be lossey (e.g. *s/since // *s/e.g./e.g.,/ *s/lossey/lossy/ *Comment: There really isn't any such word as lossey or lossy, but we can drop *the "e" if we use the rule: rhymes with "glossy" UDP), some messages may be lost. They may either be dropped through network congestion, or they may be maliciously intercepted and discarded. The consequences of the drop of one or more syslog *s/the drop of/dropping/ messages cannot be determined. If the messages are simple status updates, then their non-receipt may either not be noticed, or it may cause an annoyance for the system operators. On the other hand, if the messages are more critical, then the administrators may not become aware of a developing and potentially serious problem. Messages may also be intercepted and discarded by an attacker as a way to hide unauthorized activities. It is RECOMMENDED to use a reliable transport mapping to prevent this problem. *Comment: As far as congestion is concerned, see the comment above. As far as *malicious dropping, reliable transport does not help. 8.10 Message Integrity Besides being discarded, syslog messages may be damaged in transit, or an attacker may maliciously modify them. In such cases, the original contents of the message will not be delivered to the collector. Additionally, if an attacker is positioned between the sender and collector of syslog messages, they may be able to intercept and modify those messages while in-transit to hide unauthorized activities. 8.11 Message Observation While there are no strict guidelines pertaining to the MSG format, most syslog messages are generated in human readable form with the assumption that capable administrators should be able to read them and understand their meaning. Neither the syslog protocol nor the syslog application have mechanisms to provide confidentiality of the *s/of/for/ messages in transit. In most cases passing clear-text messages is a benefit to the operations staff if they are sniffing the packets off of the wire. The operations staff may be able to read the messages Gerhards Expires August 22, 2005 [Page 26] Internet-Draft The syslog Protocol February 2005 and associate them with other events seen from other packets crossing the wire to track down and correct problems. Unfortunately, an attacker may also be able to observe the human-readable contents of syslog messages. The attacker may then use the knowledge gained from those messages to compromise a machine or do other damage. *Comment: The fact that the messages are in human-readable form is only *loosely connected with the need for confidentiality. Many if not most *operators would consider it a problem if unauthorized parties were reading *their log messages, in human-readable form or otherwise. 8.12 Misconfiguration Since there is no control information distributed about any messages *s/Since/Because/ or configurations, it is wholly the responsibility of the network administrator to ensure that the messages are actually going to the intended recipient. Cases have been noted where senders were *s/recipient/&s/ inadvertently configured to send syslog messages to the wrong receiver. In many cases, the inadvertent receiver may not be *s/receiver/&s/ configured to receive syslog messages and it will probably discard them. In certain other cases, the receipt of syslog messages has been known to cause problems for the unintended recipient. If messages are not going to the intended recipient, then they cannot be reviewed or processed. Using a reliable transport mapping can guard against these problems. *s/guard against/help identify/ 8.13 Forwarding Loop As it is shown in Figure 1, machines may be configured to relay *s/it is // syslog messages to subsequent relays before reaching a collector. In one particular case, an administrator found that he had mistakenly configured two relays to forward messages with certain SEVERITY values to each other. When either of these machines either received or generated that type of message, it would forward it to the other relay. That relay would, in turn, forward it back. This cycle did cause degradation to the intervening network as well as to the processing availability on the two devices. Network administrators must take care to not cause such a death spiral. *s/to not/not to/ 8.14 Load Considerations Network administrators must take the time to estimate the appropriate size of the syslog receivers. An attacker may perform a Denial of *s/size/capacity/ Service attack by filling the disk of the collector with false messages. Placing the records in a circular file may alleviate this but that has the consequence of not ensuring that an administrator will be able to review the records in the future. Along this line, a receiver or collector must have a network interface capable of receiving all messages sent to it. Administrators and network planners must also critically review the network paths between the devices, the relays, and the collectors. Gerhards Expires August 22, 2005 [Page 27] Internet-Draft The syslog Protocol February 2005 Generated syslog messages should not overwhelm any of the network links. In order to reduce the impact of this issue, it is recommended to use *s/it is recommended to use/using/ transports with guaranteed delivery. *s/delivery/delivery is recommended 8.15 Denial of Service As with any system, an attacker may just overwhelm a receiver by sending more messages to it than can be handled by the infrastructure or the device itself. Implementors should attempt to provide features that minimize this threat. Such as only receiving syslog *s/. Such/, such/ *s/receiving/accepting/ messages from known IP addresses. Gerhards Expires August 22, 2005 [Page 28] Internet-Draft The syslog Protocol February 2005 9. Notice to RFC Editor This is a note to the RFC editor. This ID is submitted along with ID draft-ietf-syslog-transport-udp and they cross-reference each other. When RFC numbers are determined for each of these IDs, these references will be updated to use the RFC numbers. This section will be removed at that time. Gerhards Expires August 22, 2005 [Page 29] Internet-Draft The syslog Protocol February 2005 10. IANA Considerations 10.1 Version IANA must maintain a registry of VERSION values as described in Section 6.2.1. For this document, IANA must register the VERSION "1". New VERSION numbers must monotonically increment (the next VERSION will be "2") *s/increment/be incremented/ and will be registered via the Specification Required method as described in RFC 2434 [9]. 10.2 SD-IDs IANA must maintain a registry of Structured Data ID (SD-ID) values as described in Section 7. These are the SD-IDs which do NOT have a *s/which/that/ hyphen ("-") in the second character position. New SD-ID values may be registered through the Specification Required method as described in RFC 2434 [9]. For this document, IANA must register the SD-IDs "time" and "origin". *s/time/timeQuality/ Gerhards Expires August 22, 2005 [Page 30] Internet-Draft The syslog Protocol February 2005 11. Authors and Working Group Chair The working group can be contacted via the mailing list: syslog-sec@employees.org The current Chair of the Working Group may be contacted at: Chris Lonvick Cisco Systems Email: clonvick@cisco.com The author of this draft is: Rainer Gerhards Email: rgerhards@adiscon.com Phone: +49-9349-92880 Fax: +49-9349-928820 Adiscon GmbH Mozartstrasse 21 97950 Grossrinderfeld Germany Gerhards Expires August 22, 2005 [Page 31] Internet-Draft The syslog Protocol February 2005 12. Acknowledgments The authors wish to thank Chris Lonvick, Jon Callas, Andrew Ross, Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David Harrington, Sharon Chisholm and all other people who commented on *s/Chisholm/&,/ various versions of this proposal. Gerhards Expires August 22, 2005 [Page 32] Internet-Draft The syslog Protocol February 2005 13. References 13.1 Normative [1] American National Standards Institute, "USA Code for Information Interchange", ANSI X3.4, 1968. [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [3] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [4] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [8] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. *See note in text. This is now obsolete. [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [10] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [11] Okmianski, A., "Transmission of syslog messages over UDP", RFC 9999, August 2004. 13.2 Informative [12] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. [13] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996. Gerhards Expires August 22, 2005 [Page 33] Internet-Draft The syslog Protocol February 2005 Author's Address Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany Email: rgerhards@adiscon.com Gerhards Expires August 22, 2005 [Page 34] Internet-Draft The syslog Protocol February 2005 Appendix A. Implementor Guidelines Information in this section is given as an aid to implementors. While this information is considered to be helpful, it is not normative. As such, an implementation is NOT REQUIRED to implement *s/to implement/to follow/ it in order to claim compliance to this specification. A.1 Relationship with BSD Syslog While BSD syslog is in widespread use, its format has never been formally standardized. In RFC 3164 [12] observed formats were specified. However, RFC 3164 is an informal document and practice *s/document/document,/ shows that there are many different implementations. Consequently, RFC 3164 mandates no specific elements inside a syslog message. It defines that any message format destined to the syslog *s/defines/states/ *s/format// UDP port must be treated as a syslog message - no matter what its *s/ - /, / content is. However, in almost all cases observed in practice, a BSD *s/content/format or content/ syslog message starts with a priority value, which is a number between brackets. An example is "<133>". This document uses that known convention to provide some minimal version detection. It has deliberately changed the syslog message header so that it will never contain a less-than sign as the first character of the message. This has two advantages: If an older receiver receives a message that does not start with a less-than sign, it still assumes this is a valid syslog message. However, it does not try to parse any header fields, at least if it obeys to the rule outlined in RFC 3164. This prevents the receiver from parsing the message invalidly. It should be noted, however, that at least some of the older implementations will experience problems if the message received is larger than 1024 octets. Most of the implementations will truncate a message after the first 1024 octets. So it is wise to not send messages larger than 1024 octets *s/to not/not to/ to receivers which are known to be older. *s/which are// If a receiver compliant to this document receives a message generated *s/to/with/ by a non-compliant, older, sender, it notices that the message does *s/older,/older/ not have a proper header and thus is not formatted according to this document. This enables the receiver to take appropriate action. Please also see the description on header parsing in Appendix A.3 for more information on this scenario. RFC 3164 mandates UDP as transport protocol for syslog. This document places no restrictions on the transport. RFC 3164 specifies relay behaviour. This document does not specify *s/behaviour/behavior/ relay behaviour. This might be done in a separate document. *s/behaviour/behavior/ Gerhards Expires August 22, 2005 [Page 35] Internet-Draft The syslog Protocol February 2005 The PRI part in RFC 3164 is split into two fields - FACILITY and *s/ - /--/ SEVERITY - in this document. These new fields support the RFC 3164 *s/ - /--/ values but also allow additional values. The TIMESTAMP in RFC 3164 offers less precision and lacks the year and timezone information. If a message formatted according to this document needs to be reformatted to be RFC 3164 compliant, it is suggested that the senders local time zone is used, and the time zone *s/senders/sender's/ *s/is/be/ information and the year being dropped. If a RFC 3164 formatted *s/being/be/ message is received and must be transformed to be compliant to this document, the current year should be added and the receivers time *s/receivers/receiver's/ zone be assumed. The HOSTNAME in RFC 3164 is less specific, but this format is still supported in this document as one of the alternate HOSTNAME representations. The MSG part of the message is defined as TAG and CONTENT in RFC 3164. In this document, MSG is what was called CONTENT in RFC 3164. The TAG is now part of the header, but not as a single field. The TAG has been split into SENDER-NAME, SENDER-INST and MSGID. This *s/SENDER-INST/&,/ does not totally resemble the usage of TAG, but provides the same functionality for most of the cases. In RFC 3164, STRUCTURED-DATA was not defined. If a message compliant to this document contains STRUCTURED-DATA and must be reformatted *s/to/with/ compliant to RFC 3164, the STRUCTURED-DATA simply becomes part of the *s/compliant to/to be compliant with/ RFC 3164 CONTENT freeform text. *s/freeform/free-form/ In general, this document tries to provide an easily parsable header with clear field separations whereas traditional BSD syslog suffers from some historically developed, hard to parse field seperation rules. A.2 Message Length Implementors should note the message size limitations outlined in Section 6.1 and try to keep the most important parts early in the message (within the minimum guaranteed length). This ensures they will be seen by the receiver even if it (or a relay on the message path) truncates the message. The reason syslog receivers must only support receiving up to and including 480 octets has, among others, to do with difficult delivery *s/others/other things/ problems in a broken network. Syslog messages may use an UDP *s/an UDP/a UDP/ transport mapping and have this 480 restriction to avoid session overhead and message fragmentation. In a network being troubleshooted, the likelihood of getting one single-packet message Gerhards Expires August 22, 2005 [Page 36] Internet-Draft The syslog Protocol February 2005 delivered successfully is higher than getting two message fragments delivered successfully. So using a larger size may prevent the operator from getting some critical information about the problem, whereas keeping with that limit might get that information to the *s/with/within/ operator. As such, messages intended for troubleshooting purposes should not be larger than 480 octets. To further strengthen this point, it has also been observed that some UDP implementations generally do not support message sizes of more then 480 octets. iChar = szVarName[2] - 'a'; There are other use cases where syslog *What does "iChar = szVarName[2] - 'a'; " mean? messages are used to transmit inherently lengthy information, e.g. audit data. By not enforcing any upper limit on the message size, syslog senders and receivers can be implemented with any size needed and still be compliant to this document. In such cases, it is the *s/to/with/ operator's responsibility to ensure that all components in a syslog infrastructure support the required message sizes. Transport mappings may recommend specific message size limits that must be enforced. Implementors are reminded that the message length is specified in octets. There is a potentially large difference between the length in characters and the length in octets for UTF-8 strings. *Comment: It should also be pointed out that the IPv6 MTU is about 2.5 *times 480. A.3 HEADER Parsing The section recommends a message header parsing method based on the *s/The/This/ VERSION field described in Section 6.2.1. The receiver should check the VERSION. If the VERSION is within the set of versions supported by the receiver, it should parse the message according to the correct syslog protocol specification. If the receiver does not support the specified VERSION, it should log a diagnostic message. It should not parse beyond the VERSION field. This is because the header format may have changed in a newer version. The receiver should not try to process the message, but it MAY try this if the administrator has configured the receiver to do *s/MAY/may/ so. In the latter case, the results may be undefined. If the administrator has configured the receiver to parse a non-supported version, it should assume that these messages are legacy syslog messages and parse and process them with respect to RFC 3164 [12]. To be precise, a receiver receiving an unknown VERSION number, or a message without a valid VERSION, should discard the message by default. However, the administrator may configure it to not discard these messages. If that happens, the receiver may parse it according to RFC 3164 [12]. The administrator may again override this setting and configure the receiver to parse the messages in any way. Gerhards Expires August 22, 2005 [Page 37] Internet-Draft The syslog Protocol February 2005 The spirit behind these guidelines is that the administrator may sometime need the power to allow overriding of version-specific *s/sometime/sometimes/ parsing, but this should be done in the most secure and reliable way. Therefore, the receiver should use the appropriate defaults specified above. This document is specific on this point because it is common experience that parsing unknown formats often leads to security issues. A.4 SEVERITY Values This section describes guidelines for using SEVERITY as outlined in Section 6.2.3. All implementations should try to assign the most appropriate severity to their message. Most importantly, messages designed to enable debugging or testing of software should be assigned severity 7. Severity 0 should be reserved for messages of very high importance (like serious hardware failures or imminent power failure). An implementation may use severities 0 and 7 for other purposes if this is configured by the administrator. Since severities are very subjective, the receiver should not assume *s/Since/Because/ *s/the/a/ that all senders have the same definition of severity. A.5 TIME-SECFRAC Precision The TIMESTAMP described in Section 6.2.4 supports fractional seconds. This provides ground for a very common coding error, where leading zeros are removed from the fractional seconds. For example, the TIMESTAMP "2003-10-11T22:13:14.003" may be erroneously written as "2003-10-11T22:13:14.3". This would indicate 300 milliseconds instead of the 3 milliseconds actually meant. A.6 Case Convention for Names Names are used at various places in this document, for example for SD-IDs and PARAM-NAME. This document uses "camel case" consistently. *s/PARAM-NAME/PARAM-NAMEs/ With that, each name begins with a lower case letter and each new word starts with an upper case letter, but no hyphen or other delimiter. An example of this is "timeQuality". While an implementation is free to use any other case convention for experimental names, but it is suggested that the case convention *s/but // outlined above is followed. There is one exception from this convention in this document itself. That is that experimental SD-IDs start with "x-", so they are hyphenated. While this looks like an inconsistency, it was done Gerhards Expires August 22, 2005 [Page 38] Internet-Draft The syslog Protocol February 2005 because it is common practice (e.g. in SMTP) to prefix experimental *s/e.g. /e.g.,/ headers with "x-". A.7 Leap Seconds The TIMESTAMP described in Section 6.2.4 permits leap seconds, as described in RFC 3339 [10]. The value "60" in the TIME-SECOND field is used to indicate a leap second. This must not be misinterpreted. Implementors are advised to replace the value "60" if seen in the header, with the value "59" if it otherwise can not be processed, e.g. stored to a database. It *s/e.g. stored to/e.g., stored in/ should not be converted to the first second of the next minute. Please note that such a conversion, if done on the message text itself, will cause cryptographic signatures to become invalid. As such, it is suggested that the adjustment is not performed when the plain message text is to be stored (e.g. for later verification of *s/e.g. /e.g.,/ signatures). A.8 Syslog Senders Without Knowledge of Time In Section 6.2.4.1, a specific TIMESTAMP for usage by senders without knowledge of time is defined. This is done to support a special case when a sender is not aware of time at all. It can be argued if such *s/if/whether/ a sender can actually be found in today's IT infrastructure. However, discussion has indicated that those things may exist in practice and as such there should be a guideline established for this case. However, an implementation SHOULD emit a valid TIMESTAMP if the underlying operating system, programming system and hardware supports *s/programming system/&,/ the clock function. A proper TIMESTAMP should be emitted even if it *s/the/a/ is difficult, but doable, to obtain the system time. The TIMESTAMP described in Section 6.2.4.1 should only be used when it is actually impossible to obtain time information. This rule should not be used as an excuse for lazy implementations. If a receiver receives that special TIMESTAMP, it should know that the sender had no idea of what the time actually is and act *s/had/has/ accordingly. A.9 Additional Information on SENDER-INST The objective behind SENDER-INST (Section 6.2.7) is to provide a quick way to detect a new instance of the same sender. It must be noted that this is not reliable as a second incarnation of a SENDER-INST may actually be able to use the same SENDER-INST value as the prior one. Properly used, the SENDER-INST can be helpful for Gerhards Expires August 22, 2005 [Page 39] Internet-Draft The syslog Protocol February 2005 analysis purposes. A.10 Notes on the time SD-ID *s/time/timeQuality/ It is recommended that the value of "0" be the default for the "tzKnown" (Section 7.1.1) parameter. It should only be changed to "1" after the administrator has specifically configured the time zone. The value "1" may be used as the default if the underlying operating system provides accurate time zone information. It is still advised that the administrator explicitly acknowledges the *s/acknowledges/acknowledge/ correctness of the time zone information. It is important not to create a false impression of accuracy with the time SD-ID (Section 7.1). A sender should only indicate a given *s/time/timeQuality/ accuracy if it actually knows it is within these bounds. It is generally assumed that the sender gains this in-depth knowledge through operator configuration. As such, by default, an accuracy should not be provided. A.11 Recommendation for Diagnostic Logging In Section 8.1, this document describes the need as well as potential *s/need/need for/ problems of diagnostic logging. In this section, a real-world *s/of/with/ approach to useful diagnostic logging is recommended. While this document recommends to write meaningful diagnostic logs, *s/to write/writing/ it also recommends to allow an operator to limit the amount of *s/to allow/allowing/ diagnostic logging. At least, an implementation should differentiate between critical, informational and debugging diagnostic message. *s/informational/informational,/ */debugging diagnostic message/debugging or diagnostic messages/ Critical messages should only be issued in real critical states, e.g. *s/only be issued in real/be issued only in really/ *s/e.g./&,/ expected or happening malfunction of the application or parts of it. *s/happening/occuring/ A strong indication of an ongoing attack may also be considered critical. As a guideline, there should be very few critical messages. Informational messages should indicate all conditions not *s/indicate all conditions/be used to indicate that all conditions are/ fully correct, but still within the bounds of normal processing. A diagnostic message logging the fact that a malformed message has been received is a good example of this category. A debug diagnostic message should not be needed during normal operation, but merely as a tool for setting up or testing a system (which includes the process of an operator configuring multiple syslog applications in a complex environment). An application may decide to not provide any debugging *s/to not/not to/ diagnostic messages. An administrator should be able to configure the level for which diagnostic messages will be written. Non-configured diagnostic *s/diagnostic/diagnostic messages/ should not be written but discarded. An implementor may create as many different levels of diagnostic messages as he see useful - the *s/he see useful - /useful--/ above recommendation is just based on real-world experience of what Gerhards Expires August 22, 2005 [Page 40] Internet-Draft The syslog Protocol February 2005 is considered useful. Please note that experience shows that too many levels of diagnostics typically do no good, because the typical administrator may no longer be able to understand what each level means. Even with this categorization, a single diagnostic (or a set of them) may frequently be generated when a specific condition exists (or a system is being attacked). It will lead to the security issues outlined at the beginning of Section 8.1. To solve this, it is recommended that an implementation be allowed to set a limit of how many duplicate diagnostic messages will be generated within a limited amount of time. For example, an administrator should be able to configure that groups of 50 identical messages are logged within a specified time period with only a single diagnostic message. All subsequent identical messages will be discarded until the next time interval. It is usually considered good form to generate a subsequent message identifying the number of duplicate messages that were discarded. While this causes some information loss, it is considered a good compromise between avoiding overruns and providing most in-depth diagnostic information. An implementation offering *s/most/the most/ this feature should allow the administrator to configure the number of duplicate messages as well as the time interval to whatever the administrator thinks to be reasonable for his needs. It is up to the *s/to be reasonable for his needs/is reasonable/ implementor of what the term "duplicate" means. Some may decide that *s/of // only totally identical (in byte-to-byte comparison) messages are actually duplicate, some other may say that a message which is of *s/duplicate, some other/duplicates, whereas others/ *s/which/that/ identical type but with just some changed parameter (e.g. changed *s/e.g. /e.g.,/ remote host address) is also considered to be a duplicate. Both approaches have their advantages and disadvantages. Probably, it is best to also leave this configurable and allow the administrator to set the parameters. Gerhards Expires August 22, 2005 [Page 41] Internet-Draft The syslog Protocol February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gerhards Expires August 22, 2005 [Page 42] _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:33 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 5E5E119046 for ; Mon, 22 Aug 2005 18:51:33 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:33 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 13:07:15 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 13:07:14 -0700 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 31 May 2005 13:07:10 -0700 X-IronPort-AV: i="3.93,154,1115017200"; d="scan'208"; a="639806434:sNHT73500348" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4VK6nm3020565; Tue, 31 May 2005 13:07:02 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 31 May 2005 13:06:41 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,154,1115017200"; d="scan'208"; a="118366502:sNHT25213946" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id EC23F5C7D0; Tue, 31 May 2005 13:05:42 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by willers.employees.org (Postfix) with ESMTP id 5BAAE5C732 for ; Tue, 31 May 2005 13:04:39 -0700 (PDT) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 31 May 2005 16:04:39 -0400 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 j4VK495M010744 for ; Tue, 31 May 2005 16:04:37 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 16:04:28 -0400 Received: from [64.101.182.111] ([64.101.182.111]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 16:04:29 -0400 Date: Tue, 31 May 2005 15:04:29 -0500 (CDT) From: Chris Lonvick X-X-Sender: lonvick@linux.local To: syslog-sec@employees.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 31 May 2005 20:04:29.0508 (UTC) FILETIME=[F414C840:01C5661B] X-Mailman-Approved-At: Tue, 31 May 2005 13:05:40 -0700 Cc: Subject: [Syslog-sec] OIF Liaison on syslog-transport-udp X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.204 Status: RO X-Status: X-Keywords: X-UID: 43 Hi, Here's the markup for the syslog-transport-udp ID from the OIF. Thanks, Chris --- syslog Working Group A. Okmianski Internet-Draft Cisco Systems, Inc. Expires: May 10, 2005 November 9, 2004 Transmission of syslog messages over UDP draft-ietf-syslog-transport-udp-03 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes the transport for syslog messages over UDP/IPv4 or UDP/IPv6. Syslog protocol layered architecture provided *s/Syslog/The syslog/ *s/provided/provides/ for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementors are required to support this transport protocol. Okmianski Expires May 10, 2005 [Page 1] Internet-Draft syslog udp transport November 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. One Message Per Datagram . . . . . . . . . . . . . . . . . . . 3 3. Message Size . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Source and Target Ports . . . . . . . . . . . . . . . . . . . 4 5. Source IP Address . . . . . . . . . . . . . . . . . . . . . . 4 6. UDP/IP Structure . . . . . . . . . . . . . . . . . . . . . . . 4 7. UDP Checksums . . . . . . . . . . . . . . . . . . . . . . . . 4 8. Reliability Considerations . . . . . . . . . . . . . . . . . . 5 8.1 Lost Datagrams . . . . . . . . . . . . . . . . . . . . . . 5 8.2 Message Corruption . . . . . . . . . . . . . . . . . . . . 5 8.3 Congestion Control . . . . . . . . . . . . . . . . . . . . 5 8.4 Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9.1 Sender Authentication . . . . . . . . . . . . . . . . . . 6 9.2 Message Forgery . . . . . . . . . . . . . . . . . . . . . 6 9.3 Message Observation . . . . . . . . . . . . . . . . . . . 7 9.4 Replaying . . . . . . . . . . . . . . . . . . . . . . . . 7 9.5 Unreliable Delivery . . . . . . . . . . . . . . . . . . . 7 9.6 Message Prioritization and Differentiation . . . . . . . . 7 9.7 Denial of Service . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 11. Notice to RFC Editor . . . . . . . . . . . . . . . . . . . . 8 12. Working Group . . . . . . . . . . . . . . . . . . . . . . . 8 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 14.2 Informative References . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Okmianski Expires May 10, 2005 [Page 2] Internet-Draft syslog udp transport November 2004 1. Introduction The informational RFC 3164[1] has originally described the syslog *s/has // protocol as it was observed in the existing implementations. It *s/the // described both the format of syslog messages and a UDP[2] transport. Subsequently, the syslog protocol has been formally defined in the standards track RFC-protocol[3]. The RFC-protocol specified a layered architecture which provided for *s/which/that/ support of any number of transport layer protocols for transmitting syslog messages. This standards track RFC describes the UDP transport for the syslog protocol. This protocol can be utilized for transmitting syslog messages over *s/utilized /used/ both IPv4[4] and IPv6[5]. This transport protocol is REQUIRED for all syslog protocol implementations for interoperability purposes. Network administrators and architects should be aware of the significant reliability and security issues of this protocol, which stem from the use of UDP. They are documented in this specification. However, this protocol is lightweight and is built upon the existing popular use of UDP for syslog. *i *1.1 Conventions Used in This Document * *. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[6]. The words 'byte' and 'octet' are used interchangeably in this specification. 2. One Message Per Datagram Each syslog UDP datagram MUST contain one and only one syslog message. The message MUST be formatted according to the RFC-protocol[3]. No additional data MUST be present in the datagram *s/No a/A/ *s/MUST/MUST NOT/ payload. 3. Message Size This protocol supports transmission of syslog messages up to 65536 bytes in size. This limit stems from the maximum supported UDP payload of 65536 kilobytes specified in the RFC 768[2]. IPv4 syslog receivers MUST be able to receive datagrams with message size up to and including 480 bytes. IPv6 syslog receivers MUST be able to receive datagrams with message size up to and including 1180 bytes. All syslog receivers SHOULD be able to receive datagrams with messages size of at least 2048 bytes. *s/of at least/up to and including/ Okmianski Expires May 10, 2005 [Page 3] Internet-Draft syslog udp transport November 2004 The above restrictions and recommendations establish a baseline for interoperability. The minimum required message size support was determined based on the minimum MTU size that internet hosts are required to support: 576 bytes for IPv4[4] and 1280 bytes for IPv6[5]. Datagrams which fall within these limits have the greatest *s/which/that/ chance of being delivered because they do no require fragmentation. *s/no/not/ It is RECOMMENDED that application developers restrict message sizes such that IP datagrams do not exceed the smallest MTU of the network in use. This avoids datagram fragmentation and possible issues surrounding fragmentation such as incorrect MTU discovery. Fragmentation may be undesirable because it increases the risk of the message being lost due to loss of just one datagram fragment. When network MTU is not known in advance and cannot be reliably determined using path MTU discovery [8], the safest assumption is to restrict messages to 480 bytes for IPv4 and 1180 bytes for IPv6. 4. Source and Target Ports Syslog receivers MUST support accepting syslog datagrams on a *s/on a/on the/ well-known UDP port 514, but MAY be configurable to listen on a different port. Syslog senders MUST support sending syslog message datagrams to the UDP port 514, but MAY be configurable to send messages to a different port. Syslog senders MAY use any source UDP port for transmitting messages. 5. Source IP Address The source IP address of the UDP datagrams SHOULD NOT be interpreted as the identifier for the host which originated the syslog message. *s/which/that/ The entity sending the syslog message may be merely a relay. Syslog *s/Syslog/The syslog/ message itself contains the identifier of the originator of the message. 6. UDP/IP Structure Each UDP/IP datagram sent by the transport layer MUST completely adhere to the structure specified in the UDP RFC 768[2] and either IPv4 RFC 791[4] or IPv6 RFC 2640[5] depending on which protocol is used. 7. UDP Checksums Use of UDP checksums was defined as optional in RFC 768[2]. IPv6 has subsequently made UDP checksums required in RFC 2460[5]. Syslog senders MUST utilize valid UDP checksums when sending messages *s/utilize/use/ over IPv6. Syslog senders SHOULD utilize UDP checksums when sending *s/utilize/use/ Okmianski Expires May 10, 2005 [Page 4] Internet-Draft syslog udp transport November 2004 messages over IPv4. Syslog receivers MUST check the checksums whenever they are present and discard messages with incorrect checksums. Note that this is typically accomplished by the UDP layer implementation, and some UDP implementations allow for checksum validation to be enabled or disabled. 8. Reliability Considerations The UDP is an unreliable low-overhead protocol. This section discusses reliability issues inherent in UDP that implementers and users MUST be aware of. 8.1 Lost Datagrams This transport protocol does not provide any mechanism to detect and correct loss of datagrams. Datagrams may be lost in transit due to congestion, corruption or any other intermittent network problem. IP *s/corruption/corruption,/ fragmentation exacerbates this problem because loss of a single fragment will result in the entire message being discarded. In some circumstances the sender may receive an ICMP error message or other indication of a transmission problem. If the sender receives a reasonable indication that a datagram may have been lost, it MAY retransmit the datagram. 8.2 Message Corruption The UDP/IP datagrams may get corrupted in transit due to software, hardware or network errors. This protocol specifies use of UDP *s/hardware/hardware,/ checksums to enable corruption detection in addition to checksums utilized in IP and Layer 2 layers. However, checksums do not *s/utilized/used/ *s/layers/protocols/ guarantee corruption detection, and this protocol does not provide for message retransmission when a corrupt message is detected. A special case of corruption is corruption introduced by the UDP implementation itself. For example, several earlier UDP implementations defaulted to a buffer size of less than 65536 bytes and truncated larger payloads upon reception [9]. By following the message size recommendations of this protocol, application developers can significantly reduce the risk of this type of error. 8.3 Congestion Control The UDP does not provide for congestion control. Any network host *s/host/host or router/ can discard UDP packets when it is overloaded, and it may or may not provide an ICMP error to indicate this. One or multiple syslog Okmianski Expires May 10, 2005 [Page 5] Internet-Draft syslog udp transport November 2004 senders can maliciously or inadvertently overload the receiver or the network infrastructure and cause loss of syslog messages. 8.4 Sequenced Delivery The IP transport utilized by the UDP does not guarantee that the *s/utilized/used/ sequence of datagram delivery will match the order in which the datagrams were sent. The time stamp contained within each syslog message may serve as a rough guide in establishing sequence order, but it will not help in cases when multiple messages were generated during the same time slot or when messages originated from different *s/ or when/, the sender cannot generate a time stamp, or/ hosts whose clocks are not synchronized. The order of syslog message arrival via this transport SHOULD NOT be used as an authoritative *s/ / / guide in establishing an absolute or relative sequence of events on the syslog sender hosts. 9. Security Considerations Several syslog security considerations have been discussed in *s/have been/are/ RFC-protocol[3]. This section focuses on security considerations specific to the syslog transport over UDP. 9.1 Sender Authentication This transport protocol does not provide for strong sender authentication. The receiver of the syslog message will not be able to ascertain that the message was indeed sent from the reported sender, or if the packet was sent from another device. This may also *s/if/whether/ lead to a case of mistaken identify where a misconfigured machine may *s/identify/identity/ *s/where/if/ *s/ may// send syslog messages to a receiver representing itself as another *s/send/sends/ machine. 9.2 Message Forgery This transport protocol does not provide protection against syslog message forgery. An attacker may transmit syslog messages (either from the machine from which the messages are purportedly sent or from any other machine) to a receiver. In one case, an attacker may hide the true nature of an attack amidst many other messages. As an example, an attacker may start generating forged messages indicating a problem on some machine. This may get the attention of the system administrators who will spend their time *s/administrators/administrators,/ investigating the alleged problem. During this time, the attacker may be able to compromise a different machine, or a different process *s/,// on the same machine. Additionally, an attacker may generate false syslog messages to give Okmianski Expires May 10, 2005 [Page 6] Internet-Draft syslog udp transport November 2004 untrue indications of status of systems. As an example, an attacker *s/status/the status/ may stop a critical process on a machine, which may generate a notification of exit. The attacker may subsequently generate a forged notification that the process had been restarted. The system administrators may accept that misinformation and not verify that the process had indeed been restarted. *s/been/not been/ 9.3 Message Observation This transport protocol does not provide confidentiality of the messages in transit. If syslog messages are in clear text, this is how they will be transferred. In most cases passing clear-text human-readable messages is a benefit to the administrators. Unfortunately, an attacker may also be able to observe the human-readable contents of syslog messages. The attacker may then use the knowledge gained from these messages to compromise a machine. It is RECOMMENDED that no sensitive information be transmitted via this transport protocol or that transmission of such information be restricted to properly secured networks. 9.4 Replaying Message forgery and observation can be combined into a replay attack. An attacker may record a set of messages that indicate normal activity of a machine. At a later time, an attacker may remove that machine from the network and replay the syslog messages with new time stamps. The administrators may find nothing unusual in the received messages and their receipt would falsely indicate normal activity of *s/messages/messages,/ the machine. 9.5 Unreliable Delivery As was previously discussed in the Reliability Considerations section, the UDP transport is not reliable and packets containing *s/reliable/reliable,/ syslog message datagrams can be lost in transit without any notice. There can be security consequences to the loss of one or more syslog messages. Administrators may not become aware of a developing and potentially serious problem. Messages may also be intercepted and discarded by an attacker as a way to hide unauthorized activities. 9.6 Message Prioritization and Differentiation This transport protocol does not mandate prioritization of syslog messages on the wire or when processed on the receiving host based on their severity. The security implication of such behavior is that the syslog receiver or network devices may get overwhelmed with low *s/low /low-/ severity messages and be forced to discard potentially high severity *s/high /high-/ messages. High severity messages may contain an indication of *s/High /High-/ Okmianski Expires May 10, 2005 [Page 7] Internet-Draft syslog udp transport November 2004 serious security problems, but they will not get a higher priority. 9.7 Denial of Service An attacker may overwhelm a receiver by sending more messages to it than can be handled by the infrastructure or the device itself. Implementers SHOULD attempt to provide features that minimize this threat such as optionally restricting reception of messages to a set of know IP addresses. *s/know/known source/ 10. IANA Considerations IANA must reserve UDP port 514 for this transport. 11. Notice to RFC Editor This is a notice to the RFC editor. This ID is submitted along with ID draft-ietf-syslog-protocol and they cross-reference each other. When RFC numbers are determined for each of these IDs, please replace all references to "RFC-protocol" with the RFC number of draft-ietf-syslog-protocol ID. Please remove this section after editing. 12. Working Group The working group can be contacted via the mailing list: syslog-sec@employees.org The current Chair of the Working Group may be contacted at: Chris Lonvick Cisco Systems Email: clonvick@cisco.com 13. Acknowledgements The author gratefully acknowledges the contributions of: Chris Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova, Devin Kowatch and all others who have commented on the various *s/Kowatch/Kowatch,/ versions of this proposal. 14. References Okmianski Expires May 10, 2005 [Page 8] Internet-Draft syslog udp transport November 2004 14.1 Normative References [1] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. *Question: Is this informative? [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [3] Gerhards, R., "The syslog Protocol", RFC RFC-protocol. [4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. 14.2 Informative References [8] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [9] Stevens, W., "TCP/IP Illustrated Volume 1. The Protocols.", January 1994. Author's Address Anton Okmianski Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719-2205 USA Phone: +1-978-936-1612 EMail: aokmians@cisco.com Okmianski Expires May 10, 2005 [Page 9] Internet-Draft syslog udp transport November 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Okmianski Expires May 10, 2005 [Page 10] _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:41 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 8D2B219046 for ; Mon, 22 Aug 2005 18:51:41 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:41 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 13:21:17 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 13:21:17 -0700 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 31 May 2005 13:21:04 -0700 X-IronPort-AV: i="3.93,154,1115017200"; d="scan'208"; a="272130105:sNHT2132877514" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4VKKZm6001338; Tue, 31 May 2005 13:20:54 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 31 May 2005 13:20:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,154,1115017200"; d="scan'208"; a="68882784:sNHT15897208" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 564215C84C; Tue, 31 May 2005 13:20:55 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from loutre.ath.cx (AReims-151-1-13-217.w83-192.abo.wanadoo.fr [83.192.139.217]) by willers.employees.org (Postfix) with ESMTP id 23A445C7B0 for ; Tue, 31 May 2005 13:20:53 -0700 (PDT) Received: from [192.168.2.100] (d213-103-13-241.cust.tele2.fr [213.103.13.241]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by loutre.ath.cx (Postfix) with ESMTP id D9F4E174F03; Tue, 31 May 2005 22:22:59 +0200 (CEST) Subject: Re: [Syslog-sec] OIF Liaison on syslog-protocol From: =?ISO-8859-1?Q?Cl=E9ment?= MATHIEU To: Chris Lonvick In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Date: Tue, 31 May 2005 22:20:43 +0200 Message-Id: <1117570843.4105.9.camel@ragondin.ath.cx> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 8bit Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 31 May 2005 20:21:17.0345 (UTC) FILETIME=[4CCC8110:01C5661E] Status: RO X-Status: X-Keywords: X-UID: 44 Le mardi 31 mai 2005 à 14:59 -0500, Chris Lonvick a écrit : > Example 4 - STRUCTURED-DATA Only > > 1 888 4 2003-10-11T22:14:15.003Z mymachine.example.com > evntslog - ID47 [x-exampleSDID iut="3" > eventSource="Application" > eventID="1011"][x-examplePriority class="high"] > > This example shows a message with only STRUCTURED-DATA and no MSG > part. This is a valid message. > *One could be picky and point out that according to the ABNF, this > example MUST have > *a space at the end. That's wrong :-) SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG] Clément MATHIEU _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From aokmians@cisco.com Mon Aug 22 18:51:42 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 2A33919046 for ; Mon, 22 Aug 2005 18:51:42 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:42 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 13:30:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from xbh-rtp-201.amer.cisco.com ([64.102.31.12]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 13:30:44 -0700 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, 31 May 2005 16:30:41 -0400 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 31 May 2005 20:30:41.0940 (UTC) FILETIME=[9D52DD40:01C5661F] Subject: RE: [Syslog-sec] OIF Liaison on syslog-transport-udp Date: Tue, 31 May 2005 13:30:43 -0700 Message-ID: <98AE08B66FAD1742BED6CB9522B73122318C8A@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] OIF Liaison on syslog-transport-udp Thread-Index: AcVmHFdCZxFT90UVQdykluVTGRA6cwAAvd0Q From: "Anton Okmianski (aokmians)" To: "Chris Lonvick (clonvick)" , Status: RO X-Status: X-Keywords: X-UID: 45 Chris: I looked at a few suggested edits. As best I can tell I have already = incorporated all these changes based on the earlier unofficial = submission of this feedback by OIF. These changes went into the draft = published to this list on April 21. =20 Thanks, Anton. =20 > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org=20 > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf=20 > Of Chris Lonvick (clonvick) > Sent: Tuesday, May 31, 2005 4:04 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] OIF Liaison on syslog-transport-udp >=20 > Hi, >=20 > Here's the markup for the syslog-transport-udp ID from the OIF. >=20 > Thanks, > Chris >=20 > --- >=20 > syslog Working Group =20 > A. Okmianski > Internet-Draft Cisco=20 > Systems, Inc. > Expires: May 10, 2005 =20 > November 9, 2004 >=20 >=20 > Transmission of syslog messages over UDP > draft-ietf-syslog-transport-udp-03 >=20 > Status of this Memo >=20 > This document is an Internet-Draft and is subject to all provisions > of section 3 of RFC 3667. By submitting this Internet-Draft, each > author represents that any applicable patent or other IPR claims of > which he or she is aware have been or will be disclosed, and any of > which he or she become aware will be disclosed, in accordance with > RFC 3668. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as > Internet-Drafts. >=20 > Internet-Drafts are draft documents valid for a maximum of=20 > six months > and may be updated, replaced, or obsoleted by other=20 > documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on May 10, 2005. >=20 > Copyright Notice >=20 > Copyright (C) The Internet Society (2004). >=20 > Abstract >=20 > This document describes the transport for syslog messages over > UDP/IPv4 or UDP/IPv6. Syslog protocol layered=20 > architecture provided *s/Syslog/The syslog/ *s/provided/provides/ > for support of any number of transport mappings. However, for > interoperability purposes, syslog protocol implementors=20 > are required > to support this transport protocol. >=20 >=20 >=20 >=20 >=20 >=20 > Okmianski Expires May 10, 2005 =20 > [Page 1] >=20 > Internet-Draft syslog udp transport =20 > November 2004 >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 3 > 2. One Message Per Datagram . . . . . . . . . . . . . . .=20 > . . . . 3 > 3. Message Size . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 3 > 4. Source and Target Ports . . . . . . . . . . . . . . .=20 > . . . . 4 > 5. Source IP Address . . . . . . . . . . . . . . . . . .=20 > . . . . 4 > 6. UDP/IP Structure . . . . . . . . . . . . . . . . . . .=20 > . . . . 4 > 7. UDP Checksums . . . . . . . . . . . . . . . . . . . .=20 > . . . . 4 > 8. Reliability Considerations . . . . . . . . . . . . . .=20 > . . . . 5 > 8.1 Lost Datagrams . . . . . . . . . . . . . . . . . .=20 > . . . . 5 > 8.2 Message Corruption . . . . . . . . . . . . . . . .=20 > . . . . 5 > 8.3 Congestion Control . . . . . . . . . . . . . . . .=20 > . . . . 5 > 8.4 Sequenced Delivery . . . . . . . . . . . . . . . .=20 > . . . . 6 > 9. Security Considerations . . . . . . . . . . . . . . .=20 > . . . . 6 > 9.1 Sender Authentication . . . . . . . . . . . . . .=20 > . . . . 6 > 9.2 Message Forgery . . . . . . . . . . . . . . . . .=20 > . . . . 6 > 9.3 Message Observation . . . . . . . . . . . . . . .=20 > . . . . 7 > 9.4 Replaying . . . . . . . . . . . . . . . . . . . .=20 > . . . . 7 > 9.5 Unreliable Delivery . . . . . . . . . . . . . . .=20 > . . . . 7 > 9.6 Message Prioritization and Differentiation . . . .=20 > . . . . 7 > 9.7 Denial of Service . . . . . . . . . . . . . . . .=20 > . . . . 8 > 10. IANA Considerations . . . . . . . . . . . . . . . .=20 > . . . . 8 > 11. Notice to RFC Editor . . . . . . . . . . . . . . . .=20 > . . . . 8 > 12. Working Group . . . . . . . . . . . . . . . . . . .=20 > . . . . 8 > 13. Acknowledgements . . . . . . . . . . . . . . . . . .=20 > . . . . 8 > 14. References . . . . . . . . . . . . . . . . . . . . .=20 > . . . . 9 > 14.1 Normative References . . . . . . . . . . . . . . . .=20 > . . . . 9 > 14.2 Informative References . . . . . . . . . . . . . . .=20 > . . . . 9 > Author's Address . . . . . . . . . . . . . . . . . . .=20 > . . . . 9 > Intellectual Property and Copyright Statements . . . .=20 > . . . . 10 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Okmianski Expires May 10, 2005 =20 > [Page 2] >=20 > Internet-Draft syslog udp transport =20 > November 2004 >=20 >=20 > 1. Introduction >=20 > The informational RFC 3164[1] has originally described the=20 > syslog *s/has // > protocol as it was observed in the existing=20 > implementations. It *s/the // > described both the format of syslog messages and a UDP[2]=20 > transport. > Subsequently, the syslog protocol has been formally defined in the > standards track RFC-protocol[3]. >=20 > The RFC-protocol specified a layered architecture which=20 > provided for *s/which/that/ > support of any number of transport layer protocols for transmitting > syslog messages. This standards track RFC describes the UDP > transport for the syslog protocol. >=20 > This protocol can be utilized for transmitting syslog=20 > messages over *s/utilized /used/ > both IPv4[4] and IPv6[5]. This transport protocol is REQUIRED for > all syslog protocol implementations for interoperability purposes. >=20 > Network administrators and architects should be aware of the > significant reliability and security issues of this protocol, which > stem from the use of UDP. They are documented in this=20 > specification. > However, this protocol is lightweight and is built upon=20 > the existing > popular use of UDP for syslog. > *i > *1.1 Conventions Used in This Document > * > *. > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and=20 > "OPTIONAL" in this > document are to be interpreted as described in RFC 2119[6]. The > words 'byte' and 'octet' are used interchangeably in this > specification. >=20 > 2. One Message Per Datagram >=20 > Each syslog UDP datagram MUST contain one and only one syslog > message. The message MUST be formatted according to the > RFC-protocol[3]. No additional data MUST be present in=20 > the datagram *s/No a/A/ *s/MUST/MUST NOT/ > payload. >=20 > 3. Message Size >=20 > This protocol supports transmission of syslog messages up to 65536 > bytes in size. This limit stems from the maximum supported UDP > payload of 65536 kilobytes specified in the RFC 768[2]. >=20 > IPv4 syslog receivers MUST be able to receive datagrams=20 > with message > size up to and including 480 bytes. IPv6 syslog receivers MUST be > able to receive datagrams with message size up to and=20 > including 1180 > bytes. All syslog receivers SHOULD be able to receive=20 > datagrams with > messages size of at least 2048 bytes. > *s/of at least/up to and including/ >=20 >=20 >=20 >=20 > Okmianski Expires May 10, 2005 =20 > [Page 3] >=20 > Internet-Draft syslog udp transport =20 > November 2004 >=20 >=20 > The above restrictions and recommendations establish a baseline for > interoperability. The minimum required message size support was > determined based on the minimum MTU size that internet hosts are > required to support: 576 bytes for IPv4[4] and 1280 bytes for > IPv6[5]. Datagrams which fall within these limits have=20 > the greatest *s/which/that/ > chance of being delivered because they do no require fragmentation. > *s/no/not/ >=20 > It is RECOMMENDED that application developers restrict=20 > message sizes > such that IP datagrams do not exceed the smallest MTU of=20 > the network > in use. This avoids datagram fragmentation and possible issues > surrounding fragmentation such as incorrect MTU discovery. > Fragmentation may be undesirable because it increases the=20 > risk of the > message being lost due to loss of just one datagram fragment. When > network MTU is not known in advance and cannot be reliably=20 > determined > using path MTU discovery [8], the safest assumption is to restrict > messages to 480 bytes for IPv4 and 1180 bytes for IPv6. >=20 > 4. Source and Target Ports >=20 > Syslog receivers MUST support accepting syslog datagrams=20 > on a *s/on a/on the/ > well-known UDP port 514, but MAY be configurable to listen on a > different port. Syslog senders MUST support sending syslog message > datagrams to the UDP port 514, but MAY be configurable to send > messages to a different port. Syslog senders MAY use any=20 > source UDP > port for transmitting messages. >=20 > 5. Source IP Address >=20 > The source IP address of the UDP datagrams SHOULD NOT be=20 > interpreted > as the identifier for the host which originated the syslog message. > *s/which/that/ > The entity sending the syslog message may be merely a=20 > relay. Syslog *s/Syslog/The syslog/ > message itself contains the identifier of the originator of the > message. >=20 > 6. UDP/IP Structure >=20 > Each UDP/IP datagram sent by the transport layer MUST completely > adhere to the structure specified in the UDP RFC 768[2] and either > IPv4 RFC 791[4] or IPv6 RFC 2640[5] depending on which protocol is > used. >=20 > 7. UDP Checksums >=20 > Use of UDP checksums was defined as optional in RFC=20 > 768[2]. IPv6 has > subsequently made UDP checksums required in RFC 2460[5]. >=20 > Syslog senders MUST utilize valid UDP checksums when=20 > sending messages *s/utilize/use/ > over IPv6. Syslog senders SHOULD utilize UDP checksums=20 > when sending *s/utilize/use/ >=20 >=20 >=20 > Okmianski Expires May 10, 2005 =20 > [Page 4] >=20 > Internet-Draft syslog udp transport =20 > November 2004 >=20 >=20 > messages over IPv4. >=20 > Syslog receivers MUST check the checksums whenever they are present > and discard messages with incorrect checksums. Note that this is > typically accomplished by the UDP layer implementation,=20 > and some UDP > implementations allow for checksum validation to be enabled or > disabled. >=20 > 8. Reliability Considerations >=20 > The UDP is an unreliable low-overhead protocol. This section > discusses reliability issues inherent in UDP that implementers and > users MUST be aware of. >=20 > 8.1 Lost Datagrams >=20 > This transport protocol does not provide any mechanism to=20 > detect and > correct loss of datagrams. Datagrams may be lost in transit due to > congestion, corruption or any other intermittent network=20 > problem. IP *s/corruption/corruption,/ > fragmentation exacerbates this problem because loss of a single > fragment will result in the entire message being discarded. >=20 > In some circumstances the sender may receive an ICMP error=20 > message or > other indication of a transmission problem. If the sender=20 > receives a > reasonable indication that a datagram may have been lost, it MAY > retransmit the datagram. >=20 > 8.2 Message Corruption >=20 > The UDP/IP datagrams may get corrupted in transit due to software, > hardware or network errors. This protocol specifies use=20 > of UDP *s/hardware/hardware,/ > checksums to enable corruption detection in addition to checksums > utilized in IP and Layer 2 layers. However, checksums do=20 > not *s/utilized/used/ *s/layers/protocols/ > guarantee corruption detection, and this protocol does not provide > for message retransmission when a corrupt message is detected. >=20 > A special case of corruption is corruption introduced by the UDP > implementation itself. For example, several earlier UDP > implementations defaulted to a buffer size of less than 65536 bytes > and truncated larger payloads upon reception [9]. By following the > message size recommendations of this protocol, application=20 > developers > can significantly reduce the risk of this type of error. >=20 > 8.3 Congestion Control >=20 > The UDP does not provide for congestion control. Any=20 > network host *s/host/host or router/ > can discard UDP packets when it is overloaded, and it may=20 > or may not > provide an ICMP error to indicate this. One or multiple syslog >=20 >=20 >=20 > Okmianski Expires May 10, 2005 =20 > [Page 5] >=20 > Internet-Draft syslog udp transport =20 > November 2004 >=20 >=20 > senders can maliciously or inadvertently overload the=20 > receiver or the > network infrastructure and cause loss of syslog messages. >=20 > 8.4 Sequenced Delivery >=20 > The IP transport utilized by the UDP does not guarantee=20 > that the *s/utilized/used/ > sequence of datagram delivery will match the order in which the > datagrams were sent. The time stamp contained within each syslog > message may serve as a rough guide in establishing sequence order, > but it will not help in cases when multiple messages were generated > during the same time slot or when messages originated from=20 > different *s/ or when/, the sender cannot generate a time stamp, or/ > hosts whose clocks are not synchronized. The order of=20 > syslog message > arrival via this transport SHOULD NOT be used as an=20 > authoritative *s/ / / > guide in establishing an absolute or relative sequence of events on > the syslog sender hosts. >=20 > 9. Security Considerations >=20 > Several syslog security considerations have been discussed=20 > in *s/have been/are/ > RFC-protocol[3]. This section focuses on security considerations > specific to the syslog transport over UDP. >=20 > 9.1 Sender Authentication >=20 > This transport protocol does not provide for strong sender > authentication. The receiver of the syslog message will=20 > not be able > to ascertain that the message was indeed sent from the reported > sender, or if the packet was sent from another device. =20 > This may also *s/if/whether/ > lead to a case of mistaken identify where a misconfigured=20 > machine may *s/identify/identity/ *s/where/if/ *s/ may// > send syslog messages to a receiver representing itself as=20 > another *s/send/sends/ > machine. >=20 > 9.2 Message Forgery >=20 > This transport protocol does not provide protection against syslog > message forgery. An attacker may transmit syslog messages (either > from the machine from which the messages are purportedly=20 > sent or from > any other machine) to a receiver. >=20 > In one case, an attacker may hide the true nature of an=20 > attack amidst > many other messages. As an example, an attacker may start=20 > generating > forged messages indicating a problem on some machine. This may get > the attention of the system administrators who will spend=20 > their time *s/administrators/administrators,/ > investigating the alleged problem. During this time, the attacker > may be able to compromise a different machine, or a=20 > different process *s/,// > on the same machine. >=20 > Additionally, an attacker may generate false syslog=20 > messages to give >=20 >=20 >=20 > Okmianski Expires May 10, 2005 =20 > [Page 6] >=20 > Internet-Draft syslog udp transport =20 > November 2004 >=20 >=20 > untrue indications of status of systems. As an example,=20 > an attacker *s/status/the status/ > may stop a critical process on a machine, which may generate a > notification of exit. The attacker may subsequently generate a > forged notification that the process had been restarted. =20 > The system > administrators may accept that misinformation and not=20 > verify that the > process had indeed been restarted. > *s/been/not been/ >=20 > 9.3 Message Observation >=20 > This transport protocol does not provide confidentiality of the > messages in transit. If syslog messages are in clear text, this is > how they will be transferred. In most cases passing clear-text > human-readable messages is a benefit to the administrators. > Unfortunately, an attacker may also be able to observe the > human-readable contents of syslog messages. The attacker may then > use the knowledge gained from these messages to compromise=20 > a machine. > It is RECOMMENDED that no sensitive information be transmitted via > this transport protocol or that transmission of such information be > restricted to properly secured networks. >=20 > 9.4 Replaying >=20 > Message forgery and observation can be combined into a=20 > replay attack. > An attacker may record a set of messages that indicate normal > activity of a machine. At a later time, an attacker may=20 > remove that > machine from the network and replay the syslog messages=20 > with new time > stamps. The administrators may find nothing unusual in=20 > the received > messages and their receipt would falsely indicate normal=20 > activity of *s/messages/messages,/ > the machine. >=20 > 9.5 Unreliable Delivery >=20 > As was previously discussed in the Reliability Considerations > section, the UDP transport is not reliable and packets=20 > containing *s/reliable/reliable,/ > syslog message datagrams can be lost in transit without any notice. > There can be security consequences to the loss of one or=20 > more syslog > messages. Administrators may not become aware of a developing and > potentially serious problem. Messages may also be intercepted and > discarded by an attacker as a way to hide unauthorized activities. >=20 > 9.6 Message Prioritization and Differentiation >=20 > This transport protocol does not mandate prioritization of syslog > messages on the wire or when processed on the receiving=20 > host based on > their severity. The security implication of such behavior is that > the syslog receiver or network devices may get overwhelmed=20 > with low *s/low /low-/ > severity messages and be forced to discard potentially=20 > high severity *s/high /high-/ > messages. High severity messages may contain an=20 > indication of *s/High /High-/ >=20 >=20 >=20 > Okmianski Expires May 10, 2005 =20 > [Page 7] >=20 > Internet-Draft syslog udp transport =20 > November 2004 >=20 >=20 > serious security problems, but they will not get a higher priority. >=20 > 9.7 Denial of Service >=20 > An attacker may overwhelm a receiver by sending more messages to it > than can be handled by the infrastructure or the device itself. > Implementers SHOULD attempt to provide features that minimize this > threat such as optionally restricting reception of=20 > messages to a set > of know IP addresses. > *s/know/known source/ >=20 > 10. IANA Considerations >=20 > IANA must reserve UDP port 514 for this transport. >=20 > 11. Notice to RFC Editor >=20 > This is a notice to the RFC editor. This ID is submitted=20 > along with > ID draft-ietf-syslog-protocol and they cross-reference each other. > When RFC numbers are determined for each of these IDs,=20 > please replace > all references to "RFC-protocol" with the RFC number of > draft-ietf-syslog-protocol ID. Please remove this section after > editing. >=20 > 12. Working Group >=20 > The working group can be contacted via the mailing list: >=20 > syslog-sec@employees.org >=20 > The current Chair of the Working Group may be contacted at: >=20 > Chris Lonvick > Cisco Systems > Email: clonvick@cisco.com >=20 >=20 > 13. Acknowledgements >=20 > The author gratefully acknowledges the contributions of: Chris > Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert > Mietus, Bernie Volz, Mickael Graham, Greg Morris,=20 > Alexandra Fedorova, > Devin Kowatch and all others who have commented on the=20 > various *s/Kowatch/Kowatch,/ > versions of this proposal. >=20 > 14. References >=20 >=20 >=20 >=20 >=20 >=20 > Okmianski Expires May 10, 2005 =20 > [Page 8] >=20 > Internet-Draft syslog udp transport =20 > November 2004 >=20 >=20 > 14.1 Normative References >=20 > [1] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. > *Question: Is this informative? >=20 > [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August > 1980. >=20 > [3] Gerhards, R., "The syslog Protocol", RFC RFC-protocol. >=20 > [4] Postel, J., "Internet Protocol", STD 5, RFC 791,=20 > September 1981. >=20 > [5] Deering, S. and R. Hinden, "Internet Protocol,=20 > Version 6 (IPv6) > Specification", RFC 2460, December 1998. >=20 > [6] Bradner, S., "Key words for use in RFCs to Indicate=20 > Requirement > Levels", BCP 14, RFC 2119, March 1997. >=20 > [7] Braden, R., "Requirements for Internet Hosts - Communication > Layers", STD 3, RFC 1122, October 1989. >=20 > 14.2 Informative References >=20 > [8] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, > November 1990. >=20 > [9] Stevens, W., "TCP/IP Illustrated Volume 1. The Protocols.", > January 1994. >=20 >=20 > Author's Address >=20 > Anton Okmianski > Cisco Systems, Inc. > 1414 Massachusetts Ave > Boxborough, MA 01719-2205 > USA >=20 > Phone: +1-978-936-1612 > EMail: aokmians@cisco.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Okmianski Expires May 10, 2005 =20 > [Page 9] >=20 > Internet-Draft syslog udp transport =20 > November 2004 >=20 >=20 > Intellectual Property Statement >=20 > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be=20 > claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. =20 > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. >=20 > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for=20 > the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR=20 > repository at > http://www.ietf.org/ipr. >=20 > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. >=20 >=20 > Disclaimer of Validity >=20 > This document and the information contained herein are=20 > provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE=20 > REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >=20 >=20 > Copyright Statement >=20 > Copyright (C) The Internet Society (2004). This document=20 > is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. >=20 >=20 > Acknowledgment >=20 > Funding for the RFC Editor function is currently provided by the > Internet Society. >=20 >=20 >=20 >=20 > Okmianski =20 > Expires May 10, 2005 [Page 10] > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20