From syslog-bounces@lists.ietf.org Wed Aug 02 13:35:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8KcX-0005GP-Bc; Wed, 02 Aug 2006 13:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8KcV-0005GH-I5 for syslog@ietf.org; Wed, 02 Aug 2006 13:34:59 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8KcT-00078x-7w for syslog@ietf.org; Wed, 02 Aug 2006 13:34:59 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 1B46527C065 for ; Wed, 2 Aug 2006 19:29:15 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16398-10 for ; Wed, 2 Aug 2006 19:29:15 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D418B27C061 for ; Wed, 2 Aug 2006 19:29:14 +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, 2 Aug 2006 19:34:50 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Aug 2006 19:34:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DBD@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dtls syslog Thread-Index: Aca2WfJwURItVVuuQnW/DDQFrQR/7A== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 02 Aug 2006 17:34:50.0876 (UTC) FILETIME=[F53343C0:01C6B659] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Syslog] Dtls syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi WG, Quickly from the plane. Tom Patch and me have put some thoughts into dtls encypted syslog. This is not realted to the IPR discussion. We just find that would be an intresting concept. I've talked to Chris before starting this work, he has permitted to post it to the WG mailing list. However, the focus is obviously still on getting -transport-tls done. DTLS, however, might even provide some additional things to think about for -tls. The announcement can be found here: http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg11459.html Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 04 10:14:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90Qq-0004SY-AV; Fri, 04 Aug 2006 10:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90Qo-0004RI-RN for syslog@ietf.org; Fri, 04 Aug 2006 10:13:42 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G90Qn-00075w-9l for syslog@ietf.org; Fri, 04 Aug 2006 10:13:42 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2006 07:13:40 -0700 X-IronPort-AV: i="4.07,211,1151910000"; d="scan'208"; a="438828223:sNHT27555200" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k74EDeXp021383; Fri, 4 Aug 2006 07:13:40 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k74EDcHn002006; Fri, 4 Aug 2006 07:13:38 -0700 (PDT) Date: Fri, 4 Aug 2006 07:13:38 -0700 (PDT) From: Chris Lonvick To: Miao Fuyou Subject: RE: [Syslog] delineated datagrams In-Reply-To: <00f801c6af25$a5423c30$8c0c6f0a@china.huawei.com> Message-ID: References: <00f801c6af25$a5423c30$8c0c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=4903; t=1154700820; x=1155564820; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:RE=3A=20[Syslog]=20delineated=20datagrams; X=v=3Dcisco.com=3B=20h=3D5ucYYxzVSkmFpt9MXr2NL3s4WYg=3D; b=DxliEOPPNoMKgHTHxgVnt8fD/Vh5pAMJcvq7K2MdU42vNslIOlCzIW5xkY7rY9FeedAF6wZy ieKydIskAx2eGqgv5ltCD44+7+Kjt1GzIRtip50q+FRnn+U/TojeLXxh; Authentication-Results: sj-dkim-2.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: syslog@ietf.org, 'Tom Petch' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I'd like to get this resolved and put into the next version of the draft. Many protocols use byte-counting for framing. Many protocols use a specific character as a delimiter. Do we need both? I think that I've seen notes from Rainer, Tom Petch, and Andrew Ross saying that we should only use a special character for both simplicity of design and for interoperability with current syslog/tls implementations. Are there other opinions on this? Please speak up now. Thanks, Chris On Mon, 24 Jul 2006, Miao Fuyou wrote: > > Hi, Rainer, > > Interop is a compelling reason for protocol design, so I tend to agree with > you that it is a feature nice to have. I am wondering whether we should > define procedures for frame delineating processing in syslog-tls draft > because we have both octect-counter and LF in a record. > > Miao > >> -----Original Message----- >> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] >> Sent: Friday, July 21, 2006 6:16 PM >> To: Miao Fuyou; Tom Petch; syslog@ietf.org >> Subject: RE: [Syslog] delineated >> datagramswasdraft-ietf-syslog-transport-tls-01.txt >> >> Miao, >> >> I agree with your comments. However, using the LF as a record >> delimited would still allow us to interop with existing >> syslog/tls implementations. This is my major point. I think >> it is worth it. >> >> Rainer >> >>> -----Original Message----- >>> From: Miao Fuyou [mailto:miaofy@huawei.com] >>> Sent: Friday, July 21, 2006 12:00 PM >>> To: 'Tom Petch'; syslog@ietf.org >>> Subject: RE: [Syslog] delineated >>> datagramswasdraft-ietf-syslog-transport-tls-01.txt >>> >>> >>> TLS uses SHA-1 or MD5 in ciphersuite for message integrity >>> verification. If bytes lost happens during transferring, >> the message >>> will be dropped by TLS. >>> That is also the cause that we need a security mechanism >> for Syslog. >>> >>> As for error of encoding/decoding, I believe if an application does >>> encoding/decoding in a wrong way, you must not expect it do >> it right >>> with other mechanism, such as LF. >>> >>> Redundancy to improve robustness is good idea, but I don't >> think it >>> applies to this case. >>> >>>> -----Original Message----- >>>> From: Tom Petch [mailto:nwnetworks@dial.pipex.com] >>>> Sent: Tuesday, June 20, 2006 8:43 PM >>>> To: syslog@ietf.org >>>> Subject: Re: [Syslog] delineated datagrams >>>> wasdraft-ietf-syslog-transport-tls-01.txt >>>> >>>> I wonder if others share my concern about the lack of >> robustness in >>>> the way in which datagrams are delineated in the stream >> protocol (a >>>> TCP rather than a TLS issue). >>>> >>>> The system works as long as >>>> - the frame length is encoded perfectly >>>> - the frame length is decoded perfectly >>>> - no bytes are inserted or removed in error which is >> doubtless true >>>> in some networks, but I would prefer not to >>> rely on it. >>>> >>>> So, when an error occurs, can the Collector/Relay detect it? >>>> Can the Collector/Relay recover synch? If not, what does the >>>> Collector/Relay do? >>>> >>>> There is very little redundancy in the definition of >> frame length, >>>> and syslog messages have very little structure to help the >>>> application, so I think that this is an issue we should address. >>>> >>>> Tom Petch >>>> >>>> ----- Original Message ----- >>>> From: "David B Harrington" >>>> To: >>>> Sent: Tuesday, May 09, 2006 4:26 PM >>>> Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt >>>> >>>> >>>> Hi, >>>> >>>> A new revision of the syslog/TLS draft is available. >>>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 >>>> .txt >>>> >>>> We need reviewers. >>>> Can we get >>>> 1) a person to check the grammar? >>>> 2) a person to check the syslog technical parts? >>>> 3) a person to check compatibility with the other WG documents? >>>> 4) a person to check the TLS technical parts? >>>> >>>> We also need general reviews of the document by multiple people. >>>> >>>> Thanks, >>>> David Harrington >>>> co-chair, Syslog WG >>>> ietfdbh@comcast.net >>>> >>>> >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/syslog >>>> >>>> >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/syslog >>>> >>> >>> >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >>> >> > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 04 12:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92Vt-0006Kb-16; Fri, 04 Aug 2006 12:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G92Vq-000618-B2 for syslog@ietf.org; Fri, 04 Aug 2006 12:27:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G90q6-0002b7-Kc for syslog@ietf.org; Fri, 04 Aug 2006 10:39:50 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G90Tt-00016u-AZ for syslog@ietf.org; Fri, 04 Aug 2006 10:16:55 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 5F83827C065; Fri, 4 Aug 2006 16:10:59 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00540-09; Fri, 4 Aug 2006 16:10:59 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 03E7027C061; Fri, 4 Aug 2006 16:10:58 +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, 4 Aug 2006 16:16:40 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] delineated datagrams MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Aug 2006 16:16:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DCC@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] delineated datagrams Thread-Index: Aca30DSZmSjeusvvThu8GNUT33GrCwAAE9Rw From: "Rainer Gerhards" To: "Chris Lonvick" , "Miao Fuyou" X-OriginalArrivalTime: 04 Aug 2006 14:16:40.0142 (UTC) FILETIME=[9A98BEE0:01C6B7D0] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: syslog@ietf.org, Tom Petch X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Although I was a big advocate of byte-counting, I now prefer *just* octet stuffing (LF) for the sake of compatibility with existing technology. Rainer=20 > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Friday, August 04, 2006 8:14 AM > To: Miao Fuyou > Cc: Rainer Gerhards; 'Tom Petch'; syslog@ietf.org > Subject: RE: [Syslog] delineated datagrams >=20 > Hi, >=20 > I'd like to get this resolved and put into the next version=20 > of the draft. >=20 > Many protocols use byte-counting for framing. > Many protocols use a specific character as a delimiter. > Do we need both? >=20 > I think that I've seen notes from Rainer, Tom Petch, and Andrew Ross=20 > saying that we should only use a special character for both=20 > simplicity of=20 > design and for interoperability with current syslog/tls=20 > implementations. >=20 > Are there other opinions on this? Please speak up now. >=20 > Thanks, > Chris >=20 >=20 > On Mon, 24 Jul 2006, Miao Fuyou wrote: >=20 > > > > Hi, Rainer, > > > > Interop is a compelling reason for protocol design, so I=20 > tend to agree with > > you that it is a feature nice to have. I am wondering=20 > whether we should > > define procedures for frame delineating processing in=20 > syslog-tls draft > > because we have both octect-counter and LF in a record. > > > > Miao > > > >> -----Original Message----- > >> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > >> Sent: Friday, July 21, 2006 6:16 PM > >> To: Miao Fuyou; Tom Petch; syslog@ietf.org > >> Subject: RE: [Syslog] delineated > >> datagramswasdraft-ietf-syslog-transport-tls-01.txt > >> > >> Miao, > >> > >> I agree with your comments. However, using the LF as a record > >> delimited would still allow us to interop with existing > >> syslog/tls implementations. This is my major point. I think > >> it is worth it. > >> > >> Rainer > >> > >>> -----Original Message----- > >>> From: Miao Fuyou [mailto:miaofy@huawei.com] > >>> Sent: Friday, July 21, 2006 12:00 PM > >>> To: 'Tom Petch'; syslog@ietf.org > >>> Subject: RE: [Syslog] delineated > >>> datagramswasdraft-ietf-syslog-transport-tls-01.txt > >>> > >>> > >>> TLS uses SHA-1 or MD5 in ciphersuite for message integrity > >>> verification. If bytes lost happens during transferring, > >> the message > >>> will be dropped by TLS. > >>> That is also the cause that we need a security mechanism > >> for Syslog. > >>> > >>> As for error of encoding/decoding, I believe if an=20 > application does > >>> encoding/decoding in a wrong way, you must not expect it do > >> it right > >>> with other mechanism, such as LF. > >>> > >>> Redundancy to improve robustness is good idea, but I don't > >> think it > >>> applies to this case. > >>> > >>>> -----Original Message----- > >>>> From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > >>>> Sent: Tuesday, June 20, 2006 8:43 PM > >>>> To: syslog@ietf.org > >>>> Subject: Re: [Syslog] delineated datagrams > >>>> wasdraft-ietf-syslog-transport-tls-01.txt > >>>> > >>>> I wonder if others share my concern about the lack of > >> robustness in > >>>> the way in which datagrams are delineated in the stream > >> protocol (a > >>>> TCP rather than a TLS issue). > >>>> > >>>> The system works as long as > >>>> - the frame length is encoded perfectly > >>>> - the frame length is decoded perfectly > >>>> - no bytes are inserted or removed in error which is > >> doubtless true > >>>> in some networks, but I would prefer not to > >>> rely on it. > >>>> > >>>> So, when an error occurs, can the Collector/Relay detect it? > >>>> Can the Collector/Relay recover synch? If not, what does the > >>>> Collector/Relay do? > >>>> > >>>> There is very little redundancy in the definition of > >> frame length, > >>>> and syslog messages have very little structure to help the > >>>> application, so I think that this is an issue we should address. > >>>> > >>>> Tom Petch > >>>> > >>>> ----- Original Message ----- > >>>> From: "David B Harrington" > >>>> To: > >>>> Sent: Tuesday, May 09, 2006 4:26 PM > >>>> Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > >>>> > >>>> > >>>> Hi, > >>>> > >>>> A new revision of the syslog/TLS draft is available. > >>>> > >>> > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > >>>> .txt > >>>> > >>>> We need reviewers. > >>>> Can we get > >>>> 1) a person to check the grammar? > >>>> 2) a person to check the syslog technical parts? > >>>> 3) a person to check compatibility with the other WG documents? > >>>> 4) a person to check the TLS technical parts? > >>>> > >>>> We also need general reviews of the document by multiple people. > >>>> > >>>> Thanks, > >>>> David Harrington > >>>> co-chair, Syslog WG > >>>> ietfdbh@comcast.net > >>>> > >>>> > >>>> _______________________________________________ > >>>> Syslog mailing list > >>>> Syslog@lists.ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/syslog > >>>> > >>>> > >>>> _______________________________________________ > >>>> Syslog mailing list > >>>> Syslog@lists.ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/syslog > >>>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >>> > >> > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 04 14:00:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93yb-0007T1-0X; Fri, 04 Aug 2006 14:00:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93ya-0007RP-8u for syslog@ietf.org; Fri, 04 Aug 2006 14:00:48 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G93yZ-0007tB-RF for syslog@ietf.org; Fri, 04 Aug 2006 14:00:48 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc14) with SMTP id <20060804180046b14005b976e>; Fri, 4 Aug 2006 18:00:47 +0000 From: "David Harrington" To: "'Chris Lonvick'" , "'Miao Fuyou'" Subject: RE: [Syslog] delineated datagrams Date: Fri, 4 Aug 2006 13:59:15 -0400 Message-ID: <049a01c6b7ef$b42a36d0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: Aca30D64z9lgatT2RsuI7h3+YzyK5QAE38rw X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: syslog@ietf.org, 'Tom Petch' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, As you probably know by now, I like to see design reuse across IETF NM solutions, especially across SNMP, syslog, ipfix, and netconf where feasible. As all the IETF NM protocols move toward similar secure transport solutions, including moving from datagrams to streams, it would be a good thing to use consistent aproaches to framing. Here is what is happening in the other IETF NM protocols: SNMPv1/v2c/v3 uses octet-counting within its BER encoded messages. For SNMP over TCP (RFC3430): It is possible that the underlying TCP implementation delivers byte sequences that do not align with SNMP message boundaries. A receiving SNMP engine MUST therefore use the length field in the BER-encoded SNMP message to separate multiple requests sent over a single TCP connection (framing). An SNMP engine which looses framing (for example due to ASN.1 parse errors) SHOULD close the TCP connection. SNMP over SSH (ISMS) does not specify how to delineate datagrams, beyond the BER octet-counting. (As editor of the SNMP/SSH draft, I will probably copy the text from RFC3430.) IPFIX uses octet-counting. See http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-22.txt section 3.1. The NETCONF protocol uses an RPC-based communication model. From http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt: NETCONF peers use and elements to provide transport protocol-independent framing of NETCONF requests and responses. There is ongoing discussion about the framing in the netconf notification protocol, and the possibility of interleaving notifications and request/responses within a session or channel. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, August 04, 2006 10:14 AM > To: Miao Fuyou > Cc: syslog@ietf.org; 'Tom Petch' > Subject: RE: [Syslog] delineated datagrams > > Hi, > > I'd like to get this resolved and put into the next version > of the draft. > > Many protocols use byte-counting for framing. > Many protocols use a specific character as a delimiter. > Do we need both? > > I think that I've seen notes from Rainer, Tom Petch, and Andrew Ross > saying that we should only use a special character for both > simplicity of > design and for interoperability with current syslog/tls > implementations. > > Are there other opinions on this? Please speak up now. > > Thanks, > Chris > > > On Mon, 24 Jul 2006, Miao Fuyou wrote: > > > > > Hi, Rainer, > > > > Interop is a compelling reason for protocol design, so I > tend to agree with > > you that it is a feature nice to have. I am wondering > whether we should > > define procedures for frame delineating processing in > syslog-tls draft > > because we have both octect-counter and LF in a record. > > > > Miao > > > >> -----Original Message----- > >> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > >> Sent: Friday, July 21, 2006 6:16 PM > >> To: Miao Fuyou; Tom Petch; syslog@ietf.org > >> Subject: RE: [Syslog] delineated > >> datagramswasdraft-ietf-syslog-transport-tls-01.txt > >> > >> Miao, > >> > >> I agree with your comments. However, using the LF as a record > >> delimited would still allow us to interop with existing > >> syslog/tls implementations. This is my major point. I think > >> it is worth it. > >> > >> Rainer > >> > >>> -----Original Message----- > >>> From: Miao Fuyou [mailto:miaofy@huawei.com] > >>> Sent: Friday, July 21, 2006 12:00 PM > >>> To: 'Tom Petch'; syslog@ietf.org > >>> Subject: RE: [Syslog] delineated > >>> datagramswasdraft-ietf-syslog-transport-tls-01.txt > >>> > >>> > >>> TLS uses SHA-1 or MD5 in ciphersuite for message integrity > >>> verification. If bytes lost happens during transferring, > >> the message > >>> will be dropped by TLS. > >>> That is also the cause that we need a security mechanism > >> for Syslog. > >>> > >>> As for error of encoding/decoding, I believe if an > application does > >>> encoding/decoding in a wrong way, you must not expect it do > >> it right > >>> with other mechanism, such as LF. > >>> > >>> Redundancy to improve robustness is good idea, but I don't > >> think it > >>> applies to this case. > >>> > >>>> -----Original Message----- > >>>> From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > >>>> Sent: Tuesday, June 20, 2006 8:43 PM > >>>> To: syslog@ietf.org > >>>> Subject: Re: [Syslog] delineated datagrams > >>>> wasdraft-ietf-syslog-transport-tls-01.txt > >>>> > >>>> I wonder if others share my concern about the lack of > >> robustness in > >>>> the way in which datagrams are delineated in the stream > >> protocol (a > >>>> TCP rather than a TLS issue). > >>>> > >>>> The system works as long as > >>>> - the frame length is encoded perfectly > >>>> - the frame length is decoded perfectly > >>>> - no bytes are inserted or removed in error which is > >> doubtless true > >>>> in some networks, but I would prefer not to > >>> rely on it. > >>>> > >>>> So, when an error occurs, can the Collector/Relay detect it? > >>>> Can the Collector/Relay recover synch? If not, what does the > >>>> Collector/Relay do? > >>>> > >>>> There is very little redundancy in the definition of > >> frame length, > >>>> and syslog messages have very little structure to help the > >>>> application, so I think that this is an issue we should address. > >>>> > >>>> Tom Petch > >>>> > >>>> ----- Original Message ----- > >>>> From: "David B Harrington" > >>>> To: > >>>> Sent: Tuesday, May 09, 2006 4:26 PM > >>>> Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > >>>> > >>>> > >>>> Hi, > >>>> > >>>> A new revision of the syslog/TLS draft is available. > >>>> > >>> > >> > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > >>>> .txt > >>>> > >>>> We need reviewers. > >>>> Can we get > >>>> 1) a person to check the grammar? > >>>> 2) a person to check the syslog technical parts? > >>>> 3) a person to check compatibility with the other WG documents? > >>>> 4) a person to check the TLS technical parts? > >>>> > >>>> We also need general reviews of the document by multiple people. > >>>> > >>>> Thanks, > >>>> David Harrington > >>>> co-chair, Syslog WG > >>>> ietfdbh@comcast.net > >>>> > >>>> > >>>> _______________________________________________ > >>>> Syslog mailing list > >>>> Syslog@lists.ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/syslog > >>>> > >>>> > >>>> _______________________________________________ > >>>> Syslog mailing list > >>>> Syslog@lists.ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/syslog > >>>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >>> > >> > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Aug 06 07:20:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ggW-0008Dl-7T; Sun, 06 Aug 2006 07:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ggV-0008Cr-HL for syslog@ietf.org; Sun, 06 Aug 2006 07:20:43 -0400 Received: from balabit.hu ([82.141.167.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9ggT-0001Xj-Qi for syslog@ietf.org; Sun, 06 Aug 2006 07:20:43 -0400 Subject: RE: [Syslog] delineated datagrams From: Balazs Scheidler To: David Harrington In-Reply-To: <049a01c6b7ef$b42a36d0$0400a8c0@china.huawei.com> References: <049a01c6b7ef$b42a36d0$0400a8c0@china.huawei.com> Content-Type: text/plain Date: Sun, 06 Aug 2006 13:20:38 +0200 Message-Id: <1154863238.5782.20.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: syslog@ietf.org, 'Tom Petch' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Fri, 2006-08-04 at 13:59 -0400, David Harrington wrote: > Hi, > > As you probably know by now, I like to see design reuse across IETF NM > solutions, especially across SNMP, syslog, ipfix, and netconf where > feasible. > > As all the IETF NM protocols move toward similar secure transport > solutions, including moving from datagrams to streams, it would be a > good thing to use consistent aproaches to framing. > > Here is what is happening in the other IETF NM protocols: > > SNMPv1/v2c/v3 uses octet-counting within its BER encoded messages. > For SNMP over TCP (RFC3430): > It is possible that the underlying TCP implementation delivers byte > sequences that do not align with SNMP message boundaries. A > receiving SNMP engine MUST therefore use the length field in the > BER-encoded SNMP message to separate multiple requests sent over a > single TCP connection (framing). An SNMP engine which looses > framing > (for example due to ASN.1 parse errors) SHOULD close the TCP > connection. > > SNMP over SSH (ISMS) does not specify how to delineate datagrams, > beyond the BER octet-counting. > (As editor of the SNMP/SSH draft, I will probably copy the text from > RFC3430.) > > IPFIX uses octet-counting. See > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-22.txt > section 3.1. > > The NETCONF protocol uses an RPC-based communication model. > From > http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt: > NETCONF peers use and elements to provide > transport > protocol-independent framing of NETCONF requests and responses. > There is ongoing discussion about the framing in the netconf > notification protocol, and the possibility of interleaving > notifications and request/responses within a session or channel. I see a significant difference between syslog and and SNMP, SNMP is binary and has an internal structure with no appearent record terminator. IPFIX is again different to syslog, it has a well defined binary structure, adding a "byte counter" is a natural extension of the protocol. Netconf as I see from your description started out with a stream based transport from the first place (and by browsing the RFC quickly) In this sence Netconf has the most similarities to syslog, it has a text-based internal structure (XML) and no byte-counter based framing, the closing XML tag finishes the transaction. Syslog also has a text based internal structure (one syslog entry), terminated via NL. Adding a byte counter feels somewhat alien. I agreed with Rainer about byte-counters when he proposed that, I did it for the sake of moving forward. Dropping the byte counter idea and adding simple extensions to the message format (trying to stay compatible as much as possible) could buy us very easy migration to the new protocol. In fact this would mean that currently deployed existing syslog/tls implementations would be compliant. I read through the BEEP based syslog protocols and I liked some of the features it'd provide (see the mailing list archives), however I don't like that syslog/COOKED is not simply a syslog transport, but a format spec as well. After specifying syslog-transport-tls we might continue working on a BEEP based transport but strictly adhering to the current syslog message model (e.g. skipping the XML message representation which has no benefits over SD-IDs but is a lot more verbose). -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Aug 06 23:37:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9vvy-0004e8-Uj; Sun, 06 Aug 2006 23:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9vvx-0004dz-2o for syslog@ietf.org; Sun, 06 Aug 2006 23:37:41 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9vvw-0006GW-Ac for syslog@ietf.org; Sun, 06 Aug 2006 23:37:41 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 13121222425 for ; Sun, 6 Aug 2006 20:45:41 -0700 (PDT) To: syslog@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Sun, 06 Aug 2006 20:37:39 -0700 From: Eric Rescorla Message-Id: <20060807034541.13121222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: Subject: [Syslog] Notes on TLS transport X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I just finished reading: draft-ietf-syslog-transport-tls-02.txt draft-petch-gerhards-syslog-transport-dtls-00.txt Comments below. It seems like it would be nice to have a consistent approach to the generic question of who is the TLS client and who is the TLS server and client. The TLS draft specifies that the receiver is the TLS server but the DTLS draft can work either way. As I understand draft-petch-gerhards-syslog-transport-dtls, the argument for allowing the sender to be the server is: (a) authentication for the sender is what's important. (b) concerns about performance on the syslog device/sender I don't think (b) turns into an argument for reversing the client/server roles. The expensive step is the RSA signature or decryption and that needs to be performed by the authenticating party. Moreover, it's really not *that* expensive. I would expect it to take a second or so on all but the lowest power devices--though there used to be reports that the Dragonball processors in palms had particularly bad bignum performance. My suggestion would be to stick with standard TLS practice here and have the sender be the server. Having the server have a certificate isn't that big an obstacle, especially if it's self-signed. draft-ietf-syslog-transport-tls-02 ---------------------------------- S 3.1: report errors. Then, there is an ongoing layered record protocol that handles encryption, compression, and reassembly for the I would say, "encryption and message integrity" rather than "encryption, compression, and reassembly" S 3.2: Confidentiality is provided using symmetric cryptography for data encryption. TLS supports both stream cipher and block cipher. The key for encryption is derived from a secret established by the handshake protocol. The secret is kept private even if there is an eavesdropper in the middle. This only obtains if at least one sid ie authenticated. Integrity is provided by using HMAC [6] (computed with a secure hash function) to check the integrity of a message. Modification without the appropriate key is detectable. I would just say "a Message Authentication Code (MAC)". Future versions of TLS may not use HMAC. Authentication is provided by a handshake protocol. The peer's identity is authenticated using a certificate and signature, based on asymmetric cryptography. TLS server auth is often done by proving possession of the private exponent by doing an RSA decryption rather than a signature. TLS client auth is typically with a signature. S 5.2: TLS uses certificate [5] to authenticate the peers. When a sender authenticates a receiver it MUST validate the certificate. It SHOULD check the common name(CN) of the certificate against the host name of the receiver if it has knowledge of a common name/host name mapping. If the common name does not match the host name, the sender SHOULD send an "access_denied" error alert using the TLS alert protocol to terminate the handshake, and then it SHOULD close the connection. Do you want to cite RFC 2818 here? Also, some clarity about whether the sender is expected to validate the receiver's cert would be helpful. Similarly, is sender auth required? another active session when a new session is requested, in order to save the expense of another TLS handshake. The security parameters of the resumed session are reused for the requested session. The certificate MUST be checked when resuming a session. If the resumed session and current session use different certificates, resumption MUST not happen. The security parameters SHOULD be checked against security requirement of requested session to make sure the resumed session provides proper security. Resumed sessions do not involve a certificate exchange, so there's no way the certificate could be different. Similarly, the security parameters are always the same. S 5.3: All Syslog messages MUST be sent as TLS "application data". There MAY be multiple Syslog message in the same TLS record. The application data is defined with the following ABNF [3] expression: TLS's abstraction is as a stream, so this isn't really the business of htis spec. S 6.1: TLS authentication and the establishment of secrets is based on certificates and asymmetric cryptography. This makes TLS transport much more expensive than UDP transport. An attacker may initialize many TLS connections to a receiver as a denial of service attack. Since a receiver may act upon received data, for Syslog over TLS, the receiver SHOULD authenticate the sender to ensure that information received is authentic. TLS is more expensive than non-TLS. The issue of TCP vs. UDP is kind of orthogonal. S 6.2: When a certificate is issued to a class of device or application, the certificate may be shared by multiple hosts. Multiple hosts know the private key of the certificate. When the certificate in one host is compromised, then the certificate for all hosts that share the certificate is compromised. Any communication that is bound to the certificate is at risk. It depends what you mean "at risk". Say you have two clients who share the same cert. If client A is compromised, then the attacker can impersonate client B, but it can't view data on or tamper with a channel that client B actually established. The situation is a bit more complicated for servers and depends on which cipher suite you're using (PFS of not). S 6.3: Different applications in the same host may have different security levels (e.g., the kernel may have higher a security level than a document editor application). If a requested session resumes an existing session, then the requesting application can decrypt the Syslog messages of the resumed session using same cipher parameters as defined for the resumed session. When a session is being resumed from an application with a different security level, care must be taken to avoid disclosing sensitive data to an unauthorized application. A sensitive session must not be resumable. This isn't clear to me. It depends a lot on how the keying material is handled. You need to explain the threat model a lot more clearly here.. draft-petch-gerhards-syslog-transport-dtls-00 --------------------------------------------- S 1.4: connections - which may not be suitable for the application; DTLS offers the option of TLS over UDP, adding reliability to UDP but without all the additional features that TCP brings. As such, it offers an attractive security option for UDP-based applications. Reliability is added *only* for the handshake, not data transport. S 1.6: Most applications which now run over TLS were previously running over TCP and as such already had an application level dialog. In order to invoke TLS, these applications could then change their start command (eg STARTTLS) or, having established a TCP connection, invoke TLS (eg AUTH) to make the connection secure. I'm not sure I agree with this characterization. E.g., neither HTTP [2818] nor SIP [3261] behaves this way. You just have a separate port. S 2.1: A consequence of this mapping, of DTLS client to syslog server, is that where certificates are used for server authentication, then the syslog server is the one that has to verify the syslog client's certificates (something that it is likely to have the greater resources to do). The syslog client must have a certificate; the syslog server certificate remains optional. Cert verification is actually fast. It's being the authenticating party that's slow. S 2.8: This probably isn't necessary. -Ekr _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 07 00:17:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9wY2-0000kZ-6o; Mon, 07 Aug 2006 00:17:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9wY0-0000kR-Hb for syslog@ietf.org; Mon, 07 Aug 2006 00:17:00 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9wXz-0004ZP-8s for syslog@ietf.org; Mon, 07 Aug 2006 00:17:00 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 5A5BE222425; Sun, 6 Aug 2006 21:24:57 -0700 (PDT) To: Miao Fuyou Subject: Re: [Syslog] Notes on TLS transport In-reply-to: Your message of "Mon, 07 Aug 2006 11:58:58 +0800." <007d01c6b9d5$cfef31d0$8c0c6f0a@china.huawei.com> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Sun, 06 Aug 2006 21:16:56 -0700 From: Eric Rescorla Message-Id: <20060807042457.5A5BE222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Miao Fuyou wrote: > > My suggestion would be to stick with standard TLS practice > > here and have the sender be the server. > > This sentence confused me, is the sender should be "receiver"? Uh, yeah. Doh. -Ekr _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 07 00:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9woM-0001Gu-DK; Mon, 07 Aug 2006 00:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9woL-0001Gp-SV for syslog@ietf.org; Mon, 07 Aug 2006 00:33:53 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9woE-000075-3C for syslog@ietf.org; Mon, 07 Aug 2006 00:33:53 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3M00AZN0J04P@szxga01-in.huawei.com> for syslog@ietf.org; Mon, 07 Aug 2006 12:01:49 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3M00IR60J04R@szxga01-in.huawei.com> for syslog@ietf.org; Mon, 07 Aug 2006 12:01:48 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3M00ID10XY2M@szxml04-in.huawei.com> for syslog@ietf.org; Mon, 07 Aug 2006 12:10:50 +0800 (CST) Date: Mon, 07 Aug 2006 11:58:58 +0800 From: Miao Fuyou Subject: RE: [Syslog] Notes on TLS transport In-reply-to: <20060807034541.13121222425@laser.networkresonance.com> To: 'Eric Rescorla' , syslog@ietf.org Message-id: <007d01c6b9d5$cfef31d0$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aca50utioaRZSX13SC6e3n4933UtuwAAqTug X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > My suggestion would be to stick with standard TLS practice > here and have the sender be the server. This sentence confused me, is the sender should be "receiver"? Thanks! _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 07 08:45:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA4Tz-0003iO-Me; Mon, 07 Aug 2006 08:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA4Ty-0003h3-32 for syslog@ietf.org; Mon, 07 Aug 2006 08:45:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA1j7-0003Nn-Nn for syslog@ietf.org; Mon, 07 Aug 2006 05:48:49 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GA1fR-0005n5-A2 for syslog@ietf.org; Mon, 07 Aug 2006 05:45:02 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3M00JDUGIMXD@szxga03-in.huawei.com> for syslog@ietf.org; Mon, 07 Aug 2006 17:47:11 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3M00AR8GIMIB@szxga03-in.huawei.com> for syslog@ietf.org; Mon, 07 Aug 2006 17:47:10 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3M00K23GLA2W@szxml04-in.huawei.com> for syslog@ietf.org; Mon, 07 Aug 2006 17:48:50 +0800 (CST) Date: Mon, 07 Aug 2006 17:36:56 +0800 From: Miao Fuyou Subject: RE: [Syslog] Notes on TLS transport In-reply-to: <20060807034541.13121222425@laser.networkresonance.com> To: 'Eric Rescorla' , syslog@ietf.org Message-id: <008c01c6ba05$069ea1a0$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aca50utioaRZSX13SC6e3n4933UtuwAKqUuA X-Spam-Score: -2.3 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Response inline, thanks! > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Monday, August 07, 2006 11:38 AM > To: syslog@ietf.org > Subject: [Syslog] Notes on TLS transport > > S 5.2: > TLS uses certificate [5] to authenticate the peers. When a sender > authenticates a receiver it MUST validate the certificate. > It SHOULD > check the common name(CN) of the certificate against the > host name of > the receiver if it has knowledge of a common name/host > name mapping. > If the common name does not match the host name, the sender SHOULD > send an "access_denied" error alert using the TLS alert protocol to > terminate the handshake, and then it SHOULD close the connection. > > Do you want to cite RFC 2818 here? > > Also, some clarity about whether the sender is expected to validate > the receiver's cert would be helpful. Similarly, is sender auth > required? A very brief clarification about server authentication is in section 6.1 (last sentence). Sender authentication is preferrable when DoS is a concern, an unauthenticated sender may send spurios spurios Syslog messages to receiver. But, the threat model in this document explicitly excludes denial of service. > > S 6.2: > > When a certificate is issued to a class of device or > application, the > certificate may be shared by multiple hosts. Multiple > hosts know the > private key of the certificate. When the certificate in one host is > compromised, then the certificate for all hosts that share the > certificate is compromised. Any communication that is bound to the > certificate is at risk. > > It depends what you mean "at risk". Say you have two clients who > share the same cert. If client A is compromised, then the attacker > can impersonate client B, but it can't view data on or tamper > with a channel that client B actually established. The situation > is a bit more complicated for servers and depends on which cipher > suite you're using (PFS of not). > Thanks, very good clarification. I will update the text. BTW, generic certificate are only issued to senders, server would not be issued a generic certificate. > > S 6.3: > Different applications in the same host may have different security > levels (e.g., the kernel may have higher a security level than a > document editor application). If a requested session resumes an > existing session, then the requesting application can decrypt the > Syslog messages of the resumed session using same cipher parameters > as defined for the resumed session. When a session is being resumed > from an application with a different security level, care must be > taken to avoid disclosing sensitive data to an unauthorized > application. A sensitive session must not be resumable. > > This isn't clear to me. It depends a lot on how the keying material > is handled. You need to explain the threat model a lot more > clearly here.. > Yes. there is problem for this text. I checked 4346bits, ClientHello.Random and ServerHello.Random is used in 4346bis to make encryption key and MAC secrets different for resumed sessions. So, I may drop this paragraphy from this document. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 07 21:26:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAGMI-0006yB-FC; Mon, 07 Aug 2006 21:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAGMH-0006y6-1q for syslog@ietf.org; Mon, 07 Aug 2006 21:26:13 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAGMF-0005I0-A9 for syslog@ietf.org; Mon, 07 Aug 2006 21:26:13 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3N000N9O3XHQ@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 08 Aug 2006 09:28:46 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3N00FKEO3XEF@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 08 Aug 2006 09:28:45 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3N00263O6M2T@szxml04-in.huawei.com> for syslog@ietf.org; Tue, 08 Aug 2006 09:30:26 +0800 (CST) Date: Tue, 08 Aug 2006 09:18:32 +0800 From: Miao Fuyou Subject: RE: [Syslog] Notes on TLS transport In-reply-to: <20060807034541.13121222425@laser.networkresonance.com> To: syslog@ietf.org Message-id: <00f901c6ba88$911440a0$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aca50utioaRZSX13SC6e3n4933UtuwAs/0sg X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > > S 5.3: > All Syslog messages MUST be sent as TLS "application data". There > MAY be multiple Syslog message in the same TLS record. The > application data is defined with the following ABNF [3] expression: > > TLS's abstraction is as a stream, so this isn't really the business > of htis spec. > I agree to Eric's opinion. If syslog procotol has a mechanism to delimit message, we will never need to address same issue across different documents: syslog-tls, syslog-ssh, or syslog-tcp etc (perhaps with different mechanisms). _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 07 21:39:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAGYx-0005Ao-NI; Mon, 07 Aug 2006 21:39:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAGYw-00057L-Ha for syslog@ietf.org; Mon, 07 Aug 2006 21:39:18 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAGYv-0006IM-88 for syslog@ietf.org; Mon, 07 Aug 2006 21:39:18 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id ED06D222425; Mon, 7 Aug 2006 18:47:16 -0700 (PDT) To: Miao Fuyou Subject: Re: [Syslog] Notes on TLS transport In-reply-to: Your message of "Tue, 08 Aug 2006 09:18:32 +0800." <00f901c6ba88$911440a0$8c0c6f0a@china.huawei.com> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Mon, 07 Aug 2006 18:39:15 -0700 From: Eric Rescorla Message-Id: <20060808014716.ED06D222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Miao Fuyou wrote: > > > > > S 5.3: > > All Syslog messages MUST be sent as TLS "application data". There > > MAY be multiple Syslog message in the same TLS record. The > > application data is defined with the following ABNF [3] expression: > > > > TLS's abstraction is as a stream, so this isn't really the business > > of htis spec. > > > > I agree to Eric's opinion. If syslog procotol has a mechanism to delimit > message, we will never need to address same issue across different > documents: syslog-tls, syslog-ssh, or syslog-tcp etc (perhaps with different > mechanisms). Note, though, that you do need a mapping from syslog to DTLS because it's packetized. Same as you need a mapping from syslog to UDP. -Ekr _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 08 15:46:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXWu-00009O-BD; Tue, 08 Aug 2006 15:46:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXWt-00009C-95 for syslog@ietf.org; Tue, 08 Aug 2006 15:46:19 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAXWs-0001SP-Re for syslog@ietf.org; Tue, 08 Aug 2006 15:46:19 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 08 Aug 2006 13:46:18 -0600 Message-Id: <44D89525.37FF.0081.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Tue, 08 Aug 2006 13:44:05 -0600 From: "John Calcote" To: "Chris Lonvick" , "Miao Fuyou" Subject: RE: [Syslog] delineated datagrams References: <00f801c6af25$a5423c30$8c0c6f0a@china.huawei.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: syslog@ietf.org, 'Tom Petch' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris, While I agree with you in principle that both forms of delineation are nice to have for interop, I _wish_ we could get rid of LF - that so limits the sort of data that can be sent in the message. My two cents... John >>> Chris Lonvick 8/4/2006 8:13 AM >>> Hi, I'd like to get this resolved and put into the next version of the draft. Many protocols use byte-counting for framing. Many protocols use a specific character as a delimiter. Do we need both? I think that I've seen notes from Rainer, Tom Petch, and Andrew Ross saying that we should only use a special character for both simplicity of design and for interoperability with current syslog/tls implementations. Are there other opinions on this? Please speak up now. Thanks, Chris On Mon, 24 Jul 2006, Miao Fuyou wrote: > > Hi, Rainer, > > Interop is a compelling reason for protocol design, so I tend to agree with > you that it is a feature nice to have. I am wondering whether we should > define procedures for frame delineating processing in syslog-tls draft > because we have both octect-counter and LF in a record. > > Miao > >> -----Original Message----- >> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] >> Sent: Friday, July 21, 2006 6:16 PM >> To: Miao Fuyou; Tom Petch; syslog@ietf.org >> Subject: RE: [Syslog] delineated >> datagramswasdraft-ietf-syslog-transport-tls-01.txt >> >> Miao, >> >> I agree with your comments. However, using the LF as a record >> delimited would still allow us to interop with existing >> syslog/tls implementations. This is my major point. I think >> it is worth it. >> >> Rainer >> >>> -----Original Message----- >>> From: Miao Fuyou [mailto:miaofy@huawei.com] >>> Sent: Friday, July 21, 2006 12:00 PM >>> To: 'Tom Petch'; syslog@ietf.org >>> Subject: RE: [Syslog] delineated >>> datagramswasdraft-ietf-syslog-transport-tls-01.txt >>> >>> >>> TLS uses SHA-1 or MD5 in ciphersuite for message integrity >>> verification. If bytes lost happens during transferring, >> the message >>> will be dropped by TLS. >>> That is also the cause that we need a security mechanism >> for Syslog. >>> >>> As for error of encoding/decoding, I believe if an application does >>> encoding/decoding in a wrong way, you must not expect it do >> it right >>> with other mechanism, such as LF. >>> >>> Redundancy to improve robustness is good idea, but I don't >> think it >>> applies to this case. >>> >>>> -----Original Message----- >>>> From: Tom Petch [mailto:nwnetworks@dial.pipex.com] >>>> Sent: Tuesday, June 20, 2006 8:43 PM >>>> To: syslog@ietf.org >>>> Subject: Re: [Syslog] delineated datagrams >>>> wasdraft-ietf-syslog-transport-tls-01.txt >>>> >>>> I wonder if others share my concern about the lack of >> robustness in >>>> the way in which datagrams are delineated in the stream >> protocol (a >>>> TCP rather than a TLS issue). >>>> >>>> The system works as long as >>>> - the frame length is encoded perfectly >>>> - the frame length is decoded perfectly >>>> - no bytes are inserted or removed in error which is >> doubtless true >>>> in some networks, but I would prefer not to >>> rely on it. >>>> >>>> So, when an error occurs, can the Collector/Relay detect it? >>>> Can the Collector/Relay recover synch? If not, what does the >>>> Collector/Relay do? >>>> >>>> There is very little redundancy in the definition of >> frame length, >>>> and syslog messages have very little structure to help the >>>> application, so I think that this is an issue we should address. >>>> >>>> Tom Petch >>>> >>>> ----- Original Message ----- >>>> From: "David B Harrington" >>>> To: >>>> Sent: Tuesday, May 09, 2006 4:26 PM >>>> Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt >>>> >>>> >>>> Hi, >>>> >>>> A new revision of the syslog/TLS draft is available. >>>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 >>>> .txt >>>> >>>> We need reviewers. >>>> Can we get >>>> 1) a person to check the grammar? >>>> 2) a person to check the syslog technical parts? >>>> 3) a person to check compatibility with the other WG documents? >>>> 4) a person to check the TLS technical parts? >>>> >>>> We also need general reviews of the document by multiple people. >>>> >>>> Thanks, >>>> David Harrington >>>> co-chair, Syslog WG >>>> ietfdbh@comcast.net >>>> >>>> >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/syslog >>>> >>>> >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/syslog >>>> >>> >>> >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >>> >> > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 09 03:47:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAimG-0002UB-4H; Wed, 09 Aug 2006 03:46:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAimF-0002U5-9e for syslog@ietf.org; Wed, 09 Aug 2006 03:46:55 -0400 Received: from balabit.hu ([82.141.167.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAimC-0006ed-Su for syslog@ietf.org; Wed, 09 Aug 2006 03:46:55 -0400 Subject: RE: [Syslog] delineated datagrams From: Balazs Scheidler To: John Calcote In-Reply-To: <44D89525.37FF.0081.0@novell.com> References: <00f801c6af25$a5423c30$8c0c6f0a@china.huawei.com> <44D89525.37FF.0081.0@novell.com> Content-Type: text/plain Date: Wed, 09 Aug 2006 09:46:50 +0200 Message-Id: <1155109610.6312.10.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: syslog@ietf.org, 'Tom Petch' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Tue, 2006-08-08 at 13:44 -0600, John Calcote wrote: > Chris, > > While I agree with you in principle that both forms of delineation are > nice to have for interop, I _wish_ we could get rid of LF - that so > limits the sort of data that can be sent in the message. My two > cents... The message you send are _already_ limited as most syslog daemons replace "\n" character with something else as it would clobber the message file when it is written to disk. In fact leaving the CR LF characters in the message could be a security risk as that way messages can be "hidden", for instance if a daemon writes the following message: This is a foo message, bar= Then the value for "bar" might contain CR, putting the cursor to the beginning of the line on a usual VT100 compatible terminal, and the rest of can pose as a regular log message, overwriting the previous one on the screen. Of course this can be worked around by using some form of escaping while data is written to files, but again the LF character does not remain intact. syslog-ng for instance replaces CR and LF characters in the message with a space as it comes in. I rarely heard any complaints about this behaviour. And another fact is syslog/RAW also uses LF line terminators when multiple messages are delivered in a single BEEP frame. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 09 15:21:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtcM-0005D1-BG; Wed, 09 Aug 2006 15:21:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAtcK-0005AU-Nt for syslog@ietf.org; Wed, 09 Aug 2006 15:21:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtQN-0006s0-3G for syslog@ietf.org; Wed, 09 Aug 2006 15:09:03 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAtQJ-00019x-Hp for syslog@ietf.org; Wed, 09 Aug 2006 15:09:02 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 09 Aug 2006 13:08:50 -0600 Message-Id: <44D9DDE4.37FF.0081.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Wed, 09 Aug 2006 13:06:44 -0600 From: "John Calcote" To: "Balazs Scheidler" Subject: RE: [Syslog] delineated datagrams References: <00f801c6af25$a5423c30$8c0c6f0a@china.huawei.com> <44D89525.37FF.0081.0@novell.com> <1155109610.6312.10.camel@bzorp.balabit> In-Reply-To: <1155109610.6312.10.camel@bzorp.balabit> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.3 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: syslog@ietf.org, 'Tom Petch' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Bazsi, Thanks. You're right of course. I've been considering using a compressed form of XML for our messages anyway because I don't like the chatty nature of XML in a logging protocol. One compression technique is as simple as removing all of the \r\n\t and space characters, and then removing the closing tag names (eg., becomes ) as parsers don't need the tag name in the close tag anyway. This alone would solve a few problems. John >>> Balazs Scheidler 8/9/2006 1:46 AM >>> On Tue, 2006-08-08 at 13:44 -0600, John Calcote wrote: > Chris, > > While I agree with you in principle that both forms of delineation are > nice to have for interop, I _wish_ we could get rid of LF - that so > limits the sort of data that can be sent in the message. My two > cents... The message you send are _already_ limited as most syslog daemons replace "\n" character with something else as it would clobber the message file when it is written to disk. In fact leaving the CR LF characters in the message could be a security risk as that way messages can be "hidden", for instance if a daemon writes the following message: This is a foo message, bar= Then the value for "bar" might contain CR, putting the cursor to the beginning of the line on a usual VT100 compatible terminal, and the rest of can pose as a regular log message, overwriting the previous one on the screen. Of course this can be worked around by using some form of escaping while data is written to files, but again the LF character does not remain intact. syslog-ng for instance replaces CR and LF characters in the message with a space as it comes in. I rarely heard any complaints about this behaviour. And another fact is syslog/RAW also uses LF line terminators when multiple messages are delivered in a single BEEP frame. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 09 23:29:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB1Ea-0003rg-4s; Wed, 09 Aug 2006 23:29:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB1EY-0003rY-P2 for syslog@ietf.org; Wed, 09 Aug 2006 23:29:22 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB1EX-0002PX-8O for syslog@ietf.org; Wed, 09 Aug 2006 23:29:22 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 7DF9C9C00C; Thu, 10 Aug 2006 05:30:16 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12827-07; Thu, 10 Aug 2006 05:30:12 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id D4B1A9C00B; Thu, 10 Aug 2006 05:30:12 +0200 (CEST) Content-class: urn:content-classes:message Subject: RE: [Syslog] delineated datagrams MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Aug 2006 05:29:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DD8@grfint2.intern.adiscon.com> In-Reply-To: <1155109610.6312.10.camel@bzorp.balabit> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] delineated datagrams Thread-Index: Aca7h9w1dyaL78pkTzasulAD0jYZSwApQJwg From: "Rainer Gerhards" To: "Balazs Scheidler" , "John Calcote" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: syslog@ietf.org, Tom Petch X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Bazsi, all, I am not really able to follow the thread, but let me put in an important thought. We *must* allow LF inside the message. If we do not do that, it would cause problems with -protocol. This issue has been discussed at length, and there are good reasons for allowing it. So while I vote to use LF for record delineation, I also say that this means LF MUST be escaped if present in the actual message (transfer encoding). After being decoded, LF may be present in MSG. Maybe this already has been said ;) Rainer=20 > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20 > Sent: Wednesday, August 09, 2006 1:47 AM > To: John Calcote > Cc: syslog@ietf.org; 'Tom Petch' > Subject: RE: [Syslog] delineated datagrams >=20 > On Tue, 2006-08-08 at 13:44 -0600, John Calcote wrote: > > Chris, > >=20 > > While I agree with you in principle that both forms of=20 > delineation are > > nice to have for interop, I _wish_ we could get rid of LF - that so > > limits the sort of data that can be sent in the message. My two > > cents... >=20 > The message you send are _already_ limited as most syslog daemons > replace "\n" character with something else as it would clobber the > message file when it is written to disk.=20 >=20 > In fact leaving the CR LF characters in the message could be=20 > a security > risk as that way messages can be "hidden", for instance if a daemon > writes the following message: >=20 > This is a foo message, bar=3D >=20 > Then the value for "bar" might contain CR, putting the cursor to the > beginning of the line on a usual VT100 compatible terminal,=20 > and the rest > of can pose as a regular log message, overwriting the previous one on > the screen. >=20 > Of course this can be worked around by using some form of=20 > escaping while > data is written to files, but again the LF character does not remain > intact. >=20 > syslog-ng for instance replaces CR and LF characters in the=20 > message with > a space as it comes in. I rarely heard any complaints about this > behaviour. And another fact is syslog/RAW also uses LF line=20 > terminators > when multiple messages are delivered in a single BEEP frame. >=20 > --=20 > Bazsi >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Aug 10 04:30:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB5w6-0002l9-EZ; Thu, 10 Aug 2006 04:30:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB5w5-0002l4-UR for syslog@ietf.org; Thu, 10 Aug 2006 04:30:37 -0400 Received: from balabit.hu ([82.141.167.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB5w4-0002jT-JS for syslog@ietf.org; Thu, 10 Aug 2006 04:30:37 -0400 Subject: RE: [Syslog] delineated datagrams From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174DD8@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA174DD8@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Thu, 10 Aug 2006 10:30:33 +0200 Message-Id: <1155198633.6525.1.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: syslog@ietf.org, Tom Petch X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Thu, 2006-08-10 at 05:29 +0200, Rainer Gerhards wrote: > Bazsi, all, > > I am not really able to follow the thread, but let me put in an > important thought. > > We *must* allow LF inside the message. If we do not do that, it would > cause problems with -protocol. This issue has been discussed at length, > and there are good reasons for allowing it. So while I vote to use LF > for record delineation, I also say that this means LF MUST be escaped if > present in the actual message (transfer encoding). After being decoded, > LF may be present in MSG. > > Maybe this already has been said ;) This makes sense. What about other control characters? -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Aug 10 13:35:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEQz-0004O7-GA; Thu, 10 Aug 2006 13:35:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBEQy-0004O2-TK for syslog@ietf.org; Thu, 10 Aug 2006 13:35:04 -0400 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBEQv-0007mU-LY for syslog@ietf.org; Thu, 10 Aug 2006 13:35:04 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc11) with SMTP id <20060810173450b1100nrb2ie>; Thu, 10 Aug 2006 17:35:01 +0000 From: "David Harrington" To: Date: Thu, 10 Aug 2006 13:33:15 -0400 Message-ID: <082101c6bca3$165a36e0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xg== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Syslog] timeline X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Chris and I are working on a schedule to help the WG meet its deliverables. We have not yet agreed on all the specific dates because Chris is on (another) vacation, but should have a schedule posted within a few days. Here are two things we need to resolve soon. 1) whether draft-ietf-syslog-transport-tls should use byte-counting, special character, or both, including which special character. We want to finalize this WG decision by August 18. 2) whether draft-ietf-syslog-device-mib represents WG consensus on what needs to be managed in the protocol, udp, tls, and sign documents, and if not, what needs to be changed to represent WG consensus. We want to finalize this WG decision by August 18 as well. The chairs will be starting WGLCs on each document so we can submit them to the IESG by the November deadlines. The first two WGLCs will be for draft-ietf-syslog-protocol and draft-ietf-syslog-transport-udp, so you can get started ahead of time to do these reviews if you want. WGLCs will probably start Monday Aug 14. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Aug 10 23:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBNzw-0001wo-3J; Thu, 10 Aug 2006 23:47:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBNzu-0001wj-Ve for syslog@ietf.org; Thu, 10 Aug 2006 23:47:46 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBNzt-0000qb-Md for syslog@ietf.org; Thu, 10 Aug 2006 23:47:46 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6EB1627C066; Fri, 11 Aug 2006 05:41:41 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08398-08; Fri, 11 Aug 2006 05:41:41 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 2FA6527C061; Fri, 11 Aug 2006 05:41:41 +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, 11 Aug 2006 05:47:38 +0200 Subject: RE: [Syslog] timeline Date: Fri, 11 Aug 2006 05:47:33 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DDD@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In-Reply-To: <082101c6bca3$165a36e0$0400a8c0@china.huawei.com> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Syslog] timeline Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAVYSUA From: "Rainer Gerhards" To: "David Harrington" , X-OriginalArrivalTime: 11 Aug 2006 03:47:38.0627 (UTC) FILETIME=[E3CAD530:01C6BCF8] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, August 10, 2006 11:33 AM > To: syslog@ietf.org > Subject: [Syslog] timeline >=20 > Hi, >=20 > Chris and I are working on a schedule to help the WG meet its > deliverables. We have not yet agreed on all the specific dates because > Chris is on (another) vacation, but should have a schedule posted > within a few days.=20 >=20 > Here are two things we need to resolve soon. >=20 > 1) whether draft-ietf-syslog-transport-tls should use byte-counting, > special character, or both, including which special character. We want > to finalize this WG decision by August 18. My choices in order of preferrence, in that order: 1 (best) LF as delimiter, no byte counting=20 (because of compatibilit with existing solutions) we need to escape LF and the escape character inside MSG, NO byte-couting 2 byte-counting only 3 (worst choice) LF & byte-couting (see requirements for LF at 1 Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 11 00:32:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBOgt-0002Xq-BD; Fri, 11 Aug 2006 00:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBOgs-0002Xi-Ev for syslog@ietf.org; Fri, 11 Aug 2006 00:32:10 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBOgr-0004sJ-4i for syslog@ietf.org; Fri, 11 Aug 2006 00:32:10 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 360389C00D; Fri, 11 Aug 2006 06:33:06 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13962-05; Fri, 11 Aug 2006 06:33:02 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 786C79C00B; Fri, 11 Aug 2006 06:33:02 +0200 (CEST) Subject: RE: [Syslog] delineated datagrams Date: Fri, 11 Aug 2006 06:21:50 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DE1@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In-Reply-To: <1155198633.6525.1.camel@bzorp.balabit> X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-class: urn:content-classes:message Thread-Topic: [Syslog] delineated datagrams X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Index: Aca8We44KDRAF0sETvmLoLVEiES1iQAopC+g From: "Rainer Gerhards" To: "Balazs Scheidler" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: syslog@ietf.org, Tom Petch X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > Maybe this already has been said ;) >=20 > This makes sense. What about other control characters? >=20 We need to differentiate between on-the-wire format and storage format. On-the-wire, I would escape only LF and the escape character. In storage, I would escape any control character (which can be quite tricky with Unicode). Our current scope (and IETF scope) is on-the-wire. So I propose not to mangle any more characters than absolutely necessary. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 11 11:30:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBYxu-0008Qo-Hh; Fri, 11 Aug 2006 11:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBYxt-0008Qj-D9 for syslog@ietf.org; Fri, 11 Aug 2006 11:30:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBYxr-0006OE-5I for syslog@ietf.org; Fri, 11 Aug 2006 11:30:25 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2006 11:30:23 -0400 X-IronPort-AV: i="4.08,115,1154923200"; d="scan'208"; a="96247387:sNHT29907096" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BFUMHl001688; Fri, 11 Aug 2006 11:30:22 -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 k7BFUMdp017978; Fri, 11 Aug 2006 11:30:22 -0400 (EDT) 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.1830); Fri, 11 Aug 2006 11:30:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] timeline Date: Fri, 11 Aug 2006 11:26:38 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B7312201C96AC9@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] timeline Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYA From: "Anton Okmianski \(aokmians\)" To: "David Harrington" , X-OriginalArrivalTime: 11 Aug 2006 15:30:22.0548 (UTC) FILETIME=[0F729940:01C6BD5B] DKIM-Signature: a=rsa-sha1; q=dns; l=326; t=1155310223; x=1156174223; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20timeline |To:=22David=20Harrington=22=20,=20; X=v=3Dcisco.com=3B=20h=3DqsVO6tbXkOWAghubVPABNdVfFPM=3D; b=fu9hg/modmdaYD9JjYnfF4gElMCJnsOTM1FNfrP6M6Tcdf1Up/mtZXWlE9VAsk85U8nKc6WH ypvVSwqvPZFUrxLLvfBAtIWTc3NMXLtt4W4C7TZvAKUo2hWvdyfmu9D0; Authentication-Results: rtp-dkim-2.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > Here are two things we need to resolve soon. >=20 > 1) whether draft-ietf-syslog-transport-tls should use=20 > byte-counting, special character, or both, including which=20 > special character. We want to finalize this WG decision by August 18. My vote is for byte-counting and no magic characters. =20 Anton.=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 11 15:17:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBcVV-0004DZ-EL; Fri, 11 Aug 2006 15:17:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBcVU-0004DU-FN for syslog@ietf.org; Fri, 11 Aug 2006 15:17:20 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBcVS-0008LQ-57 for syslog@ietf.org; Fri, 11 Aug 2006 15:17:20 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2006 12:17:18 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BJHHJ8026846 for ; Fri, 11 Aug 2006 12:17:17 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7BJHHbc023678 for ; Fri, 11 Aug 2006 12:17:17 -0700 (PDT) Date: Fri, 11 Aug 2006 12:17:17 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=3091; t=1155323837; x=1156187837; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:syslog=20WG=20Timeline; X=v=3Dcisco.com=3B=20h=3DAOOUx6+MeHNGAX9MvD7YYVmuYU8=3D; b=AbtiLn6k38duiq5HRWrwGF3LLkwTVV/LGfUgEw8Zk66/9wObTT+1jtOrLSHwmdQfBs5BiTJG RFvMEbHbxIiny4YiCKHXjax/k13mg2iao7ICi44rbN+iDb5i/bkzL0q6; Authentication-Results: sj-dkim-1.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: [Syslog] syslog WG Timeline X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, David and I have agreed upon a timeline for the completion of our milestones. Please review this. We will be asking for people to provide review comments on each of the documents while they are in Working Group Last Call (WGLC). If you know that you're going to be unavailable (summer vacation) for some of these WGLCs, please submit comments to the WG beforehand, at least to let us know that you've read it. Thanks, Chris and David ===start=== Aug 11 - Drive discussion on whether draft-ietf-syslog-device-mib represents WG consensus on what needs to be managed in -protocol-, -udp-, -tls-, and -sign-. Aug 11 - Drive discussion on whether draft-ietf-syslog-transport-tls should use byte-counting, special character, or both, including which special character. Aug 14 - Begin WG Last Call for draft-ietf-syslog-protocol (45 pages) Aug 14 - Begin WG Last Call for draft-ietf-syslog-transport-udp (10 pages) Aug 18 - Decide what needs to be changed in draft-ietf-syslog-transport-tls to represent the final WG consensus on byte-counting, special character, or both, including which special character. Aug 18 - Decide what needs to be changed in the general design of draft-ietf-syslog-device-mib to represent the WG consensus. Aug 28 - Close WG Last Call for draft-ietf-syslog-protocol Aug 28 - Close WG Last Call for draft-ietf-syslog-transport-udp Aug 28 - Chairs start working on Shepherding documents for - draft-ietf-syslog-protocol - draft-ietf-syslog-transport-udp Sep 1 - updated revision of draft-ietf-syslog-transport-tls, representing WG consensus. Sep 1 - updated revision of draft-ietf-syslog-device-mib, representing WG consensus. Aug 28 - Begin WG Last Call for draft-ietf-syslog-sign (33 pages) Aug 28 - Begin WG Last Call for draft-ietf-syslog-transport-tls (11 pages) Sep 11 - Close WG Last Call for draft-ietf-syslog-sign. Sep 11 - Close WG Last Call for draft-ietf-syslog-transport-tls. Sep 11 - Chairs start working on Shepherding documents for - draft-ietf-syslog-transport-tls - draft-ietf-syslog-sign Sep 11 - Begin WG Last Call for draft-ietf-syslog-device-mib (33 pages) Sep 25 - Close WG Last Call for draft-ietf-syslog-device-mib. Sep 25 - Chairs start working on Shepherding documents for - draft-ietf-syslog-device-mib Oct 16 - Chairs produce Shepherding Documents for - draft-ietf-syslog-protocol - draft-ietf-syslog-transport-udp - draft-ietf-syslog-transport-tls - draft-ietf-syslog-device-mib - draft-ietf-syslog-sign Oct 23 - Final review of Spepherding Documents by the WG Nov 1 - Submit the following to the IESG - draft-ietf-syslog-protocol - draft-ietf-syslog-transport-udp - draft-ietf-syslog-transport-tls - draft-ietf-syslog-device-mib - draft-ietf-syslog-sign ===end=== _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 11 15:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBd1u-0008Ha-6P; Fri, 11 Aug 2006 15:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBd1q-00083w-9P for syslog@ietf.org; Fri, 11 Aug 2006 15:50:46 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBd1o-0002KG-Jx for syslog@ietf.org; Fri, 11 Aug 2006 15:50:45 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 11 Aug 2006 12:50:45 -0700 X-IronPort-AV: i="4.08,115,1154934000"; d="scan'208"; a="311256241:sNHT38742988" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BJoi1S003636 for ; Fri, 11 Aug 2006 12:50:44 -0700 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 k7BJoiHm014268 for ; Fri, 11 Aug 2006 12:50:44 -0700 (PDT) Received: from xmb-sjc-232.amer.cisco.com ([128.107.191.41]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 12:50:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] delineated datagrams Date: Fri, 11 Aug 2006 12:50:43 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] delineated datagrams Thread-Index: Aca8We44KDRAF0sETvmLoLVEiES1iQAopC+gACB59WA= From: "Nagaraj Varadharajan \(nagarajv\)" To: X-OriginalArrivalTime: 11 Aug 2006 19:50:43.0801 (UTC) FILETIME=[6E70A490:01C6BD7F] DKIM-Signature: a=rsa-sha1; q=dns; l=1546; t=1155325844; x=1156189844; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=nagarajv@cisco.com; z=From:=22Nagaraj=20Varadharajan=20\(nagarajv\)=22=20 |Subject:RE=3A=20[Syslog]=20delineated=20datagrams; X=v=3Dcisco.com=3B=20h=3DvgigDJ2yIKKxqnFCevdyGTQEcas=3D; b=m6xQd9XvIJH4hUiRHaC2zj2uYTqkqDg+jLZIQPcm3cY1cLWCYgmTeRT+7BpAqiald9boWKt2 tWxACVz5vTH1osRZayYbv330liy+jzTTqz3ogUX1EkyGhPTe4g0RKvo2; Authentication-Results: sj-dkim-4.cisco.com; header.From=nagarajv@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Sorry for jumping in late on this topic and also pardon me if I have not understood the discussion correctly. My thought is that the easiest way syslog over tls will be implemented will be by existing apps taking what they have for syslog over TCP and adding the TLS layer. So in terms of easy implementation and adoption, it may be good to support whatever is being done for tcp syslogs now. I believe that LF as a separator is quite common currently.=20 However, I do agree that this is a good opportunity to upgrade to a better method. My only concern is that this should not force applications to drastically change their underlying syslog implementations Regards, Nagaraj -----Original Message----- From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 Sent: Thursday, August 10, 2006 9:22 PM To: Balazs Scheidler Cc: syslog@ietf.org; Tom Petch Subject: RE: [Syslog] delineated datagrams > Maybe this already has been said ;) >=20 > This makes sense. What about other control characters? >=20 We need to differentiate between on-the-wire format and storage format. On-the-wire, I would escape only LF and the escape character. In storage, I would escape any control character (which can be quite tricky with Unicode). Our current scope (and IETF scope) is on-the-wire. So I propose not to mangle any more characters than absolutely necessary. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 11 16:13:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBdNg-0005fH-VF; Fri, 11 Aug 2006 16:13:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBdNg-0005f6-1N for syslog@ietf.org; Fri, 11 Aug 2006 16:13:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBdNe-0004db-O9 for syslog@ietf.org; Fri, 11 Aug 2006 16:13:20 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2006 16:13:18 -0400 X-IronPort-AV: i="4.08,115,1154923200"; d="scan'208"; a="96294825:sNHT31531140" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BKDINB007871 for ; Fri, 11 Aug 2006 16:13:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7BKDIe2004541 for ; Fri, 11 Aug 2006 16:13:18 -0400 (EDT) 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.1830); Fri, 11 Aug 2006 16:13:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] delineated datagrams Date: Fri, 11 Aug 2006 16:09:34 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B7312201C96C24@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] delineated datagrams Thread-Index: Aca8We44KDRAF0sETvmLoLVEiES1iQAopC+gACB59WAAAIf3EA== From: "Anton Okmianski \(aokmians\)" To: "Nagaraj Varadharajan \(nagarajv\)" , X-OriginalArrivalTime: 11 Aug 2006 20:13:18.0162 (UTC) FILETIME=[95B3BB20:01C6BD82] DKIM-Signature: a=rsa-sha1; q=dns; l=2545; t=1155327198; x=1156191198; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20delineated=20datagrams |To:=22Nagaraj=20Varadharajan=20\(nagarajv\)=22=20, =0A=2 0=20=20=20=20=20=20=20; X=v=3Dcisco.com=3B=20h=3DGlZ12CD0ZYNtwMp7mBOXm/cTIYU=3D; b=p0xobTAuT+vBm91TmsNGBExfnnfJijmAq/TvAtM3E7gHc6UzAnGRjavIQ2n5su7soE4gtBlH pb54GdCbtC03R8HxGhHYCFnRMu54ESa7wL/k2CNgsRbMZxbHw7xutBa7; Authentication-Results: rtp-dkim-2.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I thought we were targeting the TLS transport to the new syslog-protocol, not the current informational RFC 3164. There are some considerations in the charter for partial syslog-protocol compatibility with RFC 3164. But I don't think we have called for the new transport to necessarily work with RFC 3164, did we?=20 Does this need to be a requirement or can the implementations that wish to support both provide features to transition clients from one to another?=20 Thanks, Anton.=20 > -----Original Message----- > From: Nagaraj Varadharajan (nagarajv)=20 > Sent: Friday, August 11, 2006 3:51 PM > To: syslog@ietf.org > Subject: RE: [Syslog] delineated datagrams >=20 > Sorry for jumping in late on this topic and also pardon me if=20 > I have not understood the discussion correctly. >=20 > My thought is that the easiest way syslog over tls will be=20 > implemented will be by existing apps taking what they have=20 > for syslog over TCP and adding the TLS layer. So in terms of=20 > easy implementation and adoption, it may be good to support=20 > whatever is being done for tcp syslogs now. I believe that LF=20 > as a separator is quite common currently.=20 > However, I do agree that this is a good opportunity to=20 > upgrade to a better method. My only concern is that this=20 > should not force applications to drastically change their=20 > underlying syslog implementations >=20 > Regards, > Nagaraj >=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Thursday, August 10, 2006 9:22 PM > To: Balazs Scheidler > Cc: syslog@ietf.org; Tom Petch > Subject: RE: [Syslog] delineated datagrams >=20 > > Maybe this already has been said ;) > >=20 > > This makes sense. What about other control characters? > >=20 >=20 >=20 > We need to differentiate between on-the-wire format and=20 > storage format. > On-the-wire, I would escape only LF and the escape character.=20 > In storage, I would escape any control character (which can=20 > be quite tricky with Unicode). Our current scope (and IETF=20 > scope) is on-the-wire. So I propose not to mangle any more=20 > characters than absolutely necessary. >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 11 23:06:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBjoX-0000VJ-1c; Fri, 11 Aug 2006 23:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBjoV-0000VE-Q3 for syslog@ietf.org; Fri, 11 Aug 2006 23:05:27 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBjoU-0001yu-7d for syslog@ietf.org; Fri, 11 Aug 2006 23:05:27 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id B48D19C00C; Sat, 12 Aug 2006 05:06:32 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14764-09; Sat, 12 Aug 2006 05:06:29 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 02F9A9C00B; Sat, 12 Aug 2006 05:06:28 +0200 (CEST) Subject: RE: [Syslog] syslog WG Timeline Date: Sat, 12 Aug 2006 05:05:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DE5@grfint2.intern.adiscon.com> In-Reply-To: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] syslog WG Timeline Thread-Index: Aca9es70eIGACvKPSwq6S4kM6E4NFAAQS5JA From: "Rainer Gerhards" To: "Chris Lonvick" , X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org The schedule sounds fine to me, but I can offer only limited availability (both for comments and editing) in the next weeks (chairs are notified about the specifics, I do not like to post absence information publically). Thanks, Rainer=20 > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Friday, August 11, 2006 1:17 PM > To: syslog@ietf.org > Subject: [Syslog] syslog WG Timeline >=20 > Hi Folks, >=20 > David and I have agreed upon a timeline for the completion of our=20 > milestones. Please review this. We will be asking for=20 > people to provide=20 > review comments on each of the documents while they are in=20 > Working Group=20 > Last Call (WGLC). If you know that you're going to be=20 > unavailable (summer=20 > vacation) for some of these WGLCs, please submit comments to the WG=20 > beforehand, at least to let us know that you've read it. >=20 > Thanks, > Chris and David >=20 >=20 > =3D=3D=3Dstart=3D=3D=3D >=20 > Aug 11 - Drive discussion on whether draft-ietf-syslog-device-mib > represents WG consensus on what needs to be managed in > -protocol-, -udp-, -tls-, and -sign-. > Aug 11 - Drive discussion on whether draft-ietf-syslog-transport-tls > should use byte-counting, special character, or=20 > both, including > which special character. >=20 > Aug 14 - Begin WG Last Call for draft-ietf-syslog-protocol (45 pages) > Aug 14 - Begin WG Last Call for draft-ietf-syslog-transport-udp (10 > pages) >=20 > Aug 18 - Decide what needs to be changed in > draft-ietf-syslog-transport-tls to represent the final WG > consensus on byte-counting, special character, or=20 > both, including > which special character. > Aug 18 - Decide what needs to be changed in the general design of > draft-ietf-syslog-device-mib to represent the WG consensus. >=20 > Aug 28 - Close WG Last Call for draft-ietf-syslog-protocol > Aug 28 - Close WG Last Call for draft-ietf-syslog-transport-udp >=20 > Aug 28 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp >=20 > Sep 1 - updated revision of draft-ietf-syslog-transport-tls, > representing WG consensus. > Sep 1 - updated revision of draft-ietf-syslog-device-mib, representing > WG consensus. >=20 > Aug 28 - Begin WG Last Call for draft-ietf-syslog-sign (33 pages) > Aug 28 - Begin WG Last Call for draft-ietf-syslog-transport-tls (11 > pages) >=20 >=20 > Sep 11 - Close WG Last Call for draft-ietf-syslog-sign. > Sep 11 - Close WG Last Call for draft-ietf-syslog-transport-tls. >=20 > Sep 11 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-sign >=20 > Sep 11 - Begin WG Last Call for draft-ietf-syslog-device-mib (33 > pages) >=20 > Sep 25 - Close WG Last Call for draft-ietf-syslog-device-mib. > Sep 25 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-device-mib >=20 > Oct 16 - Chairs produce Shepherding Documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-device-mib > - draft-ietf-syslog-sign >=20 > Oct 23 - Final review of Spepherding Documents by the WG >=20 > Nov 1 - Submit the following to the IESG > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-device-mib > - draft-ietf-syslog-sign >=20 > =3D=3D=3Dend=3D=3D=3D >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Aug 12 04:53:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBpEd-0003Ni-Uo; Sat, 12 Aug 2006 04:52:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBpEc-0003Lv-4i for syslog@ietf.org; Sat, 12 Aug 2006 04:52:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBjwG-0002Od-Gr for syslog@ietf.org; Fri, 11 Aug 2006 23:13:28 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBjjL-00007H-Gd for syslog@ietf.org; Fri, 11 Aug 2006 23:00:09 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id C0C1E9C00C; Sat, 12 Aug 2006 05:01:06 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14918-02; Sat, 12 Aug 2006 05:01:02 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4E4769C00B; Sat, 12 Aug 2006 05:01:02 +0200 (CEST) Subject: RE: [Syslog] delineated datagrams Date: Sat, 12 Aug 2006 04:59:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DE4@grfint2.intern.adiscon.com> In-Reply-To: <98AE08B66FAD1742BED6CB9522B7312201C96C24@xmb-rtp-20d.amer.cisco.com> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] delineated datagrams Thread-Index: Aca8We44KDRAF0sETvmLoLVEiES1iQAopC+gACB59WAAAIf3EAAOnQrg From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , "Nagaraj Varadharajan (nagarajv)" , X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: -2.6 (--) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org No,we have not called for interopo with 3164. As there are very few 3164 "compliant" (not a standard) implementation, we can not find any common ground. Even more essential, 3164 is purely UDP, so there is no such thing as a 3164 "compliant" tcp sender. I agree, however, that -transport-tls can easily be used together with existing syslog/tls implementations if we use LF (and no octet count). It then comes down to what is described in syslog-protocol for interop with existing implementations. This is why I would prefer that mode. Rainer=20 > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Friday, August 11, 2006 2:10 PM > To: Nagaraj Varadharajan (nagarajv); syslog@ietf.org > Subject: RE: [Syslog] delineated datagrams >=20 > I thought we were targeting the TLS transport to the new > syslog-protocol, not the current informational RFC 3164. =20 > There are some > considerations in the charter for partial syslog-protocol=20 > compatibility > with RFC 3164. But I don't think we have called for the new=20 > transport to > necessarily work with RFC 3164, did we?=20 >=20 > Does this need to be a requirement or can the implementations=20 > that wish > to support both provide features to transition clients from one to > another?=20 >=20 > Thanks, > Anton.=20 >=20 > > -----Original Message----- > > From: Nagaraj Varadharajan (nagarajv)=20 > > Sent: Friday, August 11, 2006 3:51 PM > > To: syslog@ietf.org > > Subject: RE: [Syslog] delineated datagrams > >=20 > > Sorry for jumping in late on this topic and also pardon me if=20 > > I have not understood the discussion correctly. > >=20 > > My thought is that the easiest way syslog over tls will be=20 > > implemented will be by existing apps taking what they have=20 > > for syslog over TCP and adding the TLS layer. So in terms of=20 > > easy implementation and adoption, it may be good to support=20 > > whatever is being done for tcp syslogs now. I believe that LF=20 > > as a separator is quite common currently.=20 > > However, I do agree that this is a good opportunity to=20 > > upgrade to a better method. My only concern is that this=20 > > should not force applications to drastically change their=20 > > underlying syslog implementations > >=20 > > Regards, > > Nagaraj > >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Thursday, August 10, 2006 9:22 PM > > To: Balazs Scheidler > > Cc: syslog@ietf.org; Tom Petch > > Subject: RE: [Syslog] delineated datagrams > >=20 > > > Maybe this already has been said ;) > > >=20 > > > This makes sense. What about other control characters? > > >=20 > >=20 > >=20 > > We need to differentiate between on-the-wire format and=20 > > storage format. > > On-the-wire, I would escape only LF and the escape character.=20 > > In storage, I would escape any control character (which can=20 > > be quite tricky with Unicode). Our current scope (and IETF=20 > > scope) is on-the-wire. So I propose not to mangle any more=20 > > characters than absolutely necessary. > >=20 > > Rainer > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Aug 13 03:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCAQo-0001em-QY; Sun, 13 Aug 2006 03:30:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCAQn-0001eg-Sx for syslog@ietf.org; Sun, 13 Aug 2006 03:30:45 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCAQm-0008Fb-Il for syslog@ietf.org; Sun, 13 Aug 2006 03:30:45 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 858489C00C for ; Sun, 13 Aug 2006 09:31:56 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15674-03 for ; Sun, 13 Aug 2006 09:31:52 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id CAAC09C00B for ; Sun, 13 Aug 2006 09:31:52 +0200 (CEST) Received: from 172.19.0.6 ([172.19.0.6]) by grfint2.intern.adiscon.com ([172.19.0.6]) with Microsoft Exchange Server HTTP-DAV ; Sun, 13 Aug 2006 07:30:37 +0000 MIME-Version: 1.0 From: "Rainer Gerhards" Date: Sun, 13 Aug 2006 01:25:49 -0600 Message-ID: <000401c6beaa$5eddec48$060013ac@intern.adiscon.com> Importance: normal X-Priority: 3 To: Content-Transfer-Encoding: quoted-printable thread-topic: Syslog-sign & -protocol thread-index: Aca+ql7dKYBHQCNjTjOGNa+FB7vPWg== Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Syslog] Syslog-sign & -protocol X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, A general comment: syslog-sign is still based on rfc 3164 and has ist own f= ormat definitions. It needs to be edited to utilize the new work in syslog-= protocol. It should now use structured data for ist signature blocks. rainer= _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Aug 13 10:43:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCHBQ-0002Mf-7v; Sun, 13 Aug 2006 10:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCHBP-0002Ma-0A for syslog@ietf.org; Sun, 13 Aug 2006 10:43:19 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCHBN-00029O-H9 for syslog@ietf.org; Sun, 13 Aug 2006 10:43:18 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 316C69C00C for ; Sun, 13 Aug 2006 16:44:31 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15674-08 for ; Sun, 13 Aug 2006 16:44:27 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 7F1DB9C00B for ; Sun, 13 Aug 2006 16:44:27 +0200 (CEST) Received: from 172.19.0.6 ([172.19.0.6]) by grfint2.intern.adiscon.com ([172.19.0.6]) with Microsoft Exchange Server HTTP-DAV ; Sun, 13 Aug 2006 07:47:41 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: Re: [Syslog] Notes on TLS transport Date: Sun, 13 Aug 2006 16:43:05 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DE7@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Syslog] Notes on TLS transport Thread-Index: Aca+rMEXAiga3DBJRDyyezeNuIcNfg== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0850160494==" Errors-To: syslog-bounces@lists.ietf.org --===============0850160494== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyB0aGUgb2xkIGlzc3VlIG9mIHB1dHRpbmcgYSBzeXNsb2ctc3RyZWFtIGJldHdlZW4g LXByb3RvY29sIGFuZCAtdGxzLy1zc2gvLXdoYXRldmVyLiBJdCB3b250IGh1cnQgcGFja2V0IGJh c2VkIHN5c2xvZy4gSGFzIGJlZW4gb2JqZWN0ZWQgc28gZmFyLiBJIGd1ZXNzIGl0IGlzIHRvbyBs YXRlIHRvIGxvb2sgYXQgaXQgb25jZSBhZ2Fpbi4uLg0KDQpSYWluZXIgDQoNCi0tLS0tIFVyc3By w7xuZ2xpY2hlIE5hY2hyaWNodCAtLS0tLQ0KVm9uOiAiRXJpYyBSZXNjb3JsYSIgPGVrckBuZXR3 b3JrcmVzb25hbmNlLmNvbT4NCkFuOiAiTWlhbyBGdXlvdSIgPG1pYW9meUBodWF3ZWkuY29tPg0K Q2M6ICJzeXNsb2dAaWV0Zi5vcmciIDxzeXNsb2dAaWV0Zi5vcmc+DQpHZXNlbmRldDogMDcuMDgu MDYgMTk6MzkNCkJldHJlZmY6IFJlOiBbU3lzbG9nXSBOb3RlcyBvbiBUTFMgdHJhbnNwb3J0IA0K DQpNaWFvIEZ1eW91IDxtaWFvZnlAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj4gIA0KPiA+IA0KPiA+ IFMgNS4zOg0KPiA+ICAgIEFsbCBTeXNsb2cgbWVzc2FnZXMgTVVTVCBiZSBzZW50IGFzIFRMUyAi YXBwbGljYXRpb24gZGF0YSIuICBUaGVyZQ0KPiA+ICAgIE1BWSBiZSBtdWx0aXBsZSBTeXNsb2cg bWVzc2FnZSBpbiB0aGUgc2FtZSBUTFMgcmVjb3JkLiAgVGhlDQo+ID4gICAgYXBwbGljYXRpb24g ZGF0YSBpcyBkZWZpbmVkIHdpdGggdGhlIGZvbGxvd2luZyBBQk5GIFszXSBleHByZXNzaW9uOg0K PiA+IA0KPiA+IFRMUydzIGFic3RyYWN0aW9uIGlzIGFzIGEgc3RyZWFtLCBzbyB0aGlzIGlzbid0 IHJlYWxseSB0aGUgYnVzaW5lc3MNCj4gPiBvZiBodGlzIHNwZWMuDQo+ID4gDQo+IA0KPiBJIGFn cmVlIHRvIEVyaWMncyBvcGluaW9uLiBJZiBzeXNsb2cgcHJvY290b2wgaGFzIGEgbWVjaGFuaXNt IHRvIGRlbGltaXQNCj4gbWVzc2FnZSwgd2Ugd2lsbCBuZXZlciBuZWVkIHRvIGFkZHJlc3Mgc2Ft ZSBpc3N1ZSBhY3Jvc3MgZGlmZmVyZW50DQo+IGRvY3VtZW50czogc3lzbG9nLXRscywgc3lzbG9n LXNzaCwgb3Igc3lzbG9nLXRjcCBldGMgKHBlcmhhcHMgd2l0aCBkaWZmZXJlbnQNCj4gbWVjaGFu aXNtcykuIA0KDQpOb3RlLCB0aG91Z2gsIHRoYXQgeW91IGRvIG5lZWQgYSBtYXBwaW5nIGZyb20g c3lzbG9nIHRvIERUTFMNCmJlY2F1c2UgaXQncyBwYWNrZXRpemVkLiBTYW1lIGFzIHlvdSBuZWVk IGEgbWFwcGluZyBmcm9tIHN5c2xvZw0KdG8gVURQLg0KDQotRWtyDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTeXNsb2cgbWFpbGluZyBsaXN0DQpT eXNsb2dAbGlzdHMuaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3N5c2xvZw0K --===============0850160494== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --===============0850160494==-- From syslog-bounces@lists.ietf.org Mon Aug 14 02:58:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCWPI-0003HQ-7b; Mon, 14 Aug 2006 02:58:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCWPG-0003Gq-OD for syslog@ietf.org; Mon, 14 Aug 2006 02:58:38 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCWPE-0004ZX-Sn for syslog@ietf.org; Mon, 14 Aug 2006 02:58:38 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3Z00G3585L0F@szxga02-in.huawei.com> for syslog@ietf.org; Mon, 14 Aug 2006 15:15:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3Z00DED85LBM@szxga02-in.huawei.com> for syslog@ietf.org; Mon, 14 Aug 2006 15:15:21 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3Z00DR97W6SY@szxml04-in.huawei.com> for syslog@ietf.org; Mon, 14 Aug 2006 15:09:46 +0800 (CST) Date: Mon, 14 Aug 2006 14:57:43 +0800 From: Miao Fuyou Subject: RE: [Syslog] timeline In-reply-to: <98AE08B66FAD1742BED6CB9522B7312201C96AC9@xmb-rtp-20d.amer.cisco.com> To: "'Anton Okmianski (aokmians)'" , 'David Harrington' , syslog@ietf.org Message-id: <01f701c6bf6e$f1199050$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org My vote: byte-counting only > byte-counting + LF > LF > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > Sent: Friday, August 11, 2006 11:27 PM > To: David Harrington; syslog@ietf.org > Subject: RE: [Syslog] timeline > > > Here are two things we need to resolve soon. > > > > 1) whether draft-ietf-syslog-transport-tls should use > byte-counting, > > special character, or both, including which special > character. We want > > to finalize this WG decision by August 18. > > My vote is for byte-counting and no magic characters. > > Anton. > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 14 07:44:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCas9-0007Qz-I5; Mon, 14 Aug 2006 07:44:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCas6-0007Qs-Ts for syslog@ietf.org; Mon, 14 Aug 2006 07:44:42 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCas5-00049X-Li for syslog@ietf.org; Mon, 14 Aug 2006 07:44:42 -0400 Received: from pc6 (1Cust46.tnt110.lnd4.gbr.da.uu.net [62.188.174.46]) by galaxy.systems.pipex.net (Postfix) with SMTP id B3037E000203; Mon, 14 Aug 2006 12:44:40 +0100 (BST) Message-ID: <068c01c6bf8d$ede157a0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <082101c6bca3$165a36e0$0400a8c0@china.huawei.com> Subject: Re: [Syslog] timeline Date: Mon, 14 Aug 2006 12:20:13 +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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "David Harrington" To: Sent: Thursday, August 10, 2006 7:33 PM Subject: [Syslog] timeline > > 1) whether draft-ietf-syslog-transport-tls should use byte-counting, > special character, or both, including which special character. We want > to finalize this WG decision by August 18. > LF as delimiter, no byte counting As Rainer says, we want compatibility with existing solutions. It is not as if we have a green field site and can ignore the marketplace. Tom Petch > > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 14 10:20:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCdIn-0002o9-Bt; Mon, 14 Aug 2006 10:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCdIm-0002ni-AD for syslog@ietf.org; Mon, 14 Aug 2006 10:20:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCdIk-0008Pc-Uu for syslog@ietf.org; Mon, 14 Aug 2006 10:20:24 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 14 Aug 2006 07:20:22 -0700 X-IronPort-AV: i="4.08,121,1154934000"; d="scan'208"; a="1846784267:sNHT32758374" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7EEKMnO015205; Mon, 14 Aug 2006 07:20:22 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7EEKLlO015380; Mon, 14 Aug 2006 07:20:21 -0700 (PDT) Date: Mon, 14 Aug 2006 07:20:21 -0700 (PDT) From: Chris Lonvick To: Tom Petch Subject: Re: [Syslog] delineated datagrams In-Reply-To: <068701c6bf8d$a4ac7f60$0601a8c0@pc6> Message-ID: References: <049a01c6b7ef$b42a36d0$0400a8c0@china.huawei.com> <068701c6bf8d$a4ac7f60$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=2860; t=1155565222; x=1156429222; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Re=3A=20[Syslog]=20delineated=20datagrams; X=v=3Dcisco.com=3B=20h=3D2mm87HzjwXJcIu6FQYF769SL7tM=3D; b=a7Z+/9VwIL3ht8tc+vBPmMmPqD27a3PXsickjXC6qh/lj49JhRWWrZDykiaBN7/VxpajUAHY jeJjkz97CDOkjf1xxPTeyEtwN5hwqDu2jRlwbdbz3BZ3LLMuZkHMqLQd; Authentication-Results: sj-dkim-3.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Tom and All, What I've seen discussed: - There is no character or character sequence that cannot be used in the syslog payload, which might confuse a parser looking to delineate messages in a single packet based upon a character or character sequence. - Byte counting can provide assurance for the delineation of messages. - {Some | Most | All} syslog daemons already escape LF so a non-escaped LF could be used to delineate messages. Is this correct? Since it's come up on the list before as a concern, what will be done if people start putting binary information into the syslog message payload? Will that always have to be escaped by the sender and reversed by the receiver? Thanks, Chris On Mon, 14 Aug 2006, Tom Petch wrote: > ----- Original Message ----- > From: "David Harrington" > To: "'Chris Lonvick'" ; "'Miao Fuyou'" > Cc: ; "'Tom Petch'" > Sent: Friday, August 04, 2006 7:59 PM > Subject: RE: [Syslog] delineated datagrams > > >> >> As you probably know by now, I like to see design reuse across IETF NM >> solutions, especially across SNMP, syslog, ipfix, and netconf where >> feasible. >> >> As all the IETF NM protocols move toward similar secure transport >> solutions, including moving from datagrams to streams, it would be a >> good thing to use consistent aproaches to framing. >> >> Here is what is happening in the other IETF NM protocols: >> > > > >> The NETCONF protocol uses an RPC-based communication model. >> From >> http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt: >> NETCONF peers use and elements to provide >> transport >> protocol-independent framing of NETCONF requests and responses. > > Ok as far as it goes but incomplete. As the ssh mapping says, > > " As the previous example illustrates, a special character sequence, > ]]>]]>, MUST be sent by both the client and the server after each XML > document in the NETCONF exchange. This character sequence cannot > legally appear in an XML document, so it can be unambigiously used to > indentify the end of the current document in the event of an XML > syntax or parsing error, allowing resynchronization of the NETCONF > exchange." > . > Wishing to promote design reuse across IETF NM solutions, especially across the > character-based ones, I did propose the same separator for syslog over tls and > still see it as the technically best solution (even though our message content > can be anything and so, unlike NETCONF, we cannot rely 100% on that not > appearing in our message content). > >> >> David Harrington >> dharrington@huawei.com >> dbharrington@comcast.net >> ietfdbh@comcast.net >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 14 10:31:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCdTe-00078L-Dq; Mon, 14 Aug 2006 10:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCdTd-00078F-BQ for syslog@ietf.org; Mon, 14 Aug 2006 10:31:37 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCdTc-0000lX-O6 for syslog@ietf.org; Mon, 14 Aug 2006 10:31:37 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 608CA9C00C; Mon, 14 Aug 2006 16:32:55 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16818-06; Mon, 14 Aug 2006 16:32:51 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 53E099C00B; Mon, 14 Aug 2006 16:32:51 +0200 (CEST) Subject: RE: [Syslog] delineated datagrams Date: Mon, 14 Aug 2006 16:31:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DF0@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message In-Reply-To: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] delineated datagrams Thread-Index: Aca/rM8iN9g2iSTyQgmKGKboAp+QQAAAKEuA From: "Rainer Gerhards" To: "Chris Lonvick" , "Tom Petch" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org =20 > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Monday, August 14, 2006 8:20 AM > To: Tom Petch > Cc: syslog@ietf.org > Subject: Re: [Syslog] delineated datagrams >=20 > Hi Tom and All, >=20 > What I've seen discussed: > - There is no character or character sequence that cannot be=20 > used in the > syslog payload, which might confuse a parser looking to delineate > messages in a single packet based upon a character or character > sequence. > - Byte counting can provide assurance for the delineation of messages. > - {Some | Most | All} syslog daemons already escape LF so a=20 > non-escaped LF > could be used to delineate messages. >=20 > Is this correct? Partly: every character can be present in MSG. So no one can be set aside. However, we can define an escape character (or sequence) and use that to escape "magic characters". The escape itself is a magic character and needs to be escaped. With that, LF can be used as delimiter. Most existing syslogds use LF as a separator (when receiving via TCP and SSL). Octet-couting is the cleanest solution. However, it will not work with existing syslogd - not even in the limited compatibility setting outlined in -protocol. Escaping in existing syslogd does not really matter, because it would interfere with new-style messages (but mostly in an acceptable - and expected - way). >=20 > Since it's come up on the list before as a concern, what will=20 > be done if=20 > people start putting binary information into the syslog=20 > message payload?=20 This is only supported as long as the binary information results to valid Unicode sequences. If not, the message is invalid and likely to be discarded. In short: pure binary is forbidden. Use base-64 or something similar if you really need to. > Will that always have to be escaped by the sender and reversed by the=20 > receiver? NO! This is prohibited by -protocol. Any valid Unicode sequence MUST be supported in MSG. This includes a myriad of (unicode) control sequences. Think the difference between on the wire and storage here. Inside storage (outside the scope of this wg), a receiver may escape (in fact I'd recommend it). But not on the wire. >=20 > Thanks, > Chris >=20 > On Mon, 14 Aug 2006, Tom Petch wrote: >=20 > > ----- Original Message ----- > > From: "David Harrington" > > To: "'Chris Lonvick'" ; "'Miao Fuyou'"=20 > > > Cc: ; "'Tom Petch'" > > Sent: Friday, August 04, 2006 7:59 PM > > Subject: RE: [Syslog] delineated datagrams > > > > > >> > >> As you probably know by now, I like to see design reuse=20 > across IETF NM > >> solutions, especially across SNMP, syslog, ipfix, and netconf where > >> feasible. > >> > >> As all the IETF NM protocols move toward similar secure transport > >> solutions, including moving from datagrams to streams, it=20 > would be a > >> good thing to use consistent aproaches to framing. > >> > >> Here is what is happening in the other IETF NM protocols: > >> > > > > > > >> The NETCONF protocol uses an RPC-based communication model. > >> From > >> http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt: > >> NETCONF peers use and elements to provide > >> transport > >> protocol-independent framing of NETCONF requests and responses. > > > > Ok as far as it goes but incomplete. As the ssh mapping says, > > > > " As the previous example illustrates, a special character sequence, > > ]]>]]>, MUST be sent by both the client and the server=20 > after each XML > > document in the NETCONF exchange. This character sequence cannot > > legally appear in an XML document, so it can be=20 > unambigiously used to > > indentify the end of the current document in the event of an XML > > syntax or parsing error, allowing resynchronization of=20 > the NETCONF > > exchange." > > . > > Wishing to promote design reuse across IETF NM solutions,=20 > especially across the > > character-based ones, I did propose the same separator for=20 > syslog over tls and > > still see it as the technically best solution (even though=20 > our message content > > can be anything and so, unlike NETCONF, we cannot rely 100%=20 > on that not > > appearing in our message content). > > > >> > >> David Harrington > >> dharrington@huawei.com > >> dbharrington@comcast.net > >> ietfdbh@comcast.net > >> > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 14 10:32:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCdUj-0007Q3-VZ; Mon, 14 Aug 2006 10:32:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCdUi-0007Py-6o for syslog@ietf.org; Mon, 14 Aug 2006 10:32:44 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCdUg-0000sR-U9 for syslog@ietf.org; Mon, 14 Aug 2006 10:32:44 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 14 Aug 2006 07:32:42 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7EEWgv6008583; Mon, 14 Aug 2006 07:32:42 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7EEWfUK004148; Mon, 14 Aug 2006 07:32:42 -0700 (PDT) Date: Mon, 14 Aug 2006 07:32:41 -0700 (PDT) From: Chris Lonvick To: Rainer Gerhards Subject: Re: [Syslog] Syslog-sign & -protocol In-Reply-To: <000401c6beaa$5eddec48$060013ac@intern.adiscon.com> Message-ID: References: <000401c6beaa$5eddec48$060013ac@intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1234; t=1155565962; x=1156429962; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Re=3A=20[Syslog]=20Syslog-sign=20&=20-protocol; X=v=3Dcisco.com=3B=20h=3DjP6Ps8wU1QBoj9HpOn5wPGY1UzQ=3D; b=NUqsX37ee6Q2aGM43DVM5OkazTKMCI7DoDYKD80Cf25ONg53jvCglIO7W+A5TpgOBfkJjtaV 8Dc4/eDzBp/FJEbY332IRwqtwy3aE1aeZcaIY1a7bwfafcOnKmJFb1N+; Authentication-Results: sj-dkim-1.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi All, On Sun, 13 Aug 2006, Rainer Gerhards wrote: > Hi, > > A general comment: syslog-sign is still based on rfc 3164 and has ist own format definitions. It needs to be edited to utilize the new work in syslog-protocol. It should now use structured data for ist signature blocks. Alex has moved much of it to be conformant with syslog-protocol. The work that needs to be addressed (as I see it :) For the Signature Block, should the payload of signatures be part of the "ssign" SD-ID, or should it be the payload (behind the BOM)? Right now, it is part of the SD-ID. Similarly, about the "ssign-cert" and it's payload. I think it likely that the Payload Block can be placed within a single Certificate Block based upon our discussions of the max length. The document needs to define how to use "@enterpriseID" in some cases. Section 8.2 - the length is no longer limited to 1024B. Section 9 - "Cookie Fields" are no longer used. The IANA section also needs to specify which SD-IDs and SD-Params should be registered. Should other SD-IDs be included with "ssign" and "ssign-cert" SD-IDs? (I think so as that's how we include information about time accuracy, etc.) Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 14 18:33:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkzQ-00085V-F6; Mon, 14 Aug 2006 18:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkzP-00085Q-II for syslog@ietf.org; Mon, 14 Aug 2006 18:32:55 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCkzO-0001yV-0G for syslog@ietf.org; Mon, 14 Aug 2006 18:32:55 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc11) with SMTP id <20060814223253b11000r4fhe>; Mon, 14 Aug 2006 22:32:53 +0000 From: "David Harrington" To: "'Tom Petch'" , "'Chris Lonvick'" , "'Miao Fuyou'" Subject: RE: [Syslog] delineated datagrams Date: Mon, 14 Aug 2006 18:31:15 -0400 Message-ID: <0a8001c6bff1$5b323b40$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <068701c6bf8d$a4ac7f60$0601a8c0@pc6> Thread-Index: Aca/lr8soJ91u7KuQgGHvXqRwAB0OgAUVs+g X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Tom, You're right; I didn't go far enough. I was looking for a framing defined by the netconf protocol, not the separator of messages within a transport. Unfortunately, Netconf uses a number of transport-dependent schemes within the multiple transports it supports, including both octet-counting approaches and terminating character approaches. Sigh. The "]]>]]>" sequence only works in the SSH transport mapping, not the BEEP or SOAP mappings. So much for trying to find consistency. Note that Netconf is considering a design that allows multiple syslog messages to be sent in a netconf notification session. If we used "]]>]]>" as a syslog message delimiter, we would prevent netconf from transporting multiple syslog messages, since netconf can only transport valid XML, and the "]]>]]>" in a syslog message would indicate the end of an , causing netconf to lose synchronization? See the Montreal Netconf Interim minutes currently available on the netconf mailing list for more details. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Monday, August 14, 2006 6:36 AM > To: David Harrington; 'Chris Lonvick'; 'Miao Fuyou' > Cc: syslog@ietf.org > Subject: Re: [Syslog] delineated datagrams > > ----- Original Message ----- > From: "David Harrington" > To: "'Chris Lonvick'" ; "'Miao Fuyou'" > > Cc: ; "'Tom Petch'" > Sent: Friday, August 04, 2006 7:59 PM > Subject: RE: [Syslog] delineated datagrams > > > > > > As you probably know by now, I like to see design reuse > across IETF NM > > solutions, especially across SNMP, syslog, ipfix, and netconf where > > feasible. > > > > As all the IETF NM protocols move toward similar secure transport > > solutions, including moving from datagrams to streams, it would be a > > good thing to use consistent aproaches to framing. > > > > Here is what is happening in the other IETF NM protocols: > > > > > > > The NETCONF protocol uses an RPC-based communication model. > > From > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt: > > NETCONF peers use and elements to provide > > transport > > protocol-independent framing of NETCONF requests and responses. > > Ok as far as it goes but incomplete. As the ssh mapping says, > > " As the previous example illustrates, a special character sequence, > ]]>]]>, MUST be sent by both the client and the server > after each XML > document in the NETCONF exchange. This character sequence cannot > legally appear in an XML document, so it can be > unambigiously used to > indentify the end of the current document in the event of an XML > syntax or parsing error, allowing resynchronization of the NETCONF > exchange." > . > Wishing to promote design reuse across IETF NM solutions, > especially across the > character-based ones, I did propose the same separator for > syslog over tls and > still see it as the technically best solution (even though > our message content > can be anything and so, unlike NETCONF, we cannot rely 100% > on that not > appearing in our message content). > > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 14 19:34:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GClxI-0007jd-5W; Mon, 14 Aug 2006 19:34:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GClxH-0007jY-A9 for syslog@ietf.org; Mon, 14 Aug 2006 19:34:47 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GClxF-0006lg-W4 for syslog@ietf.org; Mon, 14 Aug 2006 19:34:47 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc14) with SMTP id <20060814233445b1400gir8de>; Mon, 14 Aug 2006 23:34:45 +0000 From: "David Harrington" To: "'Chris Lonvick'" , Subject: RE: [Syslog] syslog WG Timeline Date: Mon, 14 Aug 2006 19:33:07 -0400 Message-ID: <0ab701c6bff9$ffac9460$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRg X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, This message officially starts the Syslog Working Group Last Call for the following two documents: draft-ietf-syslog-protocol: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt draft-ietf-syslog-transport-udp: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt The Working Group Last Call for these documents will end August 28. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, it if does not look acceptable please identify your ibjections, preferably with suggested text that would make it acceptable. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, August 11, 2006 3:17 PM > To: syslog@ietf.org > Subject: [Syslog] syslog WG Timeline > > Hi Folks, > > David and I have agreed upon a timeline for the completion of our > milestones. Please review this. We will be asking for > people to provide > review comments on each of the documents while they are in > Working Group > Last Call (WGLC). If you know that you're going to be > unavailable (summer > vacation) for some of these WGLCs, please submit comments to the WG > beforehand, at least to let us know that you've read it. > > Thanks, > Chris and David > > > ===start=== > > Aug 11 - Drive discussion on whether draft-ietf-syslog-device-mib > represents WG consensus on what needs to be managed in > -protocol-, -udp-, -tls-, and -sign-. > Aug 11 - Drive discussion on whether draft-ietf-syslog-transport-tls > should use byte-counting, special character, or > both, including > which special character. > > Aug 14 - Begin WG Last Call for draft-ietf-syslog-protocol (45 pages) > Aug 14 - Begin WG Last Call for draft-ietf-syslog-transport-udp (10 > pages) > > Aug 18 - Decide what needs to be changed in > draft-ietf-syslog-transport-tls to represent the final WG > consensus on byte-counting, special character, or > both, including > which special character. > Aug 18 - Decide what needs to be changed in the general design of > draft-ietf-syslog-device-mib to represent the WG consensus. > > Aug 28 - Close WG Last Call for draft-ietf-syslog-protocol > Aug 28 - Close WG Last Call for draft-ietf-syslog-transport-udp > > Aug 28 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > > Sep 1 - updated revision of draft-ietf-syslog-transport-tls, > representing WG consensus. > Sep 1 - updated revision of draft-ietf-syslog-device-mib, representing > WG consensus. > > Aug 28 - Begin WG Last Call for draft-ietf-syslog-sign (33 pages) > Aug 28 - Begin WG Last Call for draft-ietf-syslog-transport-tls (11 > pages) > > > Sep 11 - Close WG Last Call for draft-ietf-syslog-sign. > Sep 11 - Close WG Last Call for draft-ietf-syslog-transport-tls. > > Sep 11 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-sign > > Sep 11 - Begin WG Last Call for draft-ietf-syslog-device-mib (33 > pages) > > Sep 25 - Close WG Last Call for draft-ietf-syslog-device-mib. > Sep 25 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-device-mib > > Oct 16 - Chairs produce Shepherding Documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-device-mib > - draft-ietf-syslog-sign > > Oct 23 - Final review of Spepherding Documents by the WG > > Nov 1 - Submit the following to the IESG > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-device-mib > - draft-ietf-syslog-sign > > ===end=== > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 14 19:40:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCm2K-0000SU-F5; Mon, 14 Aug 2006 19:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCm2I-0000SP-RQ for syslog@ietf.org; Mon, 14 Aug 2006 19:39:58 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCm2H-0006z3-Iw for syslog@ietf.org; Mon, 14 Aug 2006 19:39:58 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc11) with SMTP id <20060814233953b11000raufe>; Mon, 14 Aug 2006 23:39:57 +0000 From: "David Harrington" To: "'Chris Lonvick'" Subject: RE: [Syslog] Syslog-sign & -protocol Date: Mon, 14 Aug 2006 19:38:15 -0400 Message-ID: <0ab801c6bffa$b98295b0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: Aca/roJs2gnSJbWPRHC1ZjPsbqWczAAS1itA X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, When can we get an updated revision of syslog-sign? Our current timeline calls for starting WGLC Aug 28. The changes sound sufficiently large that we should definitely try to review the changes before we start a last call on the document. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Monday, August 14, 2006 10:33 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] Syslog-sign & -protocol > > Hi All, > > On Sun, 13 Aug 2006, Rainer Gerhards wrote: > > > Hi, > > > > A general comment: syslog-sign is still based on rfc 3164 > and has ist own format definitions. It needs to be edited to > utilize the new work in syslog-protocol. It should now use > structured data for ist signature blocks. > > Alex has moved much of it to be conformant with > syslog-protocol. The work > that needs to be addressed (as I see it :) > > For the Signature Block, should the payload of signatures be > part of the > "ssign" SD-ID, or should it be the payload (behind the BOM)? > Right now, > it is part of the SD-ID. > > Similarly, about the "ssign-cert" and it's payload. I think > it likely > that the Payload Block can be placed within a single > Certificate Block > based upon our discussions of the max length. > > The document needs to define how to use "@enterpriseID" in some cases. > > Section 8.2 - the length is no longer limited to 1024B. > > Section 9 - "Cookie Fields" are no longer used. > > The IANA section also needs to specify which SD-IDs and > SD-Params should > be registered. > > Should other SD-IDs be included with "ssign" and "ssign-cert" > SD-IDs? (I > think so as that's how we include information about time > accuracy, etc.) > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 14 21:07:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCnPB-0004cR-AR; Mon, 14 Aug 2006 21:07:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCnP9-0004ZX-JY for syslog@ietf.org; Mon, 14 Aug 2006 21:07:39 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCnP1-0001rd-Rm for syslog@ietf.org; Mon, 14 Aug 2006 21:07:39 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J400050RMKK6M@szxga02-in.huawei.com> for syslog@ietf.org; Tue, 15 Aug 2006 09:24:20 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4000BPMMKJUF@szxga02-in.huawei.com> for syslog@ietf.org; Tue, 15 Aug 2006 09:24:20 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4000AGRLX51V@szxml03-in.huawei.com> for syslog@ietf.org; Tue, 15 Aug 2006 09:10:21 +0800 (CST) Date: Tue, 15 Aug 2006 09:06:39 +0800 From: Miao Fuyou Subject: RE: [Syslog] timeline In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA174DEF@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' Message-id: <007f01c6c007$10ad8870$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhA X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Rainer, A new implementation could rely on byte-counting only and then delete LF from the frame(appplication knows exactly where the LF is), it may not force us to use escapes. For LF, I think it is difficult to get 100% compatibility for a legacy implementation to comply TLS-transport without any change to the code. At least, some imlementation may need to change CR LF to LF because some implementations use CR LF rather than LF. So, it may be ok to add several LOC to delete FRAME-LEN SP from the frame. I still prefer byte-counting only to byte-counting+LF even if it is a feasible tradeoff. Miao > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Monday, August 14, 2006 10:18 PM > To: Miao Fuyou > Subject: RE: [Syslog] timeline > > We should not go byte-counting + LF. This is the worst choice: it > > A) breaks compatibility > B) Forces us to use escapes > > So we get the bad of both worlds, without any benefits. > > Rainer > > > -----Original Message----- > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > Sent: Monday, August 14, 2006 12:58 AM > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; > syslog@ietf.org > > Subject: RE: [Syslog] timeline > > > > > > My vote: byte-counting only > byte-counting + LF > LF > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 00:41:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCqjc-0004vb-Lt; Tue, 15 Aug 2006 00:41:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCqjb-0004vW-SD for syslog@ietf.org; Tue, 15 Aug 2006 00:40:59 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCqja-0000QU-BO for syslog@ietf.org; Tue, 15 Aug 2006 00:40:59 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 3EFC79C00C; Tue, 15 Aug 2006 06:42:20 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17188-10; Tue, 15 Aug 2006 06:42:16 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 35D759C00B; Tue, 15 Aug 2006 06:42:15 +0200 (CEST) Subject: RE: [Syslog] timeline Date: Tue, 15 Aug 2006 06:40:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DF3@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message In-Reply-To: <007f01c6c007$10ad8870$8c0c6f0a@china.huawei.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] timeline Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhAAAhRtsA= From: "Rainer Gerhards" To: "Miao Fuyou" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Miao, I am actually concerned about backward compatibility with existing code *without* the need to upgrade any of that code. As you know, deployed software tends to stick. If we use just LF, existing, deployed technology (e.g. syslog-ng with stunnel) would be able to understand a message sent from a "new style" syslogd. Having the octet count in front of the message removes that ability, as the old syslogd will no longer see the at the start of the message. I agree that it is trivial to modify code to take care for the octet counter. But this is not my concern. My concern is that I would like to achive as good as possible compatibility with existing deployed (aka "unmodified") technology. I should have been more specific on that. Sorry for the omission... I am also unaware of any implementation that mandates CR LF over just LF. Could you let me know which ones are these? Rainer=20 > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Monday, August 14, 2006 7:07 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] timeline >=20 > =20 > Hi, Rainer, >=20 > A new implementation could rely on byte-counting only and=20 > then delete LF > from the frame(appplication knows exactly where the LF is),=20 > it may not force > us to use escapes. For LF, I think it is difficult to get=20 > 100% compatibility > for a legacy implementation to comply TLS-transport without=20 > any change to > the code. At least, some imlementation may need to change CR LF to LF > because some implementations use CR LF rather than LF. So, it=20 > may be ok to > add several LOC to delete FRAME-LEN SP from the frame.=20 >=20 > I still prefer byte-counting only to byte-counting+LF even if it is a > feasible tradeoff. =20 >=20 > Miao >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Monday, August 14, 2006 10:18 PM > > To: Miao Fuyou > > Subject: RE: [Syslog] timeline > >=20 > > We should not go byte-counting + LF. This is the worst choice: it=20 > >=20 > > A) breaks compatibility > > B) Forces us to use escapes > >=20 > > So we get the bad of both worlds, without any benefits. > >=20 > > Rainer=20 > >=20 > > > -----Original Message----- > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > Sent: Monday, August 14, 2006 12:58 AM > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington';=20 > > syslog@ietf.org > > > Subject: RE: [Syslog] timeline > > >=20 > > >=20 > > > My vote: byte-counting only > byte-counting + LF > LF > > =20 > >=20 >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 00:52:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCquM-00085i-GU; Tue, 15 Aug 2006 00:52:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCquK-000855-CJ for syslog@ietf.org; Tue, 15 Aug 2006 00:52:04 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCquI-0001rN-Si for syslog@ietf.org; Tue, 15 Aug 2006 00:52:04 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 3387B9C00C; Tue, 15 Aug 2006 06:53:25 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17361-04; Tue, 15 Aug 2006 06:53:21 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id BFED09C00B; Tue, 15 Aug 2006 06:53:21 +0200 (CEST) Subject: RE: [Syslog] Syslog-sign & -protocol Date: Tue, 15 Aug 2006 06:51:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DF5@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message In-Reply-To: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign & -protocol Thread-Index: Aca/roV6TkTD2QabTj61TB3npoH+gQAd6opQ From: "Rainer Gerhards" To: "Chris Lonvick" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris, Sorry, I obviously had a previous copy cached... I've just downloaded a fresh one and started re-reading it. As you say, it already is adapted to syslog-protocol. Let me raise one point without being completely through with it: -sign now supports RFC 3164, 3195 and -protocol format. I see value in that approach (works for each and everything). On the other hand, it may introduce additional complexity, even on the operator side (configuration). Given the fact that -sign code needs to be written from scratch, wouldn't it make sense to limit it to just -protocol format? Rainer=20 > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Monday, August 14, 2006 8:33 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] Syslog-sign & -protocol >=20 > Hi All, >=20 > On Sun, 13 Aug 2006, Rainer Gerhards wrote: >=20 > > Hi, > > > > A general comment: syslog-sign is still based on rfc 3164=20 > and has ist own format definitions. It needs to be edited to=20 > utilize the new work in syslog-protocol. It should now use=20 > structured data for ist signature blocks. >=20 > Alex has moved much of it to be conformant with=20 > syslog-protocol. The work=20 > that needs to be addressed (as I see it :) >=20 > For the Signature Block, should the payload of signatures be=20 > part of the=20 > "ssign" SD-ID, or should it be the payload (behind the BOM)? =20 > Right now,=20 > it is part of the SD-ID. >=20 > Similarly, about the "ssign-cert" and it's payload. I think=20 > it likely=20 > that the Payload Block can be placed within a single=20 > Certificate Block=20 > based upon our discussions of the max length. >=20 > The document needs to define how to use "@enterpriseID" in some cases. >=20 > Section 8.2 - the length is no longer limited to 1024B. >=20 > Section 9 - "Cookie Fields" are no longer used. >=20 > The IANA section also needs to specify which SD-IDs and=20 > SD-Params should=20 > be registered. >=20 > Should other SD-IDs be included with "ssign" and "ssign-cert"=20 > SD-IDs? (I=20 > think so as that's how we include information about time=20 > accuracy, etc.) >=20 > Thanks, > Chris >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 03:00:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCsub-0003F4-Ou; Tue, 15 Aug 2006 03:00:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCsua-0003Ep-QS for syslog@ietf.org; Tue, 15 Aug 2006 03:00:28 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCsuY-0004Tm-Tv for syslog@ietf.org; Tue, 15 Aug 2006 03:00:28 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4100LCQ2KEQ4@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 15 Aug 2006 15:09:51 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4100LWU2KE8F@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 15 Aug 2006 15:09:50 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4100IGJ297JM@szxml03-in.huawei.com> for syslog@ietf.org; Tue, 15 Aug 2006 15:03:10 +0800 (CST) Date: Tue, 15 Aug 2006 14:59:28 +0800 From: Miao Fuyou Subject: RE: [Syslog] timeline In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA174DF3@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' Message-id: <00ad01c6c038$59f29710$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhAAAhRtsAAAtEhEA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Rainer, Stunnel is a secure wrapper for TCP stream. Actually delimiting Syslog is done in the TCP part rather than TLS (or stunnel) part in Syslog-ng with stunnel. One can use stunnel to secure any Syslog TCP transport, such as rsyslog and kiwisyslog, and kiwisyslog does use CRLF for delimiting (http://www.kiwisyslog.com/whats_new_syslog.htm). Stunnel implementation is different from Syslog TLS transport, and I don' t think it is the exact implementation of Syslog TLS transport. I have not been aware of a Syslog implementation in TLS-transport style till now. So, most of the implementation may be modified, slightly or heavily, to existing code to get it comply to the specification. Miao > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Tuesday, August 15, 2006 12:41 PM > To: Miao Fuyou > Cc: syslog@ietf.org > Subject: RE: [Syslog] timeline > > Miao, > > I am actually concerned about backward compatibility with > existing code > *without* the need to upgrade any of that code. As you know, > deployed software tends to stick. > > If we use just LF, existing, deployed technology (e.g. syslog-ng with > stunnel) would be able to understand a message sent from a "new style" > syslogd. Having the octet count in front of the message > removes that ability, as the old syslogd will no longer see > the at the start of the message. > > I agree that it is trivial to modify code to take care for > the octet counter. But this is not my concern. My concern is > that I would like to achive as good as possible compatibility > with existing deployed (aka > "unmodified") technology. I should have been more specific on that. > Sorry for the omission... > > I am also unaware of any implementation that mandates CR LF > over just LF. Could you let me know which ones are these? > > Rainer > > > -----Original Message----- > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > Sent: Monday, August 14, 2006 7:07 PM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] timeline > > > > > > Hi, Rainer, > > > > A new implementation could rely on byte-counting only and > then delete > > LF from the frame(appplication knows exactly where the LF > is), it may > > not force us to use escapes. For LF, I think it is difficult to get > > 100% compatibility for a legacy implementation to comply > TLS-transport > > without any change to the code. At least, some > imlementation may need > > to change CR LF to LF because some implementations use CR LF rather > > than LF. So, it may be ok to add several LOC to delete FRAME-LEN SP > > from the frame. > > > > I still prefer byte-counting only to byte-counting+LF even > if it is a > > feasible tradeoff. > > > > Miao > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Monday, August 14, 2006 10:18 PM > > > To: Miao Fuyou > > > Subject: RE: [Syslog] timeline > > > > > > We should not go byte-counting + LF. This is the worst choice: it > > > > > > A) breaks compatibility > > > B) Forces us to use escapes > > > > > > So we get the bad of both worlds, without any benefits. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > > Sent: Monday, August 14, 2006 12:58 AM > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; > > > syslog@ietf.org > > > > Subject: RE: [Syslog] timeline > > > > > > > > > > > > My vote: byte-counting only > byte-counting + LF > LF > > > > > > > > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 03:59:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCtpm-00031P-9u; Tue, 15 Aug 2006 03:59:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCtpk-00031K-HG for syslog@ietf.org; Tue, 15 Aug 2006 03:59:32 -0400 Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GCtpj-0008L9-6P for syslog@ietf.org; Tue, 15 Aug 2006 03:59:32 -0400 Received: (qmail 84116 invoked from network); 15 Aug 2006 07:59:29 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 15 Aug 2006 07:59:29 -0000 X-pair-Authenticated: 222.152.111.91 From: "Andrew Ross" To: "'Miao Fuyou'" , "'Rainer Gerhards'" Subject: RE: [Syslog] timeline Date: Tue, 15 Aug 2006 19:59:26 +1200 Organization: Kiwi Enterprises Message-ID: <000d01c6c040$bc4fbca0$d9a8a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <00ad01c6c038$59f29710$8c0c6f0a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Just to clarify, Kiwi Syslog V8 currently sends CRLF as the TCP = delimiter, but will accept LF, CR, CRLF, LFCR and NULL as valid delimiters on the incoming stream. We will be changing our sending delimiter to LF in the = near future to make it more compatible with syslog-ng etc. Cheers Andrew Rainer, Stunnel is a secure wrapper for TCP stream. Actually delimiting Syslog = is done in the TCP part rather than TLS (or stunnel) part in Syslog-ng with stunnel. One can use stunnel to secure any Syslog TCP transport, such as rsyslog and kiwisyslog, and kiwisyslog does use CRLF for delimiting (http://www.kiwisyslog.com/whats_new_syslog.htm).=20 Stunnel implementation is different from Syslog TLS transport, and I = don' t think it is the exact implementation of Syslog TLS transport. I have not been aware of a Syslog implementation in TLS-transport style till now. = So, most of the implementation may be modified, slightly or heavily, to = existing code to get it comply to the specification.=20 Miao > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Tuesday, August 15, 2006 12:41 PM > To: Miao Fuyou > Cc: syslog@ietf.org > Subject: RE: [Syslog] timeline >=20 > Miao, >=20 > I am actually concerned about backward compatibility with=20 > existing code > *without* the need to upgrade any of that code. As you know,=20 > deployed software tends to stick. >=20 > If we use just LF, existing, deployed technology (e.g. syslog-ng with > stunnel) would be able to understand a message sent from a "new style" > syslogd. Having the octet count in front of the message=20 > removes that ability, as the old syslogd will no longer see=20 > the at the start of the message. >=20 > I agree that it is trivial to modify code to take care for=20 > the octet counter. But this is not my concern. My concern is=20 > that I would like to achive as good as possible compatibility=20 > with existing deployed (aka > "unmodified") technology. I should have been more specific on that. > Sorry for the omission... >=20 > I am also unaware of any implementation that mandates CR LF=20 > over just LF. Could you let me know which ones are these? >=20 > Rainer=20 >=20 > > -----Original Message----- > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > Sent: Monday, August 14, 2006 7:07 PM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] timeline > >=20 > > =20 > > Hi, Rainer, > >=20 > > A new implementation could rely on byte-counting only and=20 > then delete=20 > > LF from the frame(appplication knows exactly where the LF=20 > is), it may=20 > > not force us to use escapes. For LF, I think it is difficult to get=20 > > 100% compatibility for a legacy implementation to comply=20 > TLS-transport=20 > > without any change to the code. At least, some=20 > imlementation may need=20 > > to change CR LF to LF because some implementations use CR LF rather=20 > > than LF. So, it may be ok to add several LOC to delete FRAME-LEN SP=20 > > from the frame. > >=20 > > I still prefer byte-counting only to byte-counting+LF even=20 > if it is a=20 > > feasible tradeoff. > >=20 > > Miao > >=20 > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Monday, August 14, 2006 10:18 PM > > > To: Miao Fuyou > > > Subject: RE: [Syslog] timeline > > >=20 > > > We should not go byte-counting + LF. This is the worst choice: it > > >=20 > > > A) breaks compatibility > > > B) Forces us to use escapes > > >=20 > > > So we get the bad of both worlds, without any benefits. > > >=20 > > > Rainer > > >=20 > > > > -----Original Message----- > > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > > Sent: Monday, August 14, 2006 12:58 AM > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; > > > syslog@ietf.org > > > > Subject: RE: [Syslog] timeline > > > >=20 > > > >=20 > > > > My vote: byte-counting only > byte-counting + LF > LF > > > =20 > > >=20 > >=20 > >=20 > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 07:27:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCx4W-0003Lb-Fn; Tue, 15 Aug 2006 07:27:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCx4W-0003LW-5R for syslog@ietf.org; Tue, 15 Aug 2006 07:27:00 -0400 Received: from balabit.hu ([82.141.167.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCx4S-0001Lj-R0 for syslog@ietf.org; Tue, 15 Aug 2006 07:27:00 -0400 Subject: RE: [Syslog] timeline From: Balazs Scheidler To: andrew@kiwisyslog.com In-Reply-To: <000d01c6c040$bc4fbca0$d9a8a8c0@KiwiAndrew> References: <000d01c6c040$bc4fbca0$d9a8a8c0@KiwiAndrew> Content-Type: text/plain Date: Tue, 15 Aug 2006 13:26:56 +0200 Message-Id: <1155641216.6236.18.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Tue, 2006-08-15 at 19:59 +1200, Andrew Ross wrote: > Just to clarify, Kiwi Syslog V8 currently sends CRLF as the TCP delimiter, > but will accept LF, CR, CRLF, LFCR and NULL as valid delimiters on the > incoming stream. We will be changing our sending delimiter to LF in the near > future to make it more compatible with syslog-ng etc. > syslog-ng sends LF, but accepts CRLF. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 07:28:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCx62-0003pi-2W; Tue, 15 Aug 2006 07:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCx60-0003pa-Kl for syslog@ietf.org; Tue, 15 Aug 2006 07:28:32 -0400 Received: from balabit.hu ([82.141.167.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCx5z-0001TK-8w for syslog@ietf.org; Tue, 15 Aug 2006 07:28:32 -0400 Subject: RE: [Syslog] timeline From: Balazs Scheidler To: andrew@kiwisyslog.com In-Reply-To: <1155641216.6236.18.camel@bzorp.balabit> References: <000d01c6c040$bc4fbca0$d9a8a8c0@KiwiAndrew> <1155641216.6236.18.camel@bzorp.balabit> Content-Type: text/plain Date: Tue, 15 Aug 2006 13:28:31 +0200 Message-Id: <1155641311.6236.20.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Tue, 2006-08-15 at 13:26 +0200, Balazs Scheidler wrote: > On Tue, 2006-08-15 at 19:59 +1200, Andrew Ross wrote: > > Just to clarify, Kiwi Syslog V8 currently sends CRLF as the TCP delimiter, > > but will accept LF, CR, CRLF, LFCR and NULL as valid delimiters on the > > incoming stream. We will be changing our sending delimiter to LF in the near > > future to make it more compatible with syslog-ng etc. > > > > syslog-ng sends LF, but accepts CRLF. > Ughh let me clarify. So syslog-ng sends LF in its messages, but accepts LF, CRLF and NUL characters in received messages. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 09:36:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCz65-0006u9-Cv; Tue, 15 Aug 2006 09:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCz63-0006my-TM for syslog@ietf.org; Tue, 15 Aug 2006 09:36:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCxNz-0002On-NY for syslog@ietf.org; Tue, 15 Aug 2006 07:47:07 -0400 Received: from balabit.hu ([82.141.167.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCx9j-0005aC-5U for syslog@ietf.org; Tue, 15 Aug 2006 07:32:24 -0400 Subject: Re: [Syslog] timeline From: Balazs Scheidler To: "tom.petch" In-Reply-To: <068c01c6bf8d$ede157a0$0601a8c0@pc6> References: <082101c6bca3$165a36e0$0400a8c0@china.huawei.com> <068c01c6bf8d$ede157a0$0601a8c0@pc6> Content-Type: text/plain Date: Tue, 15 Aug 2006 13:32:14 +0200 Message-Id: <1155641534.6236.22.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Mon, 2006-08-14 at 12:20 +0200, tom.petch wrote: > ----- Original Message ----- > From: "David Harrington" > To: > Sent: Thursday, August 10, 2006 7:33 PM > Subject: [Syslog] timeline > > > > > > 1) whether draft-ietf-syslog-transport-tls should use byte-counting, > > special character, or both, including which special character. We want > > to finalize this WG decision by August 18. > > LF as delimiter, no byte counting. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 13:27:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2gK-00088w-KW; Tue, 15 Aug 2006 13:26:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2gJ-00088q-Qe for syslog@ietf.org; Tue, 15 Aug 2006 13:26:23 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2gH-0001Fm-CA for syslog@ietf.org; Tue, 15 Aug 2006 13:26:23 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc14) with SMTP id <20060815172610b1400ggodle>; Tue, 15 Aug 2006 17:26:20 +0000 From: "David Harrington" To: "'Rainer Gerhards'" Date: Tue, 15 Aug 2006 13:24:32 -0400 Message-ID: <0ada01c6c08f$b29c6c90$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174DF3@grfint2.intern.adiscon.com> Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhAAAhRtsAAGBPRkA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: syslog@ietf.org Subject: [Syslog] byte-counting vs special character X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, [speaking as co-chair] Can we change the subject line to "byte-counting vs special character" for this topic so it is easier to find comments on this topic as compared to other things in the timeline? That will make it nuch easier for the chairs. This WG has already gotten stuck, and had WG progress stall, trying to provide backwards compatibility to a bunch of incompatible implementations. I argued on this list before becoming co-chair that backwarsd compatibility may not be achieveable for some features and we need to stop getting hung up on it. Sometimes to build a good standard, you need to choose something that will break some existing implementations. I raised this concern with Chris when I started as co-chair. I do not want to see backwards compatibility arguments stall progress again. I made sure this was reflected in the timeline, which says that by Friday (if you decide to use a special character) you must reach consensus on which special character to use. [/speaking as co-chair] [speaking as contributor] I like the argument that the LF solution will not break existing implementations, but I would like to know this is actually true. Have you actually tested this against multiple implementations, or is it a theoretical argument? I know you have tested a number of other proposed ways of doing things against multiple implementations to try to verify backwards compatibility. Have you actually tested multiple existing implementations with the LF and found that they do continue to work without significant problems? Can you tell the WG which ones you have tested? Are there implementations that break when using this solution? In a different message you argue that syslog-sign only needs to support -protocol because the implementations will need to have new code added anyway, and the added complexity of backwards compatibility to rfc3164 implementations is not needed. You only mention one implementation explicitly that provides syslog/tls, syslog-ng over stunnel. Would all the other implementations need to be modified to support a TLS substrate anyway, so it would not make a difference to them which special character was chosen or if byte-counting was chosen? Which syslog/tls implementations will be impacted by our choice here? Ideally, only the implementations that support a feature need to pay the price for the feature. A syslog message delineator will only be needed in implemntations that add support for syslog/tls (or other streams). Whether one supports byte-counting or a special character, only implementations that support multiple messages in a stream, e.g. syslog/tls, should need to be modified to support the choice. Personally I find the octet-counting cleaner because previous discussions on terminators showed that available implementations are highly inconsistent with their special characters. Since byte-counting happens outside the syslog message, and only for syslog in a delimited stream coming in over the syslog/tls port, it would not impact existing code, only code that supports syslog/tls. New syslog/tls code would be needed to extract each "normal" syslog message from the stream and then send it on for processing through the existing parser. If message originators start escaping special characters in the message content, existing receivers may need to be modified to un-escape the characters. Think about applications, such as intrusion detection systems, that search for special patterns in syslog content - those could be broken by having the content changed by escaping characters in the middle of the content. What happens at a store-then-forward relay? Does the relay store the escaped characters or does it un-escape them first? Does it escape them again when it forwards the message? Does it escape them if it un-escaped them on input? Does it escape them if it did not un-escape them on input? What if the sender included some escaped characaters (like '\') for other purposes? Should the relay unescape them as well? Will it know to re-escape them on output? What should the ultimate reciever expect to receive? Byte-counting looks way less complex to me than choosing a special character and escaping/unescaping special characters in the content during the sending/forwarding/recieving process. (And my opinion has nothing to do with the H**** in my email address.) dbh > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Tuesday, August 15, 2006 12:41 AM > To: Miao Fuyou > Cc: syslog@ietf.org > Subject: RE: [Syslog] timeline > > Miao, > > I am actually concerned about backward compatibility with > existing code > *without* the need to upgrade any of that code. As you know, deployed > software tends to stick. > > If we use just LF, existing, deployed technology (e.g. syslog-ng with > stunnel) would be able to understand a message sent from a "new style" > syslogd. Having the octet count in front of the message removes that > ability, as the old syslogd will no longer see the at > the start of > the message. > > I agree that it is trivial to modify code to take care for the octet > counter. But this is not my concern. My concern is that I > would like to > achive as good as possible compatibility with existing deployed (aka > "unmodified") technology. I should have been more specific on that. > Sorry for the omission... > > I am also unaware of any implementation that mandates CR LF over just > LF. Could you let me know which ones are these? > > Rainer > > > -----Original Message----- > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > Sent: Monday, August 14, 2006 7:07 PM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] timeline > > > > > > Hi, Rainer, > > > > A new implementation could rely on byte-counting only and > > then delete LF > > from the frame(appplication knows exactly where the LF is), > > it may not force > > us to use escapes. For LF, I think it is difficult to get > > 100% compatibility > > for a legacy implementation to comply TLS-transport without > > any change to > > the code. At least, some imlementation may need to change > CR LF to LF > > because some implementations use CR LF rather than LF. So, it > > may be ok to > > add several LOC to delete FRAME-LEN SP from the frame. > > > > I still prefer byte-counting only to byte-counting+LF even > if it is a > > feasible tradeoff. > > > > Miao > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Monday, August 14, 2006 10:18 PM > > > To: Miao Fuyou > > > Subject: RE: [Syslog] timeline > > > > > > We should not go byte-counting + LF. This is the worst choice: it > > > > > > A) breaks compatibility > > > B) Forces us to use escapes > > > > > > So we get the bad of both worlds, without any benefits. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > > Sent: Monday, August 14, 2006 12:58 AM > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; > > > syslog@ietf.org > > > > Subject: RE: [Syslog] timeline > > > > > > > > > > > > My vote: byte-counting only > byte-counting + LF > LF > > > > > > > > > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 13:56:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD39N-00019s-U4; Tue, 15 Aug 2006 13:56:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD39M-00019n-FH for syslog@ietf.org; Tue, 15 Aug 2006 13:56:24 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD39K-00037t-4V for syslog@ietf.org; Tue, 15 Aug 2006 13:56:24 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 15 Aug 2006 11:56:21 -0600 Message-Id: <44E1B663.37FF.0081.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Tue, 15 Aug 2006 11:56:19 -0600 From: "John Calcote" To: "David Harrington" , Subject: RE: [Syslog] timeline References: <98AE08B66FAD1742BED6CB9522B7312201C96AC9@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <98AE08B66FAD1742BED6CB9522B7312201C96AC9@xmb-rtp-20d.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I vote for byte counting an no magic character. I'm sorry for the backward compatibility problems this may introduce, but things should move ahead, and providing a solid standard is one of the best ways to do this. John >>> "Anton Okmianski (aokmians)" 8/11/2006 9:26 AM >>> > Here are two things we need to resolve soon. > > 1) whether draft-ietf-syslog-transport-tls should use > byte-counting, special character, or both, including which > special character. We want to finalize this WG decision by August 18. My vote is for byte-counting and no magic characters. Anton. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 14:09:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3M3-0004qQ-B9; Tue, 15 Aug 2006 14:09:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3M2-0004qA-2g for syslog@ietf.org; Tue, 15 Aug 2006 14:09:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD3M0-0003kC-Ci for syslog@ietf.org; Tue, 15 Aug 2006 14:09:30 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 15 Aug 2006 11:08:27 -0700 X-IronPort-AV: i="4.08,128,1154934000"; d="scan'208"; a="1847238314:sNHT38969622" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7FI8RFL012323; Tue, 15 Aug 2006 11:08:27 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7FI8QcJ010227; Tue, 15 Aug 2006 11:08:26 -0700 (PDT) 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.1830); Tue, 15 Aug 2006 14:08:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] byte-counting vs special character Date: Tue, 15 Aug 2006 14:04:43 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B7312201C971AC@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] byte-counting vs special character Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhAAAhRtsAAGBPRkAADLZzw From: "Anton Okmianski \(aokmians\)" To: "David Harrington" , "Rainer Gerhards" X-OriginalArrivalTime: 15 Aug 2006 18:08:26.0466 (UTC) FILETIME=[CDF4A420:01C6C095] DKIM-Signature: a=rsa-sha1; q=dns; l=9870; t=1155665307; x=1156529307; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20byte-counting=20vs=20special=20character; X=v=3Dcisco.com=3B=20h=3DTxnSog6XPLJHf+1tx6kuXe3wy1U=3D; b=Q/AIsdyaSVWxDnh+n/7gSFVqhQ7mnvQEoPorh4uAdxQCN21HBdHtHC3PK9+NwmY1dPF0+eD7 8fNBNEbQShdhjVxvQifDggBeHvYLmOdDCY1WJzmyjzUPIbgRDahabbXY; Authentication-Results: sj-dkim-7.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I second these concerns. Escaping requirements result in a more interdependent layering, which is a weaker architecture (not to mention the overhead to a new standard). The syslog transport would need to mess with payload instead of treating it as opaque blob with easily known length. Not nice. Imagine TCP/IP escaping all payload to separate datagrams and segments. Escaping of magic characters is IMHO clearly a hack and should not be put into a standard! If the argument was to accommodate some real established standard and there was no way to version things - maybe. Current syslog is not standardized (not in IETF, not in reality). The transition to a cleaner design is trivial. A given implementation can support whatever legacy compatibility modes it wishes to support. Syslog is sent to a known destination configured by administrator, not some kind of broadcast to world-wide-web where you don't know what kind of receiver will get it. This problem is easily administrated in mixed legacy/standard environment if someone chooses to deploy one. =20 Anton. =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Tuesday, August 15, 2006 1:25 PM > To: 'Rainer Gerhards' > Cc: syslog@ietf.org > Subject: [Syslog] byte-counting vs special character >=20 > Hi Rainer, >=20 > [speaking as co-chair] > Can we change the subject line to "byte-counting vs special character" > for this topic so it is easier to find comments on this topic=20 > as compared to other things in the timeline? That will make=20 > it nuch easier for the chairs. >=20 > This WG has already gotten stuck, and had WG progress stall,=20 > trying to provide backwards compatibility to a bunch of=20 > incompatible implementations. I argued on this list before=20 > becoming co-chair that backwarsd compatibility may not be=20 > achieveable for some features and we need to stop getting=20 > hung up on it. Sometimes to build a good standard, you need=20 > to choose something that will break some existing implementations.=20 >=20 > I raised this concern with Chris when I started as co-chair.=20 > I do not want to see backwards compatibility arguments stall=20 > progress again. I made sure this was reflected in the=20 > timeline, which says that by Friday (if you decide to use a=20 > special character) you must reach consensus on which special=20 > character to use. > [/speaking as co-chair] >=20 > [speaking as contributor] > I like the argument that the LF solution will not break=20 > existing implementations, but I would like to know this is=20 > actually true. Have you actually tested this against multiple=20 > implementations, or is it a theoretical argument? >=20 > I know you have tested a number of other proposed ways of=20 > doing things against multiple implementations to try to=20 > verify backwards compatibility. Have you actually tested=20 > multiple existing implementations with the LF and found that=20 > they do continue to work without significant problems? Can=20 > you tell the WG which ones you have tested? Are there=20 > implementations that break when using this solution? >=20 >=20 > In a different message you argue that syslog-sign only needs=20 > to support -protocol because the implementations will need to=20 > have new code added anyway, and the added complexity of=20 > backwards compatibility to rfc3164 implementations is not needed. >=20 > You only mention one implementation explicitly that provides=20 > syslog/tls, syslog-ng over stunnel. Would all the other=20 > implementations need to be modified to support a TLS=20 > substrate anyway, so it would not make a difference to them=20 > which special character was chosen or if byte-counting was=20 > chosen? Which syslog/tls implementations will be impacted by=20 > our choice here?=20 >=20 > Ideally, only the implementations that support a feature need=20 > to pay the price for the feature. >=20 > A syslog message delineator will only be needed in=20 > implemntations that add support for syslog/tls (or other=20 > streams). Whether one supports byte-counting or a special=20 > character, only implementations that support multiple=20 > messages in a stream, e.g. syslog/tls, should need to be=20 > modified to support the choice.=20 >=20 > Personally I find the octet-counting cleaner because previous=20 > discussions on terminators showed that available=20 > implementations are highly inconsistent with their special=20 > characters.=20 >=20 > Since byte-counting happens outside the syslog message, and=20 > only for syslog in a delimited stream coming in over the=20 > syslog/tls port, it would not impact existing code, only code=20 > that supports syslog/tls. > New syslog/tls code would be needed to extract each "normal"=20 > syslog message from the stream and then send it on for=20 > processing through the existing parser.=20 >=20 > If message originators start escaping special characters in=20 > the message content, existing receivers may need to be=20 > modified to un-escape the characters. Think about=20 > applications, such as intrusion detection systems, that=20 > search for special patterns in syslog content > - those could be broken by having the content changed by=20 > escaping characters in the middle of the content. >=20 > What happens at a store-then-forward relay? Does the relay=20 > store the escaped characters or does it un-escape them first?=20 > Does it escape them again when it forwards the message? Does=20 > it escape them if it un-escaped them on input? Does it escape=20 > them if it did not un-escape them on input? What if the=20 > sender included some escaped characaters (like '\') for other=20 > purposes? Should the relay unescape them as well? > Will it know to re-escape them on output? What should the=20 > ultimate reciever expect to receive? >=20 > Byte-counting looks way less complex to me than choosing a=20 > special character and escaping/unescaping special characters=20 > in the content during the sending/forwarding/recieving=20 > process. (And my opinion has nothing to do with the H**** in=20 > my email address.) >=20 > dbh >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Tuesday, August 15, 2006 12:41 AM > > To: Miao Fuyou > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] timeline > >=20 > > Miao, > >=20 > > I am actually concerned about backward compatibility with existing=20 > > code > > *without* the need to upgrade any of that code. As you know, > deployed > > software tends to stick. > >=20 > > If we use just LF, existing, deployed technology (e.g. syslog-ng > with > > stunnel) would be able to understand a message sent from a "new > style" > > syslogd. Having the octet count in front of the message=20 > removes that=20 > > ability, as the old syslogd will no longer see the at=20 > the start=20 > > of the message. > >=20 > > I agree that it is trivial to modify code to take care for=20 > the octet=20 > > counter. But this is not my concern. My concern is that I=20 > would like=20 > > to achive as good as possible compatibility with existing deployed=20 > > (aka > > "unmodified") technology. I should have been more specific on that. > > Sorry for the omission... > >=20 > > I am also unaware of any implementation that mandates CR LF over > just > > LF. Could you let me know which ones are these? > >=20 > > Rainer > >=20 > > > -----Original Message----- > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > Sent: Monday, August 14, 2006 7:07 PM > > > To: Rainer Gerhards > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] timeline > > >=20 > > > =20 > > > Hi, Rainer, > > >=20 > > > A new implementation could rely on byte-counting only and then=20 > > > delete LF from the frame(appplication knows exactly where the LF=20 > > > is), it may not force us to use escapes. For LF, I think it is=20 > > > difficult to get 100% compatibility for a legacy=20 > implementation to=20 > > > comply TLS-transport without any change to the code. At=20 > least, some=20 > > > imlementation may need to change > > CR LF to LF > > > because some implementations use CR LF rather than LF.=20 > So, it may be=20 > > > ok to add several LOC to delete FRAME-LEN SP from the frame. > > >=20 > > > I still prefer byte-counting only to byte-counting+LF even > > if it is a > > > feasible tradeoff. =20 > > >=20 > > > Miao > > >=20 > > > > -----Original Message----- > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > > Sent: Monday, August 14, 2006 10:18 PM > > > > To: Miao Fuyou > > > > Subject: RE: [Syslog] timeline > > > >=20 > > > > We should not go byte-counting + LF. This is the worst choice: > it=20 > > > >=20 > > > > A) breaks compatibility > > > > B) Forces us to use escapes > > > >=20 > > > > So we get the bad of both worlds, without any benefits. > > > >=20 > > > > Rainer > > > >=20 > > > > > -----Original Message----- > > > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > > > Sent: Monday, August 14, 2006 12:58 AM > > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; > > > > syslog@ietf.org > > > > > Subject: RE: [Syslog] timeline > > > > >=20 > > > > >=20 > > > > > My vote: byte-counting only > byte-counting + LF > LF > > > > =20 > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 14:44:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3sk-00074H-Pw; Tue, 15 Aug 2006 14:43:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3sk-00074C-31 for syslog@ietf.org; Tue, 15 Aug 2006 14:43:18 -0400 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD3sh-0006Bq-MR for syslog@ietf.org; Tue, 15 Aug 2006 14:43:18 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc11) with SMTP id <20060815184315b11000r83ue>; Tue, 15 Aug 2006 18:43:15 +0000 From: "David Harrington" To: Date: Tue, 15 Aug 2006 14:41:37 -0400 Message-ID: <0ae601c6c09a$713c1f60$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Subject: [Syslog] Working Group Last Call: protocol and udp documents X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I am resending this message with a new subject line, in case anybody is watching for the words "working group last call" in the subject line. It's also easier for me for bookkeeping reasons ;-) David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Monday, August 14, 2006 7:33 PM To: 'Chris Lonvick'; syslog@ietf.org Subject: RE: [Syslog] syslog WG Timeline Hi, This message officially starts the Syslog Working Group Last Call for the following two documents: draft-ietf-syslog-protocol: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt draft-ietf-syslog-transport-udp: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt The Working Group Last Call for these documents will end August 28. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, it if does not look acceptable please identify your ibjections, preferably with suggested text that would make it acceptable. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, August 11, 2006 3:17 PM > To: syslog@ietf.org > Subject: [Syslog] syslog WG Timeline > > Hi Folks, > > David and I have agreed upon a timeline for the completion of our > milestones. Please review this. We will be asking for > people to provide > review comments on each of the documents while they are in > Working Group > Last Call (WGLC). If you know that you're going to be > unavailable (summer > vacation) for some of these WGLCs, please submit comments to the WG > beforehand, at least to let us know that you've read it. > > Thanks, > Chris and David > > > ===start=== > > Aug 11 - Drive discussion on whether draft-ietf-syslog-device-mib > represents WG consensus on what needs to be managed in > -protocol-, -udp-, -tls-, and -sign-. > Aug 11 - Drive discussion on whether draft-ietf-syslog-transport-tls > should use byte-counting, special character, or > both, including > which special character. > > Aug 14 - Begin WG Last Call for draft-ietf-syslog-protocol (45 pages) > Aug 14 - Begin WG Last Call for draft-ietf-syslog-transport-udp (10 > pages) > > Aug 18 - Decide what needs to be changed in > draft-ietf-syslog-transport-tls to represent the final WG > consensus on byte-counting, special character, or > both, including > which special character. > Aug 18 - Decide what needs to be changed in the general design of > draft-ietf-syslog-device-mib to represent the WG consensus. > > Aug 28 - Close WG Last Call for draft-ietf-syslog-protocol > Aug 28 - Close WG Last Call for draft-ietf-syslog-transport-udp > > Aug 28 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > > Sep 1 - updated revision of draft-ietf-syslog-transport-tls, > representing WG consensus. > Sep 1 - updated revision of draft-ietf-syslog-device-mib, representing > WG consensus. > > Aug 28 - Begin WG Last Call for draft-ietf-syslog-sign (33 pages) > Aug 28 - Begin WG Last Call for draft-ietf-syslog-transport-tls (11 > pages) > > > Sep 11 - Close WG Last Call for draft-ietf-syslog-sign. > Sep 11 - Close WG Last Call for draft-ietf-syslog-transport-tls. > > Sep 11 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-sign > > Sep 11 - Begin WG Last Call for draft-ietf-syslog-device-mib (33 > pages) > > Sep 25 - Close WG Last Call for draft-ietf-syslog-device-mib. > Sep 25 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-device-mib > > Oct 16 - Chairs produce Shepherding Documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-device-mib > - draft-ietf-syslog-sign > > Oct 23 - Final review of Spepherding Documents by the WG > > Nov 1 - Submit the following to the IESG > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-device-mib > - draft-ietf-syslog-sign > > ===end=== > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 16:20:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD5O2-0000mM-Uh; Tue, 15 Aug 2006 16:19:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD5O2-0000lR-2O for syslog@ietf.org; Tue, 15 Aug 2006 16:19:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD0aW-0001mG-2N for syslog@ietf.org; Tue, 15 Aug 2006 11:12:16 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCzse-0008UQ-Vc for syslog@ietf.org; Tue, 15 Aug 2006 10:27:13 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 0F1449C00C; Tue, 15 Aug 2006 16:28:05 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17871-01; Tue, 15 Aug 2006 16:27:57 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id D784B9C00B; Tue, 15 Aug 2006 16:27:57 +0200 (CEST) Subject: RE: [Syslog] timeline Date: Tue, 15 Aug 2006 16:26:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DF8@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message In-Reply-To: <00ad01c6c038$59f29710$8c0c6f0a@china.huawei.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] timeline Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhAAAhRtsAAAtEhEAARtJ0A From: "Rainer Gerhards" To: "Miao Fuyou" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Miao, Rsyslog accepts CRLF, and can even be configured to emit it. I have no access to a lab. Could you please clarify where exactly -transport-tls is unable to work with currently existing deployments using stunnel? I would greatly appreciate insight as I can not try it out for a while (and I am also unable to do any in-depth analysis). Thanks, Rainer=20 > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Tuesday, August 15, 2006 12:59 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] timeline >=20 >=20 > Rainer, >=20 > Stunnel is a secure wrapper for TCP stream. Actually=20 > delimiting Syslog is > done in the TCP part rather than TLS (or stunnel) part in=20 > Syslog-ng with > stunnel. One can use stunnel to secure any Syslog TCP=20 > transport, such as > rsyslog and kiwisyslog, and kiwisyslog does use CRLF for delimiting > (http://www.kiwisyslog.com/whats_new_syslog.htm).=20 >=20 > Stunnel implementation is different from Syslog TLS=20 > transport, and I don' t > think it is the exact implementation of Syslog TLS transport.=20 > I have not > been aware of a Syslog implementation in TLS-transport style=20 > till now. So, > most of the implementation may be modified, slightly or=20 > heavily, to existing > code to get it comply to the specification.=20 >=20 > Miao >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Tuesday, August 15, 2006 12:41 PM > > To: Miao Fuyou > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] timeline > >=20 > > Miao, > >=20 > > I am actually concerned about backward compatibility with=20 > > existing code > > *without* the need to upgrade any of that code. As you know,=20 > > deployed software tends to stick. > >=20 > > If we use just LF, existing, deployed technology (e.g.=20 > syslog-ng with > > stunnel) would be able to understand a message sent from a=20 > "new style" > > syslogd. Having the octet count in front of the message=20 > > removes that ability, as the old syslogd will no longer see=20 > > the at the start of the message. > >=20 > > I agree that it is trivial to modify code to take care for=20 > > the octet counter. But this is not my concern. My concern is=20 > > that I would like to achive as good as possible compatibility=20 > > with existing deployed (aka > > "unmodified") technology. I should have been more specific on that. > > Sorry for the omission... > >=20 > > I am also unaware of any implementation that mandates CR LF=20 > > over just LF. Could you let me know which ones are these? > >=20 > > Rainer=20 > >=20 > > > -----Original Message----- > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > Sent: Monday, August 14, 2006 7:07 PM > > > To: Rainer Gerhards > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] timeline > > >=20 > > > =20 > > > Hi, Rainer, > > >=20 > > > A new implementation could rely on byte-counting only and=20 > > then delete=20 > > > LF from the frame(appplication knows exactly where the LF=20 > > is), it may=20 > > > not force us to use escapes. For LF, I think it is=20 > difficult to get=20 > > > 100% compatibility for a legacy implementation to comply=20 > > TLS-transport=20 > > > without any change to the code. At least, some=20 > > imlementation may need=20 > > > to change CR LF to LF because some implementations use CR=20 > LF rather=20 > > > than LF. So, it may be ok to add several LOC to delete=20 > FRAME-LEN SP=20 > > > from the frame. > > >=20 > > > I still prefer byte-counting only to byte-counting+LF even=20 > > if it is a=20 > > > feasible tradeoff. > > >=20 > > > Miao > > >=20 > > > > -----Original Message----- > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > > Sent: Monday, August 14, 2006 10:18 PM > > > > To: Miao Fuyou > > > > Subject: RE: [Syslog] timeline > > > >=20 > > > > We should not go byte-counting + LF. This is the worst=20 > choice: it > > > >=20 > > > > A) breaks compatibility > > > > B) Forces us to use escapes > > > >=20 > > > > So we get the bad of both worlds, without any benefits. > > > >=20 > > > > Rainer > > > >=20 > > > > > -----Original Message----- > > > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > > > Sent: Monday, August 14, 2006 12:58 AM > > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; > > > > syslog@ietf.org > > > > > Subject: RE: [Syslog] timeline > > > > >=20 > > > > >=20 > > > > > My vote: byte-counting only > byte-counting + LF > LF > > > > =20 > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 16:49:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD5qA-0003OQ-Uz; Tue, 15 Aug 2006 16:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD5qA-0003OD-0a for syslog@ietf.org; Tue, 15 Aug 2006 16:48:46 -0400 Received: from dsl081-242-052.sfo1.dsl.speakeasy.net ([64.81.242.52] helo=gandalf.taltos.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD5q9-0000iU-AH for syslog@ietf.org; Tue, 15 Aug 2006 16:48:45 -0400 Received: from gandalf.taltos.org (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id 894ED21C14 for ; Tue, 15 Aug 2006 13:48:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on gandalf.taltos.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.168.1.2] (unknown [192.168.1.2]) by gandalf.taltos.org (Postfix) with ESMTP id 872A121B73 for ; Tue, 15 Aug 2006 13:48:38 -0700 (PDT) Date: Tue, 15 Aug 2006 13:50:40 -0700 From: Carson Gaspar To: syslog@ietf.org Subject: RE: [Syslog] byte-counting vs special character Message-ID: In-Reply-To: <98AE08B66FAD1742BED6CB9522B7312201C971AC@xmb-rtp-20d.amer.cisco.com> References: <98AE08B66FAD1742BED6CB9522B7312201C971AC@xmb-rtp-20d.amer.cisco .com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I've been mostly lurking lately, but I would like to re-iterate my support for byte counting. It's the Right Thing To Do, and theoretical "backwards compatibility" with existing non-standard non-widely-deployed syslog over TCP solutions isn't a good enough reason to put bad ideas in the standard. --On Tuesday, August 15, 2006 2:04 PM -0400 "Anton Okmianski (aokmians)" wrote: > I second these concerns. Escaping requirements result in a more > interdependent layering, which is a weaker architecture (not to mention > the overhead to a new standard). The syslog transport would need to mess > with payload instead of treating it as opaque blob with easily known > length. Not nice. Imagine TCP/IP escaping all payload to separate > datagrams and segments. > > Escaping of magic characters is IMHO clearly a hack and should not be > put into a standard! If the argument was to accommodate some real > established standard and there was no way to version things - maybe. > Current syslog is not standardized (not in IETF, not in reality). The > transition to a cleaner design is trivial. A given implementation can > support whatever legacy compatibility modes it wishes to support. Syslog > is sent to a known destination configured by administrator, not some > kind of broadcast to world-wide-web where you don't know what kind of > receiver will get it. This problem is easily administrated in mixed > legacy/standard environment if someone chooses to deploy one. > > Anton. > >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Tuesday, August 15, 2006 1:25 PM >> To: 'Rainer Gerhards' >> Cc: syslog@ietf.org >> Subject: [Syslog] byte-counting vs special character >> >> Hi Rainer, >> >> [speaking as co-chair] >> Can we change the subject line to "byte-counting vs special character" >> for this topic so it is easier to find comments on this topic >> as compared to other things in the timeline? That will make >> it nuch easier for the chairs. >> >> This WG has already gotten stuck, and had WG progress stall, >> trying to provide backwards compatibility to a bunch of >> incompatible implementations. I argued on this list before >> becoming co-chair that backwarsd compatibility may not be >> achieveable for some features and we need to stop getting >> hung up on it. Sometimes to build a good standard, you need >> to choose something that will break some existing implementations. >> >> I raised this concern with Chris when I started as co-chair. >> I do not want to see backwards compatibility arguments stall >> progress again. I made sure this was reflected in the >> timeline, which says that by Friday (if you decide to use a >> special character) you must reach consensus on which special >> character to use. >> [/speaking as co-chair] >> >> [speaking as contributor] >> I like the argument that the LF solution will not break >> existing implementations, but I would like to know this is >> actually true. Have you actually tested this against multiple >> implementations, or is it a theoretical argument? >> >> I know you have tested a number of other proposed ways of >> doing things against multiple implementations to try to >> verify backwards compatibility. Have you actually tested >> multiple existing implementations with the LF and found that >> they do continue to work without significant problems? Can >> you tell the WG which ones you have tested? Are there >> implementations that break when using this solution? >> >> >> In a different message you argue that syslog-sign only needs >> to support -protocol because the implementations will need to >> have new code added anyway, and the added complexity of >> backwards compatibility to rfc3164 implementations is not needed. >> >> You only mention one implementation explicitly that provides >> syslog/tls, syslog-ng over stunnel. Would all the other >> implementations need to be modified to support a TLS >> substrate anyway, so it would not make a difference to them >> which special character was chosen or if byte-counting was >> chosen? Which syslog/tls implementations will be impacted by >> our choice here? >> >> Ideally, only the implementations that support a feature need >> to pay the price for the feature. >> >> A syslog message delineator will only be needed in >> implemntations that add support for syslog/tls (or other >> streams). Whether one supports byte-counting or a special >> character, only implementations that support multiple >> messages in a stream, e.g. syslog/tls, should need to be >> modified to support the choice. >> >> Personally I find the octet-counting cleaner because previous >> discussions on terminators showed that available >> implementations are highly inconsistent with their special >> characters. >> >> Since byte-counting happens outside the syslog message, and >> only for syslog in a delimited stream coming in over the >> syslog/tls port, it would not impact existing code, only code >> that supports syslog/tls. >> New syslog/tls code would be needed to extract each "normal" >> syslog message from the stream and then send it on for >> processing through the existing parser. >> >> If message originators start escaping special characters in >> the message content, existing receivers may need to be >> modified to un-escape the characters. Think about >> applications, such as intrusion detection systems, that >> search for special patterns in syslog content >> - those could be broken by having the content changed by >> escaping characters in the middle of the content. >> >> What happens at a store-then-forward relay? Does the relay >> store the escaped characters or does it un-escape them first? >> Does it escape them again when it forwards the message? Does >> it escape them if it un-escaped them on input? Does it escape >> them if it did not un-escape them on input? What if the >> sender included some escaped characaters (like '\') for other >> purposes? Should the relay unescape them as well? >> Will it know to re-escape them on output? What should the >> ultimate reciever expect to receive? >> >> Byte-counting looks way less complex to me than choosing a >> special character and escaping/unescaping special characters >> in the content during the sending/forwarding/recieving >> process. (And my opinion has nothing to do with the H**** in >> my email address.) >> >> dbh >> >> > -----Original Message----- >> > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] >> > Sent: Tuesday, August 15, 2006 12:41 AM >> > To: Miao Fuyou >> > Cc: syslog@ietf.org >> > Subject: RE: [Syslog] timeline >> > >> > Miao, >> > >> > I am actually concerned about backward compatibility with existing >> > code >> > *without* the need to upgrade any of that code. As you know, >> deployed >> > software tends to stick. >> > >> > If we use just LF, existing, deployed technology (e.g. syslog-ng >> with >> > stunnel) would be able to understand a message sent from a "new >> style" >> > syslogd. Having the octet count in front of the message >> removes that >> > ability, as the old syslogd will no longer see the at >> the start >> > of the message. >> > >> > I agree that it is trivial to modify code to take care for >> the octet >> > counter. But this is not my concern. My concern is that I >> would like >> > to achive as good as possible compatibility with existing deployed >> > (aka >> > "unmodified") technology. I should have been more specific on that. >> > Sorry for the omission... >> > >> > I am also unaware of any implementation that mandates CR LF over >> just >> > LF. Could you let me know which ones are these? >> > >> > Rainer >> > >> > > -----Original Message----- >> > > From: Miao Fuyou [mailto:miaofy@huawei.com] >> > > Sent: Monday, August 14, 2006 7:07 PM >> > > To: Rainer Gerhards >> > > Cc: syslog@ietf.org >> > > Subject: RE: [Syslog] timeline >> > > >> > > >> > > Hi, Rainer, >> > > >> > > A new implementation could rely on byte-counting only and then >> > > delete LF from the frame(appplication knows exactly where the LF >> > > is), it may not force us to use escapes. For LF, I think it is >> > > difficult to get 100% compatibility for a legacy >> implementation to >> > > comply TLS-transport without any change to the code. At >> least, some >> > > imlementation may need to change >> > CR LF to LF >> > > because some implementations use CR LF rather than LF. >> So, it may be >> > > ok to add several LOC to delete FRAME-LEN SP from the frame. >> > > >> > > I still prefer byte-counting only to byte-counting+LF even >> > if it is a >> > > feasible tradeoff. >> > > >> > > Miao >> > > >> > > > -----Original Message----- >> > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] >> > > > Sent: Monday, August 14, 2006 10:18 PM >> > > > To: Miao Fuyou >> > > > Subject: RE: [Syslog] timeline >> > > > >> > > > We should not go byte-counting + LF. This is the worst choice: >> it >> > > > >> > > > A) breaks compatibility >> > > > B) Forces us to use escapes >> > > > >> > > > So we get the bad of both worlds, without any benefits. >> > > > >> > > > Rainer >> > > > >> > > > > -----Original Message----- >> > > > > From: Miao Fuyou [mailto:miaofy@huawei.com] >> > > > > Sent: Monday, August 14, 2006 12:58 AM >> > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; >> > > > syslog@ietf.org >> > > > > Subject: RE: [Syslog] timeline >> > > > > >> > > > > >> > > > > My vote: byte-counting only > byte-counting + LF > LF >> > > > >> > > > >> > > >> > > >> > > >> > >> > _______________________________________________ >> > Syslog mailing list >> > Syslog@lists.ietf.org >> > https://www1.ietf.org/mailman/listinfo/syslog >> > >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 15 20:24:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD9Bj-0006rR-Sc; Tue, 15 Aug 2006 20:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD9Bi-0006rM-BI for syslog@ietf.org; Tue, 15 Aug 2006 20:23:14 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD9Bh-0003FU-Sz for syslog@ietf.org; Tue, 15 Aug 2006 20:23:14 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc12) with SMTP id <20060816002312b1200se533e>; Wed, 16 Aug 2006 00:23:13 +0000 From: "David Harrington" To: Date: Tue, 15 Aug 2006 20:21:35 -0400 Message-ID: <0b4e01c6c0c9$ef25f700$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbAye5nX/6MyTgHSY2bGGKvmBcxKQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: Subject: [Syslog] WGLC: protocol X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Here is my review of the protocol-17 document. Let me apologize (slightly) for such a thorough review, late in the process, but as co-chair I need to say I reviewed this thoroughly and that I agree it is ready to be published as a standard. I am much pickier about a document I will sign-off as co-chair than one I accept as a casual WG participant. For the most part, this review focuses on publication and standardization requirements rather than on the technical design of the protocol. I plan to do that review separately, and consider the WG members more competent in syslog specifics than me. >From the standpoint of what I reviewed, this document generally looks good. dbh -- idnits -- The document has the correct IPR boilerplates, RFC2119 boilerplate, and the document passes the automated idnits tool. Idnits found two reference problems that should be addressed. Reference [2] is never used in the text. Reference [17] is never used in the text. -- xml2rfc validation -- Since the source for this document is written in xml2rfc format, the RFC editor will request that you submit a copy of the xml2rfc source with the document to be published. It is a good thing if the sources used to publish the final document are consisteent with the copy we have for future update work, so it is a good thing to fix any known problems in the xml2rfc source before submitting it to the RFC editor. The rfc editor typically does not return their edited version to us. The xml2rfc-validator tool at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi identified a number of usages that are invalid according to the rfc2629.dtd, and some usages that have been deprecated or obsoleted by the xml2rfc tool. The xml2rfc tool will still accept these on the basis of being liberal in what it accepts, but we should also be conservative in what we send. It would be good to fix all these errors and warnings. -- References -- The xml2rfc-validator tool at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi identified some obsolete references: RFC 2234 has been obsoleted by RFC4234 RFC 3513 has been obsoleted by RFC4291 6.2.1.1 says The Alarm MIB defines ITU perceived severities. Actually, don't ITU M.3100 and X.733 define the severities, and the Alarm MIB just uses them? I don't have a copy of M.3100 or X.733, so I cannot check this; can somebody check this? I think we should reference the original definition, and then we can point out that the Alarm MIB references the ITU severities as well. According to RFC3877, the references are "ITU Recommendation M.3100, 'Generic Network Information Model', 1995" and "ITU Recommendation X.733, 'Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function', 1992" -- RFC2119 language -- Section 5 states the UDP "transport is REQUIRED for interoperability ...". I think this might be better phrased as the UDP "transport is mandatory to implement for compliance to the standard to support interoperability ..." or remove the sentence since the next section discusses the minimum required transport mapping. In section 5.1, it says "This ensures interoperability ...". This might be better stated as "This ensures at least a minimum interoperability ..." Section 6 is entitled "Required syslog format". I suggest making it simply "Syslog Message Format". Section 6.1: "After trucation, the message MAY contain invalid UTF-8 encoding or invalid STRUCTURED-DATA." Does this need an addendum to standardize subsequent behavior? If the truncated message now contains invalid content, should the whole message be discarded, or should the receiver try to process as much as it can, even if it is incomplete, and the results of subsequent processing could be misleading to an operator? 6.2.1: "A receiver MUST NOT assume any specific semantics by default." I think this fails the RFC2119 test - RFC2119 keywords MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm; this assumption would happen after the message came off the wire, so should not impact interoperability on-the-wire, and it should have no effect on behavior such as retransmission. Obviously, a management application might cause a configuration change based on a faulty assumption, but I don't think that is a protocol issue. I think the maximum RFC2119 language here would be a SHOULD NOT. 6.2.5 This section should mention that APP-NAME is an operator-configured value, which justifies the use of SHOULD rather than MUST here. 6.2.6 if operator-configured, then ditto. 6.2.7 if operator-configured, then ditto. 6.3.2 "to be assigned by IETF CONSENSUS" should include a reference to BCP26 (RFC2434), since IETF CONSENSUS has a specific meaning defined in the BCP. 6.3.4 "An exception is the addition of a new OPTIONAL PARAM-NAME to an existing SD-ID, what MAY be done." This strikes me as incorrect English grammar; I recommend rewording it. Here is some suggested text: "OPTIONAL PARAM-NAMEs MAY be added to an existing SD-ID." 7.2.1 Can it list an ip address in the "ip" parameter AND provide a list of multiple "ip" parameters in an "origin" element? If not, why not? Wouldn't it be useful to provide the "origin" list, but also to identify its "preferred" address for syslog purposes in "ip"? 7.2.3 "It always contains the name of the generating software," - should this one be MUST? "whereas APP-NAME can contain anything else, including an operator-configured value." Section 6.2.5 should mention that APP-NAME is an operator-configured value. If the software parameter contains UTF-8, then it is important to specify the maximum length of strings in octets rather than characters, since characters can be multi-byte. 7.2.4 If the swVersion parameter contains UTF-8, then it is important to specify the maximum length of strings in octets rather than characters, since characters can be multi-byte. -- spelling -- /parsable/parseable/g neither MS-Word nor Merriam-Webster recognizes either spelling. Wikipedia supports parseable under parsing. computing-dictionary.thefreedictionary.com supports parseable. Apparently the Oxford dictionary supports parseable, based on a discussion at apache.org, but I don't have a subscription to check it. /trucation/truncation /conceptionally/conceptually/ /mimimize/minimize/ /timezone/time zone/g according to MS-Word and Mirriam-Webster online /implementor/implementer/g for consistency with rfc-editor boilerplate text. /any-enterprise assigned/any enterprise-assigned/ enterpriseId or enterpriseID - inconsistent usage. 6.2.4 "described in RFC 3513" should this be ", as described in RFC 3513"? 7.2.2 "Only that number and any-enterprise assigned ID below it MUST be specified in the "enterpriseId" parameter." seems awkward. Would this be better as "An enterprise is only authorized to assign values within the iso.org.dod.internet.private.enterprise. subtree assigned by IANA to that enterprise. The enterpriseId MUST contain only a value from the iso.org.dod.internet.private.enterprise. subtree." 7.3.2 /integer/INTEGER/ Note that the semantics in RFC3418 are "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." This of course relates to the SNMP-related management portion of the system, which MAY be different than the syslog-related management portion of the system. -- security considerations Good job describing the potential configuration issues. Since the transport documents will describe the threat models, it is probably acceptable that the threat model is not covered here in the terminology recommended by rfc3552. -- IANA considerations -- Good. -- Authors -- We now have a syslog@ietf.org mailing list adddress. That should be used rather than the employees.org address. You should identify that I work for Huawei Technologies USA. -- Acknowledgment -- The funding acknowledgment for the RFC Editor function is out of date, but the latest xml2rfc tool corrects it to acknowledge the IASA rather than the Internet Society. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 01:39:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDE6U-0005uL-Ew; Wed, 16 Aug 2006 01:38:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDE6T-0005uG-5d for syslog@ietf.org; Wed, 16 Aug 2006 01:38:09 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDE6Q-0001je-5a for syslog@ietf.org; Wed, 16 Aug 2006 01:38:09 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 7D2FD9C00C; Wed, 16 Aug 2006 07:39:33 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18328-06; Wed, 16 Aug 2006 07:39:27 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id DBAF29C00B; Wed, 16 Aug 2006 07:39:27 +0200 (CEST) Subject: RE: [Syslog] WGLC: protocol MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Aug 2006 07:37:58 +0200 Content-class: urn:content-classes:message Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DFC@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <0b4e01c6c0c9$ef25f700$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] WGLC: protocol Thread-Index: AcbAye5nX/6MyTgHSY2bGGKvmBcxKQAGY+ug From: "Rainer Gerhards" To: "David Harrington" , X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Rainer PS: I might be offline tomorrow... > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Tuesday, August 15, 2006 6:22 PM > To: syslog@ietf.org > Subject: [Syslog] WGLC: protocol >=20 > Hi, >=20 > Here is my review of the protocol-17 document.=20 >=20 > Let me apologize (slightly) for such a thorough review, Nothing to apologize, I am glad it happened. I just feared it would occur when I have the least ability to do serious work. Anyhow, I have been able to edit it. Find comments inline... > late in the > process, but as co-chair I need to say I reviewed this thoroughly and > that I agree it is ready to be published as a standard. I am much > pickier about a document I will sign-off as co-chair than one I accept > as a casual WG participant. >=20 > For the most part, this review focuses on publication and > standardization requirements rather than on the technical design of > the protocol. I plan to do that review separately, and consider the WG > members more competent in syslog specifics than me. >=20 > >From the standpoint of what I reviewed, this document generally looks > good. >=20 > dbh >=20 > -- idnits -- >=20 > The document has the correct IPR boilerplates, RFC2119 boilerplate, > and the document passes the automated idnits tool. >=20 > Idnits found two reference problems that should be addressed. >=20 > Reference [2] is never used in the text. > Reference [17] is never used in the text. >=20 Removed > -- xml2rfc validation -- >=20 > Since the source for this document is written in xml2rfc format, the > RFC editor will request that you submit a copy of the xml2rfc source > with the document to be published. It is a good thing if the sources > used to publish the final document are consisteent with the copy we > have for future update work, so it is a good thing to fix any known > problems in the xml2rfc source before submitting it to the RFC editor. > The rfc editor typically does not return their edited version to us. >=20 > The xml2rfc-validator tool at > http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi identified a > number of usages that are invalid according to the rfc2629.dtd, and > some usages that have been deprecated or obsoleted by the xml2rfc > tool. The xml2rfc tool will still accept these on the basis of being > liberal in what it accepts, but we should also be conservative in what > we send. >=20 > It would be good to fix all these errors and warnings.=20 I am working on that, but it is a pain with the low-bandwidth, instable Internet I currently have ;) >=20 > -- References -- >=20 > The xml2rfc-validator tool at > http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi identified > some obsolete references: >=20 > RFC 2234 has been obsoleted by RFC4234 > RFC 3513 has been obsoleted by RFC4291 I have changed the references, but have not (Yet) been able to check if that means any material differences. A quick check tells me it does not. >=20 > 6.2.1.1 says The Alarm MIB defines ITU perceived severities. Actually, > don't ITU M.3100 and X.733 define the severities, and the Alarm MIB > just uses them? I don't have a copy of M.3100 or X.733, so I cannot > check this; can somebody check this? I think we should reference the > original definition, and then we can point out that the Alarm MIB > references the ITU severities as well. According to RFC3877, the > references are=20 > "ITU Recommendation M.3100, 'Generic Network Information Model', 1995" > and > "ITU Recommendation X.733, 'Information Technology - Open Systems > Interconnection - System Management: Alarm Reporting Function', 1992" I have no references here, either. If someone could verify, I would appreciate. Alternatively, Chris had recommended that we drop this section. If there is no objection, we could also do that. > -- RFC2119 language -- >=20 > Section 5 states the UDP "transport is REQUIRED for interoperability > ...". I think this might be better phrased as the UDP "transport is > mandatory to implement for compliance to the standard to support > interoperability ..." or remove the sentence since the next section > discusses the minimum required transport mapping. changed >=20 > In section 5.1, it says "This ensures interoperability ...". This > might be better stated as "This ensures at least a minimum > interoperability ..." >=20 Changed=20 > Section 6 is entitled "Required syslog format". I suggest making it > simply "Syslog Message Format". Changed >=20 > Section 6.1: "After trucation, the message MAY contain invalid UTF-8 > encoding or invalid STRUCTURED-DATA."=20 > Does this need an addendum to standardize subsequent behavior? If the > truncated message now contains invalid content, should the whole > message be discarded, or should the receiver try to process as much as > it can, even if it is incomplete, and the results of subsequent > processing could be misleading to an operator?=20 This was discussed on-list and the consensus at that time was that the behaviour should be unspecified. The reasoning was to avoid any complexity at the receiver. I have added the following sentence: The receiver MAY discard the message or MAY try to process as much=20 as possible in this case. >=20 > 6.2.1: "A receiver MUST NOT assume any specific semantics by default." > I think this fails the RFC2119 test - RFC2119 keywords MUST only be > used where it is actually required for interoperation or to limit > behavior which has potential for causing harm; this assumption would > happen after the message came off the wire, so should not impact > interoperability on-the-wire, and it should have no effect on behavior > such as retransmission. Obviously, a management application might > cause a configuration change based on a faulty assumption, but I don't > think that is a protocol issue. I think the maximum RFC2119 language > here would be a SHOULD NOT. Agree, changed to SHOULD NOT >=20 > 6.2.5 This section should mention that APP-NAME is an > operator-configured value, which justifies the use of SHOULD rather > than MUST here. >=20 > 6.2.6 if operator-configured, then ditto.=20 >=20 > 6.2.7 if operator-configured, then ditto. These three fields must not necessarily be operator-assigned (I guess most often the vendor-specific defaults be used). I have added the following sentence to all three: =09 This field MAY be operator-assigned. =09 >=20 > 6.3.2 "to be assigned by IETF CONSENSUS" should include a reference to > BCP26 (RFC2434), since IETF CONSENSUS has a specific meaning defined > in the BCP. >=20 Added > 6.3.4 "An exception is the addition of a new OPTIONAL PARAM-NAME to an > existing SD-ID, what MAY be done." This strikes me as incorrect > English grammar; I recommend rewording it. Here is some suggested > text: "OPTIONAL PARAM-NAMEs MAY be added to an existing SD-ID." changed >=20 > 7.2.1 Can it list an ip address in the "ip" parameter AND provide a > list of multiple "ip" parameters in an "origin" element? If not, why > not? Wouldn't it be useful to provide the "origin" list, but also to > identify its "preferred" address for syslog purposes in "ip"? We could add a preferred address param, but would that actually be useful? I am not sure, as we have the hostname (granted, a FQDN) for the orginator. The (potential) list should help log analysers. It can list all addresses it may send from there. >=20 > 7.2.3 "It always contains the name of the generating software," - > should this one be MUST? >=20 > "whereas APP-NAME can contain anything else, including an > operator-configured value." Section 6.2.5 should mention that APP-NAME > is an operator-configured value. Agreed, changed "... MUST always contain..." >=20 > If the software parameter contains UTF-8, then it is important to > specify the maximum length of strings in octets rather than > characters, since characters can be multi-byte. changed >=20 > 7.2.4 If the swVersion parameter contains UTF-8, then it is important > to specify the maximum length of strings in octets rather than > characters, since characters can be multi-byte. Changed NOTE on both above: I left the size as is, as this was already a compromise given the small guaranteed size of a message. I expect that in the vast majority of cases these fields will be USASCII strings. >=20 >=20 > -- spelling -- >=20 > /parsable/parseable/g > neither MS-Word nor Merriam-Webster recognizes either > spelling. Wikipedia supports parseable under parsing. > computing-dictionary.thefreedictionary.com supports parseable. > Apparently the Oxford dictionary supports parseable, based on a > discussion at apache.org, but I don't have a subscription to check it. > =20 > /trucation/truncation > /conceptionally/conceptually/ > /mimimize/minimize/ > /timezone/time zone/g > according to MS-Word and Mirriam-Webster online > /implementor/implementer/g =20 > for consistency with rfc-editor boilerplate text. > /any-enterprise assigned/any enterprise-assigned/ >=20 Corrected > enterpriseId or enterpriseID - inconsistent usage. That stems back to the discussion that we should use camelcase on all parameters. Thus I have change to enterpriseId whereever used. >=20 > 6.2.4 "described in RFC 3513" should this be ", as described in RFC > 3513"? Yes - corrected >=20 > 7.2.2 "Only that number and any-enterprise assigned > ID below it MUST be specified in the "enterpriseId" parameter." > seems awkward.=20 >=20 > Would this be better as "An enterprise is only authorized to assign > values within the iso.org.dod.internet.private.enterprise. ID> subtree assigned by IANA to that enterprise. The enterpriseId MUST > contain only a value from the > iso.org.dod.internet.private.enterprise. subtree."=20 Excellent - thank you! >=20 > 7.3.2 /integer/INTEGER/ >=20 > Note that the semantics in RFC3418 are > "The time (in hundredths of a second) since the network > management portion of the system was last > re-initialized." > This of course relates to the SNMP-related management portion of the > system, which MAY be different than the syslog-related management > portion of the system. I have added this note to the text. >=20 > -- security considerations >=20 > Good job describing the potential configuration issues. > Since the transport documents will describe the threat models, it is > probably acceptable that the threat model is not covered here in the > terminology recommended by rfc3552. I could merge this in from a transport document, if that would help. Please advise. >=20 > -- IANA considerations -- >=20 > Good. >=20 > -- Authors -- >=20 > We now have a syslog@ietf.org mailing list adddress. That should be > used rather than the employees.org address. changed >=20 > You should identify that I work for Huawei Technologies USA. >=20 David Harrington Huawei Technologies USA Email: dbharrington@comcast.net Ok? > -- Acknowledgment -- >=20 > The funding acknowledgment for the RFC Editor function is out of date, > but the latest xml2rfc tool corrects it to acknowledge the IASA rather > than the Internet Society. >=20 >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 03:40:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDG02-0007sY-NI; Wed, 16 Aug 2006 03:39:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDG01-0007sT-7S for syslog@ietf.org; Wed, 16 Aug 2006 03:39:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDBso-0001gl-Ef for syslog@ietf.org; Tue, 15 Aug 2006 23:15:54 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDBq5-0007ZH-2j for syslog@ietf.org; Tue, 15 Aug 2006 23:13:08 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 43B329C00C; Wed, 16 Aug 2006 05:14:29 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18236-06; Wed, 16 Aug 2006 05:14:23 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id C6C099C00B; Wed, 16 Aug 2006 05:14:23 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Aug 2006 05:12:51 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DFB@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <0ada01c6c08f$b29c6c90$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: byte-counting vs special character Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhAAAhRtsAAGBPRkAAWpwkQ From: "Rainer Gerhards" To: "David Harrington" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: -2.6 (--) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: syslog@ietf.org Subject: [Syslog] RE: byte-counting vs special character X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Tuesday, August 15, 2006 11:25 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: byte-counting vs special character >=20 > Hi Rainer, >=20 > [speaking as co-chair] > Can we change the subject line to "byte-counting vs special character" > for this topic so it is easier to find comments on this topic as > compared to other things in the timeline? That will make it nuch > easier for the chairs. >=20 Sure > This WG has already gotten stuck, and had WG progress stall, trying to > provide backwards compatibility to a bunch of incompatible > implementations. I argued on this list before becoming co-chair that > backwarsd compatibility may not be achieveable for some features and > we need to stop getting hung up on it. Sometimes to build a good > standard, you need to choose something that will break some existing > implementations.=20 >=20 > I raised this concern with Chris when I started as co-chair. I do not > want to see backwards compatibility arguments stall progress again. I > made sure this was reflected in the timeline, which says that by > Friday (if you decide to use a special character) you must reach > consensus on which special character to use. > [/speaking as co-chair] As you know, I have originally opted for octet-couting. However, I am trying to describe what made me think this is a sub-optimal solution. I think backwards compatibilty can easily be brought in here. However, I do not think this is a vital point. I can live with octet-couting and would not object it if it is the WG consensus to use it. So far, I've not seen a clear consesus for either. What I would find very unfortunate is using both escapes and octet-counting (for the reasons outlined in previous mails - gains nothing, costs many). To fulfil your requirement, I propse that we use the backslash character ("\") as escape if we should decide to go the "escape way". =20 > [speaking as contributor] > I like the argument that the LF solution will not break existing > implementations, but I would like to know this is actually true. Have > you actually tested this against multiple implementations, or is it a > theoretical argument? No, it's a practical one, but based on plain tcp transport seen in the wild. I know for sure that Cisco PIX, syslog-ng, rsyslog, WinSyslog/MonitorWare and most probably Kiwi syslog support LF as terminator (Kiwi with a leading CR as Andrew has pointed out). All of these solutions interop via ssl if used with stunnel. > I know you have tested a number of other proposed ways of doing things > against multiple implementations to try to verify backwards > compatibility. Have you actually tested multiple existing > implementations with the LF and found that they do continue to work > without significant problems? Can you tell the WG which ones you have > tested? Are there implementations that break when using this solution? >=20 All quoted above rely on the LF. If it is not present, at least most of them will merge syslog records (I can not at this moment verify the later for all one mentioned because I have no lab access). So far, my understanding was that stunnel is basically compatible to what -transport-tls specifies. Miao has questions that this morning. Again, I can not verify at this time (not even having a -transport-tls implementation at hand). I have asked Miao for details where he sees the incompatibility. When he replies, his argument might actually settle the whole issue and proove me wrong. > In a different message you argue that syslog-sign only needs to > support -protocol because the implementations will need to have new > code added anyway, and the added complexity of backwards compatibility > to rfc3164 implementations is not needed. I see a big difference here. To support -sign, all new implementations are needed. -tls (at least in my current view) does not come with this restriction. =20 > You only mention one implementation explicitly that provides > syslog/tls, syslog-ng over stunnel. Would all the other > implementations need to be modified to support a TLS substrate anyway, > so it would not make a difference to them which special character was > chosen or if byte-counting was chosen? Which syslog/tls > implementations will be impacted by our choice here?=20 Stunnel is a wrapper. It works with anything that runs on tcp. I have mentioned syslog-ng because it is the best known (and nothing I am involved with). All implementations I have quoted work with stunnel and are interoperable in that way (again, Kiwi only 98% sure). =20 > Ideally, only the implementations that support a feature need to pay > the price for the feature. >=20 > A syslog message delineator will only be needed in implemntations that > add support for syslog/tls (or other streams). Whether one supports > byte-counting or a special character, only implementations that > support multiple messages in a stream, e.g. syslog/tls, should need to > be modified to support the choice.=20 >=20 > Personally I find the octet-counting cleaner=20 I have argued much in the same way and still find byte-counting the technically best solution. > because previous > discussions on terminators showed that available implementations are > highly inconsistent with their special characters.=20 >=20 > Since byte-counting happens outside the syslog message, and only for > syslog in a delimited stream coming in over the syslog/tls port, it > would not impact existing code, only code that supports syslog/tls. I think it impacts existing deployed solutions using syslog with stunnel. > New syslog/tls code would be needed to extract each "normal" syslog > message from the stream and then send it on for processing through the > existing parser.=20 >=20 > If message originators start escaping special characters in the > message content, existing receivers may need to be modified to > un-escape the characters. Think about applications, such as intrusion > detection systems, that search for special patterns in syslog content > - those could be broken by having the content changed by escaping > characters in the middle of the content. LF is currently not seen in log files. A problem could occur by escaping \, but it seems to be seldomly used. > What happens at a store-then-forward relay? Does the relay store the > escaped characters or does it un-escape them first? Does it escape > them again when it forwards the message? Does it escape them if it > un-escaped them on input? Does it escape them if it did not un-escape > them on input? What if the sender included some escaped characaters > (like '\') for other purposes? Should the relay unescape them as well? > Will it know to re-escape them on output? What should the ultimate > reciever expect to receive? > Existing receivers should never unescape and escape. -transport-tls receivers MUST unescape and escape the message when forwarding. The escape is just a transfer encoding, so it is not present in the actual message. =20 > Byte-counting looks way less complex to me than choosing a special > character and escaping/unescaping special characters in the content > during the sending/forwarding/recieving process. (And my opinion has > nothing to do with the H**** in my email address.) >=20 I agree octet-couting is easier. As I said, it was my preferred soltution, too. What made me change my mind was backwards compatibility. The added complexity IMHO is a small price to pay for immediately being compatible to everything that is deployed today. If I am wrong here (Miao's answer...), escaping would be a big mistake. Until this is proven, I stick with it as my preferrence. I do not, however, object octet-couting if that is consensus. Rainer > dbh >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Tuesday, August 15, 2006 12:41 AM > > To: Miao Fuyou > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] timeline > >=20 > > Miao, > >=20 > > I am actually concerned about backward compatibility with=20 > > existing code > > *without* the need to upgrade any of that code. As you know, > deployed > > software tends to stick. > >=20 > > If we use just LF, existing, deployed technology (e.g. syslog-ng > with > > stunnel) would be able to understand a message sent from a "new > style" > > syslogd. Having the octet count in front of the message removes that > > ability, as the old syslogd will no longer see the at=20 > > the start of > > the message. > >=20 > > I agree that it is trivial to modify code to take care for the octet > > counter. But this is not my concern. My concern is that I=20 > > would like to > > achive as good as possible compatibility with existing deployed (aka > > "unmodified") technology. I should have been more specific on that. > > Sorry for the omission... > >=20 > > I am also unaware of any implementation that mandates CR LF over > just > > LF. Could you let me know which ones are these? > >=20 > > Rainer=20 > >=20 > > > -----Original Message----- > > > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > > > Sent: Monday, August 14, 2006 7:07 PM > > > To: Rainer Gerhards > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] timeline > > >=20 > > > =20 > > > Hi, Rainer, > > >=20 > > > A new implementation could rely on byte-counting only and=20 > > > then delete LF > > > from the frame(appplication knows exactly where the LF is),=20 > > > it may not force > > > us to use escapes. For LF, I think it is difficult to get=20 > > > 100% compatibility > > > for a legacy implementation to comply TLS-transport without=20 > > > any change to > > > the code. At least, some imlementation may need to change=20 > > CR LF to LF > > > because some implementations use CR LF rather than LF. So, it=20 > > > may be ok to > > > add several LOC to delete FRAME-LEN SP from the frame.=20 > > >=20 > > > I still prefer byte-counting only to byte-counting+LF even=20 > > if it is a > > > feasible tradeoff. =20 > > >=20 > > > Miao > > >=20 > > > > -----Original Message----- > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > > > Sent: Monday, August 14, 2006 10:18 PM > > > > To: Miao Fuyou > > > > Subject: RE: [Syslog] timeline > > > >=20 > > > > We should not go byte-counting + LF. This is the worst choice: > it=20 > > > >=20 > > > > A) breaks compatibility > > > > B) Forces us to use escapes > > > >=20 > > > > So we get the bad of both worlds, without any benefits. > > > >=20 > > > > Rainer=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > > > Sent: Monday, August 14, 2006 12:58 AM > > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington';=20 > > > > syslog@ietf.org > > > > > Subject: RE: [Syslog] timeline > > > > >=20 > > > > >=20 > > > > > My vote: byte-counting only > byte-counting + LF > LF > > > > =20 > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 06:26:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDIa5-0006hV-Jk; Wed, 16 Aug 2006 06:25:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDIa4-0006hO-SZ for syslog@ietf.org; Wed, 16 Aug 2006 06:25:01 -0400 Received: from balabit.hu ([82.141.167.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDIa2-0005T6-9e for syslog@ietf.org; Wed, 16 Aug 2006 06:25:00 -0400 Subject: RE: [Syslog] byte-counting vs special character From: Balazs Scheidler To: Carson Gaspar In-Reply-To: References: <98AE08B66FAD1742BED6CB9522B7312201C971AC@xmb-rtp-20d.amer.cisco .com> Content-Type: text/plain Date: Wed, 16 Aug 2006 12:24:51 +0200 Message-Id: <1155723892.6352.67.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Tue, 2006-08-15 at 13:50 -0700, Carson Gaspar wrote: > I've been mostly lurking lately, but I would like to re-iterate my support > for byte counting. It's the Right Thing To Do, and theoretical "backwards > compatibility" with existing non-standard non-widely-deployed syslog over > TCP solutions isn't a good enough reason to put bad ideas in the standard. Then why on earth did the BEEP based syslog/RAW use LF as line terminator? Quoting RFC3195: If multiple syslog messages are included in a single ANS reply, each is separated from the preceding with a CRLF. There is no ending delimiter, but each syslog event message body length MUST be 1024 bytes or less, excluding BEEP framing overhead. Note that there MUST NOT be a CRLF between the text of the final syslog event message and the "END" marking the trailer of the BEEP frame. As it currently stands: * nonstandard, but widely deployed syslog over TCP use LF * nonstandard, less widely deployed syslog-over-TCP-over-SSL use LF * standard, even less widely deployed syslog/RAW uses CRLF * semi-standard, UDP based syslog uses UDP packet framing for message termination Syslog-ng has supported TCP transport since its first release in 1998, a number of devices interoperate with it. Whatever the decision of the working group, syslog-ng will need to support this legacy TCP mode of operation for backward compatibility. And as there is little incentive for a user to change to the byte-counted form, I think the legacy mode will still be more widely used for a couple of years to come. Of course syslog-ng might not be the most widely deployed syslog implementation, but I'm sure it is in the top three. Some numbers using google search, which I know is not really representative: sysklogd 607000 (default on Linux, no TCP support) syslog-ng 593000 kiwi syslog 321000 msyslog 33400 sdsc syslog 21900 rsyslog 21500 In my opinion we either design something that is really sexy (application layer acknowledgements, authentication, compression, something that BEEP based syslog provides but which has other problems) or we should be as compatible with existing installations as possible. In my opinion the goal here is that the user will not need to change its configuration file, or will not need a separate port on her firewalls, a simple software upgrade on either receiver/sender and be done with it. The current TCP based protocol _is_ implemented in closed-box devices where replacing the sender software component is not possible or feasible, if the new feature is incompatible, it will be difficult to convince users to change, unless some real value is also added, other than "byte-counted" form is cleaner. I tend to agree that byte-counting is cleaner, I just don't see the advantate in the current state of affairs. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 11:54:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDNgy-0008GB-0p; Wed, 16 Aug 2006 11:52:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDNdl-0007Di-FJ for syslog@ietf.org; Wed, 16 Aug 2006 11:49:09 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDNUX-0007fc-Ci for syslog@ietf.org; Wed, 16 Aug 2006 11:39:39 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 76A2F9C00C; Wed, 16 Aug 2006 17:40:56 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18807-09; Wed, 16 Aug 2006 17:40:51 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id CD4EF9C00B; Wed, 16 Aug 2006 17:40:51 +0200 (CEST) Subject: RE: [Syslog] timeline MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Aug 2006 17:39:21 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DFF@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <007401c6c11a$ee589110$8c0c6f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] timeline Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhAAAhRtsAAAtEhEAARtJ0AACebwIAADTn+wA== From: "Rainer Gerhards" To: "Miao Fuyou" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Miao, I need to leave, thus short: To the best of my knowledge, a native sender can talk to an stunnel-enhanced receiver. I am pretty sure I have tested this, but I can not verify due to missing lab abilities right now. Maybe somebody else could try it out. AFAIK the stunnel manual also describes that scenario. This ability is my #1 reason why I think escaping is superiour to octet-couting. Rainer > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Wednesday, August 16, 2006 4:01 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] timeline >=20 > Rainer, >=20 > As you know, in stunnel/syslog model, a syslog sender sends=20 > syslog message > in TCP transport to a local port of the stunnel client, it=20 > then forwards it > to the stunnel server on another host in a TLS secure tunnel.=20 > After stunnel > server received the message it sends the message to the=20 > receiver on the same > host. Basically stunnel is a port forwarding facility for=20 > application(any > application in TCP transport, not only syslog), and stunnel client and > server are both stand-alone applications co-locating on same host with > syslog sender or receiver application.=20 >=20 > Transport-tls requires a secure transport mechanism for=20 > Syslog, that means > the TLS transport is part of the sender/receiver application=20 > rather than > another stand-alone application. So, I believe stunnel/syslog=20 > is not the > exact implementation for transport-tls.=20 >=20 > I have not checked whether a transport-TLS sender can works=20 > well with a > "stunnelized" receiver or vice versa because there are not available > transport-tls implementation currently. It may be possible,=20 > however, is such > interaction capability a requirement for transport-tls? >=20 > Thanks! > Miao >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Tuesday, August 15, 2006 10:26 PM > > To: Miao Fuyou > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] timeline > >=20 > > Miao, > >=20 > > Rsyslog accepts CRLF, and can even be configured to emit it. > >=20 > > I have no access to a lab. Could you please clarify where=20 > > exactly -transport-tls is unable to work with currently=20 > > existing deployments using stunnel? I would greatly=20 > > appreciate insight as I can not try it out for a while (and I=20 > > am also unable to do any in-depth analysis). > >=20 > > Thanks, > > Rainer=20 > >=20 > > > -----Original Message----- > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > Sent: Tuesday, August 15, 2006 12:59 AM > > > To: Rainer Gerhards > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] timeline > > >=20 > > >=20 > > > Rainer, > > >=20 > > > Stunnel is a secure wrapper for TCP stream. Actually=20 > > delimiting Syslog=20 > > > is done in the TCP part rather than TLS (or stunnel) part=20 > > in Syslog-ng=20 > > > with stunnel. One can use stunnel to secure any Syslog TCP=20 > > transport,=20 > > > such as rsyslog and kiwisyslog, and kiwisyslog does use CRLF for=20 > > > delimiting (http://www.kiwisyslog.com/whats_new_syslog.htm). > > >=20 > > > Stunnel implementation is different from Syslog TLS=20 > > transport, and I=20 > > > don' t think it is the exact implementation of Syslog TLS=20 > transport. > > > I have not > > > been aware of a Syslog implementation in TLS-transport=20 > > style till now.=20 > > > So, most of the implementation may be modified, slightly or=20 > > heavily,=20 > > > to existing code to get it comply to the specification. > > >=20 > > > Miao > > >=20 > > > > -----Original Message----- > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > > Sent: Tuesday, August 15, 2006 12:41 PM > > > > To: Miao Fuyou > > > > Cc: syslog@ietf.org > > > > Subject: RE: [Syslog] timeline > > > >=20 > > > > Miao, > > > >=20 > > > > I am actually concerned about backward compatibility with=20 > > existing=20 > > > > code > > > > *without* the need to upgrade any of that code. As you know,=20 > > > > deployed software tends to stick. > > > >=20 > > > > If we use just LF, existing, deployed technology (e.g.=20 > > > syslog-ng with > > > > stunnel) would be able to understand a message sent from a > > > "new style" > > > > syslogd. Having the octet count in front of the message=20 > > removes that=20 > > > > ability, as the old syslogd will no longer see the at the=20 > > > > start of the message. > > > >=20 > > > > I agree that it is trivial to modify code to take care=20 > > for the octet=20 > > > > counter. But this is not my concern. My concern is that I=20 > > would like=20 > > > > to achive as good as possible compatibility with existing=20 > > deployed=20 > > > > (aka > > > > "unmodified") technology. I should have been more=20 > > specific on that. > > > > Sorry for the omission... > > > >=20 > > > > I am also unaware of any implementation that mandates=20 > CR LF over=20 > > > > just LF. Could you let me know which ones are these? > > > >=20 > > > > Rainer > > > >=20 > > > > > -----Original Message----- > > > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > > > Sent: Monday, August 14, 2006 7:07 PM > > > > > To: Rainer Gerhards > > > > > Cc: syslog@ietf.org > > > > > Subject: RE: [Syslog] timeline > > > > >=20 > > > > > =20 > > > > > Hi, Rainer, > > > > >=20 > > > > > A new implementation could rely on byte-counting only and > > > > then delete > > > > > LF from the frame(appplication knows exactly where the LF > > > > is), it may > > > > > not force us to use escapes. For LF, I think it is > > > difficult to get > > > > > 100% compatibility for a legacy implementation to comply > > > > TLS-transport > > > > > without any change to the code. At least, some > > > > imlementation may need > > > > > to change CR LF to LF because some implementations use CR > > > LF rather > > > > > than LF. So, it may be ok to add several LOC to delete > > > FRAME-LEN SP > > > > > from the frame. > > > > >=20 > > > > > I still prefer byte-counting only to byte-counting+LF even > > > > if it is a > > > > > feasible tradeoff. > > > > >=20 > > > > > Miao > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > > > > Sent: Monday, August 14, 2006 10:18 PM > > > > > > To: Miao Fuyou > > > > > > Subject: RE: [Syslog] timeline > > > > > >=20 > > > > > > We should not go byte-counting + LF. This is the worst > > > choice: it > > > > > >=20 > > > > > > A) breaks compatibility > > > > > > B) Forces us to use escapes > > > > > >=20 > > > > > > So we get the bad of both worlds, without any benefits. > > > > > >=20 > > > > > > Rainer > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > > > > > Sent: Monday, August 14, 2006 12:58 AM > > > > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; > > > > > > syslog@ietf.org > > > > > > > Subject: RE: [Syslog] timeline > > > > > > >=20 > > > > > > >=20 > > > > > > > My vote: byte-counting only > byte-counting + LF > LF > > > > > > =20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 13:57:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDPcq-0002W3-Ms; Wed, 16 Aug 2006 13:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDPcp-0002Vy-5H for syslog@ietf.org; Wed, 16 Aug 2006 13:56:19 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDPcn-0006lb-T2 for syslog@ietf.org; Wed, 16 Aug 2006 13:56:19 -0400 Received: from pc6 (1Cust18.tnt16.lnd4.gbr.da.uu.net [62.188.145.18]) by astro.systems.pipex.net (Postfix) with SMTP id CFEF8E000070; Wed, 16 Aug 2006 18:56:16 +0100 (BST) Message-ID: <004101c6c154$2a1a0600$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <082101c6bca3$165a36e0$0400a8c0@china.huawei.com> Subject: Re: [Syslog] timeline Date: Wed, 16 Aug 2006 18:51:02 +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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org From: "David Harrington" To: Sent: Thursday, August 10, 2006 7:33 PM Subject: [Syslog] timeline > > Here are two things we need to resolve soon. > > 2) whether draft-ietf-syslog-device-mib represents WG consensus on > what needs to be managed in the protocol, udp, tls, and sign > documents, and if not, what needs to be changed to represent WG > consensus. We want to finalize this WG decision by August 18 as well. I still have trouble with the mib document, not for any mibby reason but simply because, as I commented on the previous version, it seems to be written in a different language to the other I-D and, insofar as I understand that language, seems to be describing a different set of concepts to the other documents. As I said, this is a question of reading the introductory text, no network management skills required, to see, if like me, you think this out of line with the other I-D. TOm Petch > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 14:42:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDQKu-0000j6-9P; Wed, 16 Aug 2006 14:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDQKt-0000iz-KL for syslog@ietf.org; Wed, 16 Aug 2006 14:41:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDIQT-0004rp-GB for syslog@ietf.org; Wed, 16 Aug 2006 06:15:05 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDIHb-0000Hd-Ng for syslog@ietf.org; Wed, 16 Aug 2006 06:06:06 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4300H4W5ZTKM@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 16 Aug 2006 18:19:05 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J43005QS5ZSCM@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 16 Aug 2006 18:19:04 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4300A935CHWH@szxml03-in.huawei.com> for syslog@ietf.org; Wed, 16 Aug 2006 18:05:08 +0800 (CST) Date: Wed, 16 Aug 2006 18:01:23 +0800 From: Miao Fuyou Subject: RE: [Syslog] timeline In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA174DF8@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' Message-id: <007401c6c11a$ee589110$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhAAAhRtsAAAtEhEAARtJ0AACebwIA= X-Spam-Score: -2.3 (--) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Rainer, As you know, in stunnel/syslog model, a syslog sender sends syslog message in TCP transport to a local port of the stunnel client, it then forwards it to the stunnel server on another host in a TLS secure tunnel. After stunnel server received the message it sends the message to the receiver on the same host. Basically stunnel is a port forwarding facility for application(any application in TCP transport, not only syslog), and stunnel client and server are both stand-alone applications co-locating on same host with syslog sender or receiver application. Transport-tls requires a secure transport mechanism for Syslog, that means the TLS transport is part of the sender/receiver application rather than another stand-alone application. So, I believe stunnel/syslog is not the exact implementation for transport-tls. I have not checked whether a transport-TLS sender can works well with a "stunnelized" receiver or vice versa because there are not available transport-tls implementation currently. It may be possible, however, is such interaction capability a requirement for transport-tls? Thanks! Miao > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Tuesday, August 15, 2006 10:26 PM > To: Miao Fuyou > Cc: syslog@ietf.org > Subject: RE: [Syslog] timeline > > Miao, > > Rsyslog accepts CRLF, and can even be configured to emit it. > > I have no access to a lab. Could you please clarify where > exactly -transport-tls is unable to work with currently > existing deployments using stunnel? I would greatly > appreciate insight as I can not try it out for a while (and I > am also unable to do any in-depth analysis). > > Thanks, > Rainer > > > -----Original Message----- > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > Sent: Tuesday, August 15, 2006 12:59 AM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] timeline > > > > > > Rainer, > > > > Stunnel is a secure wrapper for TCP stream. Actually > delimiting Syslog > > is done in the TCP part rather than TLS (or stunnel) part > in Syslog-ng > > with stunnel. One can use stunnel to secure any Syslog TCP > transport, > > such as rsyslog and kiwisyslog, and kiwisyslog does use CRLF for > > delimiting (http://www.kiwisyslog.com/whats_new_syslog.htm). > > > > Stunnel implementation is different from Syslog TLS > transport, and I > > don' t think it is the exact implementation of Syslog TLS transport. > > I have not > > been aware of a Syslog implementation in TLS-transport > style till now. > > So, most of the implementation may be modified, slightly or > heavily, > > to existing code to get it comply to the specification. > > > > Miao > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Tuesday, August 15, 2006 12:41 PM > > > To: Miao Fuyou > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] timeline > > > > > > Miao, > > > > > > I am actually concerned about backward compatibility with > existing > > > code > > > *without* the need to upgrade any of that code. As you know, > > > deployed software tends to stick. > > > > > > If we use just LF, existing, deployed technology (e.g. > > syslog-ng with > > > stunnel) would be able to understand a message sent from a > > "new style" > > > syslogd. Having the octet count in front of the message > removes that > > > ability, as the old syslogd will no longer see the at the > > > start of the message. > > > > > > I agree that it is trivial to modify code to take care > for the octet > > > counter. But this is not my concern. My concern is that I > would like > > > to achive as good as possible compatibility with existing > deployed > > > (aka > > > "unmodified") technology. I should have been more > specific on that. > > > Sorry for the omission... > > > > > > I am also unaware of any implementation that mandates CR LF over > > > just LF. Could you let me know which ones are these? > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > > Sent: Monday, August 14, 2006 7:07 PM > > > > To: Rainer Gerhards > > > > Cc: syslog@ietf.org > > > > Subject: RE: [Syslog] timeline > > > > > > > > > > > > Hi, Rainer, > > > > > > > > A new implementation could rely on byte-counting only and > > > then delete > > > > LF from the frame(appplication knows exactly where the LF > > > is), it may > > > > not force us to use escapes. For LF, I think it is > > difficult to get > > > > 100% compatibility for a legacy implementation to comply > > > TLS-transport > > > > without any change to the code. At least, some > > > imlementation may need > > > > to change CR LF to LF because some implementations use CR > > LF rather > > > > than LF. So, it may be ok to add several LOC to delete > > FRAME-LEN SP > > > > from the frame. > > > > > > > > I still prefer byte-counting only to byte-counting+LF even > > > if it is a > > > > feasible tradeoff. > > > > > > > > Miao > > > > > > > > > -----Original Message----- > > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > > > Sent: Monday, August 14, 2006 10:18 PM > > > > > To: Miao Fuyou > > > > > Subject: RE: [Syslog] timeline > > > > > > > > > > We should not go byte-counting + LF. This is the worst > > choice: it > > > > > > > > > > A) breaks compatibility > > > > > B) Forces us to use escapes > > > > > > > > > > So we get the bad of both worlds, without any benefits. > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > > > > Sent: Monday, August 14, 2006 12:58 AM > > > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; > > > > > syslog@ietf.org > > > > > > Subject: RE: [Syslog] timeline > > > > > > > > > > > > > > > > > > My vote: byte-counting only > byte-counting + LF > LF > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 15:31:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDR6H-0007do-J1; Wed, 16 Aug 2006 15:30:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDR6F-0007de-R7 for syslog@ietf.org; Wed, 16 Aug 2006 15:30:47 -0400 Received: from dsl081-242-052.sfo1.dsl.speakeasy.net ([64.81.242.52] helo=gandalf.taltos.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDR6E-0003JX-FR for syslog@ietf.org; Wed, 16 Aug 2006 15:30:47 -0400 Received: from gandalf.taltos.org (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id 31C5D21CD3 for ; Wed, 16 Aug 2006 12:30:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on gandalf.taltos.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.168.1.2] (unknown [192.168.1.2]) by gandalf.taltos.org (Postfix) with ESMTP id 2405621CD2 for ; Wed, 16 Aug 2006 12:30:45 -0700 (PDT) Date: Wed, 16 Aug 2006 12:32:46 -0700 From: Carson Gaspar To: syslog@ietf.org Subject: Re: [Syslog] RE: byte-counting vs special character Message-ID: <3EC76EAEC1590ED5FF81F03E@[192.168.1.2]> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174DFB@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA174DFB@grfint2.intern.adiscon.c om> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Escaping precludes no-configuration backwards compatibility, as no legacy syslog-over-tcp code does escaping. So if you want to interoperate with existing code, you must have a "don't escape or expect escapes" switch in your code. If you're going to do that, just have a "LF mode vs byte-count mode" switch. This whole backwards compat argument is bogus, iff we decide to escape embedded LF instead of forbidding it. And I have yet to see anyone argue for LF on any grounds except backwards compatibility. -- Carson _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 20:09:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDVQg-0006Vs-6U; Wed, 16 Aug 2006 20:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDVQe-0006Vn-Gt for syslog@ietf.org; Wed, 16 Aug 2006 20:08:08 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDVQd-0001pp-4z for syslog@ietf.org; Wed, 16 Aug 2006 20:08:08 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 5B6FF9C00C; Thu, 17 Aug 2006 02:09:38 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19005-07; Thu, 17 Aug 2006 02:09:34 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id C18229C00B; Thu, 17 Aug 2006 02:09:34 +0200 (CEST) Subject: RE: [Syslog] RE: byte-counting vs special character MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Aug 2006 02:08:01 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174E01@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <3EC76EAEC1590ED5FF81F03E@[192.168.1.2]> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] RE: byte-counting vs special character Thread-Index: AcbBaq66hmc81BxAQ9SLuFg3FGeWpAAJkC0w From: "Rainer Gerhards" To: "Carson Gaspar" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Carson, Legacy code does not contain LF in messages. It is advised that new-style syslog also does not contain control characters (though it now is allowed). Thus the argument is valid. Again, I do not object octet-couting (I actually introduced the idea ;)) but find it the second best-solution. Maybe we should do a simple poll - some have already voiced their choices... Rainer=20 > -----Original Message----- > From: Carson Gaspar [mailto:carson@taltos.org]=20 > Sent: Wednesday, August 16, 2006 1:33 PM > To: syslog@ietf.org > Subject: Re: [Syslog] RE: byte-counting vs special character >=20 > Escaping precludes no-configuration backwards compatibility,=20 > as no legacy=20 > syslog-over-tcp code does escaping. So if you want to=20 > interoperate with=20 > existing code, you must have a "don't escape or expect=20 > escapes" switch in=20 > your code. If you're going to do that, just have a "LF mode=20 > vs byte-count=20 > mode" switch. This whole backwards compat argument is bogus,=20 > iff we decide=20 > to escape embedded LF instead of forbidding it. And I have yet to see=20 > anyone argue for LF on any grounds except backwards compatibility. >=20 > --=20 > Carson >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 20:19:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDVbd-0000LS-MM; Wed, 16 Aug 2006 20:19:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDVbc-0000LN-Hx for syslog@ietf.org; Wed, 16 Aug 2006 20:19:28 -0400 Received: from dsl081-242-052.sfo1.dsl.speakeasy.net ([64.81.242.52] helo=gandalf.taltos.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDVbZ-0003CH-3y for syslog@ietf.org; Wed, 16 Aug 2006 20:19:28 -0400 Received: from gandalf.taltos.org (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id 4833221CB9 for ; Wed, 16 Aug 2006 17:19:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on gandalf.taltos.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.168.1.2] (unknown [192.168.1.2]) by gandalf.taltos.org (Postfix) with ESMTP id 45FA021B73 for ; Wed, 16 Aug 2006 17:19:19 -0700 (PDT) Date: Wed, 16 Aug 2006 17:21:20 -0700 From: Carson Gaspar To: syslog@ietf.org Subject: RE: [Syslog] RE: byte-counting vs special character Message-ID: <197BA82F0137F9D5A2AFDBDE@[192.168.1.2]> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174E01@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA174E01@grfint2.intern.adiscon.c om> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --On Thursday, August 17, 2006 2:08 AM +0200 Rainer Gerhards wrote: > Legacy code does not contain LF in messages. It is advised that > new-style syslog also does not contain control characters (though it now > is allowed). Legacy code _will_ emit doubled escape characters (unless the escape character selected is forbidden in legacy code). They will then be mis-interpreted by new code. New code _will_ double the escape character when sending it to legacy code, mangling the message. You can't have it both ways. Either you forbid LF and use it as a EOM marker and get backwards compatibility, or you allow LF (via whatever mechanism, escaping or octet counting are equivalent) and break backwards compatibility. Statements that "doubled escape characters are unlikely in legacy messages" are bogus. Either they are _impossible_, or they will happen eventually. If you want to bow at the alter of the installed base, forbid LF in messages. If not, then octet counting is technically superior. This wishy-washy middle ground is just a terrible idea. -- Carson _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 21:06:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDWKF-0003f0-95; Wed, 16 Aug 2006 21:05:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDWKD-0003es-VL for syslog@ietf.org; Wed, 16 Aug 2006 21:05:33 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDWKB-00047U-Lk for syslog@ietf.org; Wed, 16 Aug 2006 21:05:33 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc14) with SMTP id <20060817010520b1400glbd2e>; Thu, 17 Aug 2006 01:05:31 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , "'Carson Gaspar'" Subject: RE: [Syslog] RE: byte-counting vs special character Date: Wed, 16 Aug 2006 21:03:41 -0400 Message-ID: <0bfb01c6c199$01c71860$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174E01@grfint2.intern.adiscon.com> Thread-Index: AcbBaq66hmc81BxAQ9SLuFg3FGeWpAAJkC0wAAHBOKA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, The IETF doesn't vote. The chairs will determine consensus on or after the Aug 18 deadline for this decision. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Wednesday, August 16, 2006 8:08 PM > To: Carson Gaspar > Cc: syslog@ietf.org > Subject: RE: [Syslog] RE: byte-counting vs special character > > Carson, > > Legacy code does not contain LF in messages. It is advised that > new-style syslog also does not contain control characters > (though it now > is allowed). > > Thus the argument is valid. Again, I do not object octet-couting (I > actually introduced the idea ;)) but find it the second best-solution. > Maybe we should do a simple poll - some have already voiced their > choices... > > Rainer > > > -----Original Message----- > > From: Carson Gaspar [mailto:carson@taltos.org] > > Sent: Wednesday, August 16, 2006 1:33 PM > > To: syslog@ietf.org > > Subject: Re: [Syslog] RE: byte-counting vs special character > > > > Escaping precludes no-configuration backwards compatibility, > > as no legacy > > syslog-over-tcp code does escaping. So if you want to > > interoperate with > > existing code, you must have a "don't escape or expect > > escapes" switch in > > your code. If you're going to do that, just have a "LF mode > > vs byte-count > > mode" switch. This whole backwards compat argument is bogus, > > iff we decide > > to escape embedded LF instead of forbidding it. And I have > yet to see > > anyone argue for LF on any grounds except backwards compatibility. > > > > -- > > Carson > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 21:19:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDWXK-00026n-8x; Wed, 16 Aug 2006 21:19:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDWXJ-00026i-2h for syslog@ietf.org; Wed, 16 Aug 2006 21:19:05 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDWXH-0006X8-I9 for syslog@ietf.org; Wed, 16 Aug 2006 21:19:05 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4227B9C00D; Thu, 17 Aug 2006 03:20:35 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19005-09; Thu, 17 Aug 2006 03:20:31 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 944649C00B; Thu, 17 Aug 2006 03:20:31 +0200 (CEST) Subject: RE: [Syslog] RE: byte-counting vs special character MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Aug 2006 03:18:56 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174E03@grfint2.intern.adiscon.com> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <197BA82F0137F9D5A2AFDBDE@[192.168.1.2]> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] RE: byte-counting vs special character Thread-Index: AcbBktcDOGoCrxPJQZW8FrXfSK6ykwABwWzA From: "Rainer Gerhards" To: "Carson Gaspar" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Caspar - since when does legacy code do escaping? (Even if I've overlooked it, we might use a different escape character...) Anyhow - the "whishy-washy" blew the WGs work last year. Ignoring legacy compatibility trashed roughly a year of work. I don't want to see this happen again. I'll post a more elaborate message on last years failure of the syslog WG due to ignoring backward compatibility as soon as I am able to do so... Rainer=20 > -----Original Message----- > From: Carson Gaspar [mailto:carson@taltos.org]=20 > Sent: Wednesday, August 16, 2006 6:21 PM > To: syslog@ietf.org > Subject: RE: [Syslog] RE: byte-counting vs special character >=20 > --On Thursday, August 17, 2006 2:08 AM +0200 Rainer Gerhards=20 > wrote: >=20 > > Legacy code does not contain LF in messages. It is advised that > > new-style syslog also does not contain control characters=20 > (though it now > > is allowed). >=20 > Legacy code _will_ emit doubled escape characters (unless the escape=20 > character selected is forbidden in legacy code). They will then be=20 > mis-interpreted by new code. >=20 > New code _will_ double the escape character when sending it=20 > to legacy code,=20 > mangling the message. >=20 > You can't have it both ways. Either you forbid LF and use it as a EOM=20 > marker and get backwards compatibility, or you allow LF (via whatever=20 > mechanism, escaping or octet counting are equivalent) and=20 > break backwards=20 > compatibility. Statements that "doubled escape characters are=20 > unlikely in=20 > legacy messages" are bogus. Either they are _impossible_, or=20 > they will=20 > happen eventually. >=20 > If you want to bow at the alter of the installed base, forbid LF in=20 > messages. If not, then octet counting is technically superior. This=20 > wishy-washy middle ground is just a terrible idea. >=20 > --=20 > Carson >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 21:53:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDX4g-0007A7-K3; Wed, 16 Aug 2006 21:53:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDX4e-00079q-F5 for syslog@ietf.org; Wed, 16 Aug 2006 21:53:32 -0400 Received: from dsl081-242-052.sfo1.dsl.speakeasy.net ([64.81.242.52] helo=gandalf.taltos.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDX4d-00031w-4s for syslog@ietf.org; Wed, 16 Aug 2006 21:53:32 -0400 Received: from gandalf.taltos.org (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id B4E4821CB8 for ; Wed, 16 Aug 2006 18:53:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on gandalf.taltos.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.168.1.2] (unknown [192.168.1.2]) by gandalf.taltos.org (Postfix) with ESMTP id B124921B73 for ; Wed, 16 Aug 2006 18:53:27 -0700 (PDT) Date: Wed, 16 Aug 2006 18:55:28 -0700 From: Carson Gaspar To: syslog@ietf.org Subject: RE: [Syslog] RE: byte-counting vs special character Message-ID: <2B15665BA66B721F16F22A56@[192.168.1.2]> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174E03@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA174E03@grfint2.intern.adiscon.c om> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --On Thursday, August 17, 2006 3:18 AM +0200 Rainer Gerhards wrote: > Caspar - since when does legacy code do escaping? (Even if I've > overlooked it, we might use a different escape character...) It doesn't. However, if the escape character is legal in legacy code, it can appear twice. Which will be converted to a single escape character by a new receiver. Which is a bug. Which is why I said: >> Legacy code _will_ emit doubled escape characters (unless the escape >> character selected is forbidden in legacy code). They will then be >> mis-interpreted by new code. Note the "unless". > Anyhow - the "whishy-washy" blew the WGs work last year. Ignoring legacy > compatibility trashed roughly a year of work. I don't want to see this > happen again. I'll post a more elaborate message on last years failure > of the syslog WG due to ignoring backward compatibility as soon as I am > able to do so... Great. So forbid LF in the message and drop the escaping thing. I'm fine with that. Adding an escape character and claiming backwards compatibility is a sham, unless you can _guarantee_ that the escape character is never emitted by legacy code. The appearance of compatibility without the substance is useless. -- Carson _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 22:43:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDXpY-0007pI-3u; Wed, 16 Aug 2006 22:42:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDXpW-0007pD-Uc for syslog@ietf.org; Wed, 16 Aug 2006 22:41:58 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDXpV-0007Ds-KC for syslog@ietf.org; Wed, 16 Aug 2006 22:41:58 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 973D49C00C; Thu, 17 Aug 2006 04:43:29 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19328-02; Thu, 17 Aug 2006 04:43:24 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id C18A99C00B; Thu, 17 Aug 2006 04:43:24 +0200 (CEST) Subject: RE: [Syslog] RE: byte-counting vs special character MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Aug 2006 04:41:49 +0200 Content-class: urn:content-classes:message Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174E05@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <2B15665BA66B721F16F22A56@[192.168.1.2]> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] RE: byte-counting vs special character Thread-Index: AcbBoATsieQeRsYBTmyuyYA/T3xm/AABofkg From: "Rainer Gerhards" To: "Carson Gaspar" , X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org =20 > -----Original Message----- > From: Carson Gaspar [mailto:carson@taltos.org]=20 > Sent: Wednesday, August 16, 2006 7:55 PM > To: syslog@ietf.org > Subject: RE: [Syslog] RE: byte-counting vs special character >=20 > --On Thursday, August 17, 2006 3:18 AM +0200 Rainer Gerhards=20 > wrote: >=20 > > Caspar - since when does legacy code do escaping? (Even if I've > > overlooked it, we might use a different escape character...) >=20 > It doesn't. However, if the escape character is legal in=20 > legacy code, it=20 > can appear twice. Which will be converted to a single escape=20 > character by a=20 > new receiver. Which is a bug. Which is why I said: No - a new receiver checks the version field and detects that it is a legacy message. This is what the header is designed for. As it knows it is legacy, it won't unescape... Rainer=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 16 23:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDY9S-0008Ov-Rx; Wed, 16 Aug 2006 23:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDY9R-0008Ok-J0 for syslog@ietf.org; Wed, 16 Aug 2006 23:02:33 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDY9Q-0000vh-0i for syslog@ietf.org; Wed, 16 Aug 2006 23:02:33 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 3E4569C00C for ; Thu, 17 Aug 2006 05:04:04 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19328-03 for ; Thu, 17 Aug 2006 05:04:00 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 3B05D9C00B for ; Thu, 17 Aug 2006 05:04:00 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Aug 2006 05:02:26 +0200 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174E06@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Backward compatibility Thread-Index: AcbBqZHE/jmA93cERKGyHBesAVGytw== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [Syslog] Backward compatibility X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi all, I just would like to refresh your memory about what happened last year. As David has already pointed out, the WG was stalled on backwards compatibility issues. Actually, it was nearly torn apart by them. What happened is very similar to the current discussion: Last year (and the year before), we have been discussing how syslog could be improved. We argued about backwards compatibility much in the same way we do now. The difference was that we did not persist that much with asking for it. So we moved to a glory new and clean world of non-backwards compatible but great syslog. We created documents in that spirit, always knowing that it would be a bad idea to sacrifice any of the "cleanless" on the altair of legacy syslog. We reached consensus on list, had wg last call, and were quite happy with the documents. Then came an IETF meeting where everything should be finalized. We expected everything would move smoothly. Quite the difference happened. The documents were violently objected because backwards compatibility was now considered overly important. Long-term WG members were quite surprised (to phrase it mildly) and for some weeks it looked like the WG would be concluded without finishing its goals. Then, the WG recovered and a new charter was crafted. One of the big topics in that charter is backwards compatibility. This is, why that sentence is in the charter: --- The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that ######considers the ease of migration between and the co-existence of existing versions and the Standard####. --- I was working hard at this time to get the nonsense backwards compatibility issues out of the charter that did not exist in realtiy (because legacy syslog itself was not compatible to it). Besides being close to concluded, last years compatibility issue caused loss of considerable work. What you now need to consider is that last years backward compatibility issue was of much less substance than the current one is. What was considered "legacy standard" was mostly non-existing (I have shown that in numerous posts). There were (and there are) much less similarity between different syslogd message formats than there are similarities between the popular syslog over TCP (over SSL) solutions which are deployed. Do not misunderstand me: I like clean solutions, just as I have liked them last year. My experience, however, generates a big warning alert. I do *not* once again like to create a set of documents just to get it objected because it is not compatible to existing technology. This time, we have a very simple and clean way to introduce it. This time, there is actually value in doing that. I agree it is not as technically clean as octet-couting, but it is within acceptable limits (at least mine). Again, I do not object octect-couting. I just want to make sure that everybody is aware of the history of this WG when it comes to backwards compatibility. What I object is wasting another year just on a simple question like this one. If we can make sure that won't happen, I am quite happy with octet-counting. If, however, the I-D's fail either in the next meeting or last call because of exactly this reason I am more than upset and would quit any further work on syslog. Besides octet-counting/LF we should look at other issues in the light of things that happened. Please see the mailing list archive if you do not believe what I have written. Again, I do NOT object octet-couting. I want try to make sure it wont be the last nail in the coffin of this WG, though. Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Aug 17 07:16:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDfpu-0002Zv-Aj; Thu, 17 Aug 2006 07:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDfpt-0002Zq-MP for syslog@ietf.org; Thu, 17 Aug 2006 07:14:53 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDfps-000413-DY for syslog@ietf.org; Thu, 17 Aug 2006 07:14:53 -0400 Received: from pc6 (1Cust74.tnt13.lnd4.gbr.da.uu.net [62.188.142.74]) by galaxy.systems.pipex.net (Postfix) with SMTP id 8FF6DE000396; Thu, 17 Aug 2006 12:14:39 +0100 (BST) Message-ID: <006e01c6c1e5$39c4ace0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" References: <0ada01c6c08f$b29c6c90$0400a8c0@china.huawei.com> Subject: Re: [Syslog] byte-counting vs special character Date: Wed, 16 Aug 2006 19:07:34 +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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "David Harrington" To: "'Rainer Gerhards'" Cc: Sent: Tuesday, August 15, 2006 7:24 PM Subject: [Syslog] byte-counting vs special character > Hi Rainer, >> > [speaking as contributor] > I like the argument that the LF solution will not break existing > implementations, but I would like to know this is actually true. Have > you actually tested this against multiple implementations, or is it a > theoretical argument? > Turning the argument around, how many implementations have you got and have tested for interoperability that use byte counting for syslog? As Rainer's posts and earlier work as documented on his web site show, there is an awful lot of syslog out there, more pre-existing, interoperable implementation than in any other activity of the IETF I have been involved with. For me, this overcomes any technical, architectural considerations of 'betterness' and says we must go with our best understanding of the existing marketplace (I thought differently when I started:-( Other participants on this list may only represent a little of the implemented code but it is still an awful lot of pre-existing implementation. Tom Petch > I know you have tested a number of other proposed ways of doing things > against multiple implementations to try to verify backwards > compatibility. Have you actually tested multiple existing > implementations with the LF and found that they do continue to work > without significant problems? Can you tell the WG which ones you have > tested? Are there implementations that break when using this solution? > > > dbh > >/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Aug 17 08:20:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDgqb-0002xq-03; Thu, 17 Aug 2006 08:19:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDgqZ-0002xl-Oy for syslog@ietf.org; Thu, 17 Aug 2006 08:19:39 -0400 Received: from balabit.hu ([82.141.167.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDgqY-0005z8-Cm for syslog@ietf.org; Thu, 17 Aug 2006 08:19:39 -0400 Subject: Re: [Syslog] RE: byte-counting vs special character From: Balazs Scheidler To: Carson Gaspar In-Reply-To: <3EC76EAEC1590ED5FF81F03E@[192.168.1.2]> References: <577465F99B41C842AAFBE9ED71E70ABA174DFB@grfint2.intern.adiscon.c om> <3EC76EAEC1590ED5FF81F03E@[192.168.1.2]> Content-Type: text/plain Date: Thu, 17 Aug 2006 14:19:22 +0200 Message-Id: <1155817162.6514.27.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Wed, 2006-08-16 at 12:32 -0700, Carson Gaspar wrote: > Escaping precludes no-configuration backwards compatibility, as no legacy > syslog-over-tcp code does escaping. So if you want to interoperate with > existing code, you must have a "don't escape or expect escapes" switch in > your code. If you're going to do that, just have a "LF mode vs byte-count > mode" switch. This whole backwards compat argument is bogus, iff we decide > to escape embedded LF instead of forbidding it. And I have yet to see > anyone argue for LF on any grounds except backwards compatibility. As I said in a private mail to you, no we don't need that switch. LF is escaped as a sequence of two characters '\' and 'n'. This way escaped LF characters will not affect protocol processing, the only issue is that LFs in the message will be written to the disk in a slightly different format. But adding the fact that current TCP senders are not transparent wrt LFs this is not a big deal. - old sender - new receiver => works, because current syslog-TCP senders strip LFs off the message, either they replace it with space or forward multiple messages - new sender - old receiver => works, because the old receiver does not care about the "\n" string in the message, although it will not unescape it when it writes it to disk -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Aug 17 10:36:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDixQ-0006ls-SL; Thu, 17 Aug 2006 10:34:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDixP-0006Qx-CM for syslog@ietf.org; Thu, 17 Aug 2006 10:34:51 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDikI-0002aW-Hd for syslog@ietf.org; Thu, 17 Aug 2006 10:21:19 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 17 Aug 2006 07:21:18 -0700 X-IronPort-AV: i="4.08,137,1154934000"; d="scan'208"; a="1848057942:sNHT30722452" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7HELIdM022790; Thu, 17 Aug 2006 07:21:18 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7HELH6X020404; Thu, 17 Aug 2006 07:21:17 -0700 (PDT) Date: Thu, 17 Aug 2006 07:21:16 -0700 (PDT) From: Chris Lonvick To: Balazs Scheidler Subject: Re: [Syslog] RE: byte-counting vs special character In-Reply-To: <1155817162.6514.27.camel@bzorp.balabit> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA174DFB@grfint2.intern.adiscon.c om> <3EC76EAEC1590ED5FF81F03E@[192.168.1.2]> <1155817162.6514.27.camel@bzorp.balabit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=2028; t=1155824478; x=1156688478; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Re=3A=20[Syslog]=20RE=3A=20byte-counting=20vs=20special=20character; X=v=3Dcisco.com=3B=20h=3DMKyuInNi2zgmdXLiilw4ckD/4Dw=3D; b=psLprqoC+9rxUwKiyzw/72H8i08Sc7nSRr66jqgiL5uyaDDv4A9DKSHycrN7KKRTv/1wc9MT oPbZL0mQPs8mrR5dMvSH1EDNeO7GsLfU83iNNcMLUdYJ+N5BGnfnq+sv; Authentication-Results: sj-dkim-7.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, On Thu, 17 Aug 2006, Balazs Scheidler wrote: > On Wed, 2006-08-16 at 12:32 -0700, Carson Gaspar wrote: >> Escaping precludes no-configuration backwards compatibility, as no legacy >> syslog-over-tcp code does escaping. So if you want to interoperate with >> existing code, you must have a "don't escape or expect escapes" switch in >> your code. If you're going to do that, just have a "LF mode vs byte-count >> mode" switch. This whole backwards compat argument is bogus, iff we decide >> to escape embedded LF instead of forbidding it. And I have yet to see >> anyone argue for LF on any grounds except backwards compatibility. > > As I said in a private mail to you, no we don't need that switch. LF is > escaped as a sequence of two characters '\' and 'n'. This way escaped LF > characters will not affect protocol processing, the only issue is that > LFs in the message will be written to the disk in a slightly different > format. But adding the fact that current TCP senders are not transparent > wrt LFs this is not a big deal. > > - old sender - new receiver > => works, because current syslog-TCP senders strip LFs off the > message, either they replace it with space or forward multiple messages > > - new sender - old receiver > => works, because the old receiver does not care about the "\n" > string in the message, although it will not unescape it when it writes > it to disk What's going to happen with syslog-sign and/or other mechanisms that will look at the packet and create a hash of it? It sounds like everything will be acceptable if a new receiver gets it and does the re-conversion before anything looks at the contents. However, an old receiver will continue to keep the \n which will mess up syslog-sign. Is that correct? Also, what's going to happen to a new receiver that receives a legitimate "\n" as in an original message send: ... BOM The offending characters are \n Will the receiver convert that into LF? Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Aug 17 10:38:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDj0U-00080Q-9z; Thu, 17 Aug 2006 10:38:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDj0T-00080B-5O for syslog@ietf.org; Thu, 17 Aug 2006 10:38:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDj0T-0006uH-3f for syslog@ietf.org; Thu, 17 Aug 2006 10:38:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDilZ-0007Hu-Dg for syslog@ietf.org; Thu, 17 Aug 2006 10:22:40 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 17 Aug 2006 07:22:36 -0700 X-IronPort-AV: i="4.08,137,1154934000"; d="scan'208"; a="312069298:sNHT32560368" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7HEMaX7009821; Thu, 17 Aug 2006 07:22:36 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7HEMZ6X021067; Thu, 17 Aug 2006 07:22:35 -0700 (PDT) Date: Thu, 17 Aug 2006 07:22:35 -0700 (PDT) From: Chris Lonvick To: David Harrington Subject: RE: [Syslog] RE: byte-counting vs special character In-Reply-To: <0bfb01c6c199$01c71860$0400a8c0@china.huawei.com> Message-ID: References: <0bfb01c6c199$01c71860$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=2431; t=1155824556; x=1156688556; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:RE=3A=20[Syslog]=20RE=3A=20byte-counting=20vs=20special=20character; X=v=3Dcisco.com=3B=20h=3DRBXSe64fi0EdrHj8Tz0GuQtbh4g=3D; b=KGxRcUxzw4d6NrODmqacyZc/JMBQRZKBhb8kkzRFCTxRVc7r/Awny2LeBaWSagAZkq55en47 QF4Svr0q0RlUhB9HpkOxmG5490Hz/NFuqNl2TxLXvFxzezfvepTC1/WS; Authentication-Results: sj-dkim-6.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I agree; we don't want a vote here. We want strong technical reasons for making a decision. Thanks, Chris On Wed, 16 Aug 2006, David Harrington wrote: > Hi Rainer, > > The IETF doesn't vote. > The chairs will determine consensus on or after the Aug 18 deadline > for this decision. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > > >> -----Original Message----- >> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] >> Sent: Wednesday, August 16, 2006 8:08 PM >> To: Carson Gaspar >> Cc: syslog@ietf.org >> Subject: RE: [Syslog] RE: byte-counting vs special character >> >> Carson, >> >> Legacy code does not contain LF in messages. It is advised that >> new-style syslog also does not contain control characters >> (though it now >> is allowed). >> >> Thus the argument is valid. Again, I do not object octet-couting (I >> actually introduced the idea ;)) but find it the second > best-solution. >> Maybe we should do a simple poll - some have already voiced their >> choices... >> >> Rainer >> >>> -----Original Message----- >>> From: Carson Gaspar [mailto:carson@taltos.org] >>> Sent: Wednesday, August 16, 2006 1:33 PM >>> To: syslog@ietf.org >>> Subject: Re: [Syslog] RE: byte-counting vs special character >>> >>> Escaping precludes no-configuration backwards compatibility, >>> as no legacy >>> syslog-over-tcp code does escaping. So if you want to >>> interoperate with >>> existing code, you must have a "don't escape or expect >>> escapes" switch in >>> your code. If you're going to do that, just have a "LF mode >>> vs byte-count >>> mode" switch. This whole backwards compat argument is bogus, >>> iff we decide >>> to escape embedded LF instead of forbidding it. And I have >> yet to see >>> anyone argue for LF on any grounds except backwards compatibility. >>> >>> -- >>> Carson >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >>> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Aug 17 11:57:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDkEd-0002eJ-5K; Thu, 17 Aug 2006 11:56:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDkEb-0002dx-Ob for syslog@ietf.org; Thu, 17 Aug 2006 11:56:41 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDkEa-0006W4-En for syslog@ietf.org; Thu, 17 Aug 2006 11:56:41 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc14) with SMTP id <20060817155635b1400glpt2e>; Thu, 17 Aug 2006 15:56:35 +0000 From: "David Harrington" To: "'tom.petch'" Subject: RE: [Syslog] byte-counting vs special character Date: Thu, 17 Aug 2006 11:54:56 -0400 Message-ID: <0c3301c6c215$7d47b130$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <006e01c6c1e5$39c4ace0$0601a8c0@pc6> Thread-Index: AcbB7lWmMlyQEV5RSSihbwXq/h9xeQAG8ozg X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Tom, [speaking as a contributor] Rainer asserted that using LF would not break existing implementations. It does not appear to me that we have reached consensus that this assertion is true. I personally have concerns because this WG has already found that many syslog implementations are not compatible, especially on the point of having reserved/escaped control characters for special use. I asked if Rainer could provide any empirical support for his assertion, or whether his assertion was theoretical. I have not asserted that a message containing an octet count would work with existing implementations; only syslog implementations that were updated to support the not-yet-defined standard would use octet counting. Legacy messages without an octet-count would continue to be sent to the legacy syslog port, presumably one by one or delineated using whatever mechanism the legacy implementation currently supports. As I see it, a syslog/tls implementation would prepend an octet-count field to each syslog message, concatenate the messages into a stream, and send the concatenated messages to the new port. An implementation that supports the syslog/tls standard would strip off the prepending octet-count and extract each counted syslog message from the stream. Each extracted message could then be processed using the exact same parser code as would be used for messages received at the legacy syslog port. Using an octet-count encapsulation technique like this means the existing syslog message is not touched in any way, and the presence of an octet-counted stream delivered to a special port expecting the octet-counted stream, cannot interfere with any existing assumptions about the message format or content. Note that the syslog messages encapsulated by the octet-count might be able to be of any syslog format. The legacy parser implementation (whichever of the many incompatible variations) would not be changed. If the ability to carry different formats of syslog messages is desired, an additional field should probably be prepended to each syslog message in the stream that identified which syslog parser should be used to parse it. I am not a supporter of this approach because I would rather see implementations move to the syslog-protocol standard, but for those who value backwards compatibility above all else, this might be an interesting property. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, August 16, 2006 1:08 PM > To: David Harrington > Cc: syslog@ietf.org > Subject: Re: [Syslog] byte-counting vs special character > > ----- Original Message ----- > From: "David Harrington" > To: "'Rainer Gerhards'" > Cc: > Sent: Tuesday, August 15, 2006 7:24 PM > Subject: [Syslog] byte-counting vs special character > > > > Hi Rainer, > >> > > [speaking as contributor] > > I like the argument that the LF solution will not break existing > > implementations, but I would like to know this is actually > true. Have > > you actually tested this against multiple implementations, > or is it a > > theoretical argument? > > > Turning the argument around, how many implementations have > you got and have > tested for interoperability that use byte counting for syslog? > > As Rainer's posts and earlier work as documented on his web > site show, there is > an awful lot of syslog out there, more pre-existing, interoperable > implementation than in any other activity of the IETF I have > been involved with. > For me, this overcomes any technical, architectural considerations of > 'betterness' and says we must go with our best understanding > of the existing > marketplace (I thought differently when I started:-( > > Other participants on this list may only represent a little > of the implemented > code but it is still an awful lot of pre-existing implementation. > > Tom Petch > > > > > I know you have tested a number of other proposed ways of > doing things > > against multiple implementations to try to verify backwards > > compatibility. Have you actually tested multiple existing > > implementations with the LF and found that they do continue to work > > without significant problems? Can you tell the WG which > ones you have > > tested? Are there implementations that break when using > this solution? > > > > > > dbh > > > >/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Aug 17 12:54:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDl84-00057F-HC; Thu, 17 Aug 2006 12:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDl83-000578-00 for syslog@ietf.org; Thu, 17 Aug 2006 12:53:59 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDl80-00029D-P4 for syslog@ietf.org; Thu, 17 Aug 2006 12:53:58 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc11) with SMTP id <20060817165356b11000sup7e>; Thu, 17 Aug 2006 16:53:56 +0000 From: "David B Harrington" To: Date: Thu, 17 Aug 2006 12:52:17 -0400 Message-ID: <0c3601c6c21d$7fdb5ac0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xgFd3xtA X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Syslog] MIB document decision needed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Tomorrow is the deadline for establishing consensus on whether draft-ietf-syslog-device-mib represents WG consensus on what needs to be managed in the protocol, udp, tls, and sign documents, and if not, what needs to be changed to represent WG consensus. Tom has pointed out that the terminology and concepts don't seem to match what we are standardizing in the other documents. Please look at the MIB document and answer the following questions: 1) Is the terminology consistent with the other WG documents? 2) are the concepts consistent with the other WG documents? 3) does the MIB provide management for what is being defined in the other WG documents? 4) does the MIB not provide adequate management for what is defined in the WG documents? Please reply by August 18. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Aug 17 16:27:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDoR7-0001Dv-6B; Thu, 17 Aug 2006 16:25:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDoR5-0001BY-Qz for syslog@ietf.org; Thu, 17 Aug 2006 16:25:51 -0400 Received: from balabit.hu ([82.141.167.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDoEJ-0001SP-Ft for syslog@ietf.org; Thu, 17 Aug 2006 16:12:40 -0400 Subject: RE: [Syslog] RE: byte-counting vs special character From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: <0bfb01c6c199$01c71860$0400a8c0@china.huawei.com> Content-Type: text/plain Date: Thu, 17 Aug 2006 22:12:32 +0200 Message-Id: <1155845552.15643.28.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Thu, 2006-08-17 at 07:22 -0700, Chris Lonvick wrote: > Hi, > > I agree; we don't want a vote here. We want strong technical reasons for > making a decision. > As I see: We have a technically superior (we all seem to agree on this one) solution that breaks compatibility. Compatibility is important, this is documented in our charter. If we are to break compatibility we definitely need to have important incentives to do so. As I see the byte counter in itself is not important enough, I would simply forbid LF in messages as a compromise if that is acceptable to others. Thus we should not simply stop at adding the byte counter. There are other features currently missing from the protocol which can only be implemented with an incompatible change. An important example is application layer acknowledgements. (not the complex one in syslog/COOKED but a simpler scheme) What I'm afraid about this path is that we need to deliver something soon. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 18 10:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE5Rk-0007kU-O4; Fri, 18 Aug 2006 10:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE5Rj-0007kO-Mj for syslog@ietf.org; Fri, 18 Aug 2006 10:35:39 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE5Rg-0002gL-DX for syslog@ietf.org; Fri, 18 Aug 2006 10:35:39 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2006 07:35:36 -0700 X-IronPort-AV: i="4.08,145,1154934000"; d="scan'208"; a="440992656:sNHT27460638" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7IEZZnk005723 for ; Fri, 18 Aug 2006 07:35:35 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7IEZZYq011347 for ; Fri, 18 Aug 2006 07:35:35 -0700 (PDT) Date: Fri, 18 Aug 2006 07:35:35 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=345; t=1155911735; x=1156775735; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Legitimate=20\n=20or=20byte-counting; X=v=3Dcisco.com=3B=20h=3DPdAHXIz5kgQBSRbH2IAGA4jV/uA=3D; b=uTnZMV434wZClUZFqNvZ2U4EYWfZZ7juOfEXw5ghRKIbY+tj7AQgdgalYKQ8klbuTODWK73Q 7rH+j/p9JMrGpUQGNiOCKLFhe0VqjvMwzt1VO9KwJsS+rgbQMJCl1uLy; Authentication-Results: sj-dkim-3.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Syslog] Legitimate \n or byte-counting X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, If we use LF-escaping in syslog messages, what's going to happen if a legitimate "\n" is sent by a sender? An example would be: ... BOM The offending characters are \n Will a receiver convert that into LF? If that's the case then we should not be using LF-escaping. We need this answered today. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 18 13:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE8JE-0006eQ-A3; Fri, 18 Aug 2006 13:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE8JC-0006eD-TJ for syslog@ietf.org; Fri, 18 Aug 2006 13:39:02 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE8JC-0002W2-8P for syslog@ietf.org; Fri, 18 Aug 2006 13:39:02 -0400 Received: from pc6 (1Cust156.tnt107.lnd4.gbr.da.uu.net [213.116.62.156]) by blaster.systems.pipex.net (Postfix) with SMTP id BB71DE0002C7; Fri, 18 Aug 2006 18:38:52 +0100 (BST) Message-ID: <000401c6c2e4$0f11e1c0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <0b4e01c6c0c9$ef25f700$0400a8c0@china.huawei.com> Subject: Re: [Syslog] WGLC: protocol Date: Thu, 17 Aug 2006 16:18:53 +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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org The only comments I would add are - p.18 suggest replacing 'ABNF %D92' by 'ABNF %d92' - 6.4 suggest ' a "meta" SD-ID' for 'an "meta" SD-ID' - 8.1 suggest replacing. 'security issues bound with UNICODE' by 'security issues with UNICODE' or 'security issues bound up with UNICODE' - On ITU perceived severity, I would stay with the Alam MIB reference. I seem to recall that the discussions in disman were complex and that what is there is the best compromise. M.3100 only talks of perceivedSeverity in a reference to Q.821, it uses severity in several other contexts with different enumerations for the same severity in different places. I think that disman provided a good interpretation of the complexity of the ITU Recommendations and that we cannot better that in syslog. Tom Petch ----- Original Message ----- From: "David Harrington" To: Sent: Wednesday, August 16, 2006 2:21 AM Subject: [Syslog] WGLC: protocol > Hi, > > Here is my review of the protocol-17 document. > > Let me apologize (slightly) for such a thorough review, late in the > process, but as co-chair I need to say I reviewed this thoroughly and > that I agree it is ready to be published as a standard. I am much > pickier about a document I will sign-off as co-chair than one I accept > as a casual WG participant. > > For the most part, this review focuses on publication and > standardization requirements rather than on the technical design of > the protocol. I plan to do that review separately, and consider the WG > members more competent in syslog specifics than me. > > >From the standpoint of what I reviewed, this document generally looks > good. > > dbh > > -- idnits -- > > The document has the correct IPR boilerplates, RFC2119 boilerplate, > and the document passes the automated idnits tool. > > Idnits found two reference problems that should be addressed. > > Reference [2] is never used in the text. > Reference [17] is never used in the text. > > -- xml2rfc validation -- > > Since the source for this document is written in xml2rfc format, the > RFC editor will request that you submit a copy of the xml2rfc source > with the document to be published. It is a good thing if the sources > used to publish the final document are consisteent with the copy we > have for future update work, so it is a good thing to fix any known > problems in the xml2rfc source before submitting it to the RFC editor. > The rfc editor typically does not return their edited version to us. > > The xml2rfc-validator tool at > http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi identified a > number of usages that are invalid according to the rfc2629.dtd, and > some usages that have been deprecated or obsoleted by the xml2rfc > tool. The xml2rfc tool will still accept these on the basis of being > liberal in what it accepts, but we should also be conservative in what > we send. > > It would be good to fix all these errors and warnings. > > -- References -- > > The xml2rfc-validator tool at > http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi identified > some obsolete references: > > RFC 2234 has been obsoleted by RFC4234 > RFC 3513 has been obsoleted by RFC4291 > > 6.2.1.1 says The Alarm MIB defines ITU perceived severities. Actually, > don't ITU M.3100 and X.733 define the severities, and the Alarm MIB > just uses them? I don't have a copy of M.3100 or X.733, so I cannot > check this; can somebody check this? I think we should reference the > original definition, and then we can point out that the Alarm MIB > references the ITU severities as well. According to RFC3877, the > references are > "ITU Recommendation M.3100, 'Generic Network Information Model', 1995" > and > "ITU Recommendation X.733, 'Information Technology - Open Systems > Interconnection - System Management: Alarm Reporting Function', 1992" > > -- RFC2119 language -- > > Section 5 states the UDP "transport is REQUIRED for interoperability > ...". I think this might be better phrased as the UDP "transport is > mandatory to implement for compliance to the standard to support > interoperability ..." or remove the sentence since the next section > discusses the minimum required transport mapping. > > In section 5.1, it says "This ensures interoperability ...". This > might be better stated as "This ensures at least a minimum > interoperability ..." > > Section 6 is entitled "Required syslog format". I suggest making it > simply "Syslog Message Format". > > Section 6.1: "After trucation, the message MAY contain invalid UTF-8 > encoding or invalid STRUCTURED-DATA." > Does this need an addendum to standardize subsequent behavior? If the > truncated message now contains invalid content, should the whole > message be discarded, or should the receiver try to process as much as > it can, even if it is incomplete, and the results of subsequent > processing could be misleading to an operator? > > 6.2.1: "A receiver MUST NOT assume any specific semantics by default." > I think this fails the RFC2119 test - RFC2119 keywords MUST only be > used where it is actually required for interoperation or to limit > behavior which has potential for causing harm; this assumption would > happen after the message came off the wire, so should not impact > interoperability on-the-wire, and it should have no effect on behavior > such as retransmission. Obviously, a management application might > cause a configuration change based on a faulty assumption, but I don't > think that is a protocol issue. I think the maximum RFC2119 language > here would be a SHOULD NOT. > > 6.2.5 This section should mention that APP-NAME is an > operator-configured value, which justifies the use of SHOULD rather > than MUST here. > > 6.2.6 if operator-configured, then ditto. > > 6.2.7 if operator-configured, then ditto. > > 6.3.2 "to be assigned by IETF CONSENSUS" should include a reference to > BCP26 (RFC2434), since IETF CONSENSUS has a specific meaning defined > in the BCP. > > 6.3.4 "An exception is the addition of a new OPTIONAL PARAM-NAME to an > existing SD-ID, what MAY be done." This strikes me as incorrect > English grammar; I recommend rewording it. Here is some suggested > text: "OPTIONAL PARAM-NAMEs MAY be added to an existing SD-ID." > > 7.2.1 Can it list an ip address in the "ip" parameter AND provide a > list of multiple "ip" parameters in an "origin" element? If not, why > not? Wouldn't it be useful to provide the "origin" list, but also to > identify its "preferred" address for syslog purposes in "ip"? > > 7.2.3 "It always contains the name of the generating software," - > should this one be MUST? > > "whereas APP-NAME can contain anything else, including an > operator-configured value." Section 6.2.5 should mention that APP-NAME > is an operator-configured value. > > If the software parameter contains UTF-8, then it is important to > specify the maximum length of strings in octets rather than > characters, since characters can be multi-byte. > > 7.2.4 If the swVersion parameter contains UTF-8, then it is important > to specify the maximum length of strings in octets rather than > characters, since characters can be multi-byte. > > > -- spelling -- > > /parsable/parseable/g > neither MS-Word nor Merriam-Webster recognizes either > spelling. Wikipedia supports parseable under parsing. > computing-dictionary.thefreedictionary.com supports parseable. > Apparently the Oxford dictionary supports parseable, based on a > discussion at apache.org, but I don't have a subscription to check it. > > /trucation/truncation > /conceptionally/conceptually/ > /mimimize/minimize/ > /timezone/time zone/g > according to MS-Word and Mirriam-Webster online > /implementor/implementer/g > for consistency with rfc-editor boilerplate text. > /any-enterprise assigned/any enterprise-assigned/ > > enterpriseId or enterpriseID - inconsistent usage. > > 6.2.4 "described in RFC 3513" should this be ", as described in RFC > 3513"? > > 7.2.2 "Only that number and any-enterprise assigned > ID below it MUST be specified in the "enterpriseId" parameter." > seems awkward. > > Would this be better as "An enterprise is only authorized to assign > values within the iso.org.dod.internet.private.enterprise. ID> subtree assigned by IANA to that enterprise. The enterpriseId MUST > contain only a value from the > iso.org.dod.internet.private.enterprise. subtree." > > 7.3.2 /integer/INTEGER/ > > Note that the semantics in RFC3418 are > "The time (in hundredths of a second) since the network > management portion of the system was last > re-initialized." > This of course relates to the SNMP-related management portion of the > system, which MAY be different than the syslog-related management > portion of the system. > > -- security considerations > > Good job describing the potential configuration issues. > Since the transport documents will describe the threat models, it is > probably acceptable that the threat model is not covered here in the > terminology recommended by rfc3552. > > -- IANA considerations -- > > Good. > > -- Authors -- > > We now have a syslog@ietf.org mailing list adddress. That should be > used rather than the employees.org address. > > You should identify that I work for Huawei Technologies USA. > > -- Acknowledgment -- > > The funding acknowledgment for the RFC Editor function is out of date, > but the latest xml2rfc tool corrects it to acknowledge the IASA rather > than the Internet Society. > > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 18 13:40:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE8JE-0006eI-51; Fri, 18 Aug 2006 13:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE8JC-0006e8-KG for syslog@ietf.org; Fri, 18 Aug 2006 13:39:02 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE8JB-0002VK-BP for syslog@ietf.org; Fri, 18 Aug 2006 13:39:02 -0400 Received: from pc6 (1Cust156.tnt107.lnd4.gbr.da.uu.net [213.116.62.156]) by blaster.systems.pipex.net (Postfix) with SMTP id E2CD2E0000D2; Fri, 18 Aug 2006 18:38:48 +0100 (BST) Message-ID: <000201c6c2e4$0d6e43e0$0601a8c0@pc6> From: "tom.petch" To: "Anton Okmianski (aokmians)" References: <98AE08B66FAD1742BED6CB9522B7312201C971AC@xmb-rtp-20d.amer.cisco.com> Subject: Re: [Syslog] byte-counting vs special character Date: Thu, 17 Aug 2006 12:53:25 +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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Anton Okmianski (aokmians)" To: "David Harrington" ; "Rainer Gerhards" Cc: Sent: Tuesday, August 15, 2006 8:04 PM Subject: RE: [Syslog] byte-counting vs special character I second these concerns. Escaping requirements result in a more interdependent layering, which is a weaker architecture (not to mention the overhead to a new standard). The syslog transport would need to mess with payload instead of treating it as opaque blob with easily known length. Not nice. Imagine TCP/IP escaping all payload to separate datagrams and segments. Escaping of magic characters is IMHO clearly a hack and should not be put into a standard! Well, I think you just wrote off most of the IETF STANDARDs that deal with character-based protocols (like the e-mail we are using to communicate(?)). A set of characters, of symbols, in a 'message' is encoded, given a number, be it 6 or 8 or 16 or whatever number of bits. If that bit pattern conflicts with the 'control' aspects of a protocol, then that bit pattern must be 'transfer-encoded' so that it does not appear per se on the wire. That is what base64 or quoted-printable do for e-mail. So we are talking of using a well-understood, widely deployed piece of protocol architecture to solve a common problem. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 18 16:18:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEAm3-0007wf-Df; Fri, 18 Aug 2006 16:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEAm2-0007wa-9D for syslog@ietf.org; Fri, 18 Aug 2006 16:16:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEAm2-0003Bn-7Q for syslog@ietf.org; Fri, 18 Aug 2006 16:16:58 -0400 Received: from dsl081-242-052.sfo1.dsl.speakeasy.net ([64.81.242.52] helo=gandalf.taltos.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GEAly-0004Lv-FT for syslog@ietf.org; Fri, 18 Aug 2006 16:16:56 -0400 Received: from gandalf.taltos.org (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id EE68A21CC4 for ; Fri, 18 Aug 2006 13:16:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on gandalf.taltos.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.168.1.2] (unknown [192.168.1.2]) by gandalf.taltos.org (Postfix) with ESMTP id EC67421B73 for ; Fri, 18 Aug 2006 13:16:48 -0700 (PDT) Date: Fri, 18 Aug 2006 13:18:51 -0700 From: Carson Gaspar To: syslog@ietf.org Subject: Re: [Syslog] Legitimate \n or byte-counting Message-ID: <18208CB19EAB34CE8960181B@[192.168.1.2]> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.6 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --On Friday, August 18, 2006 7:35 AM -0700 Chris Lonvick wrote: > If we use LF-escaping in syslog messages, what's going to happen if a > legitimate "\n" is sent by a sender? An example would be: > > ... BOM The offending characters are \n > > Will a receiver convert that into LF? If that's the case then we should > not be using LF-escaping. I raised the same issue. The answer is the receiver will examine the protocol version and will not un-escape unless the sender is a new-style sender. I'm still not convinced that the installed base of TCP syslog deployments is large enough to care about, but, given the decision to maximize backwards comparability, this is "good enough" to make implementation possible. -- Carson _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 18 16:48:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEBG7-0003Wx-Dy; Fri, 18 Aug 2006 16:48:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEBG6-0003Wp-72 for syslog@ietf.org; Fri, 18 Aug 2006 16:48:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEBG6-0006OG-5V for syslog@ietf.org; Fri, 18 Aug 2006 16:48:02 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GEBCa-00055J-Jv for syslog@ietf.org; Fri, 18 Aug 2006 16:44:26 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc12) with SMTP id <20060818204409b1200sd9tre>; Fri, 18 Aug 2006 20:44:21 +0000 From: "David Harrington" To: Date: Fri, 18 Aug 2006 16:42:28 -0400 Message-ID: <0d3701c6c306$dacebdc0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbDBqP2soXaCfddQauLsamuuFYmbA== X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [Syslog] MIB document decision X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I agree the terminology in the MIB document differs from that in -protocol- and should be updated to match the WG consensus on terminology. Here are a few things I spotted that should be fixed or checked: The references in the MIB are to RFC3164, not the current -protocol- document produced by the WG. Since -protocol- will be a standard while RFC3164 is informational, we should reference the standard documents. (If it is useful to compare the RFC3164 attributes to the -protocol- attributes, I recommend a section that shows how they map/compare. There are DEFVAL default values; are these connsistent with the new document? Use existing textual-conventions (such as transportDomain) rather than SyslogTransport ? Is syslDevCCtlConfFileName implementation-neutral? MOs should be spelled out as managed objects. syslDevOpsLastError - could this contain sen sitive information, such as passwords or user names? Has the MIB been checked against RFC4181? MIB Doctors will expect a section entitled "Relationship to other MIB Modules". See ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-harrington-tex t-mib-doc-template-00.txt for further advice about what should be in the document. The documents that contain the IMPORTS must be cited in text outside the MIB module. The document does not pass the id-nits check by http://tools.ietf.org/tools/idnits/idnits.pyht It would be good to make this RFC4181-compliant and idnits-compliant before we start the WGLC. The document should also be compared to the functionality described in -protocol-, -udp-, and -tls- documents to make sure the defaults are consistent, and the management functionality adequate. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 18 18:23:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GECjM-0005OD-6V; Fri, 18 Aug 2006 18:22:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GECjK-0005O6-QS for syslog@ietf.org; Fri, 18 Aug 2006 18:22:18 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GECjI-0001V2-HI for syslog@ietf.org; Fri, 18 Aug 2006 18:22:18 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc13) with SMTP id <20060818222205b13002iemve>; Fri, 18 Aug 2006 22:22:15 +0000 From: "David Harrington" To: "'Carson Gaspar'" , Subject: RE: [Syslog] Legitimate \n or byte-counting Date: Fri, 18 Aug 2006 18:20:26 -0400 Message-ID: <0d6801c6c314$87fe73c0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <18208CB19EAB34CE8960181B@[192.168.1.2]> Thread-Index: AcbDA3Ho3Rz5w1zURQSVnlxYZzITPwAA2AKg X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [speaking as co-chair] I believe it is inaccurate to say there has been a WG decision to maximize backwards compatibility. The charter says "The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard." There is a big difference between "maximizing for backwards compatibility" and "considering the ease of migration between and the co-existence of existing versions and the standard." This difference was discussed during the charter discussions. We need to balance backwards compatibility with improved interoperability and good technical design. We need to focus on **forward** compatibility - defining a standard that implementors can move forward toward so there is increased commonality, vendor neutrality, and interoperability. If we keep trying for backwards compatibility to a wide range of incompatible implementations, then we might as well go home now. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Carson Gaspar [mailto:carson@taltos.org] > Sent: Friday, August 18, 2006 4:19 PM > To: syslog@ietf.org > Subject: Re: [Syslog] Legitimate \n or byte-counting > > --On Friday, August 18, 2006 7:35 AM -0700 Chris Lonvick > wrote: > > > If we use LF-escaping in syslog messages, what's going to > happen if a > > legitimate "\n" is sent by a sender? An example would be: > > > > ... BOM The offending characters are \n > > > > Will a receiver convert that into LF? If that's the case > then we should > > not be using LF-escaping. > > I raised the same issue. The answer is the receiver will examine the > protocol version and will not un-escape unless the sender is > a new-style > sender. I'm still not convinced that the installed base of TCP syslog > deployments is large enough to care about, but, given the decision to > maximize backwards comparability, this is "good enough" to make > implementation possible. > > -- > Carson > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 18 23:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEHNq-0000VZ-72; Fri, 18 Aug 2006 23:20:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEHNo-0000VQ-E8 for syslog@ietf.org; Fri, 18 Aug 2006 23:20:24 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEHNm-0004Wm-SP for syslog@ietf.org; Fri, 18 Aug 2006 23:20:24 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 8937F9C00C; Sat, 19 Aug 2006 05:21:57 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20977-05; Sat, 19 Aug 2006 05:21:53 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 022F79C00B; Sat, 19 Aug 2006 05:21:52 +0200 (CEST) Subject: RE: [Syslog] Legitimate \n or byte-counting MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Aug 2006 05:20:06 +0200 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174E0B@grfint2.intern.adiscon.com> In-Reply-To: <0d6801c6c314$87fe73c0$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Legitimate \n or byte-counting Thread-Index: AcbDA3Ho3Rz5w1zURQSVnlxYZzITPwAA2AKgAA3PvuA= From: "Rainer Gerhards" To: "David Harrington" , "Carson Gaspar" , X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David, I have just now be able to poll my mail. I trust you as a co-chair that this time the documents will not be torn apart because of the missing backwards compatibility. Thus, I agree we should move to octet-couting, as there is more consensus to use that (and it is technically superior). I would just deeply appreciate if you could try to make sure this will not be the reason for violent objection of the document set as it was last year. Thanks for driving this discussion and getting us to consensus. Rainer=20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, August 18, 2006 4:20 PM > To: 'Carson Gaspar'; syslog@ietf.org > Subject: RE: [Syslog] Legitimate \n or byte-counting >=20 > Hi, >=20 > [speaking as co-chair] >=20 > I believe it is inaccurate to say there has been a WG decision to > maximize backwards compatibility. >=20 > The charter says > "The goal of this working group is to address the security and > integrity > problems, and to standardize the syslog protocol, transport, and a=20 > select set of mechanisms in a manner that considers the ease of=20 > migration between and the co-existence of existing versions and the=20 > standard." >=20 > There is a big difference between "maximizing for backwards > compatibility" and "considering the ease of migration between and the > co-existence of existing versions and the standard."=20 >=20 > This difference was discussed during the charter discussions. We need > to balance backwards compatibility with improved interoperability and > good technical design. >=20 > We need to focus on **forward** compatibility - defining a standard > that implementors can move forward toward so there is increased > commonality, vendor neutrality, and interoperability. > =20 > If we keep trying for backwards compatibility to a wide range of > incompatible implementations, then we might as well go home now. >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Carson Gaspar [mailto:carson@taltos.org]=20 > > Sent: Friday, August 18, 2006 4:19 PM > > To: syslog@ietf.org > > Subject: Re: [Syslog] Legitimate \n or byte-counting > >=20 > > --On Friday, August 18, 2006 7:35 AM -0700 Chris Lonvick=20 > > wrote: > >=20 > > > If we use LF-escaping in syslog messages, what's going to=20 > > happen if a > > > legitimate "\n" is sent by a sender? An example would be: > > > > > > ... BOM The offending characters are \n > > > > > > Will a receiver convert that into LF? If that's the case=20 > > then we should > > > not be using LF-escaping. > >=20 > > I raised the same issue. The answer is the receiver will examine the >=20 > > protocol version and will not un-escape unless the sender is=20 > > a new-style=20 > > sender. I'm still not convinced that the installed base of TCP > syslog=20 > > deployments is large enough to care about, but, given the decision > to=20 > > maximize backwards comparability, this is "good enough" to make=20 > > implementation possible. > >=20 > > --=20 > > Carson > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Aug 19 02:04:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEJvT-0001xk-4b; Sat, 19 Aug 2006 02:03:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEJvQ-0001xf-LE for syslog@ietf.org; Sat, 19 Aug 2006 02:03:16 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEJvO-0001xn-Tt for syslog@ietf.org; Sat, 19 Aug 2006 02:03:16 -0400 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k7J62tm9020480 for ; Sat, 19 Aug 2006 15:02:55 +0900 (JST) Received: from [127.0.0.1] (kiras4.priv.cysol.co.jp [192.168.0.154]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k7J62k5x010384 for ; Sat, 19 Aug 2006 15:02:54 +0900 (JST) Message-ID: <44E6A985.7080306@cysols.com> Date: Sat, 19 Aug 2006 15:02:45 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] MIB document decision References: <0d3701c6c306$dacebdc0$0400a8c0@china.huawei.com> In-Reply-To: <0d3701c6c306$dacebdc0$0400a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Dave, Thanks for the review. I am in full agreement with the observations. This present document belongs to the 3164 era. Now that the protocol, udp documents are stable, it is time for an update. The following are TBDs 1. Update terminology to bring it incline with the protocol document. 2. Shift the base reference to the protocol document from RFC3164 3. Make the defaults specified in the DEFVALs consistent with the protocol, udp, tls documents 4. Make the document RFC4181-compliant, idnits-compliant [ref. draft-harrington-text-mib-doc-template-00.txt] a. Add references for IMPORTS b. Add a paragraph on relationship to other MIBs section 5. Review a. Is syslDevCCtlConfFileName implementation-neutral? b. Could syslDevOpsLastError contain sensitive information, such as passwords or user names? What will be the impact ? c. Is the management functionality adequate? 6. Editorial nits. MO=> managed objects 7. Make the changes and submit the revised I-D 1-4, 6-7 is doable. I will do it. I will look for WG input on item 5. Particularly on 5c. Cheers Glenn David Harrington wrote: > Hi, > > I agree the terminology in the MIB document differs from that in > -protocol- and should be updated to match the WG consensus on > terminology. > > Here are a few things I spotted that should be fixed or checked: > > The references in the MIB are to RFC3164, not the current -protocol- > document produced by the WG. Since -protocol- will be a standard while > RFC3164 is informational, we should reference the standard documents. > (If it is useful to compare the RFC3164 attributes to the -protocol- > attributes, I recommend a section that shows how they map/compare. > > There are DEFVAL default values; are these connsistent with the new > document? > Use existing textual-conventions (such as transportDomain) rather than > SyslogTransport ? > Is syslDevCCtlConfFileName implementation-neutral? > MOs should be spelled out as managed objects. > syslDevOpsLastError - could this contain sen sitive information, such > as passwords or user names? > > Has the MIB been checked against RFC4181? > MIB Doctors will expect a section entitled "Relationship to other MIB > Modules". > See > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-harrington-tex > t-mib-doc-template-00.txt for further advice about what should be in > the document. > The documents that contain the IMPORTS must be cited in text outside > the MIB module. > > The document does not pass the id-nits check by > http://tools.ietf.org/tools/idnits/idnits.pyht > > It would be good to make this RFC4181-compliant and idnits-compliant > before we start the WGLC. > > The document should also be compared to the functionality described in > -protocol-, -udp-, and -tls- documents to make sure the defaults are > consistent, and the management functionality adequate. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 22 11:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFYP8-0000HE-M9; Tue, 22 Aug 2006 11:43:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFYP7-0000H9-BQ for syslog@ietf.org; Tue, 22 Aug 2006 11:43:01 -0400 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFYP6-0006o8-55 for syslog@ietf.org; Tue, 22 Aug 2006 11:43:01 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc12) with SMTP id <20060822154258b1200aqipie>; Tue, 22 Aug 2006 15:42:58 +0000 From: "David Harrington" To: Date: Tue, 22 Aug 2006 11:41:18 -0400 Message-ID: <0f4801c6c601$69bba550$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbGARa0X4Nn1wYiRr+xAJ/rPpQSEw== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Syslog] Consensus: octet-counting X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [speaking as co-chair] Chris and I have reviewed the discussions and have reached the conclusion that the WG consensus is to use octet-counting rather a special character for delineating messages in a TLS transport. Miao and Yuzhi, please update the syslog-tls draft accordingly. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 22 21:51:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFhsc-0004jW-Da; Tue, 22 Aug 2006 21:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFhsa-0004jO-BK for syslog@ietf.org; Tue, 22 Aug 2006 21:50:04 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFhsL-0006WX-Lz for syslog@ietf.org; Tue, 22 Aug 2006 21:50:04 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4F00KAJH71C4@szxga01-in.huawei.com> for syslog@ietf.org; Wed, 23 Aug 2006 09:52:13 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4F00EUVH70QK@szxga01-in.huawei.com> for syslog@ietf.org; Wed, 23 Aug 2006 09:52:13 +0800 (CST) Received: from m03573B ([10.111.12.65]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4F00G5MHLXNK@szxml04-in.huawei.com> for syslog@ietf.org; Wed, 23 Aug 2006 10:01:13 +0800 (CST) Date: Wed, 23 Aug 2006 09:49:00 +0800 From: Ma Yuzhi Subject: RE: [Syslog] Consensus: octet-counting In-reply-to: <0f4801c6c601$69bba550$0400a8c0@china.huawei.com> To: 'David Harrington' , syslog@ietf.org Message-id: <008601c6c656$4dfed030$410c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbGARa0X4Nn1wYiRr+xAJ/rPpQSEwAVND2g X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, OK, We will update the syslog-tls draft ASAP. Yuzhi > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, August 22, 2006 11:41 PM > To: syslog@ietf.org > Subject: [Syslog] Consensus: octet-counting > > Hi, > > [speaking as co-chair] > > Chris and I have reviewed the discussions and have reached > the conclusion that the WG consensus is to use octet-counting > rather a special character for delineating messages in a TLS > transport. > > Miao and Yuzhi, please update the syslog-tls draft accordingly. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 23 06:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFpf7-0008VQ-Se; Wed, 23 Aug 2006 06:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFpf6-0008VK-CW for syslog@ietf.org; Wed, 23 Aug 2006 06:08:40 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFpf4-00068w-G8 for syslog@ietf.org; Wed, 23 Aug 2006 06:08:40 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4G00LY54TNK5@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 23 Aug 2006 18:22:35 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4G000UK4TM1W@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 23 Aug 2006 18:22:34 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4G001NH46E3A@szxml03-in.huawei.com> for syslog@ietf.org; Wed, 23 Aug 2006 18:08:42 +0800 (CST) Date: Wed, 23 Aug 2006 18:04:42 +0800 From: Miao Fuyou Subject: RE: [Syslog] MIB document decision In-reply-to: <44E6A985.7080306@cysols.com> To: "'Glenn M. Keeni'" , syslog@ietf.org Message-id: <009801c6c69b$8dbc0d60$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbDVXIR0mkM9n4XQiWuftjYDihcuADRebkQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Should we add something about TLS transport? 1, Page 9, trasport, should add TLS, may add DTLS and BEEP 2, Page 10, syslogDefaultTransport's defaul value is UDP, TLS? But I think it's UDP My 0.01$ Thanks! Miao > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Saturday, August 19, 2006 2:03 PM > To: syslog@ietf.org > Subject: Re: [Syslog] MIB document decision > > Dave, > Thanks for the review. I am in full agreement with the > observations. > This > present document belongs to the 3164 era. Now that the > protocol, udp documents are stable, it is time for an update. > The following are TBDs > 1. Update terminology to bring it incline with the > protocol document. > 2. Shift the base reference to the protocol document from RFC3164 > 3. Make the defaults specified in the DEFVALs consistent with the > protocol, udp, tls documents > 4. Make the document RFC4181-compliant, idnits-compliant > [ref. draft-harrington-text-mib-doc-template-00.txt] > a. Add references for IMPORTS > b. Add a paragraph on relationship to other MIBs section > 5. Review > a. Is syslDevCCtlConfFileName implementation-neutral? > b. Could syslDevOpsLastError contain sensitive > information, such > as passwords or user names? What will be the impact ? > c. Is the management functionality adequate? > 6. Editorial nits. > MO=> managed objects > 7. Make the changes and submit the revised I-D > > 1-4, 6-7 is doable. I will do it. I will look for WG input on item 5. > Particularly on 5c. > > Cheers > > Glenn > David Harrington wrote: > > Hi, > > > > I agree the terminology in the MIB document differs from that in > > -protocol- and should be updated to match the WG consensus on > > terminology. > > > > Here are a few things I spotted that should be fixed or checked: > > > > The references in the MIB are to RFC3164, not the current > -protocol- > > document produced by the WG. Since -protocol- will be a > standard while > > RFC3164 is informational, we should reference the standard > documents. > > (If it is useful to compare the RFC3164 attributes to the > -protocol- > > attributes, I recommend a section that shows how they map/compare. > > > > There are DEFVAL default values; are these connsistent with the new > > document? > > Use existing textual-conventions (such as transportDomain) > rather than > > SyslogTransport ? > > Is syslDevCCtlConfFileName implementation-neutral? > > MOs should be spelled out as managed objects. > > syslDevOpsLastError - could this contain sen sitive > information, such > > as passwords or user names? > > > > Has the MIB been checked against RFC4181? > > MIB Doctors will expect a section entitled "Relationship to > other MIB > > Modules". > > See > > > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-harrington-tex > > t-mib-doc-template-00.txt for further advice about what > should be in > > the document. > > The documents that contain the IMPORTS must be cited in > text outside > > the MIB module. > > > > The document does not pass the id-nits check by > > http://tools.ietf.org/tools/idnits/idnits.pyht > > > > It would be good to make this RFC4181-compliant and > idnits-compliant > > before we start the WGLC. > > > > The document should also be compared to the functionality > described in > > -protocol-, -udp-, and -tls- documents to make sure the > defaults are > > consistent, and the management functionality adequate. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 23 10:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtJy-0005eh-Ri; Wed, 23 Aug 2006 10:03:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtJw-0005eU-RK for syslog@ietf.org; Wed, 23 Aug 2006 10:03:04 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFtJv-0000xR-EY for syslog@ietf.org; Wed, 23 Aug 2006 10:03:04 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc11) with SMTP id <20060823140252b1100pn70le>; Wed, 23 Aug 2006 14:03:02 +0000 From: "David Harrington" To: Subject: FW: [Syslog] Working Group Last Call: protocol and udp documents Date: Wed, 23 Aug 2006 10:01:11 -0400 Message-ID: <102c01c6c6bc$9d735350$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iABiIFSoA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I haven't seen many reviews for the WGLC. Come on people, we're trying to finally get this work finished. Please put away your apathy and do some reviews. Dbh co-chair, Syslog WG -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Tuesday, August 15, 2006 2:42 PM To: syslog@ietf.org Subject: [Syslog] Working Group Last Call: protocol and udp documents Hi, I am resending this message with a new subject line, in case anybody is watching for the words "working group last call" in the subject line. It's also easier for me for bookkeeping reasons ;-) David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Monday, August 14, 2006 7:33 PM To: 'Chris Lonvick'; syslog@ietf.org Subject: RE: [Syslog] syslog WG Timeline Hi, This message officially starts the Syslog Working Group Last Call for the following two documents: draft-ietf-syslog-protocol: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt draft-ietf-syslog-transport-udp: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt The Working Group Last Call for these documents will end August 28. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, it if does not look acceptable please identify your ibjections, preferably with suggested text that would make it acceptable. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, August 11, 2006 3:17 PM > To: syslog@ietf.org > Subject: [Syslog] syslog WG Timeline > > Hi Folks, > > David and I have agreed upon a timeline for the completion of our > milestones. Please review this. We will be asking for > people to provide > review comments on each of the documents while they are in > Working Group > Last Call (WGLC). If you know that you're going to be > unavailable (summer > vacation) for some of these WGLCs, please submit comments to the WG > beforehand, at least to let us know that you've read it. > > Thanks, > Chris and David > > > ===start=== > > Aug 11 - Drive discussion on whether draft-ietf-syslog-device-mib > represents WG consensus on what needs to be managed in > -protocol-, -udp-, -tls-, and -sign-. > Aug 11 - Drive discussion on whether draft-ietf-syslog-transport-tls > should use byte-counting, special character, or > both, including > which special character. > > Aug 14 - Begin WG Last Call for draft-ietf-syslog-protocol (45 pages) > Aug 14 - Begin WG Last Call for draft-ietf-syslog-transport-udp (10 > pages) > > Aug 18 - Decide what needs to be changed in > draft-ietf-syslog-transport-tls to represent the final WG > consensus on byte-counting, special character, or > both, including > which special character. > Aug 18 - Decide what needs to be changed in the general design of > draft-ietf-syslog-device-mib to represent the WG consensus. > > Aug 28 - Close WG Last Call for draft-ietf-syslog-protocol > Aug 28 - Close WG Last Call for draft-ietf-syslog-transport-udp > > Aug 28 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > > Sep 1 - updated revision of draft-ietf-syslog-transport-tls, > representing WG consensus. > Sep 1 - updated revision of draft-ietf-syslog-device-mib, representing > WG consensus. > > Aug 28 - Begin WG Last Call for draft-ietf-syslog-sign (33 pages) > Aug 28 - Begin WG Last Call for draft-ietf-syslog-transport-tls (11 > pages) > > > Sep 11 - Close WG Last Call for draft-ietf-syslog-sign. > Sep 11 - Close WG Last Call for draft-ietf-syslog-transport-tls. > > Sep 11 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-sign > > Sep 11 - Begin WG Last Call for draft-ietf-syslog-device-mib (33 > pages) > > Sep 25 - Close WG Last Call for draft-ietf-syslog-device-mib. > Sep 25 - Chairs start working on Shepherding documents for > - draft-ietf-syslog-device-mib > > Oct 16 - Chairs produce Shepherding Documents for > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-device-mib > - draft-ietf-syslog-sign > > Oct 23 - Final review of Spepherding Documents by the WG > > Nov 1 - Submit the following to the IESG > - draft-ietf-syslog-protocol > - draft-ietf-syslog-transport-udp > - draft-ietf-syslog-transport-tls > - draft-ietf-syslog-device-mib > - draft-ietf-syslog-sign > > ===end=== > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 23 11:14:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuQE-0001il-TX; Wed, 23 Aug 2006 11:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuQD-0001iU-Nz for syslog@ietf.org; Wed, 23 Aug 2006 11:13:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFsJ8-0006pq-QY for syslog@ietf.org; Wed, 23 Aug 2006 08:58:10 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFsHn-0000g6-0T for syslog@ietf.org; Wed, 23 Aug 2006 08:56:47 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 23 Aug 2006 05:56:46 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7NCukiC003380 for ; Wed, 23 Aug 2006 05:56:46 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7NCuk1F016846 for ; Wed, 23 Aug 2006 05:56:46 -0700 (PDT) Date: Wed, 23 Aug 2006 05:56:45 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1277; t=1156337806; x=1157201806; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:syslog-sign=20Signature=20Block=20Hash=20Block=20Values; X=v=3Dcisco.com=3B=20h=3DJECDg4OASUOLZzMnGu6mFghXJMc=3D; b=IJoUERsI1j+s5xhTfVYbxNmpNkphX3neTdiNBvUWO1XISO61BciZ0dHVb4S7G0moTMv/iVn2 X1/rxdXvtR0lDz+VxyS6Ha/tnaMWWALbkc8/1m+FEH7FsJInvxv4SPCT; Authentication-Results: sj-dkim-2.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Syslog] syslog-sign Signature Block Hash Block Values X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, As everyone should recall from Section 4.8 ("Hash Block") from syslog-sign, The hash block is a block of hashes, each separately encoded in base 64. Each hash in the hash block is the hash of the entire syslog message represented by the hash. The hashing algorithm used effectively specified by the Version field determines the size of each hash, but the size MUST NOT be shorter than 160 bits. It is base 64 encoded as per RFC 2045. We should come to agreement on the definition of the "entire syslog message". I believe (but I'm willing to open this to debate on the list) that the "entire syslog message" is what is described in syslog-protocol. This excludes the transport parts that are described in syslog-transport-udp and syslog-transport-tls (like the byte-counter), and will exclude any other parts that may be defined in future transports. Specifically for syslog-protocol, the hash value will be the result of the hashing algorithm run across the payload starting with "<" and ending with the BOM. If no one disagrees with this, then I'll ask Alex to get it into the next version of syslog-sign. Can anyone propose similar language for how to deal with 3164-style messages? Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 28 15:55:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHnBe-0002AW-Rq; Mon, 28 Aug 2006 15:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHnBd-0002AH-SG for syslog@ietf.org; Mon, 28 Aug 2006 15:54:21 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHm38-0006Mh-Jr for syslog@ietf.org; Mon, 28 Aug 2006 14:41:30 -0400 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHlyS-0004Dy-Vx for syslog@ietf.org; Mon, 28 Aug 2006 14:36:43 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc12) with SMTP id <20060828183640b1200ofg4se>; Mon, 28 Aug 2006 18:36:40 +0000 From: "David Harrington" To: Date: Mon, 28 Aug 2006 14:34:59 -0400 Message-ID: <132101c6cad0$ab256200$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbK0EccWrnTLUORTl+8XZZYLZCqJQ== X-Spam-Score: -0.4 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Syslog] Working Group Last Calls X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The WGLC for -protocol-17 and -udp-07 documents will end later today. Please review and comment on these documents today. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 28 16:24:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHneY-0001ru-Jt; Mon, 28 Aug 2006 16:24:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHneW-0001rp-U3 for syslog@ietf.org; Mon, 28 Aug 2006 16:24:12 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHneU-0004MI-Lx for syslog@ietf.org; Mon, 28 Aug 2006 16:24:12 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc12) with SMTP id <20060828202410b1200oi93je>; Mon, 28 Aug 2006 20:24:10 +0000 From: "David Harrington" To: Date: Mon, 28 Aug 2006 16:22:29 -0400 Message-ID: <133f01c6cadf$afa2d600$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iACkS6mUA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Syslog] Working Group Last Call: syslog-sign document X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, This message officially starts the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt The Working Group Last Call for this document will end September 11. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, if it does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 28 17:14:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHoQ8-00011g-FQ; Mon, 28 Aug 2006 17:13:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHoQ6-0000tj-DR for syslog@ietf.org; Mon, 28 Aug 2006 17:13:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHm3Z-0006PE-9a for syslog@ietf.org; Mon, 28 Aug 2006 14:41:57 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53] helo=alnrmhc11.comcast.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHm3S-0004k5-Ps for syslog@ietf.org; Mon, 28 Aug 2006 14:41:56 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc13) with SMTP id <20060828184147b13002vahge>; Mon, 28 Aug 2006 18:41:47 +0000 From: "David Harrington" To: Date: Mon, 28 Aug 2006 14:40:07 -0400 Message-ID: <132201c6cad1$628ab170$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbK0K9M+tcoQBzESHWT+Vw2/Sk/Lw== X-Spam-Score: -1.4 (-) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: Subject: [Syslog] WGLC: udp-07 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I have reviewed http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt for WGLC. The xml2rfc will be submitted with the final draft, so this should be a "clean" xml2rfc source file. The xml2rfc-validator tools at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi shows the following warnings or errors, which should be fixed in the source file. Note that my copy of the XML source apparently does not match that used to generate the official draft. ---- start validation output --- Validation results for D:\My Documents\IETF\syslog\draft-ietf-syslog-transport-udp-07.xml Processing... Validating document... 280: element front: validity error : Element front content does not follow the DTD, expecting (title , author+ , date , area* , workgroup* , keyword* , abstract? , note*), got (title author ) 279: 280: 281: The syslog Protocol ...validation failed Performing additional checks... 50: fyi: anchor intro not referenced 49: 50:
51: 68: fyi: anchor terms not referenced 67: 68:
69: 76: fyi: anchor Transport not referenced 75: 76:
77: 78: fyi: anchor Datagram not referenced 77: 78:
79: 84: fyi: anchor MessageSize not referenced 83: 84:
85: 104: fyi: anchor TargetPort not referenced 103: 104:
105: 110: fyi: anchor SourceIPAddress not referenced 109: 110:
111: 116: fyi: anchor UDPIPStructure not referenced 115: 116:
117: 122: fyi: anchor UDPChecksums not referenced 121: 122:
123: 137: fyi: anchor reliability not referenced 136: 137:
138: 143: fyi: anchor loss not referenced 142: 143:
144: 152: fyi: anchor corruption not referenced 151: 152:
153: 162: fyi: anchor overload not referenced 161: 162:
163: 168: fyi: anchor sequence not referenced 167: 168:
169: 177: fyi: anchor security not referenced 176: 177:
178: 182: fyi: anchor SenderAuthentication not referenced 181: 182:
183: 188: fyi: anchor SecForg not referenced 187: 188:
189: 200: fyi: anchor SecObs not referenced 199: 200:
201: 206: fyi: anchor SecReplay not referenced 205: 206:
207: 212: fyi: anchor SecRelDel not referenced 211: 212:
213: 218: fyi: anchor SecPri not referenced 217: 218:
219: 224: fyi: anchor SecDen not referenced 223: 224:
225: 231: fyi: anchor iana not referenced 230: 231:
232: 237: fyi: anchor rfc-editor not referenced 236: 237:
238: 244: fyi: anchor acks not referenced 243: 244:
245: 310: warning: anchor RFC1122 not referenced 309: 310: 311: ...done ---- end xml2rfc validation output --- Idnits (using http://tools.ietf.org/tools/idnits/idnits.pyht) Boilerplates and formatting checks look good. ---- spelling ---- (using MS-Word on the xml2rfc-generated html file) The implementer/implementor debate rages on. Usage is inconsistenct within this document. It would be nice if we were consistent across our documents. My research shows implementer as the preferred spelling. The term "misconfigured" is used. This is apparently not a real English word, and that means that implementers and readers who rely on translation tools will probably have problems with this term. Can we use "inappropriately configured" instead? The draft acknowledges Mickael Graham; is this the correct spelling? --- grammar --- "The informational RFC 3164 [7] originally described the syslog" - eliminate "originally" The documentt talks about "RFC3164 described" - doesn't it still describe? Shouldn't this be "describes"? "The RFC-protocol specifies a layered architecture that provided for" - /provided/provides/ "This standards track RFC describes" should be "This document describes"; the IESG could always decide to publish this as a non-standards-track RFC, and it could be moved to "Historic" at a later date, so we should not specify standards-track in the body of the document; that status is external to the document. I don't feel very comfortable with use of the word protocol in "Network administrators and architects should be aware of the significant reliability and security issues of this protocol, which stem from the use of UDP." I think this document describes a transport mapping - how syslog should "interface to" the UDP protocol. We are not defining a syslog-udp message format. Part of the problem is that when the text says "this protocol", I need to think about whether "this protocol" means syslog (which is definitely a protocol), or the syslog-udp transport mapping. So "This protocol supports transmission of syslog messages up to 65535 octets in size" is ambiguous as to wehere the limit is defined, but "This transport mapping supports transmission of syslog messages up to 65535 octets in size" is not. In sexction 5.3, "This transport protocol" apparently refers to UDP. It woul dbe less ambiguous if each usage of "this ... Protocol" was replaced by "the UDP protocol" or "the syslog/udp transport mapping". "a well-known port 514" s/b "the well-known port 514" --- RFC2119 terminology --- Some of the keywrods are used in both lowercase and uppercase; I believe the preferred approach is to use uppercase consistently. Some authors use lowercase when th eterm is not used as an rfc2119 keyword, but uppercase when referring to an rfc2119 keyword. I recommend always using uppercase and avoiding the keywords when they are not meant to be used as an rfc2119 keyword to avoid ambiguity. The word "can" is used where MAY might be more appropriate. The document says that "this transport protocol" is required for interoperability. However, two transport protocols are referred to, and they are not necessarily interoperable. For a system that only supports IPv4, then the UDP/IPv4 protocol should be required for interoperability. For a system that only supports IPv6, then UDP/IPv6 should be supported for interoperability in an IPv6 environment. For a system that supports both IPv4 and IPv6, what is required - UDP/IPv4, UDP/IPv6, or both, for interoperability? If both, then by default, should operators have syslog messages sent over both (i.e. duplicate the messages) so they can be transmitted over IPv4 and IPv6 networks? In SNMPv3, we chose UDP/IPv4 as the required even if both IPv4 and IPv6 are available, and for IPv6-only devices, we require UDP/IPv6. --- general review --- "This limit stems from the maximum supported UDP payload of 65535 octets specified in the RFC 768 [1]." - I couldn't find such a limit specified in rfc768. In fact, rfc768 **assumes** this will run over the IP protocol. IP might define some limits that would lead to this syslog limit. If UDP had a limit, then saying UDP supported "payloads" of 65535 would probably be incorrect, since part of the 65535 limit would be used up by header fields, thus lessening the "payload" limit. "It is RECOMMENDED that application developers restrict message sizes" - shouldn't this be "It is RECOMMENDED that syslog senders restrict message sizes"? The receivers are also applications and we don't really want the receivers to restrict message sizes. I am a bit concerned that we are violating layer separation when we get too specific about the structure and checksums of the transport protocol; lower-layer details like checksums should not necessarily be made accessible to the syslog protocol, which operates at a higher layer. We should trust the underlying transport to do its job correctly, and operators to configure their devices correctly, so requiring syslog receivers to examine the UDP checksums seems wrong. In section 4.1, we go even further - "This protocol specifies use of UDP checksums to enable corruption detection in addition to checksums used in IP and Layer 2 protocols." We have no business looking at layer 3 and layer 2 checksums. If a checksum is neede to validate the syslog mesdsage, then we should have a syslog checksum. Doesn't the last sentence of 5.1 mean basically the same thing as what is discussed in 5.2? Section 5.6 says "they will not get a higher priority". The standard will not mandate prioritization because that is an implementation decision and would not affect interoperability on-the-wire, but a sending implementation might provide such prioritization, so the document should not say they will not get a higher priority. It might even be a good idea to suggest that implementers of sending applications and relays consider support for prioritization based on the label. Section 5.7 discusses DoS attacks. Should the MIB include the ability to restrict the nuber of messages sent per minute? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Aug 28 20:01:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHr1z-0002K3-Iv; Mon, 28 Aug 2006 20:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHr1y-0002Jy-La for syslog@ietf.org; Mon, 28 Aug 2006 20:00:38 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHr1x-0005Em-9k for syslog@ietf.org; Mon, 28 Aug 2006 20:00:38 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc11) with SMTP id <20060829000036b1100eoashe>; Tue, 29 Aug 2006 00:00:36 +0000 From: "David Harrington" To: Date: Mon, 28 Aug 2006 19:58:55 -0400 Message-ID: <136e01c6cafd$ec33eb40$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbK/VCn78UvyZWPQhuvj8fLV8mTZQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Subject: [Syslog] WGLC: protocol, part 2 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Here are some additional coments on the protocol draft, as promised. Section 5.1 - if a receiver implementation supports UDP/IPv4 and a sender support UDP/IPv6, I believe these will not interoperate unless there is a 6-to-4 proxy between them. Therefore, claiming "interoperability between all systems" is incorrect. Section 6.3 says "A receiver MAY ignore malformed STRUCTURED-DATA elements." We do not actually standardize what a receiver does with the messages it receives, since that is implementation dependent. Isn't it true that a receiver can ignore any STRUCTURED-DATA elements, whether malformed or not? So I think the question that needs to be answered is what happens at a relay? If a relay can "ignore" malformed structured data, does that mean it can discard that portion of the message, even if it is in the middle of the message, and pass the syslog message to a receiver without that portion of the content? Or is the relay REQUIRED to pass the malformed SD in the forwarded message? Wouldn't dropping the SD have an impact on syslog-sign? So we need to define in a clear and unambiguous manner what ignore means. Is the escape format defined in 6.3.3 a UTF-8 standard, or something specific to syslog SD-PARAMS? The text should specify this. "This is necessary to avoid parsing errors." - how is this necessary? Which parser is being used? How does escaping ']' prevent parser implementation errors as compared to not escaping this and implementing the parser to not expect this to be escaped within a PARAM-VALUE field? If the escape format defined in 6.3.3. is not standard UTF-8, then why are we making this non-standard UTF-8? Will UTF8-standard-compliant parsers be able to parse this modified UTF-8 content correctly? Doesn't this defeat the purpose of using a standard encoding? How do these two statements co-exist? "It MAY modify messages containing control characters (e.g. by escaping an octet with value 0 to "\0")." and "A backslash ('\') followed by none of the three described characters is considered an invalid escape sequence...it MAY [replace the sequence or] it MAY drop the message." Why don't we either make all escaped characters except '"' and '\' and ']' invalid - period and not permit them in a valid syslog message, or make them valid and require receivers to process them in a standardized manner so we have a MUST for interoperability rather than two non-interoperable MAY clauses? "They are wrapped on multiple lines for readability purposes only." s/b "They are wrapped on multiple lines in this document for readability purposes only." "which has been left out for brevity" s/b "which has been left out of this document for brevity" In 6.5 example 1, aren't these contrsdictory statements - "The encoding is defined by the BOM, and also advertised in STRUCTURED-DATA. There is no STRUCTURED-DATA present in the message, this is indicated by "-" in the STRUCTURED-DATA field." So should this read ""and MAY be advertised" 7.3.3 Let's see. If BOM and enc are both specified, believe the BOM. If BOM is not present and enc=UTF8 is present, then you should make no assumptions about the encoding. If the BOM is not present and the encoding is not UTF8 then enc MUST NOT be specified. So when is this field actually useful? Why have it if the value of the field is always either duplicative or not-to-be-trusted? Let's either make it useful when the BOM is not specified and/or when the encoding is not UTF8, or let's eliminate it. Section 8.2 specifies why it is a security risk to send control characters in the MSG or PARAM-VALUE content. We should simply say, if you want to be a standard-compliant implementation, you MUST NOT send control characters in these fields. Period. Strip them out and add a section to your release notes tahat explains this decision was made by the IETF for security reasons. Section 8.5 "the underlying transport may be unreliable (e.g., UDP), some messages may be lost." insert an "and" before "some". 8.8 "misconfiguration" is apparently not an English word recognized by most dictionaries. Therefore, this term will eb difficult for implementers and operators who use translation tools from English to their native language. "Inappropriate configuration" is better English. Section A.1: RFC3164 is not a standard or a specification, it is an informational document that describes existing practice. "In RFC 3164 [16] observed formats were specified." should be changed to "In RFC 3164 [16] describes observed formats." It is inapprorpriate to refer to rfc3164 as being able to mandate or specify behavior. That is the role of a standards-track specification, not an informational document. So sentences like "RFC 3164 specifies relay behavior" should be changed to "RFC 3164 describes observed relay behavior." "RFC 3164 mandates UDP as transport protocol for syslog." should be changed to "Most existing implementations support UDP as the transport protocol for syslog. This specification REQUIRES UDP support in compliant implementations, and allows additional transport protocols to be used." Section A.2 "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." Is this accurate? Is it the UDP implementations that do not support more than 480 bytes, or is it the syslog/udp implementations? I am not sure I agree that the IPv6 MTU must be noted in this document. It is more approrpiately mentioned in a transport mapping that addresses transport over IPv6. I prefer to eliminate it here. A.6 and A.8 are related; it would be good to have them next to each other. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 29 05:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHziu-0006e9-4W; Tue, 29 Aug 2006 05:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHzis-0006dz-CC for syslog@ietf.org; Tue, 29 Aug 2006 05:17:30 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHzip-0002nw-DK for syslog@ietf.org; Tue, 29 Aug 2006 05:17:30 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4R00GXA5M18D@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 29 Aug 2006 17:13:14 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4R00G2R5M165@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 29 Aug 2006 17:13:13 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4R00A9W5NERQ@szxml03-in.huawei.com> for syslog@ietf.org; Tue, 29 Aug 2006 17:14:05 +0800 (CST) Date: Tue, 29 Aug 2006 17:09:54 +0800 From: Miao Fuyou Subject: RE: [Syslog] Working Group Last Calls In-reply-to: <132101c6cad0$ab256200$0400a8c0@china.huawei.com> To: syslog@ietf.org Message-id: <00b301c6cb4a$e48508a0$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcbK0EccWrnTLUORTl+8XZZYLZCqJQAcyWHw X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Some my review finding: 1, "originator" is used twice in the document without terminology definition, "original sender" is used in other paragraphs for the same entity, replace "originator" with "original sender"? 2, Section 8.4, "Cryptographically signing messages could prevent the alteration of TIMESTAMPs and thus the replay attack.', Signature is only one option for message integrity. My suggestion is to change it to "Message or transport integrity mechansim could be used to prevent the alteration TIMESTAMP of the message or message delivery sequence." 3, TimeStamp: when timestamp is set, by whom? An originator or relay? I can not find in the doc. BTW, TIMESTAMP can be utilized to avoid a forward loop descripted in section 8.9, if it is set by originator. Thanks! Miao > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, August 29, 2006 2:35 AM > To: syslog@ietf.org > Subject: [Syslog] Working Group Last Calls > > Hi, > > The WGLC for -protocol-17 and -udp-07 documents will end later today. > Please review and comment on these documents today. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 29 12:26:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI6Oa-0004hA-AV; Tue, 29 Aug 2006 12:25:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI6OY-0004df-9b for syslog@ietf.org; Tue, 29 Aug 2006 12:24:58 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI6OX-0005Dt-2q for syslog@ietf.org; Tue, 29 Aug 2006 12:24:58 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc14) with SMTP id <20060829162456b1400ijgete>; Tue, 29 Aug 2006 16:24:56 +0000 From: "David B Harrington" To: Date: Tue, 29 Aug 2006 12:23:15 -0400 Message-ID: <13ec01c6cb87$6e5a1a20$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbLB6M5QH3V/DkJTzuccOKfI+PU0QAfxYHg X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Syslog] WG timeline update X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, We didn't include revisions and subsequent WGLCs in our timeline. Here is an update to the timeline Aug 28 Close WGLC on protocol and udp Aug 28 start WGLC on syslog-sign Sep 1 tls and mib drafts published with requested changes (before WGLC) Sep 4 start WGLC on tls and mib drafts Sep 11 Close WGLC on syslog-sign Sep 11 revisions of protocol and udp drafts (after WGLC) Sep 18 Close WGLC for tls and mib Sep 25 revisions of sign, tls, mib Sep 25 start final WGLC on all modified documents if needed. Oct 9 end final WGLCs Oct 20 submit all final-WGLC-modified drafts to internet-drafts Oct 23 publication cut-off preceding IETF67 Nov 1 submit documents to the IESG. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 29 17:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAsI-00014h-2E; Tue, 29 Aug 2006 17:11:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAqK-0000ew-SX; Tue, 29 Aug 2006 17:09:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI9dZ-0001fX-UO; Tue, 29 Aug 2006 15:52:41 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GI9bU-0002vE-6A; Tue, 29 Aug 2006 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1DEC42AC4B; Tue, 29 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GI9az-0001lG-SS; Tue, 29 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 29 Aug 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-03.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : TLS Transport Mapping for SYSLOG Author(s) : F. Miao, M. Yuzhi Filename : draft-ietf-syslog-transport-tls-03.txt Pages : 11 Date : 2006-8-29 This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-transport-tls-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-transport-tls-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-29113635.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-tls-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-tls-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-29113635.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Tue Aug 29 17:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBSZ-00072o-Sw; Tue, 29 Aug 2006 17:49:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBSY-00072i-5P for syslog@ietf.org; Tue, 29 Aug 2006 17:49:26 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBSV-000456-TT for syslog@ietf.org; Tue, 29 Aug 2006 17:49:26 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc14) with SMTP id <20060829214923b1400igm7ge>; Tue, 29 Aug 2006 21:49:23 +0000 From: "David Harrington" To: Date: Tue, 29 Aug 2006 17:47:41 -0400 Message-ID: <14ed01c6cbb4$c17526f0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iACkS6mUAA1Nbhg X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Syslog] Working Group Last Call: syslog-tls document X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, This message officially starts the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 .txt The Working Group Last Call for this document will end September 12. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, if it does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 29 17:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBXc-0002K7-FF; Tue, 29 Aug 2006 17:54:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBXb-0002K2-Us for syslog@ietf.org; Tue, 29 Aug 2006 17:54:39 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBXa-0004yh-Ne for syslog@ietf.org; Tue, 29 Aug 2006 17:54:39 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc13) with SMTP id <20060829215425b130037vvae>; Tue, 29 Aug 2006 21:54:38 +0000 From: "David Harrington" To: Date: Tue, 29 Aug 2006 17:52:43 -0400 Message-ID: <14ee01c6cbb5$7d0dbfd0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbLtUSbzsluKEgWRbaBdbxEh7ZPbA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Syslog] WGLC closeed for protocol and udp X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The WGLC was scheduled to end yesterday. We allowed the complete day to get responses in. The WGLC is now closed for draft-ietf-syslog-protocol: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt draft-ietf-syslog-transport-udp: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt The editors are requested to modify the documents and post new revisions. If the editors have any questions, they should initiate a discussion on the mailing list. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 29 17:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBXf-0002Mc-OV; Tue, 29 Aug 2006 17:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBXf-0002MP-92 for syslog@ietf.org; Tue, 29 Aug 2006 17:54:43 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBXd-0004yh-13 for syslog@ietf.org; Tue, 29 Aug 2006 17:54:43 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc13) with SMTP id <20060829215438b130037vvbe>; Tue, 29 Aug 2006 21:54:38 +0000 From: "David Harrington" To: Date: Tue, 29 Aug 2006 17:52:43 -0400 Message-ID: <14ef01c6cbb5$7d530630$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbLB6M5QH3V/DkJTzuccOKfI+PU0QAfxYHgAAtaOrA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Syslog] WG timeline update - again X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in NFrom syslog-bounces@lists.ietf.org Tue Aug 29 17:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBXc-0002K7-FF; Tue, 29 Aug 2006 17:54:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBXb-0002K2-Us for syslog@ietf.org; Tue, 29 Aug 2006 17:54:39 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBXa-0004yh-Ne for syslog@ietf.org; Tue, 29 Aug 2006 17:54:39 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc13) with SMTP id <20060829215425b130037vvae>; Tue, 29 Aug 2006 21:54:38 +0000 From: "David Harrington" To: Date: Tue, 29 Aug 2006 17:52:43 -0400 Message-ID: <14ee01c6cbb5$7d0dbfd0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbLtUSbzsluKEgWRbaBdbxEh7ZPbA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Syslog] WGLC closeed for protocol and udp X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The WGLC was scheduled to end yesterday. We allowed the complete day to get responses in. The WGLC is now closed for draft-ietf-syslog-protocol: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt draft-ietf-syslog-transport-udp: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt The editors are requested to modify the documents and post new revisions. If the editors have any questions, they should initiate a discussion on the mailing list. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 29 17:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBXf-0002Mc-OV; Tue, 29 Aug 2006 17:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBXf-0002MP-92 for syslog@ietf.org; Tue, 29 Aug 2006 17:54:43 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBXd-0004yh-13 for syslog@ietf.org; Tue, 29 Aug 2006 17:54:43 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc13) with SMTP id <20060829215438b130037vvbe>; Tue, 29 Aug 2006 21:54:38 +0000 From: "David Harrington" To: Date: Tue, 29 Aug 2006 17:52:43 -0400 Message-ID: <14ef01c6cbb5$7d530630$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbLB6M5QH3V/DkJTzuccOKfI+PU0QAfxYHgAAtaOrA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Syslog] WG timeline update - again X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, In the original timeline, we planned to start the WGLC for syslog-tls on Aug 28, but we didn't have an updated document to work with. Now a revision has been published, so we'll start the WGLC now. Here is another update to the timeline Aug 28 Close WGLC on protocol and udp Aug 28 start WGLC on syslog-sign Aug 29 tls drafts published with requested changes (before WGLC) Aug 29 start WGLC on syslog-tls Sep 1 mib draftspublished with requested changes (before WGLC) Sep 4 start WGLC on mib draft Sep 11 Close WGLC on syslog-sign Sep 11 revisions of protocol and udp drafts (after WGLC) Sep 12 Close WGLC on syslog-tls document Sep 18 Close WGLC for mib Sep 25 revisions of sign, tls, mib Sep 25 start final WGLC on all modified documents if needed. Oct 9 end final WGLCs Oct 20 submit all final-WGLC-modified drafts to internet-drafts Oct 23 publication cut-off preceding IETF67 Nov 1 submit documents to the IESG. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog etwork Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, In the original timeline, we planned to start the WGLC for syslog-tls on Aug 28, but we didn't have an updated document to work with. Now a revision has been published, so we'll start the WGLC now. Here is another update to the timeline Aug 28 Close WGLC on protocol and udp Aug 28 start WGLC on syslog-sign Aug 29 tls drafts published with requested changes (before WGLC) Aug 29 start WGLC on syslog-tls Sep 1 mib draftspublished with requested changes (before WGLC) Sep 4 start WGLC on mib draft Sep 11 Close WGLC on syslog-sign Sep 11 revisions of protocol and udp drafts (after WGLC) Sep 12 Close WGLC on syslog-tls document Sep 18 Close WGLC for mib Sep 25 revisions of sign, tls, mib Sep 25 start final WGLC on all modified documents if needed. Oct 9 end final WGLCs Oct 20 submit all final-WGLC-modified drafts to internet-drafts Oct 23 publication cut-off preceding IETF67 Nov 1 submit documents to the IESG. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 29 20:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIE7j-0001rP-39; Tue, 29 Aug 2006 20:40:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIE7i-0001pK-Mb for syslog@ietf.org; Tue, 29 Aug 2006 20:40:06 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIE7g-0000GL-Ta for syslog@ietf.org; Tue, 29 Aug 2006 20:40:06 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4S00KDFDBHOL@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 30 Aug 2006 08:57:17 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4S00FS9DBHR4@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 30 Aug 2006 08:57:17 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4S0069NCOCC7@szxml03-in.huawei.com> for syslog@ietf.org; Wed, 30 Aug 2006 08:43:27 +0800 (CST) Date: Wed, 30 Aug 2006 08:39:13 +0800 From: Miao Fuyou Subject: RE: [Syslog] Working Group Last Calls In-reply-to: To: syslog@ietf.org Message-id: <00d801c6cbcc$b7ca8e70$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcbK0EccWrnTLUORTl+8XZZYLZCqJQAcyWHwACJNe5A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Sorry, the comments are for syslog-protocol. Thanks! > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com] > Sent: Tuesday, August 29, 2006 5:10 PM > To: 'syslog@ietf.org' > Subject: RE: [Syslog] Working Group Last Calls > > Hi, > > Some my review finding: > > 1, "originator" is used twice in the document without > terminology definition, "original sender" is used in other > paragraphs for the same entity, replace "originator" with > "original sender"? > > 2, Section 8.4, "Cryptographically signing messages could > prevent the alteration of TIMESTAMPs and thus the replay > attack.', Signature is only one option for message integrity. > My suggestion is to change it to "Message or transport > integrity mechansim could be used to prevent the alteration > TIMESTAMP of the message or message delivery sequence." > > 3, TimeStamp: when timestamp is set, by whom? An originator > or relay? I can not find in the doc. BTW, TIMESTAMP can be > utilized to avoid a forward loop descripted in section 8.9, > if it is set by originator. > > Thanks! > Miao > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Tuesday, August 29, 2006 2:35 AM > > To: syslog@ietf.org > > Subject: [Syslog] Working Group Last Calls > > > > Hi, > > > > The WGLC for -protocol-17 and -udp-07 documents will end > later today. > > Please review and comment on these documents today. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Aug 29 20:44:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIEBu-0003nf-PJ; Tue, 29 Aug 2006 20:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIEBt-0003nZ-Rn for syslog@ietf.org; Tue, 29 Aug 2006 20:44:25 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIEBt-0000wN-2y for syslog@ietf.org; Tue, 29 Aug 2006 20:44:25 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc13) with SMTP id <20060830004423b130034s6he>; Wed, 30 Aug 2006 00:44:23 +0000 From: "David Harrington" To: Date: Tue, 29 Aug 2006 20:42:42 -0400 Message-ID: <152401c6cbcd$34372040$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbLzKJOC+WCQ3IEQzKdgZfKkXhrGg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a0f005dcc96c32c6d659bdf82d519da Cc: Subject: [Syslog] WGLC: sysog-sign, part 1 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Here is a review of the syslog-sign document. This is validation of the XML source file. This file will be submitted to the rfc-editor when the internet-draft will be publsihed as an RFC. It helps if the source is "clean", so please fix the reported problems in the source file. --- Validation results for D:\My Documents\IETF\syslog\escrow\draft-ietf-syslog-sign-18.xml Processing... Validating document... 238: element section: validity error : Element section content does not follow the DTD, expecting (t | figure | texttable | iref | section)*, got (t list t ) 237: 238:
239: 291: element section: validity error : Element section content does not follow the DTD, expecting (t | figure | texttable | iref | section)*, got (t t t list t ) 290: 291:
292: 459: element section: validity error : Element section content does not follow the DTD, expecting (t | figure | texttable | iref | section)*, got (t t list ) 458: 459:
460: 510: element section: validity error : Element section content does not follow the DTD, expecting (t | figure | texttable | iref | section)*, got (t list ) 509: 510:
511: 523: element list: validity error : Element list content does not follow the DTD, expecting (t)+, got (t t t list t ) 522: 523: 524: 759: element section: validity error : Element section content does not follow the DTD, expecting (t | figure | texttable | iref | section)*, got (t list t ) 758: 759:
760: 794: element section: validity error : Element section content does not follow the DTD, expecting (t | figure | texttable | iref | section)*, got (t list t t ) 793: 794:
795: 806: element list: validity error : Element list content does not follow the DTD, expecting (t)+, got (t t t list t ) 805: 806: 807: 834: element list: validity error : Element list content does not follow the DTD, expecting (t)+, got (t t list t ) 833: 834: 835: 891: element section: validity error : Element section content does not follow the DTD, expecting (t | figure | texttable | iref | section)*, got (t list t ) 890: 891:
892: 1640: element front: validity error : Element front content does not follow the DTD, expecting (title , author+ , date , area* , workgroup* , keyword* , abstract? , note*), got (title author author date seriesInfo ) 1639: 1640: 1641: User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) 1654: element front: validity error : Element front content does not follow the DTD, expecting (title , author+ , date , area* , workgroup* , keyword* , abstract? , note*), got (title author date seriesInfo ) 1653: 1654: 1655: UTF-8, a transformation format of ISO 10646 1665: element front: validity error : Element front content does not follow the DTD, expecting (title , author+ , date , area* , workgroup* , keyword* , abstract? , note*), got (title author author date seriesInfo ) 1664: 1665: 1666: IP Version 6 Addressing Architecture 1679: element front: validity error : Element front content does not follow the DTD, expecting (title , author+ , date , area* , workgroup* , keyword* , abstract? , note*), got (title author author date seriesInfo ) 1678: 1679: 1680: Augmented BNF for Syntax Specifications: ABNF ...validation failed Performing additional checks... 49: fyi: anchor intro not referenced 48: 49:
50: 116: fyi: anchor conventions not referenced 115: 116:
117: 124: fyi: anchor format not referenced 123: 124:
125: 165: fyi: anchor sigBlock not referenced 164: 165:
166: 171: fyi: anchor sigBlkPkts not referenced 170: 171:
172: 378: fyi: anchor globBlk not referenced 377: 378:
379: 402: fyi: anchor firstmsg not referenced 401: 402:
403: 416: fyi: anchor count not referenced 415: 416:
417: 427: fyi: anchor hash not referenced 426: 427:
428: 452: fyi: anchor payncert not referenced 451: 452:
453: 459: fyi: anchor prelims not referenced 458: 459:
460: 569: fyi: anchor buildcert not referenced 568: 569:
570: 628: fyi: anchor VersionCER not referenced 627: 628:
629: 640: fyi: anchor rebootidCER not referenced 639: 640:
641: 647: fyi: anchor siggrpCER not referenced 646: 647:
648: 655: fyi: anchor tpbl not referenced 654: 655:
656: 662: fyi: anchor index not referenced 661: 662:
663: 670: fyi: anchor fraglen not referenced 669: 670:
671: 677: fyi: anchor sigCER not referenced 676: 677:
678: 693: fyi: anchor redunnflex not referenced 692: 693:
694: 703: fyi: anchor redun not referenced 702: 703:
704: 725: fyi: anchor redunCertblk not referenced 724: 725:
726: 742: fyi: anchor redunSigblk not referenced 741: 742:
743: 759: fyi: anchor flex not referenced 758: 759:
760: 787: fyi: anchor verify not referenced 786: 787:
788: 794: fyi: anchor offline not referenced 793: 794:
795: 891: fyi: anchor online not referenced 890: 891:
892: 973: fyi: anchor security not referenced 972: 973:
974: 983: fyi: anchor SecCrypto not referenced 982: 983:
984: 1005: fyi: anchor SecPacket not referenced 1004: 1005:
1006: 1031: fyi: anchor SecAuth not referenced 1030: 1031:
1032: 1048: fyi: anchor SeqDel not referenced 1047: 1048:
1049: 1059: fyi: anchor SecReplay not referenced 1058: 1059:
1060: 1069: fyi: anchor SecRelDel not referenced 1068: 1069:
1070: 1083: fyi: anchor SecSeq not referenced 1082: 1083:
1084: 1094: fyi: anchor SecInt not referenced 1093: 1094:
1095: 1105: fyi: anchor SecObs not referenced 1104: 1105:
1106: 1114: fyi: anchor SecMITM not referenced 1113: 1114:
1115: 1126: fyi: anchor SecDen not referenced 1125: 1126:
1127: 1142: fyi: anchor SecCov not referenced 1141: 1142:
1143: 1156: fyi: anchor iana not referenced 1155: 1156:
1157: 1181: fyi: anchor ianaVer not referenced 1180: 1181:
1182: 1261: fyi: anchor ianaSIG not referenced 1260: 1261:
1262: 1270: fyi: anchor ianabuild not referenced 1269: 1270:
1271: 1280: fyi: anchor authors not referenced 1279: 1280:
1281: 1288: error:
inside is deprecated by rfc2629bis 1287: The working group can be contacted via the mailing list: 1288:
1289: syslog-sec@employees.org 1295: error:
inside is deprecated by rfc2629bis 1294: The current Chairs of the Working Group may be contacted at: 1295:
1296: Chris Lonvick 1310: error:
inside is deprecated by rfc2629bis 1309: The authors of this draft are: 1310:
1311: John Kelsey 1323: fyi: anchor acks not referenced 1322: 1323:
1324: 1359: warning: anchor ANSI.X3-4.1968 not referenced 1358: 1359: 1360: 1391: warning: anchor RFC1034 not referenced 1390: 1391: 1392: 1405: warning: anchor RFC1035 not referenced 1404: 1405: 1406: 1429: warning: anchor RFC2085 not referenced 1428: 1429: 1430: 1653: warning: anchor RFC3629 not referenced 1652: 1653: 1654: 1664: warning: anchor RFC4291 not referenced 1663: 1664: 1665: 1678: warning: anchor RFC4234 not referenced 1677: 1678: 1679: 1695: warning: anchor MENEZES not referenced 1694: 1695: 1696: 1786: warning: anchor RFC1983 not referenced 1785: 1786: 1787: 1817: warning: anchor RFC2104 not referenced 1816: 1817: 1818: 2007: warning: anchor RFC3339 not referenced 2006: 2007: 2008: 2050: warning: anchor SCHNEIER not referenced 2049: 2050: 2051: ...done --- Idnits from http://tools.ietf.org/tools/idnits/idnits.pyht idnits 1.108 tmp/draft-ietf-syslog-sign-18-official.txt: tmp/draft-ietf-syslog-sign-18-official.txt(343): RFC 2119 keyword: format. It is RECOMMENDED to be used within the syslog protocol as. tmp/draft-ietf-syslog-sign-18-official.txt(344): RFC 2119 keyword: defined in RFC xxxx [24]. It MAY be transported over a traditional. tmp/draft-ietf-syslog-sign-18-official.txt(346): RFC 2119 keyword: 3164 [20], or it MAY be used over the Reliable Delivery of syslog. tmp/draft-ietf-syslog-sign-18-official.txt(350): RFC 2119 keyword: entirety, it is imperative that the messages MUST NOT be changed in. tmp/draft-ietf-syslog-sign-18-official.txt(353): RFC 2119 keyword: 3164 MAY make changes to a syslog packet if specific fields are not. tmp/draft-ietf-syslog-sign-18-official.txt(403): RFC 2119 keyword: Signature Block messages MUST be encompassed within completely formed. tmp/draft-ietf-syslog-sign-18-official.txt(404): RFC 2119 keyword: syslog messages. It SHOULD also contain valid APP-NAME, PROCID, and. tmp/draft-ietf-syslog-sign-18-official.txt(407): RFC 2119 keyword: the latter case, it is RECOMMENDED that the TAG field have the value. tmp/draft-ietf-syslog-sign-18-official.txt(410): RFC 2119 keyword: Signature Block messages MUST be encoded as an SD ELEMENT, as defined. tmp/draft-ietf-syslog-sign-18-official.txt(438): Line is too long: the offending characters are 'h' tmp/draft-ietf-syslog-sign-18-official.txt(439): Line is too long: the offending characters are 'y)' tmp/draft-ietf-syslog-sign-18-official.txt(442): Line is too long: the offending characters are 'y)' tmp/draft-ietf-syslog-sign-18-official.txt(491): RFC 2119 keyword: always be set to a value of 0. Otherwise, it MUST increase whenever. tmp/draft-ietf-syslog-sign-18-official.txt(494): RFC 2119 keyword: to 0. Implementors MAY wish to consider using the snmpEngineBoots. tmp/draft-ietf-syslog-sign-18-official.txt(627): RFC 2119 keyword: Signature Block MUST be chosen such that the length of the resulting. tmp/draft-ietf-syslog-sign-18-official.txt(637): RFC 2119 keyword: each hash, but the size MUST NOT be shorter than 160 bits. It is. tmp/draft-ietf-syslog-sign-18-official.txt(738): RFC 2119 keyword: Block MUST have the following fields. Each of these fields are. tmp/draft-ietf-syslog-sign-18-official.txt(771): RFC 2119 keyword: that the device MAY make the Certificate Blocks of any legal length. tmp/draft-ietf-syslog-sign-18-official.txt(915): RFC 2119 keyword: provides redundancy; since the collector MUST ignore Signature/. tmp/draft-ietf-syslog-sign-18-official.txt(1210): RFC 2119 keyword: bytes. As seen in RFC 3164, relays MAY truncate messages with. tmp/draft-ietf-syslog-sign-18-official.txt(1416): RFC 2119 keyword: SHOULD have the same values in the fields described in this section.. Checking nits according to http://www.ietf.org/ID-Checklist.html: * The document seems to lack separate sections for Informative/Normative References. Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: - Mismatching filename: the document gives the document name as 'draft-ietf-syslog-sign-18', but the file name used is 'draft-ietf-syslog-sign-18-official' Miscellaneous warnings: - The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 paragraph 2 text: "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." ... text found in draft: "The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", ............^ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that appear in this document are to be interpreted as described in RFC 2119 [13].") (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). Experimental warnings: - Unused Reference: '3' is defined on line 1111, but not referenced '[3] American National Standards Institute, "USA Code for Informat...' - Unused Reference: '4' is defined on line 1114, but not referenced '[4] Menezes, A., van Oorschot, P., and S. Vanstone, ""Handbook of...' - Unused Reference: '6' is defined on line 1120, but not referenced '[6] Mockapetris, P., "Domain names - concepts and facilities", ST...' - Unused Reference: '7' is defined on line 1123, but not referenced '[7] Mockapetris, P., "Domain names - implementation and specifica...' - Unused Reference: '9' is defined on line 1129, but not referenced '[9] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996...' - Unused Reference: '10' is defined on line 1131, but not referenced '[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Exte...' - Unused Reference: '11' is defined on line 1135, but not referenced '[11] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Rep...' - Unused Reference: '12' is defined on line 1138, but not referenced '[12] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashi...' - Unused Reference: '14' is defined on line 1144, but not referenced '[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", R...' - Unused Reference: '15' is defined on line 1147, but not referenced '[15] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifi...' - Unused Reference: '16' is defined on line 1150, but not referenced '[16] Hinden, R. and S. Deering, "IP Version 6 Addressing Architect...' - Unused Reference: '22' is defined on line 1169, but not referenced '[22] Klyne, G. and C. Newman, "Date and Time on the Internet: Time...' - Unused Reference: '25' is defined on line 1179, but not referenced '[25] Schneier, B., "Applied Cryptography Second Edition: protocols...' ---- spelling "Predistributed" is not an English word. This could be difficult for those who rely on translators. "distributed" should be adequate for the usage. Otherwise, please use "pre-distributed" "SD ELEMENTS(SDEs)" add a space after ELEMENTS For consistency among all our documents, please use implementers rather than implementors. Correspondsss /permissable/permissible/ Can you spell out the meaning of O(N lg N) at its first usage? "collusionist" does not appear to be an English word. Would "attacker" do? In section 9.3 "Section Section" Abstract: /"The syslog Protocol", however it may be used atop any message delivery mechanism, even that/"The syslog Protocol" However it may be used atop any message delivery mechanism, including that/ and change the following "or" to "and" Introduction: /the type of key material which may be/the type of key material, which may be/ -- added a comma /In the cases of certificates being sent, the certificates may have/Ceetificates may have/ /actual transport protocol/transport protocol/ /defined in the informational RFC 3164/described in the informational RFC 3164/ There are lots of "it" references in the document, and in many cases it would be better if it was spelled out to be unambiguous. "The MSG part of the syslog message as defined in RFC xxxx [23] will simply be empty - it is not intended for interpretation by humans" What isn't intended for human consumption, the MSG? this specification? The signature block? Syslog-sign messages? /Having said that, as stated above,// /independent of the SD-ID definitions and/independent of the SD-ID definitions, and/ /The SD-ID must have the value of "ssign"./The SD-ID MUST have the value of "ssign"./ --- general review snmpEngineBoots has a range of 1..2147483647 and records the reboot of the SNMP engine. The Reboot Session ID has a range of 1..9999999999 and records the reboot of the device. "is rendered useless." - does this mean an attacker culd deliberately create a denial fo service so that they could then attack the system with less chance of detection? I found section 3 a bit hard to follow, since it discusses how this uses SD-IDs, but is indpendent of SD-IDs, and so on. I think the backwarsd compatbility discussion should happen after you describe what the current proposal is. Let's put the discussions about how to use this with RFC3164 into an appendix, and focus on defining the current proposal before spending lots of verbiage making sure everybody is happy that it is all backwards caompatible with rfc3164 and rfc3195. "The value of each field must be printable ASCII" - can you specify the range of characters included in "printable ASCII"? --- I will be sending another review as I read through the document for content and grammar. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Aug 30 21:17:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIbAT-0008C7-9B; Wed, 30 Aug 2006 21:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIbAR-0008C1-Mb for syslog@ietf.org; Wed, 30 Aug 2006 21:16:27 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIbAP-00060t-0w for syslog@ietf.org; Wed, 30 Aug 2006 21:16:27 -0400 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k7V1GAm9013161 for ; Thu, 31 Aug 2006 10:16:10 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k7V1G45x017047 for ; Thu, 31 Aug 2006 10:16:10 +0900 (JST) Message-ID: <44F63854.1080904@cysols.com> Date: Thu, 31 Aug 2006 10:16:04 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] WG timeline update - again References: <14ef01c6cbb5$7d530630$0400a8c0@china.huawei.com> In-Reply-To: <14ef01c6cbb5$7d530630$0400a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, > Sep 1 mib draftspublished with requested changes (before WGLC) Sep 4 is a more realistic date. Glenn David Harrington wrote: > > Hi, > > In the original timeline, we planned to start the WGLC for syslog-tls > on Aug 28, but we didn't have an updated document to work with. Now a > revision has been published, so we'll start the WGLC now. > > Here is another update to the timeline > > Aug 28 Close WGLC on protocol and udp > Aug 28 start WGLC on syslog-sign > Aug 29 tls drafts published with requested changes (before WGLC) > Aug 29 start WGLC on syslog-tls > Sep 1 mib draftspublished with requested changes (before WGLC) > Sep 4 start WGLC on mib draft > Sep 11 Close WGLC on syslog-sign > Sep 11 revisions of protocol and udp drafts (after WGLC) > Sep 12 Close WGLC on syslog-tls document > Sep 18 Close WGLC for mib > Sep 25 revisions of sign, tls, mib > Sep 25 start final WGLC on all modified documents if needed. > Oct 9 end final WGLCs > Oct 20 submit all final-WGLC-modified drafts to internet-drafts > Oct 23 publication cut-off preceding IETF67 > Nov 1 submit documents to the IESG. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog