From syslog-bounces@lists.ietf.org Thu Feb 01 06:05:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZki-0003am-C4; Thu, 01 Feb 2007 06:05:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZe7-0001gi-DI; Thu, 01 Feb 2007 05:58:27 -0500 Received: from www.balabit.hu ([212.92.18.33] helo=lists.balabit.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCZdG-0004pd-LP; Thu, 01 Feb 2007 05:57:35 -0500 Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id 6A37F4C1F7; Thu, 1 Feb 2007 11:57:29 +0100 (CET) Subject: Re: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslog Protocol) to Proposed Standard From: Balazs Scheidler To: Mark Andrews In-Reply-To: <200701312131.l0VLVJNu052111@drugs.dv.isc.org> References: <200701312131.l0VLVJNu052111@drugs.dv.isc.org> Content-Type: text/plain Date: Thu, 01 Feb 2007 10:57:17 +0000 Message-Id: <1170327437.6261.23.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: syslog@ietf.org, ietf@ietf.org, IETF-Announce X-BeenThere: syslog@lists.ietf.org X-Mailman-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, 2007-02-01 at 08:31 +1100, Mark Andrews wrote: > > - 'The syslog Protocol ' > > as a Proposed Standard > > draft-ietf-syslog-protocol-19.txt recommends using a reliable > protocol. Existing implementations of syslog do this and > deadlock with nameservers which are logging via syslog. > > I'm very wary of this recommendation. I think this is not the fault of the new standard, but an operational issue, that probably has a fix/workaround in implementations. (for example syslog-ng permits disabling DNS, or latest versions can use a list of internal IP->hostname mappings) -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 01 08:10:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCbgz-0008L5-LH; Thu, 01 Feb 2007 08:09:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCbgx-0008Kk-JX; Thu, 01 Feb 2007 08:09:31 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCbgv-0002b3-Ci; Thu, 01 Feb 2007 08:09:31 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9EA32E02DF; Thu, 1 Feb 2007 08:09:29 -0500 (EST) From: Sam Hartman To: Mark Andrews References: <200701312131.l0VLVJNu052111@drugs.dv.isc.org> Date: Thu, 01 Feb 2007 08:09:29 -0500 In-Reply-To: <200701312131.l0VLVJNu052111@drugs.dv.isc.org> (Mark Andrews's message of "Thu, 01 Feb 2007 08:31:19 +1100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF-Announce@mit.edu, syslog@ietf.org, ietf@ietf.org Subject: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslog Protocol) to Proposed Standard X-BeenThere: syslog@lists.ietf.org X-Mailman-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 >>>>> "Mark" == Mark Andrews writes: >> - 'The syslog Protocol ' as >> a Proposed Standard Mark> draft-ietf-syslog-protocol-19.txt recommends using a Mark> reliable protocol. Existing implementations of syslog do Mark> this and deadlock with nameservers which are logging via Mark> syslog. Please explain the deadlock in more detail. One of the primary reasons for the syslog working group is reliable syslog, so I think we need to focus on how to avoid the deadlock in other ways rather than avoiding reliability. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 01 08:19:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCbqj-00089H-1J; Thu, 01 Feb 2007 08:19:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCbqh-000895-QM; Thu, 01 Feb 2007 08:19:35 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCbqf-0005qu-BL; Thu, 01 Feb 2007 08:19:35 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 9BDBD27C013; Thu, 1 Feb 2007 14:19:56 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32006-05; Thu, 1 Feb 2007 14:19:56 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 42DEF27C012; Thu, 1 Feb 2007 14:19:56 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 14:19:28 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslogProtocol) to Proposed Standard X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 1 Feb 2007 14:19:28 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8D66@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslogProtocol) to Proposed Standard Thread-Index: AcdGAnYM3RJBC08qQAqj6a8cdV5H9gAAAyow References: <200701312131.l0VLVJNu052111@drugs.dv.isc.org> From: "Rainer Gerhards" To: "Sam Hartman" , "Mark Andrews" X-OriginalArrivalTime: 01 Feb 2007 13:19:28.0606 (UTC) FILETIME=[9A02A7E0:01C74603] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: IETF-Announce@mit.edu, syslog@ietf.org, ietf@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 am thinking on how to come this by on the protocol basis, but so far I have no good clue (except that Baszi is probably right and it is a purely operational issue). However, I know some problems in this relation and though it is not a deadlock issue, I would like to share the scenario for sake of completeness: It occurs on a typical *nix system that runs both syslogd and the dns daemon. So it could potentially occur on almost all *nix DNS servers. The problem exists if syslogd contains rules for remote forwarding AND these rules do contain hostnames which need to be resolved by DNS. A typical problem is that syslogd starts before the dns daemon. When it intend to send a message to the remote host, it must do a dns lookup, which fails because dns daemon is not yet active. The stock linux syslogd contains some logic which simply defers the connection request, but at the cost of some message loss. Other ways to avoid this problem is to use IP addresses in syslog configuration, host files or, as Baszi said, special configuration options for static address mapping in syslgod. I do not, however, know actual deadlock situations (that is neither syslogd nor dnsd can proceed because they are waiting on each other). I, too, would appreciate any details on that. Rainer > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Thursday, February 01, 2007 2:09 PM > To: Mark Andrews > Cc: IETF-Announce@mit.edu; syslog@ietf.org; ietf@ietf.org > Subject: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The > syslogProtocol) to Proposed Standard >=20 > >>>>> "Mark" =3D=3D Mark Andrews writes: >=20 > >> - 'The syslog Protocol ' as > >> a Proposed Standard >=20 > Mark> draft-ietf-syslog-protocol-19.txt recommends using a > Mark> reliable protocol. Existing implementations of syslog do > Mark> this and deadlock with nameservers which are logging via > Mark> syslog. >=20 >=20 > Please explain the deadlock in more detail. One of the primary > reasons for the syslog working group is reliable syslog, so I think we > need to focus on how to avoid the deadlock in other ways rather than > avoiding reliability. >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 01 11:09:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCeUG-00054K-W3; Thu, 01 Feb 2007 11:08:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCeUF-00052m-Qt for syslog@ietf.org; Thu, 01 Feb 2007 11:08:35 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCeUE-0006qQ-Fn for syslog@ietf.org; Thu, 01 Feb 2007 11:08:35 -0500 Received: from pc6 (1Cust107.tnt105.lnd4.gbr.da.uu.net [213.116.58.107]) by ranger.systems.pipex.net (Postfix) with SMTP id 049ABE000754; Thu, 1 Feb 2007 16:08:10 +0000 (GMT) Message-ID: <028d01c74612$9b144120$0601a8c0@pc6> From: "tom.petch" To: "Rainer Gerhards" , "Sam Hartman" References: <577465F99B41C842AAFBE9ED71E70ABA1F8D3C@grfint2.intern.adiscon.com> Subject: Re: [Syslog] An early last call comment on protocol-19 Date: Thu, 1 Feb 2007 16:05:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Because our chair proposed it and copied Sam on the e-mail? (21Nov2005) BCP0047 is horrendously complex, way over the top for most use cases and fails to define a simple subset when that is all the application needs. ISO meets the need, why make it more complex than it need be? I would not like to see a reference change to the BCP as it stands without a strict limit on which bits of the BCP we are agreeing to the use of, like what ISO specifies and no more! Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Sam Hartman" Cc: Sent: Wednesday, January 31, 2007 7:45 PM Subject: RE: [Syslog] An early last call comment on protocol-19 Sam, I need to check the mailing list archives and my notes, but I think there was no technical reason to use ISO instead of BCP 47. If I do not find anything, I'll simply change the reference. In any case, I'll post what I find out. Rainer > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, January 31, 2007 10:39 AM > To: syslog@ietf.org > Subject: [Syslog] An early last call comment on protocol-19 > > > > I failed to write this up yesterday. > > Your protocol document uses ISO language identifiers rather than BCP > 47. Please either use BCP 47 or explain for all the language sets > that BCP 47 can identify but your choice cannot why syslog > implementations will not care. > > > _______________________________________________ > 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 Feb 01 11:25:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCejx-0001X8-FA; Thu, 01 Feb 2007 11:24:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCejw-0001Wy-D3 for syslog@ietf.org; Thu, 01 Feb 2007 11:24:48 -0500 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCeju-0002CI-6w for syslog@ietf.org; Thu, 01 Feb 2007 11:24:48 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B2681E00B3; Thu, 1 Feb 2007 11:24:45 -0500 (EST) From: Sam Hartman To: "tom.petch" Subject: Re: [Syslog] An early last call comment on protocol-19 References: <577465F99B41C842AAFBE9ED71E70ABA1F8D3C@grfint2.intern.adiscon.com> <028d01c74612$9b144120$0601a8c0@pc6> Date: Thu, 01 Feb 2007 11:24:45 -0500 In-Reply-To: <028d01c74612$9b144120$0601a8c0@pc6> (tom petch's message of "Thu, 1 Feb 2007 16:05:52 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 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 As I said before if you are not going to use BCP 47, you need to clearly explain for each class of languages BCP 47 supports and your application does not support why it is OK to be unable to label those applications. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 01 11:45:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCf3r-0001KC-4G; Thu, 01 Feb 2007 11:45:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCf3q-0001K2-4Z for syslog@ietf.org; Thu, 01 Feb 2007 11:45:22 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCf3o-0002SH-Qe for syslog@ietf.org; Thu, 01 Feb 2007 11:45:22 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007020116451801500far8ge>; Thu, 1 Feb 2007 16:45:18 +0000 From: "David Harrington" To: "'Sam Hartman'" , "'tom.petch'" References: <577465F99B41C842AAFBE9ED71E70ABA1F8D3C@grfint2.intern.adiscon.com><028d01c74612$9b144120$0601a8c0@pc6> Subject: RE: [Syslog] An early last call comment on protocol-19 Date: Thu, 1 Feb 2007 11:41:34 -0500 Message-ID: <08ef01c7461f$d598cd40$0600a8c0@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.2962 In-reply-to: Thread-index: AcdGHY0ujQg/tN5ESc+YJALnN6AbzQAAF8CA X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 WG, If ISO is a subset of what is covered by BCP047, then would it be acceptable to REQUIRE the ISO subset mandatory-to-implement-for-compliance for interoperability purposes, and implementations MAY support other languages in BCP047 with no assurance of interoperability with standard-compliant implementations? Would that satisfy the needs of both Sam and Tom and others in the WG? Are there technical reasons why implementations MUST NOT support BCP047, but only ISO? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Thursday, February 01, 2007 11:25 AM > To: tom.petch > Cc: syslog@ietf.org > Subject: Re: [Syslog] An early last call comment on protocol-19 > > As I said before if you are not going to use BCP 47, you need to > clearly explain for each class of languages BCP 47 supports and your > application does not support why it is OK to be unable to label those > applications. > > _______________________________________________ > 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 Feb 01 13:44:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgty-0000Wo-JM; Thu, 01 Feb 2007 13:43:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgtw-0000Wc-S0 for syslog@ietf.org; Thu, 01 Feb 2007 13:43:16 -0500 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCgtu-00024L-8i for syslog@ietf.org; Thu, 01 Feb 2007 13:43:16 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7D8DEE00B3; Thu, 1 Feb 2007 13:43:13 -0500 (EST) From: Sam Hartman To: "David Harrington" Subject: Re: [Syslog] An early last call comment on protocol-19 References: <577465F99B41C842AAFBE9ED71E70ABA1F8D3C@grfint2.intern.adiscon.com> <028d01c74612$9b144120$0601a8c0@pc6> <08ef01c7461f$d598cd40$0600a8c0@china.huawei.com> Date: Thu, 01 Feb 2007 13:43:13 -0500 In-Reply-To: <08ef01c7461f$d598cd40$0600a8c0@china.huawei.com> (David Harrington's message of "Thu, 1 Feb 2007 11:41:34 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 >>>>> "David" == David Harrington writes: David> Hi WG, If ISO is a subset of what is covered by BCP047, David> then would it be acceptable to REQUIRE the ISO subset David> mandatory-to-implement-for-compliance for interoperability David> purposes, and implementations MAY support other languages David> in BCP047 with no assurance of interoperability with David> standard-compliant implementations? No, I'd really need a fairly strong justification that went through the languages you were not supporting and explained why that was appropriate for syslog. BCP 47 is by definition the IETF's best current practice for language tagging. Absent a compelling reason to do something else, you should identify languages that way. Tom has not (so far) presented a compelling reason. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 01 15:51:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCit6-0003r3-Dp; Thu, 01 Feb 2007 15:50:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCisj-0002bG-LN; Thu, 01 Feb 2007 15:50:09 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCisd-0006qp-DD; Thu, 01 Feb 2007 15:50:09 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E9E5C272AE; Thu, 1 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCisc-00086C-PP; Thu, 01 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-device-mib-14.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 : Syslog Management Information Base Author(s) : G. Keeni Filename : draft-ietf-syslog-device-mib-14.txt Pages : 46 Date : 2007-2-1 This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-14.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-device-mib-14.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-device-mib-14.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: <2007-2-1134722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-device-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-device-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-1134722.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 Thu Feb 01 18:18:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HClBJ-0002xD-EX; Thu, 01 Feb 2007 18:17:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HClBI-0002vi-60; Thu, 01 Feb 2007 18:17:28 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HClBG-0001VM-TN; Thu, 01 Feb 2007 18:17:28 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 17151E00B3; Thu, 1 Feb 2007 18:17:11 -0500 (EST) From: Sam Hartman To: Mark Andrews References: <200702012301.l11N19pd064891@drugs.dv.isc.org> Date: Thu, 01 Feb 2007 18:17:11 -0500 In-Reply-To: <200702012301.l11N19pd064891@drugs.dv.isc.org> (Mark Andrews's message of "Fri, 02 Feb 2007 10:01:09 +1100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF-Announce@mit.edu, syslog@ietf.org, ietf@ietf.org Subject: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslog Protocol) to Proposed Standard X-BeenThere: syslog@lists.ietf.org X-Mailman-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 >>>>> "Mark" == Mark Andrews writes: >> >>>>> "Mark" == Mark Andrews writes: >> >> >> - 'The syslog Protocol ' >> as >> a Proposed Standard >> Mark> draft-ietf-syslog-protocol-19.txt recommends using a Mark> reliable protocol. Existing implementations of syslog do Mark> this and deadlock with nameservers which are logging via Mark> syslog. >> >> >> Please explain the deadlock in more detail. One of the primary >> reasons for the syslog working group is reliable syslog, so I >> think we need to focus on how to avoid the deadlock in other >> ways rather than avoiding reliability. Mark> nameserver logs to syslog. syslog trys to resolve a Mark> address which requires the nameserver to succeed. syslog() Mark> uses a reliable transport to talk to syslogd. This pipe Mark> fills up. syslog() then blocks waiting on syslogd which is Mark> waiting on the nameserver .... This is mostly out of scope for the current document which focuses on syslog communication between systems not within a system. Additional ways to break the deadlock: 1) Provide syslogd with at least one non-locally-logging nameserver 2) Provide enough buffering that the probability you run into this is acceptable. 3) Use an asynchronous DNS library in syslogd I do think a note about deadlocks would be useful in the protocol document. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 01 20:55:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCnd0-0008UQ-EV; Thu, 01 Feb 2007 20:54:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCncz-0008U7-8l for syslog@ietf.org; Thu, 01 Feb 2007 20:54:13 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCncy-0004WV-A6 for syslog@ietf.org; Thu, 01 Feb 2007 20:54:13 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l121ruJW028141 for ; Fri, 2 Feb 2007 10:53:56 +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 l121rpsN026513 for ; Fri, 2 Feb 2007 10:53:55 +0900 (JST) Message-ID: <45C299AE.2070102@cysols.com> Date: Fri, 02 Feb 2007 10:53:50 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Mib-13 References: <03e001c73b6f$7072f860$0600a8c0@china.huawei.com> In-Reply-To: <03e001c73b6f$7072f860$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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, Thanks for the comments. A revised I-D mib-14.txt has been posted to the drafts archives. The response to the comments are given in line below. Cheers Glenn David Harrington wrote: > Hi, > > [speaking as a contributor] > > Glenn, thanks for the new revision. > A few comments. > 1-1. >1) I find the use of entity an unnecessary abstraction. >"In this document we refer to a syslog application as a syslog >entity." >Since -protocol- uses application, why not just use syslog >application instead of syslog entity? That will make the >terminology more consistent. > I disagree. We have been through device, demon and applications. It does appear that "entity" is the most appropriate reference. Let me hear more from the WG on this. 1-2. >In the MIB itself, let's change the hierarchy to be > > syslogObjects > | > ----------------------------------------- > | | | >syslogSystem(1) syslogControlTable(2) syslogOperationsTable(3) > >We don't need the syslogEntity node, or the syslogEntity prefix. This >change will make it easier to read, and eliminate the extra sub-oid >in every varbind. > I am not sure that this is the right design. It certainly does not look elegant to me. Done. 2. >2) "The discussion in this document in general applies to a generic >syslog entity." >If we get rid of all the generalities, we get "This document applies >to syslog applications." >Of course, once you remove the indirection, I'm not sure it is needed >because it is obvious. > See 1. 3. >3) the Copyright in the MODULE-IDENTITY needs to be for the IETF >Trust, not the Internet Trust. (I'm surprised the ID editor didn't >catch that one; they always catch incorrect copyrights on my > documents ;-) Done. 4. >4) section 2 mentions the UDP transport. It doesn't really need to. >If you keep it there, then you should also mention TLS and BEEP >transports in the same paragraph. > Removed the reference to UDP transport in section 2. 5. >5) I do not find Figure 1 enlightening. I suggest you have 2 (or 3) >figures: I want to make this clear - we are not trying to show the relationship between the various roles. That is left for the Protocol (and other) documents. I will be keen to know if some part of the text in the MIB document is obscure or unclear due to insufficient explanation in the diagram. >- One that shows the relationship of senders and relays and receivers > >(section) 2.1 Syslog Applications > > +--------+ +----------+ > | Sender |--syslog message->| Receiver | > +--------+ +----------+ > > +--------+ +-------+ >+----------+ > | Sender |--syslog message->| Relay |--syslog message->| >Receiver | > +--------+ +-- ----+ >+----------+ > > Fig. 1: syslog applications > > o A syslog application that can generate a syslog message is > called a "sender". > > o A syslog application that can receive a syslog message is > called a "receiver". > > o A syslog application that can receive syslog messages and > forward them to another receiver is called a "relay". > > >- One that shows the relationship of facilities to senders. >(section) 2.2 Facilities > > +---------+ > | Sender1 |----syslog message--> > /+---------+ > Facility-1-->| / > -->| / +---------+ / > Facility-N-->|+---| Sender2 |----syslog message--> > -->| \ +---------+ \ > SyslogHost-N-->| \ > \+---------+ / > | Sender3 |----syslog message--> > +---------+ \ > Fig. 2: Facilities > >Facility: an application or device that asks a syslog sender to send >a message. Sometimes the facility and the sysog sender are built into >the same application; sometimes they are separate applications. > >Since we plan to modify the collector definition in protocol, is the >collector always the same as the receiver, or is the collector the >application(s) behind the syslog application (e.g. syslogd)? If they >are separate, then we should probably show that relationship: > >- One that shows the relationship of receivers and collectors >(section) 2.3 Collectors > > +-----------+ > ----syslog message-->| Receiver1 |\ |--> Collector1 > +-----------+ \ | > \ | > +--|--> Collector2 > / | > +-----------+ / | > >Can one receiver (one port) support multiple collectors, or is this >always a 1:1 relationship? Can a collector ask multiple receivers >(different ports, presumably) to listen for traffic? > 6. >6) I am not sure we had consensus to remove all the objects you >removed. I will check further and consult with Chris. > With the departure of rfc3164 from informational to history, these objects have lost their the raison d'etre. I have put back the TCs for SyslogSeverity and SyslogFacility as per our discussions. 7. >7) MsgDropped counts messages that could not be queued by a relay; >but it will be zero if this is not a sender. The WG distinguishes >between senders and relays, so this does not make sense. If we only >count these on a relay, then it should be zero if it is a reciever >or sender, and non-zero only on a relay. >OR we need to change our definition for relay to be a syslog >application that includes both a sender and a receiver, so a relay >also increments counters specific to a sender and those specific to a >reciever. > If you look at the diagram in Fig.1 and the explanation that follows - this will be clear. We basically have syslog senders and syslog receivers. A syslog relay is a special case - it "forwards some of the received syslog messages to other syslog entities." 8. >8) Malformed - The WG distinguishes between receivers and relays; >should we have both receivers and relays count malformed headers? I recommend that we do not. I would say that the administrator is interested in knowing that his/her syslog is receiving too many malformed messages. The administrator is less interested in knowing whether the malformed message was meant for local consumption or for forwarding. (I am not saying that the information is useless. We are trying to look at the cost benefits.) 9. >9) MsgsReceived - should we count messages recived by receivers and >relays? > I recommend that we do not. We have separate counters on MsgsReceived and MsgsRelayed. The difference is the number of messages received for local consumption. 10. >10) MsgsReceived. This description doesn't have the note that this >value will be zero if the entity is not a reciever. > Done. 11. >11) should we also have a MsgsSent? > Yes. I have added this. 12. >12) MsgsDiscarded - you changed the terminology from ignored to >discarded. The description in MsgsRecieved needs to be changed to >match. > Done. 13. >13) MsgsDiscarded - relays should also count these. > Yes. A relay is a receiver too. So it is counted. 14. >14) LastMsgRecdTime - the locally or from a remote entity is >confusing. Locally appears to refer to the non-syslog-message >communication between a facility and a sender. Is that correct? If >that is not what locally means, I don't know how to interpret this >text. I think we need to distinguish between the on-the-wire (i.e. >syslog messages) and the off-the-wire communications (i.e. non-syslog >messages). > > I have removed the part that was confusing "locally or from a remote entity". There is no other way the syslog receiver can receive a message. Nothing is lost by removing that text. 15. >15) local management system - since both SNMP and syslog are local >management systems, I think this should be the SNMP management >system. > Done. 16. >16) OperationsReference - can we change this to OperationsRunIndex? I >think that will more meaningful. Done. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 01 22:36:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCpD6-0001qa-67; Thu, 01 Feb 2007 22:35:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCpD4-0001qU-Hp for syslog@ietf.org; Thu, 01 Feb 2007 22:35:34 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCpD2-00026p-Qm for syslog@ietf.org; Thu, 01 Feb 2007 22:35:34 -0500 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 <0JCT00DC6GBG1U@szxga02-in.huawei.com> for syslog@ietf.org; Fri, 02 Feb 2007 11:28:28 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JCT00J22GBF48@szxga02-in.huawei.com> for syslog@ietf.org; Fri, 02 Feb 2007 11:28:28 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCT00KMJGB933@szxml03-in.huawei.com> for syslog@ietf.org; Fri, 02 Feb 2007 11:28:27 +0800 (CST) Date: Fri, 02 Feb 2007 11:28:21 +0800 From: Miao Fuyou Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls In-reply-to: To: 'Sam Hartman' Message-id: <017001c7467a$30c352d0$800c6f0a@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: AcdFG09J1/2P/qkZQf+Rnc/hahwF9gBVaIkA 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 Section 2 identifies masquerade as a major security threat for syslog. In the draft, client authentication and server authentication are SHOULDs(server authenticaiton may be not spelled out explicitly). After reading RFC2818 once again, I think the server authentication may have to be a MUST for the specification to mitigate the MITM, while client authentication (mutual authentication actually) may still be kept SHOULD. If generic certificate is not right to be reccomended in an IETF specification, probably we have to remove it from the draft. Thanks! Miao > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, January 31, 2007 5:37 PM > To: Miao Fuyou > Cc: syslog@ietf.org > Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > I'll get back to you on the generic certificates issue. For > now, I recommend you read RFC 4107. Also note that each > device needs a unique MAC address so the manufacturing > process tends to have a step for making a device unique. > > > > So, it sounds like all forms of authentication are optional > in this spec. > > You need a clear table describing what attacks are protected > against given each authentication choice. > > > Wording that table so that man-in-the-middle issues are dealt > with correctly and it is still informative will be tricky. > > --Sam > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 01 23:31:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCq4X-0005wN-Ku; Thu, 01 Feb 2007 23:30:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCq4X-0005wC-6A for syslog@ietf.org; Thu, 01 Feb 2007 23:30:49 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCq4J-0005WT-PW for syslog@ietf.org; Thu, 01 Feb 2007 23:30:49 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E7B16E00B3; Thu, 1 Feb 2007 23:30:11 -0500 (EST) From: Sam Hartman To: Miao Fuyou Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls References: <017001c7467a$30c352d0$800c6f0a@china.huawei.com> Date: Thu, 01 Feb 2007 23:30:11 -0500 In-Reply-To: <017001c7467a$30c352d0$800c6f0a@china.huawei.com> (Miao Fuyou's message of "Fri, 02 Feb 2007 11:28:21 +0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) 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 >>>>> "Miao" == Miao Fuyou writes: Miao> Section 2 identifies masquerade as a major security threat Miao> for syslog. In the draft, client authentication and server Miao> authentication are SHOULDs(server authenticaiton may be not Miao> spelled out explicitly). After reading RFC2818 once again, I Miao> think the server authentication may have to be a MUST for Miao> the specification to mitigate the MITM, while client Miao> authentication (mutual authentication actually) may still be Miao> kept SHOULD. You can also decide to document that if you care about MITM you need authentication. My point was not to change your decisions, simply to require that you provide an easy way for people to know what security they are getting based on what they are doing. I've talked to Russ Housley and we will not take a document to the IESG that recommends the reuse of private keys, so the generic certificates section needs to go. You could talk about how devices could be identified by some component of a subject name or subject alternative name and such mechanisms can be used to identify all the devices from a manufacturer; that's true regardless of whether generic certificates are used or one certificate per device. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Feb 02 08:13:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCyCq-00014x-98; Fri, 02 Feb 2007 08:11:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkw1-00015F-0I; Thu, 01 Feb 2007 18:01:41 -0500 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCkvv-00053d-80; Thu, 01 Feb 2007 18:01:40 -0500 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.8/8.13.8) with ESMTP id l11N19pd064891; Fri, 2 Feb 2007 10:01:09 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200702012301.l11N19pd064891@drugs.dv.isc.org> To: Sam Hartman From: Mark Andrews In-reply-to: Your message of "Thu, 01 Feb 2007 08:09:29 CDT." Date: Fri, 02 Feb 2007 10:01:09 +1100 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Fri, 02 Feb 2007 08:11:54 -0500 Cc: IETF-Announce@mit.edu, syslog@ietf.org, ietf@ietf.org Subject: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslog Protocol) to Proposed Standard X-BeenThere: syslog@lists.ietf.org X-Mailman-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 > >>>>> "Mark" == Mark Andrews writes: > > >> - 'The syslog Protocol ' as > >> a Proposed Standard > > Mark> draft-ietf-syslog-protocol-19.txt recommends using a > Mark> reliable protocol. Existing implementations of syslog do > Mark> this and deadlock with nameservers which are logging via > Mark> syslog. > > > Please explain the deadlock in more detail. One of the primary > reasons for the syslog working group is reliable syslog, so I think we > need to focus on how to avoid the deadlock in other ways rather than > avoiding reliability. nameserver logs to syslog. syslog trys to resolve a address which requires the nameserver to succeed. syslog() uses a reliable transport to talk to syslogd. This pipe fills up. syslog() then blocks waiting on syslogd which is waiting on the nameserver .... There are two way to break this. 1. use a lossy transport 2. don't attempt to resolve names/addresses in syslogd. You can reduce the problem by always logging using IP addresses. However it doesn't remove the problem completely as you still need to look up addresses for forwarding purposes. Similarly if syslogd is using a reliable transport to talk to another syslogd. That too can block which will eventualy lead to blockages to applications / memory exhaustion. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Feb 02 09:26:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzM0-0007QD-QC; Fri, 02 Feb 2007 09:25:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzLz-0007NA-Kw; Fri, 02 Feb 2007 09:25:27 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzLx-0003iR-7Z; Fri, 02 Feb 2007 09:25:27 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 2FD2527C06C; Fri, 2 Feb 2007 15:25:35 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05274-06; Fri, 2 Feb 2007 15:25:35 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D1B4027C06B; Fri, 2 Feb 2007 15:25:34 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 15:25:13 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslogProtocol) to Proposed Standard X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 2 Feb 2007 15:24:25 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8D9C@grfint2.intern.adiscon.com> In-Reply-To: <200702012301.l11N19pd064891@drugs.dv.isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslogProtocol) to Proposed Standard Thread-Index: AcdGzAz1WmBIHDwpSV6WKY7SeuuLRwAB0smQ References: Your message of "Thu, 01 Feb 2007 08:09:29 CDT." <200702012301.l11N19pd064891@drugs.dv.isc.org> From: "Rainer Gerhards" To: "Mark Andrews" , "Sam Hartman" X-OriginalArrivalTime: 02 Feb 2007 14:25:13.0222 (UTC) FILETIME=[F3990A60:01C746D5] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF-Announce@mit.edu, syslog@ietf.org, ietf@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 > > >>>>> "Mark" =3D=3D Mark Andrews writes: > > [snip] > Similarly if syslogd is using a reliable transport > to talk to another syslogd. That too can block which > will eventualy lead to blockages to applications / > memory exhaustion. *That* is a different beast, not yet discussed. I know that it exists but it is not related to DNS. If it happens, it is really bad and typically results in a complete system hang. There are some situations where a lossy transport is preferable. For example, I have written a syslog/TCP implementation which, if forced to run in single-threaded mode, favours discarding messages over blocking as the later could indeed lead to fatal problems on a typical linux system. The root cause, however, is not reliable syslog per se. The root cause is the implementation. A reliable syslogd actually needs to be implemented with a non-blocking, de-coupled, buffered design. In almost all cases, that means separate receiver threads, a to-be-processed message queue and separate sender threads. Still, you have to decide what to do if the queue size is exhausted. But that scenario is much less likely. In that case, I'd still favour loosing some messages over potentially loosing all AND the system the syslogd runs on. As far as I see it, this is an app-layer issue out of scope for the underlying protocol. The problem, of course, is that syslog is simplex and hop-to-hop, so the original sender will never know that the message was lost. Protocol-wise, I do not see any fix to that except integrating some asynchronous notification mechanism. IMHO, this is outside the scope of syslog. It may be useful to add some hint to implementors pointing to this blocking condition. But I am not sure if it is really justified. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Feb 02 13:32:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD3CE-00006N-81; Fri, 02 Feb 2007 13:31:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD3CD-000066-9H for syslog@ietf.org; Fri, 02 Feb 2007 13:31:37 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD3CB-00078l-PM for syslog@ietf.org; Fri, 02 Feb 2007 13:31:37 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007020218313501400q6hgse>; Fri, 2 Feb 2007 18:31:35 +0000 From: "David Harrington" To: "'Glenn M. Keeni'" , References: <03e001c73b6f$7072f860$0600a8c0@china.huawei.com> <45C299AE.2070102@cysols.com> Subject: RE: [Syslog] Mib-13 Date: Fri, 2 Feb 2007 13:27:31 -0500 Message-ID: <0a8a01c746f7$d558edf0$0600a8c0@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.2962 In-reply-to: <45C299AE.2070102@cysols.com> Thread-index: AcdGbTSHQpGcRz2vSW+Dkl55Miz3cAAgKUxw X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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 Glenn, Some comments. First let me start out by noting that MIB modules are frequently implemented by junior developers, since the senior developers don't want to waste their time working on management stuff; they want to go design new hardware and new protocols. So the implementer of a syslog MIB module may not have much experience with syslog. As a result, it is important to be unambiguous in our terminology. This is especially true when describing what should be counted in a counter. This is a common problem in MIB module implementations - different implementations interpret the instructions slightly differently, and end up counting slightly different things, and as a result, the counters cannot be interpreted in an interoperable way across implementations. Protocol says there are three application types - senders, receivers, and relays. -protocol- does NOT say that a relay is a special case and that a relay IS a receiver and IS a sender: Per the protocol document: > > o A syslog application that can generate a syslog message is > > called a "sender". > > > > o A syslog application that can receive a syslog message is > > called a "receiver". > > > > o A syslog application that can receive syslog messages and > > forward them to another receiver is called a "relay". > > Here's where ambiguity comes in as the result of terminology differences between -protocol- and -mib-. You know and I know that a relay really both recieves and sends and it does some stuff in between, but protocol does not say that a relay is both a receiver and a sender, and nothing says that when counting things, a relay should count things relevant to a receiver AND relevant to a sender. SyslogRoles is not clear on this point: If I am a relay, then do I set all three bits ON (sender, receiver, relay) or do I only set the relay BIT ON? Malformed says "The number of messages received by the syslog receiver which had malformed header. If this syslog entity is not a syslog receiver the this object will have a zero value.", Well, if I am a relay am I also a reciever? Protocol does not say that! In fact, protocol says there are three types of applications, so if I am a relay then I can interpret this to mean I am not a "reciever" and I am not a "sender"; I am a "relay". Therefore, as a relay, I should not count malformed headers, because only receivers should count malformed headers. Am I just thick? No. I fully understand that a relay both receives and sends; but the text in our specififcations does not say that this means a relay is both a "receiver" and a "sender". I am an experienced MIB Doctor that has dealt with this same type of ambiguity in WG after WG, where the WG members understand, but they are sloppy in their MIB module specification work. We have an ambiguity: Does the Malformed counter include malformed headers received by a relay or not? This can be interpreted as "relays should not count malformed headers that it receives; only receivers should count them." I think that would be a bad interpretation, but the ambiguity of the terminology allows for this interpretation. We need to modify the text so that such an interpretation is not allowed. I recommend changing the text to: "The number of messages received by the syslog receiver or relay which had malformed header. If this syslog entity is not a syslog receiver or relay the this object will have a zero value." This way, whether the implementer interprets the terminology differences to be "I am a relay therefore I am NOT a receiver" or "I am a relay therefore I AM a receiver" makes no difference. An alternative is to change the protocol document to be clear that there are only two basic types of application- a sender and a receiver, and the relay is a special case that is both a receiver and a sender plus other stuff. Right now the protocol document definitions do not state that clearly. (also note the "the this" s/b "then this" (also note "had malformed" s/b "had a malformed") > > 8. > >8) Malformed - The WG distinguishes between receivers and relays; > >should we have both receivers and relays count malformed headers? > > I recommend that we do not. I would say that the administrator is > interested in knowing that his/her syslog is receiving too many > malformed messages. The administrator is less interested in knowing > whether the malformed message was meant for local consumption or for > forwarding. (I am not saying that the information is useless. We are > trying to look at the cost benefits.) I think you misinterpreted me here. I was not suggesting two separate counters, one for receivers and one for relays; I am trying to make sure the relays also increment this counter when they receive a malformed header. dbh > > _______________________________________________ > 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 Feb 04 05:10:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDeJA-0005ns-3Z; Sun, 04 Feb 2007 05:09:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDeJ8-0005jc-9X; Sun, 04 Feb 2007 05:09:14 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HDeJ6-0002zV-FU; Sun, 04 Feb 2007 05:09:14 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6345c610ed; Sun, 04 Feb 2007 18:19:18 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm3545c1239c; Thr, 01 Feb 2007 00:18:24 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm645c0c3b3; Thr, 01 Feb 2007 00:18:22 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 01 Feb 2007 00:18:22 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHwN-0007ZZ-QJ; Wed, 31 Jan 2007 11:04:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHwL-0007Yu-2g; Wed, 31 Jan 2007 11:04:05 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHw4-0003k8-IQ; Wed, 31 Jan 2007 11:04:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6E54026E85; Wed, 31 Jan 2007 16:03:48 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCHw4-0001DO-B3; Wed, 31 Jan 2007 11:03:48 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 31 Jan 2007 11:03:48 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: syslog@ietf.org Subject: [Syslog] Last Call: draft-ietf-syslog-protocol (The syslog Protocol) to Proposed Standard X-BeenThere: syslog@lists.ietf.org Reply-To: ietf@ietf.org 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 IESG has received a request from the Security Issues in Network Event Logging WG (syslog) to consider the following documents: - 'Transmission of syslog messages over UDP ' as a Proposed Standard - 'The syslog Protocol ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. In order to add security services to the syslog protocol, the syslog working group has undertaken the task of formally specifying the format of syslog messages and transports. Their solution is neither fully backward nor forward compatible with syslog implementations deployed today. RFC 3164 and Appendix A of draft-ietf-syslog-protocol discuss the compatibility issue and the working group's decision in this matter at length. The IETF community is encouraged to review this discussion as well as the chartering discussion that codified this decision in the syslog charter. Major changes include the addition of structured data to syslog messages and the addition of a mandatory secure transport. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-08.txt http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-19.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11213&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 06:36:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE27W-0006GA-FY; Mon, 05 Feb 2007 06:34:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE27V-0006G5-Jv for syslog@ietf.org; Mon, 05 Feb 2007 06:34:49 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE27T-0002WD-QZ for syslog@ietf.org; Mon, 05 Feb 2007 06:34:49 -0500 Received: from pc6 (1Cust231.tnt4.lnd4.gbr.da.uu.net [62.188.133.231]) by blaster.systems.pipex.net (Postfix) with SMTP id E2601E000672; Mon, 5 Feb 2007 11:34:43 +0000 (GMT) Message-ID: <001701c74911$0ebd30e0$0601a8c0@pc6> From: "tom.petch" To: "Glenn M. Keeni" , References: <03e001c73b6f$7072f860$0600a8c0@china.huawei.com> <45C299AE.2070102@cysols.com> Subject: entity `Re: [Syslog] Mib-13 Date: Mon, 5 Feb 2007 10:42:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" 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: d0bdc596f8dd1c226c458f0b4df27a88 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 I am with David on this one. Since RFC3164, -protocol, -sign, -tls etc all manage without reference to 'entity', then I think there needs to be good justification for introducing a new technical term eg it should label a distinctly different concept and that I do not see. Tom Petch ----- Original Message ----- From: "Glenn M. Keeni" To: Sent: Friday, February 02, 2007 2:53 AM Subject: Re: [Syslog] Mib-13 > Hi, > Thanks for the comments. A revised I-D mib-14.txt has been > posted to the drafts archives. The response to the comments > are given in line below. > > Cheers > > Glenn > > David Harrington wrote: > > > > [speaking as a contributor] > > > > Glenn, thanks for the new revision. > > A few comments. > > > 1-1. > >1) I find the use of entity an unnecessary abstraction. > >"In this document we refer to a syslog application as a syslog > >entity." > >Since -protocol- uses application, why not just use syslog > >application instead of syslog entity? That will make the > >terminology more consistent. > > > I disagree. We have been through device, demon and applications. It > does appear that "entity" is the most appropriate reference. Let me > hear more from the WG on this. > > 1-2. > >In the MIB itself, let's change the hierarchy to be > > > > syslogObjects > > | > > ----------------------------------------- > > | | | > >syslogSystem(1) syslogControlTable(2) syslogOperationsTable(3) > > > >We don't need the syslogEntity node, or the syslogEntity prefix. This > >change will make it easier to read, and eliminate the extra sub-oid > >in every varbind. > > > I am not sure that this is the right design. It certainly does not > look elegant to me. > Done. > > 2. > >2) "The discussion in this document in general applies to a generic > >syslog entity." > >If we get rid of all the generalities, we get "This document applies > >to syslog applications." > >Of course, once you remove the indirection, I'm not sure it is needed > >because it is obvious. > > > See 1. > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 06:36:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE27b-0006GX-Jw; Mon, 05 Feb 2007 06:34:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE27a-0006GR-81 for syslog@ietf.org; Mon, 05 Feb 2007 06:34:54 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE27Y-0002Wf-Ge for syslog@ietf.org; Mon, 05 Feb 2007 06:34:54 -0500 Received: from pc6 (1Cust231.tnt4.lnd4.gbr.da.uu.net [62.188.133.231]) by blaster.systems.pipex.net (Postfix) with SMTP id 18498E0006B8; Mon, 5 Feb 2007 11:34:47 +0000 (GMT) Message-ID: <001801c74911$107938c0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" References: <03e001c73b6f$7072f860$0600a8c0@china.huawei.com><45C299AE.2070102@cysols.com> <0a8a01c746f7$d558edf0$0600a8c0@china.huawei.com> Subject: senders and receivers nothing to do with Mibs was Re: [Syslog] Mib-13 Date: Mon, 5 Feb 2007 11:32:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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 David I disagree with you here. I think that we should use four terms, sender, receiver, relay, collector. RFC3164 I find very clear. collector receives and does not forward relay receives and forwards sender sends, device or relay receiver receives, relay or collector. -protocol started off life with identical definitions but by -10, two key phrases had vanished leaving sender sends, receiver receives, which would be ambiguous except that further down it says " Senders send messages to receivers with no knowledge of whether they are collectors or relays" which again I find very clear - receiver receives, relay or collector. So while the present text is not as clear as it used to be, I still believe that what we are saying is what we always have said, namely collector receives and does not forward relay receives and forwards sender sends, device or relay receiver receives, relay or collector and I see this implicitly endorsed in the documentation of other bodies; collector, in particular, I see used, if not as precisely defined as we used to. So, I conclude that we have four well-defined terms, in use for many years, and need a good reason to change them. Of course we could do things differently, but at the risk of confusing those who have not followed this WG. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'Glenn M. Keeni'" ; Sent: Friday, February 02, 2007 7:27 PM Subject: RE: [Syslog] Mib-13 > Hi Glenn, > > Some comments. > > First let me start out by noting that MIB modules are frequently > implemented by junior developers, since the senior developers don't > want to waste their time working on management stuff; they want to go > design new hardware and new protocols. So the implementer of a syslog > MIB module may not have much experience with syslog. > > As a result, it is important to be unambiguous in our terminology. > This is especially true when describing what should be counted in a > counter. This is a common problem in MIB module implementations - > different implementations interpret the instructions slightly > differently, and end up counting slightly different things, and as a > result, the counters cannot be interpreted in an interoperable way > across implementations. > > Protocol says there are three application types - senders, receivers, > and relays. -protocol- does NOT say that a relay is a special case and > that a relay IS a receiver and IS a sender: > > Per the protocol document: > > > o A syslog application that can generate a syslog message is > > > called a "sender". > > > > > > o A syslog application that can receive a syslog message is > > > called a "receiver". > > > > > > o A syslog application that can receive syslog messages and > > > forward them to another receiver is called a "relay". > > > > > Here's where ambiguity comes in as the result of terminology > differences between -protocol- and -mib-. > > You know and I know that a relay really both recieves and sends and it > does some stuff in between, but protocol does not say that a relay is > both a receiver and a sender, and nothing says that when counting > things, a relay should count things relevant to a receiver AND > relevant to a sender. > > SyslogRoles is not clear on this point: If I am a relay, then do I set > all three bits ON (sender, receiver, relay) or do I only set the relay > BIT ON? > > Malformed says "The number of messages received by the syslog > receiver which had malformed header. > If this syslog entity is not a syslog receiver > the this object will have a zero value.", > Well, if I am a relay am I also a reciever? Protocol does not say > that! In fact, protocol says there are three types of applications, so > if I am a relay then I can interpret this to mean I am not a > "reciever" and I am not a "sender"; I am a "relay". Therefore, as a > relay, I should not count malformed headers, because only receivers > should count malformed headers. > > Am I just thick? No. I fully understand that a relay both receives and > sends; but the text in our specififcations does not say that this > means a relay is both a "receiver" and a "sender". I am an experienced > MIB Doctor that has dealt with this same type of ambiguity in WG after > WG, where the WG members understand, but they are sloppy in their MIB > module specification work. > > We have an ambiguity: Does the Malformed counter include malformed > headers received by a relay or not? This can be interpreted as "relays > should not count malformed headers that it receives; only receivers > should count them." I think that would be a bad interpretation, but > the ambiguity of the terminology allows for this interpretation. We > need to modify the text so that such an interpretation is not allowed. > I recommend changing the text to: > "The number of messages received by the syslog > receiver or relay which had malformed header. > If this syslog entity is not a syslog receiver > or relay the this object will have a zero value." > This way, whether the implementer interprets the terminology > differences to be "I am a relay therefore I am NOT a receiver" or "I > am a relay therefore I AM a receiver" makes no difference. > > An alternative is to change the protocol document to be clear that > there are only two basic types of application- a sender and a > receiver, and the relay is a special case that is both a receiver and > a sender plus other stuff. Right now the protocol document definitions > do not state that clearly. > > (also note the "the this" s/b "then this" > (also note "had malformed" s/b "had a malformed") > > > > > 8. > > >8) Malformed - The WG distinguishes between receivers and relays; > > >should we have both receivers and relays count malformed headers? > > > > I recommend that we do not. I would say that the administrator is > > interested in knowing that his/her syslog is receiving too many > > malformed messages. The administrator is less interested in > knowing > > whether the malformed message was meant for local consumption or > for > > forwarding. (I am not saying that the information is useless. We > are > > trying to look at the cost benefits.) > > I think you misinterpreted me here. I was not suggesting two separate > counters, one for receivers and one for relays; I am trying to make > sure the relays also increment this counter when they receive a > malformed header. > > > > dbh > > > > _______________________________________________ > > 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 Mon Feb 05 08:31:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3vo-0002GY-Ef; Mon, 05 Feb 2007 08:30:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE3vo-0002GT-0C for syslog@ietf.org; Mon, 05 Feb 2007 08:30:52 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE3vm-00047f-BZ for syslog@ietf.org; Mon, 05 Feb 2007 08:30:51 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l15DUKJW025458 for ; Mon, 5 Feb 2007 22:30:20 +0900 (JST) Received: from [127.0.0.1] (kiras6.priv.cysol.co.jp [192.168.0.156]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l15DUEsN025718 for ; Mon, 5 Feb 2007 22:30:20 +0900 (JST) Message-ID: <45C73166.1030605@cysols.com> Date: Mon, 05 Feb 2007 22:30:14 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: entity `Re: [Syslog] Mib-13 References: <03e001c73b6f$7072f860$0600a8c0@china.huawei.com> <45C299AE.2070102@cysols.com> <001701c74911$0ebd30e0$0601a8c0@pc6> In-Reply-To: <001701c74911$0ebd30e0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Tom, I do not understand what you mean by a technical term. Perhaps entity is as technical as "it". It is convenient and appropriate since we do not know or do not want to predict whether a syslog message will be generated by a "application", "device", "organism", "machine" or whatever. Glenn tom.petch wrote: > I am with David on this one. Since RFC3164, -protocol, -sign, -tls etc all > manage without reference to 'a technical term. entity', then I think there needs to be good > justification for introducing a new technical term eg it should label a > distinctly different concept and that I do not see. > > Tom Petch > > > ----- Original Message ----- > From: "Glenn M. Keeni" > To: > Sent: Friday, February 02, 2007 2:53 AM > Subject: Re: [Syslog] Mib-13 > > >> Hi, >> Thanks for the comments. A revised I-D mib-14.txt has been >> posted to the drafts archives. The response to the comments >> are given in line below. >> >> Cheers >> >> Glenn >> >> David Harrington wrote: >>> [speaking as a contributor] >>> >>> Glenn, thanks for the new revision. >>> A few comments. >>> >> 1-1. >> >1) I find the use of entity an unnecessary abstraction. >> >"In this document we refer to a syslog application as a syslog >> >entity." >> >Since -protocol- uses application, why not just use syslog >> >application instead of syslog entity? That will make the >> >terminology more consistent. >> > >> I disagree. We have been through device, demon and applications. It >> does appear that "entity" is the most appropriate reference. Let me >> hear more from the WG on this. >> >> 1-2. >> >In the MIB itself, let's change the hierarchy to be >> > >> > syslogObjects >> > | >> > ----------------------------------------- >> > | | | >> >syslogSystem(1) syslogControlTable(2) syslogOperationsTable(3) >> > >> >We don't need the syslogEntity node, or the syslogEntity prefix. This >> >change will make it easier to read, and eliminate the extra sub-oid >> >in every varbind. >> > >> I am not sure that this is the right design. It certainly does not >> look elegant to me. >> Done. >> >> 2. >> >2) "The discussion in this document in general applies to a generic >> >syslog entity." >> >If we get rid of all the generalities, we get "This document applies >> >to syslog applications." >> >Of course, once you remove the indirection, I'm not sure it is needed >> >because it is obvious. >> > >> See 1. >> > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 11:18:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6XE-0001H6-8C; Mon, 05 Feb 2007 11:17:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6XC-0001Gv-AP for syslog@ietf.org; Mon, 05 Feb 2007 11:17:39 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE6XB-0002S1-0L for syslog@ietf.org; Mon, 05 Feb 2007 11:17:38 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007020516173601200i5g83e>; Mon, 5 Feb 2007 16:17:36 +0000 From: "David Harrington" To: "'tom.petch'" , "'Miao Fuyou'" , "'Sam Hartman'" , References: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com> <031d01c74560$cebe3f60$0601a8c0@pc6> Subject: RE: Relays was Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls Date: Mon, 5 Feb 2007 11:13:41 -0500 Message-ID: <0c2701c74940$9a745bc0$0600a8c0@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.2962 In-reply-to: <031d01c74560$cebe3f60$0601a8c0@pc6> Thread-index: AcdFaW3WNbqR4F+cTSmg9ESbMza7XwD0Xh4g 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 WG, [speaking as co-chair] As co-chair, I will need to advise Miao to remove support for generic certificates unless there is overwhelming WG consensus to keep them, and the explanation of why reuse of private keys is necessary will need to be compelling. Please read RFC4107 (which is short). There are ambiguities in the TLS document regarding who MUST authenticate that will need to be tightened up. As the email from Tom reflects, part of the problem is the ambiguity in the definition of relay; I think it needs to be made clearer in the -protocol- document that a relay is a receiver and is a sender, and clearer in the -tls- document that authentication is hop-by-hop. Personally, I think we should make authentication more mandatory than is currently described, but the WG needs to reach such a consensus. If we keep the optional authentication(s), then the WG should justify in the document why it makes "protocol sense" for the authentication(s) to be optional. The WG needs to develop the table showing how the various authentication options mitigate threats, especially MITM threats, and we should have text that describes this as well. Please work with Miao to address these issues. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, January 31, 2007 12:53 PM > To: Miao Fuyou; 'Sam Hartman'; syslog@ietf.org > Subject: Relays was Re: [Syslog] AD Review for > draft-ietf-syslog-transport-tls > > > > Tom Petch > > ----- Original Message ----- > From: "Miao Fuyou" > To: "'Sam Hartman'" ; > Sent: Wednesday, January 31, 2007 5:50 AM > Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > Hi Sam, > > > > Thanks for the review! My response is inline. > > > > Regards, > > Miao > > > > > -----Original Message----- > > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > > Sent: Wednesday, January 31, 2007 7:23 AM > > > To: syslog@ietf.org > > > Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > > > > Hi, folks. I had no comments on the UDP draft or the main > > > protocol draft so I have forwarded them to IETF last call. > > > > > > I do have some concerns with the TLS draft. > > > > > > > > > > > Are senders and relays required to have a certificate and to > > > use that certificate? > > > > > > > It is not required, but it is preferrable for some deployment where > > malicious senders may send lots of messages to overwhelm > the receiver. > > > Sam > > I have a slightly different view. To quote the I-D, where it says > "The sender/relay should initiate a connection to the receiver" > I take that as the sender initiates a connection to the > receiver if no relay is > present or to the relay (when present), the relay (when > present) initiates the > connection to the receiver (collector). Relay and receiver > become TLS Servers > and insofar as TLS Servers have certificates, the relay will have one! > > When the next paragraph says > "When a sender/ relay authenticates a receiver it MUST > validate the certificate" > I take that to mean that the sender authenticates the > receiver if no relay is > present or the sender authenticates the relay (when present) > and the relay > authenticates the receiver. > > relay and sender are TLS clients. > > I appreciate that this is hop by hop security and not ideal > end to end security. > > Tom Petch > > > --Sam > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > 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 Feb 05 11:33:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6lg-0001OV-Om; Mon, 05 Feb 2007 11:32:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6lf-0001OK-2d for syslog@ietf.org; Mon, 05 Feb 2007 11:32:35 -0500 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE6le-00052N-8c for syslog@ietf.org; Mon, 05 Feb 2007 11:32:35 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 537CA9C00D; Mon, 5 Feb 2007 17:48:52 +0100 (CET) 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 09945-02; Mon, 5 Feb 2007 17:48:44 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 534609C00B; Mon, 5 Feb 2007 17:48:44 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 5 Feb 2007 17:32:11 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8DD5@grfint2.intern.adiscon.com> In-Reply-To: <0c2701c74940$9a745bc0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls Thread-Index: AcdFaW3WNbqR4F+cTSmg9ESbMza7XwD0Xh4gAAG6hbA= References: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com><031d01c74560$cebe3f60$0601a8c0@pc6> <0c2701c74940$9a745bc0$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" , "tom.petch" , "Miao Fuyou" , "Sam Hartman" , X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd 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, let me start with the relays: given the recent discussion, I think it would be much more advisible to add a few sentences to -protocol (I already made a proposal) that clarifies the situation. It is not much that needs to be added. It would resolve all those other issues. Regarding generic certificates, I do not see an overwhelming reason to have them (and I was one of them who liked them). I agree with Sam that there can be placed unique certificates on the device during the manufacturing process. Another story, however, is the need to authenticate/verify a device. Without any doubt, there is more than one scenario where authentication based on the device is mandatory. However, syslog is also often deployed in (low end) scenarios where the (part-time) operator is simply interested receiving log messages from his 5 or so routers. This admin is often not very knowledgable. If we now require that admin to either a) configure access rules for all (though few) devices or b) use unencrypted UDP syslog I am sure many of these admins will resort to b) because a) requires too much learning. In the essence, strong security/authentication would bring us less real-world security (pretty much the same thing with strong passwords ... so strong that they are "stored" on post-it notes under the keyboard). So I would not like to see client and server authentication to be a MUST. Well ... a MUST for an implementation to have that capability would be OK. But an admin must be capable to configure sender and/or receiver to work without authentication. No matter what we specify in -protocol, that capability will be available in all implementations that I foresee. IMHO an uncoditional MUST would create a false sense of security ... and the most insecure thing is false sense of security. Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Monday, February 05, 2007 5:14 PM > To: 'tom.petch'; 'Miao Fuyou'; 'Sam Hartman'; syslog@ietf.org > Subject: RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog- > transport-tls >=20 > Hi WG, >=20 > [speaking as co-chair] >=20 > As co-chair, I will need to advise Miao to remove support for generic > certificates unless there is overwhelming WG consensus to keep them, > and the explanation of why reuse of private keys is necessary will > need to be compelling. Please read RFC4107 (which is short). >=20 > There are ambiguities in the TLS document regarding who MUST > authenticate that will need to be tightened up. As the email from Tom > reflects, part of the problem is the ambiguity in the definition of > relay; I think it needs to be made clearer in the -protocol- document > that a relay is a receiver and is a sender, and clearer in the -tls- > document that authentication is hop-by-hop. >=20 > Personally, I think we should make authentication more mandatory than > is currently described, but the WG needs to reach such a consensus. If > we keep the optional authentication(s), then the WG should justify in > the document why it makes "protocol sense" for the authentication(s) > to be optional. >=20 > The WG needs to develop the table showing how the various > authentication options mitigate threats, especially MITM threats, and > we should have text that describes this as well. >=20 > Please work with Miao to address these issues. >=20 > Thanks, > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG >=20 >=20 > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Wednesday, January 31, 2007 12:53 PM > > To: Miao Fuyou; 'Sam Hartman'; syslog@ietf.org > > Subject: Relays was Re: [Syslog] AD Review for > > draft-ietf-syslog-transport-tls > > > > > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Miao Fuyou" > > To: "'Sam Hartman'" ; > > Sent: Wednesday, January 31, 2007 5:50 AM > > Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > > > Hi Sam, > > > > > > Thanks for the review! My response is inline. > > > > > > Regards, > > > Miao > > > > > > > -----Original Message----- > > > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > > > Sent: Wednesday, January 31, 2007 7:23 AM > > > > To: syslog@ietf.org > > > > Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > > > > > > Hi, folks. I had no comments on the UDP draft or the main > > > > protocol draft so I have forwarded them to IETF last call. > > > > > > > > I do have some concerns with the TLS draft. > > > > > > > > > > > > > > > > Are senders and relays required to have a certificate and to > > > > use that certificate? > > > > > > > > > > It is not required, but it is preferrable for some deployment > where > > > malicious senders may send lots of messages to overwhelm > > the receiver. > > > > > Sam > > > > I have a slightly different view. To quote the I-D, where it says > > "The sender/relay should initiate a connection to the receiver" > > I take that as the sender initiates a connection to the > > receiver if no relay is > > present or to the relay (when present), the relay (when > > present) initiates the > > connection to the receiver (collector). Relay and receiver > > become TLS Servers > > and insofar as TLS Servers have certificates, the relay will have > one! > > > > When the next paragraph says > > "When a sender/ relay authenticates a receiver it MUST > > validate the certificate" > > I take that to mean that the sender authenticates the > > receiver if no relay is > > present or the sender authenticates the relay (when present) > > and the relay > > authenticates the receiver. > > > > relay and sender are TLS clients. > > > > I appreciate that this is hop by hop security and not ideal > > end to end security. > > > > Tom Petch > > > > --Sam > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 11:40:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6sq-0005ph-12; Mon, 05 Feb 2007 11:40:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6so-0005pa-Kr for syslog@ietf.org; Mon, 05 Feb 2007 11:39:58 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE6sn-00066N-Ci for syslog@ietf.org; Mon, 05 Feb 2007 11:39:58 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BB472E00B3; Mon, 5 Feb 2007 11:39:56 -0500 (EST) From: Sam Hartman To: "Rainer Gerhards" Subject: Re: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls References: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com> <031d01c74560$cebe3f60$0601a8c0@pc6> <0c2701c74940$9a745bc0$0600a8c0@china.huawei.com> <577465F99B41C842AAFBE9ED71E70ABA1F8DD5@grfint2.intern.adiscon.com> Date: Mon, 05 Feb 2007 11:39:56 -0500 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8DD5@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Mon, 5 Feb 2007 17:32:11 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) 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 >>>>> "Rainer" == Rainer Gerhards writes: Rainer> So I would not like to see client and server Rainer> authentication to be a MUST. Well ... a MUST for an Rainer> implementation to have that capability would be OK. But an Rainer> admin must be capable to configure sender and/or receiver Rainer> to work without authentication. No matter what we specify Rainer> in -protocol, that capability will be available in all Rainer> implementations that I foresee. IMHO an uncoditional MUST Rainer> would create a false sense of security ... and the most Rainer> insecure thing is false sense of security. I'm not asking for mandatory authentication for all the reasons you cite. What I'm asking for is 1) Mandatory behavior such that all implementations can work together. This includes things like if authentication is going to be optional to implement, then there must be an option not to require it. 2) A description of what the possibilities are for authentication and what security properties you actually get based on what options you select when you deploy syslog. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 12:01:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Do-0008WG-Ji; Mon, 05 Feb 2007 12:01:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Dn-0008W1-Gk for syslog@ietf.org; Mon, 05 Feb 2007 12:01:39 -0500 Received: from ext-nj2ut-10.online-age.net ([64.14.54.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7Dm-0001e3-03 for syslog@ietf.org; Mon, 05 Feb 2007 12:01:39 -0500 Received: from int-nj2ut-3.online-age.net (int-nj2ut-3.online-age.net [3.159.237.72]) by ext-nj2ut-10.online-age.net (8.13.6/8.13.6/20051114-SVVS-TLS-DNSBL) with ESMTP id l15H1bha008369 for ; Mon, 5 Feb 2007 12:01:37 -0500 Received: from cinmlef07.e2k.ad.ge.com (int-nj2ut-3.online-age.net [3.159.237.72]) by int-nj2ut-3.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP id l15H1Z0q030475 for ; Mon, 5 Feb 2007 12:01:36 -0500 Received: from ALPMLVEM07.e2k.ad.ge.com ([3.159.17.65]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 5 Feb 2007 11:57:28 -0500 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: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls Date: Mon, 5 Feb 2007 11:57:14 -0500 Message-ID: In-Reply-To: <0c2701c74940$9a745bc0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls Thread-Index: AcdFaW3WNbqR4F+cTSmg9ESbMza7XwD0Xh4gAALjhTA= References: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com><031d01c74560$cebe3f60$0601a8c0@pc6> <0c2701c74940$9a745bc0$0600a8c0@china.huawei.com> From: "Moehrke, John \(GE Healthcare\)" To: "David Harrington" , "tom.petch" , "Miao Fuyou" , "Sam Hartman" , X-OriginalArrivalTime: 05 Feb 2007 16:57:28.0921 (UTC) FILETIME=[B8235490:01C74946] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 would recommend against constraining the key management in -tls-. This is a POLICY decision, not a protocol decision. (as highlighted by RFC4107) John=20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Monday, February 05, 2007 10:14 AM > To: 'tom.petch'; 'Miao Fuyou'; 'Sam Hartman'; syslog@ietf.org > Subject: RE: Relays was Re: [Syslog] AD Review=20 > fordraft-ietf-syslog-transport-tls >=20 > Hi WG, >=20 > [speaking as co-chair] >=20 > As co-chair, I will need to advise Miao to remove support for generic > certificates unless there is overwhelming WG consensus to keep them, > and the explanation of why reuse of private keys is necessary will > need to be compelling. Please read RFC4107 (which is short). >=20 > There are ambiguities in the TLS document regarding who MUST > authenticate that will need to be tightened up. As the email from Tom > reflects, part of the problem is the ambiguity in the definition of > relay; I think it needs to be made clearer in the -protocol- document > that a relay is a receiver and is a sender, and clearer in the -tls- > document that authentication is hop-by-hop.=20 >=20 > Personally, I think we should make authentication more mandatory than > is currently described, but the WG needs to reach such a consensus. If > we keep the optional authentication(s), then the WG should justify in > the document why it makes "protocol sense" for the authentication(s) > to be optional. >=20 > The WG needs to develop the table showing how the various > authentication options mitigate threats, especially MITM threats, and > we should have text that describes this as well. >=20 > Please work with Miao to address these issues. >=20 > Thanks, > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG=20 >=20 >=20 > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com]=20 > > Sent: Wednesday, January 31, 2007 12:53 PM > > To: Miao Fuyou; 'Sam Hartman'; syslog@ietf.org > > Subject: Relays was Re: [Syslog] AD Review for=20 > > draft-ietf-syslog-transport-tls > >=20 > > > >=20 > > Tom Petch > >=20 > > ----- Original Message ----- > > From: "Miao Fuyou" > > To: "'Sam Hartman'" ; > > Sent: Wednesday, January 31, 2007 5:50 AM > > Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls > >=20 > > > Hi Sam, > > > > > > Thanks for the review! My response is inline. > > > > > > Regards, > > > Miao > > > > > > > -----Original Message----- > > > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > > > Sent: Wednesday, January 31, 2007 7:23 AM > > > > To: syslog@ietf.org > > > > Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > > > > > > Hi, folks. I had no comments on the UDP draft or the main > > > > protocol draft so I have forwarded them to IETF last call. > > > > > > > > I do have some concerns with the TLS draft. > > > > > > > > > > > > > > > > Are senders and relays required to have a certificate and to > > > > use that certificate? > > > > > > > > > > It is not required, but it is preferrable for some deployment > where > > > malicious senders may send lots of messages to overwhelm=20 > > the receiver. > > > > > Sam > >=20 > > I have a slightly different view. To quote the I-D, where it says > > "The sender/relay should initiate a connection to the receiver" > > I take that as the sender initiates a connection to the=20 > > receiver if no relay is > > present or to the relay (when present), the relay (when=20 > > present) initiates the > > connection to the receiver (collector). Relay and receiver=20 > > become TLS Servers > > and insofar as TLS Servers have certificates, the relay will have > one! > >=20 > > When the next paragraph says > > "When a sender/ relay authenticates a receiver it MUST=20 > > validate the certificate" > > I take that to mean that the sender authenticates the=20 > > receiver if no relay is > > present or the sender authenticates the relay (when present)=20 > > and the relay > > authenticates the receiver. > >=20 > > relay and sender are TLS clients. > >=20 > > I appreciate that this is hop by hop security and not ideal=20 > > end to end security. > >=20 > > Tom Petch > > > > --Sam > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 12:15:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7QZ-0007jn-K8; Mon, 05 Feb 2007 12:14:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7QY-0007jc-7X for syslog@ietf.org; Mon, 05 Feb 2007 12:14:50 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7QV-000414-RW for syslog@ietf.org; Mon, 05 Feb 2007 12:14:50 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007020517144701300sc6fde>; Mon, 5 Feb 2007 17:14:47 +0000 From: "David Harrington" To: "'Moehrke, John \(GE Healthcare\)'" , "'tom.petch'" , "'Miao Fuyou'" , "'Sam Hartman'" , References: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com><031d01c74560$cebe3f60$0601a8c0@pc6> <0c2701c74940$9a745bc0$0600a8c0@china.huawei.com> Subject: RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls Date: Mon, 5 Feb 2007 12:10:52 -0500 Message-ID: <0c2901c74948$975e6f90$0600a8c0@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.2962 In-reply-to: Thread-index: AcdFaW3WNbqR4F+cTSmg9ESbMza7XwD0Xh4gAALjhTAAADm1oA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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 believe this is a protocol decision only to the point of requiring that compliant implementations provide support for the functionality. I agree that whether operators choose to use it during deployment is a policy decision and not a protocol decision. I wonder why an operator would choose to use a TLS transport without authentication, rather than simply using a non-secure transport. dbh > -----Original Message----- > From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com] > Sent: Monday, February 05, 2007 11:57 AM > To: David Harrington; tom.petch; Miao Fuyou; Sam Hartman; > syslog@ietf.org > Subject: RE: Relays was Re: [Syslog] AD Review > fordraft-ietf-syslog-transport-tls > > I would recommend against constraining the key management in > -tls-. This > is a POLICY decision, not a protocol decision. (as highlighted by > RFC4107) > > John > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Monday, February 05, 2007 10:14 AM > > To: 'tom.petch'; 'Miao Fuyou'; 'Sam Hartman'; syslog@ietf.org > > Subject: RE: Relays was Re: [Syslog] AD Review > > fordraft-ietf-syslog-transport-tls > > > > Hi WG, > > > > [speaking as co-chair] > > > > As co-chair, I will need to advise Miao to remove support > for generic > > certificates unless there is overwhelming WG consensus to keep them, > > and the explanation of why reuse of private keys is necessary will > > need to be compelling. Please read RFC4107 (which is short). > > > > There are ambiguities in the TLS document regarding who MUST > > authenticate that will need to be tightened up. As the > email from Tom > > reflects, part of the problem is the ambiguity in the definition of > > relay; I think it needs to be made clearer in the > -protocol- document > > that a relay is a receiver and is a sender, and clearer in the -tls- > > document that authentication is hop-by-hop. > > > > Personally, I think we should make authentication more > mandatory than > > is currently described, but the WG needs to reach such a > consensus. If > > we keep the optional authentication(s), then the WG should > justify in > > the document why it makes "protocol sense" for the authentication(s) > > to be optional. > > > > The WG needs to develop the table showing how the various > > authentication options mitigate threats, especially MITM > threats, and > > we should have text that describes this as well. > > > > Please work with Miao to address these issues. > > > > Thanks, > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > co-chair, Syslog WG > > > > > > > -----Original Message----- > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > Sent: Wednesday, January 31, 2007 12:53 PM > > > To: Miao Fuyou; 'Sam Hartman'; syslog@ietf.org > > > Subject: Relays was Re: [Syslog] AD Review for > > > draft-ietf-syslog-transport-tls > > > > > > > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Miao Fuyou" > > > To: "'Sam Hartman'" ; > > > Sent: Wednesday, January 31, 2007 5:50 AM > > > Subject: RE: [Syslog] AD Review for > draft-ietf-syslog-transport-tls > > > > > > > Hi Sam, > > > > > > > > Thanks for the review! My response is inline. > > > > > > > > Regards, > > > > Miao > > > > > > > > > -----Original Message----- > > > > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > > > > Sent: Wednesday, January 31, 2007 7:23 AM > > > > > To: syslog@ietf.org > > > > > Subject: [Syslog] AD Review for > draft-ietf-syslog-transport-tls > > > > > > > > > > Hi, folks. I had no comments on the UDP draft or the main > > > > > protocol draft so I have forwarded them to IETF last call. > > > > > > > > > > I do have some concerns with the TLS draft. > > > > > > > > > > > > > > > > > > > > > Are senders and relays required to have a certificate and to > > > > > use that certificate? > > > > > > > > > > > > > It is not required, but it is preferrable for some deployment > > where > > > > malicious senders may send lots of messages to overwhelm > > > the receiver. > > > > > > > Sam > > > > > > I have a slightly different view. To quote the I-D, where it says > > > "The sender/relay should initiate a connection to the receiver" > > > I take that as the sender initiates a connection to the > > > receiver if no relay is > > > present or to the relay (when present), the relay (when > > > present) initiates the > > > connection to the receiver (collector). Relay and receiver > > > become TLS Servers > > > and insofar as TLS Servers have certificates, the relay will have > > one! > > > > > > When the next paragraph says > > > "When a sender/ relay authenticates a receiver it MUST > > > validate the certificate" > > > I take that to mean that the sender authenticates the > > > receiver if no relay is > > > present or the sender authenticates the relay (when present) > > > and the relay > > > authenticates the receiver. > > > > > > relay and sender are TLS clients. > > > > > > I appreciate that this is hop by hop security and not ideal > > > end to end security. > > > > > > Tom Petch > > > > > --Sam > > > > > > > > > > > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > Syslog@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > _______________________________________________ > > > 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 Mon Feb 05 12:26:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7bQ-0006h0-S6; Mon, 05 Feb 2007 12:26:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7bQ-0006gv-HG for syslog@ietf.org; Mon, 05 Feb 2007 12:26:04 -0500 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7bP-0005db-NT for syslog@ietf.org; Mon, 05 Feb 2007 12:26:04 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 6C2B09C00D; Mon, 5 Feb 2007 18:42:32 +0100 (CET) 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 09978-03; Mon, 5 Feb 2007 18:42:20 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id E69519C00B; Mon, 5 Feb 2007 18:42:20 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Relays was Re: [Syslog] AD Reviewfordraft-ietf-syslog-transport-tls X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 5 Feb 2007 18:25:44 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8DD7@grfint2.intern.adiscon.com> In-Reply-To: <0c2901c74948$975e6f90$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Relays was Re: [Syslog] AD Reviewfordraft-ietf-syslog-transport-tls Thread-Index: AcdFaW3WNbqR4F+cTSmg9ESbMza7XwD0Xh4gAALjhTAAADm1oAAAxUpw References: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com><031d01c74560$cebe3f60$0601a8c0@pc6><0c2701c74940$9a745bc0$0600a8c0@china.huawei.com> <0c2901c74948$975e6f90$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" , "Moehrke, John (GE Healthcare)" , "tom.petch" , "Miao Fuyou" , "Sam Hartman" , X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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 wonder why an operator would choose to use a TLS transport without > authentication, rather than simply using a non-secure transport. To prevent casual observation. In my experience, this is the primary driving force behing syslog/ssl deployments. And, yes, I agree we should educate operators to use authentication, too. Rainer >=20 > dbh >=20 > > -----Original Message----- > > From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com] >=20 > > Sent: Monday, February 05, 2007 11:57 AM > > To: David Harrington; tom.petch; Miao Fuyou; Sam Hartman; > > syslog@ietf.org > > Subject: RE: Relays was Re: [Syslog] AD Review > > fordraft-ietf-syslog-transport-tls > > > > I would recommend against constraining the key management in > > -tls-. This > > is a POLICY decision, not a protocol decision. (as highlighted by > > RFC4107) > > > > John > > > > > -----Original Message----- > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Monday, February 05, 2007 10:14 AM > > > To: 'tom.petch'; 'Miao Fuyou'; 'Sam Hartman'; syslog@ietf.org > > > Subject: RE: Relays was Re: [Syslog] AD Review > > > fordraft-ietf-syslog-transport-tls > > > > > > Hi WG, > > > > > > [speaking as co-chair] > > > > > > As co-chair, I will need to advise Miao to remove support > > for generic > > > certificates unless there is overwhelming WG consensus to keep > them, > > > and the explanation of why reuse of private keys is necessary will > > > need to be compelling. Please read RFC4107 (which is short). > > > > > > There are ambiguities in the TLS document regarding who MUST > > > authenticate that will need to be tightened up. As the > > email from Tom > > > reflects, part of the problem is the ambiguity in the definition > of > > > relay; I think it needs to be made clearer in the > > -protocol- document > > > that a relay is a receiver and is a sender, and clearer in the > -tls- > > > document that authentication is hop-by-hop. > > > > > > Personally, I think we should make authentication more > > mandatory than > > > is currently described, but the WG needs to reach such a > > consensus. If > > > we keep the optional authentication(s), then the WG should > > justify in > > > the document why it makes "protocol sense" for the > authentication(s) > > > to be optional. > > > > > > The WG needs to develop the table showing how the various > > > authentication options mitigate threats, especially MITM > > threats, and > > > we should have text that describes this as well. > > > > > > Please work with Miao to address these issues. > > > > > > Thanks, > > > David Harrington > > > dharrington@huawei.com > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > co-chair, Syslog WG > > > > > > > > > > -----Original Message----- > > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > > Sent: Wednesday, January 31, 2007 12:53 PM > > > > To: Miao Fuyou; 'Sam Hartman'; syslog@ietf.org > > > > Subject: Relays was Re: [Syslog] AD Review for > > > > draft-ietf-syslog-transport-tls > > > > > > > > > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "Miao Fuyou" > > > > To: "'Sam Hartman'" ; > > > > Sent: Wednesday, January 31, 2007 5:50 AM > > > > Subject: RE: [Syslog] AD Review for > > draft-ietf-syslog-transport-tls > > > > > > > > > Hi Sam, > > > > > > > > > > Thanks for the review! My response is inline. > > > > > > > > > > Regards, > > > > > Miao > > > > > > > > > > > -----Original Message----- > > > > > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > > > > > Sent: Wednesday, January 31, 2007 7:23 AM > > > > > > To: syslog@ietf.org > > > > > > Subject: [Syslog] AD Review for > > draft-ietf-syslog-transport-tls > > > > > > > > > > > > Hi, folks. I had no comments on the UDP draft or the main > > > > > > protocol draft so I have forwarded them to IETF last call. > > > > > > > > > > > > I do have some concerns with the TLS draft. > > > > > > > > > > > > > > > > > > > > > > > > > > Are senders and relays required to have a certificate and to > > > > > > use that certificate? > > > > > > > > > > > > > > > > It is not required, but it is preferrable for some deployment > > > where > > > > > malicious senders may send lots of messages to overwhelm > > > > the receiver. > > > > > > > > > Sam > > > > > > > > I have a slightly different view. To quote the I-D, where it > says > > > > "The sender/relay should initiate a connection to the receiver" > > > > I take that as the sender initiates a connection to the > > > > receiver if no relay is > > > > present or to the relay (when present), the relay (when > > > > present) initiates the > > > > connection to the receiver (collector). Relay and receiver > > > > become TLS Servers > > > > and insofar as TLS Servers have certificates, the relay will > have > > > one! > > > > > > > > When the next paragraph says > > > > "When a sender/ relay authenticates a receiver it MUST > > > > validate the certificate" > > > > I take that to mean that the sender authenticates the > > > > receiver if no relay is > > > > present or the sender authenticates the relay (when present) > > > > and the relay > > > > authenticates the receiver. > > > > > > > > relay and sender are TLS clients. > > > > > > > > I appreciate that this is hop by hop security and not ideal > > > > end to end security. > > > > > > > > Tom Petch > > > > > > --Sam > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Syslog mailing list > > > > > > Syslog@lists.ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > Syslog@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > >=20 >=20 >=20 > _______________________________________________ > 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 Feb 05 12:46:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7vV-0000Dw-OO; Mon, 05 Feb 2007 12:46:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7vU-0000Do-A5 for syslog@ietf.org; Mon, 05 Feb 2007 12:46:48 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7vS-0001Km-Rv for syslog@ietf.org; Mon, 05 Feb 2007 12:46:48 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007020517464601400htmb0e>; Mon, 5 Feb 2007 17:46:46 +0000 From: "David Harrington" To: "'tom.petch'" References: <03e001c73b6f$7072f860$0600a8c0@china.huawei.com><45C299AE.2070102@cysols.com> <0a8a01c746f7$d558edf0$0600a8c0@china.huawei.com> <001801c74911$107938c0$0601a8c0@pc6> Subject: RE: senders and receivers nothing to do with Mibs was Re: [Syslog] Mib-13 Date: Mon, 5 Feb 2007 12:42:40 -0500 Message-ID: <0c2e01c7494d$0ef560a0$0600a8c0@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.2962 In-reply-to: <001801c74911$107938c0$0601a8c0@pc6> Thread-index: AcdJGaaD5wMB/qMDRj6YLZQTOaNDcAALsLug X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 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, [speaking as a contributor] My main concern is that if we are going to use three terms or four, then we need to make it clear which roles are responsible for incrementing counters regarding received messages, and for incrementing counters regarding sent messages. As currently written, only receivers (and not relays or collectors) increment the counters regarding received messages, and only senders (not relays) increment the counters regarding sent messages. Our definitions are missing the crucial info about which roles are senders and which are receivers; the description in your email does include this info: > sender sends, device or relay > receiver receives, relay or collector But Glenn's email says this: > We basically have syslog senders and syslog > receivers. A syslog relay is a special case - it "forwards some of the > received syslog messages to other syslog entities." Should a relay be incrementing the counters for received messages? Should a collector be incrementing the counters for received messages? Does a relay "forward" a syslog message by **sending** it to other syslog "entities"? Should a relay be incrementing the counters for sent messages? The answers to these questions are ambiguous given the current text in the protocol and in the mib documents. I don't care which way we modify the text to resolve the ambiguity; I care that we DO resolve the ambiguity. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Monday, February 05, 2007 5:32 AM > To: David Harrington > Cc: 'Glenn M. Keeni'; syslog@ietf.org > Subject: senders and receivers nothing to do with Mibs was > Re: [Syslog] Mib-13 > > David > > I disagree with you here. I think that we should use four > terms, sender, > receiver, relay, collector. > > RFC3164 I find very clear. > > collector receives and does not forward > relay receives and forwards > > -protocol started off life with identical definitions but by > -10, two key > phrases had vanished leaving > > sender sends, > receiver receives, > > which would be ambiguous except that further down it says > " Senders send messages to receivers with no knowledge of > whether they are > collectors or relays" > which again I find very clear - receiver receives, relay or collector. > > So while the present text is not as clear as it used to be, I > still believe that > what we are saying is what we always have said, namely > > collector receives and does not forward > relay receives and forwards > sender sends, device or relay > receiver receives, relay or collector > > and I see this implicitly endorsed in the documentation of > other bodies; > collector, in particular, I see used, if not as precisely > defined as we used to. > > So, I conclude that we have four well-defined terms, in use > for many years, and > need a good reason to change them. Of course we could do > things differently, > but at the risk of confusing those who have not followed this WG. > > Tom Petch > > ----- Original Message ----- > From: "David Harrington" > To: "'Glenn M. Keeni'" ; > Sent: Friday, February 02, 2007 7:27 PM > Subject: RE: [Syslog] Mib-13 > > > > Hi Glenn, > > > > Some comments. > > > > First let me start out by noting that MIB modules are frequently > > implemented by junior developers, since the senior developers don't > > want to waste their time working on management stuff; they > want to go > > design new hardware and new protocols. So the implementer > of a syslog > > MIB module may not have much experience with syslog. > > > > As a result, it is important to be unambiguous in our terminology. > > This is especially true when describing what should be counted in a > > counter. This is a common problem in MIB module implementations - > > different implementations interpret the instructions slightly > > differently, and end up counting slightly different things, and as a > > result, the counters cannot be interpreted in an interoperable way > > across implementations. > > > > Protocol says there are three application types - senders, > receivers, > > and relays. -protocol- does NOT say that a relay is a > special case and > > that a relay IS a receiver and IS a sender: > > > > Per the protocol document: > > > > o A syslog application that can generate a syslog > message is > > > > called a "sender". > > > > > > > > o A syslog application that can receive a syslog message is > > > > called a "receiver". > > > > > > > > o A syslog application that can receive syslog messages and > > > > forward them to another receiver is called a "relay". > > > > > > > > Here's where ambiguity comes in as the result of terminology > > differences between -protocol- and -mib-. > > > > You know and I know that a relay really both recieves and > sends and it > > does some stuff in between, but protocol does not say that > a relay is > > both a receiver and a sender, and nothing says that when counting > > things, a relay should count things relevant to a receiver AND > > relevant to a sender. > > > > SyslogRoles is not clear on this point: If I am a relay, > then do I set > > all three bits ON (sender, receiver, relay) or do I only > set the relay > > BIT ON? > > > > Malformed says "The number of messages received by the syslog > > receiver which had malformed header. > > If this syslog entity is not a syslog receiver > > the this object will have a zero value.", > > Well, if I am a relay am I also a reciever? Protocol does not say > > that! In fact, protocol says there are three types of > applications, so > > if I am a relay then I can interpret this to mean I am not a > > "reciever" and I am not a "sender"; I am a "relay". Therefore, as a > > relay, I should not count malformed headers, because only receivers > > should count malformed headers. > > > > Am I just thick? No. I fully understand that a relay both > receives and > > sends; but the text in our specififcations does not say that this > > means a relay is both a "receiver" and a "sender". I am an > experienced > > MIB Doctor that has dealt with this same type of ambiguity > in WG after > > WG, where the WG members understand, but they are sloppy in > their MIB > > module specification work. > > > > We have an ambiguity: Does the Malformed counter include malformed > > headers received by a relay or not? This can be interpreted > as "relays > > should not count malformed headers that it receives; only receivers > > should count them." I think that would be a bad interpretation, but > > the ambiguity of the terminology allows for this interpretation. We > > need to modify the text so that such an interpretation is > not allowed. > > I recommend changing the text to: > > "The number of messages received by the syslog > > receiver or relay which had malformed header. > > If this syslog entity is not a syslog receiver > > or relay the this object will have a zero value." > > This way, whether the implementer interprets the terminology > > differences to be "I am a relay therefore I am NOT a receiver" or "I > > am a relay therefore I AM a receiver" makes no difference. > > > > An alternative is to change the protocol document to be clear that > > there are only two basic types of application- a sender and a > > receiver, and the relay is a special case that is both a > receiver and > > a sender plus other stuff. Right now the protocol document > definitions > > do not state that clearly. > > > > (also note the "the this" s/b "then this" > > (also note "had malformed" s/b "had a malformed") > > > > > > > > 8. > > > >8) Malformed - The WG distinguishes between receivers > and relays; > > > >should we have both receivers and relays count > malformed headers? > > > > > > I recommend that we do not. I would say that the > administrator is > > > interested in knowing that his/her syslog is receiving too many > > > malformed messages. The administrator is less interested in > > knowing > > > whether the malformed message was meant for local consumption or > > for > > > forwarding. (I am not saying that the information is useless. We > > are > > > trying to look at the cost benefits.) > > > > I think you misinterpreted me here. I was not suggesting > two separate > > counters, one for receivers and one for relays; I am trying to make > > sure the relays also increment this counter when they receive a > > malformed header. > > > > > > > > dbh > > > > > > _______________________________________________ > > > 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 Mon Feb 05 13:10:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8Hx-00035G-S1; Mon, 05 Feb 2007 13:10:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8Hw-000351-VI for syslog@ietf.org; Mon, 05 Feb 2007 13:10:00 -0500 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE8Hu-0004uh-Ht for syslog@ietf.org; Mon, 05 Feb 2007 13:10:00 -0500 Received: from pc6 (1Cust67.tnt10.lnd4.gbr.da.uu.net [62.188.139.67]) by galaxy.systems.pipex.net (Postfix) with SMTP id 5E4A3E00023C; Mon, 5 Feb 2007 18:09:56 +0000 (GMT) Message-ID: <003301c74948$435eaea0$0601a8c0@pc6> From: "tom.petch" To: "Sam Hartman" , "David Harrington" References: <577465F99B41C842AAFBE9ED71E70ABA1F8D3C@grfint2.intern.adiscon.com><028d01c74612$9b144120$0601a8c0@pc6> <08ef01c7461f$d598cd40$0600a8c0@china.huawei.com> Subject: Re: [Syslog] An early last call comment on protocol-19 Date: Mon, 5 Feb 2007 17:15:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Tom Petch ----- Original Message ----- From: "Sam Hartman" To: "David Harrington" Cc: "'tom.petch'" ; Sent: Thursday, February 01, 2007 7:43 PM Subject: Re: [Syslog] An early last call comment on protocol-19 > >>>>> "David" == David Harrington writes: > > David> Hi WG, If ISO is a subset of what is covered by BCP047, > David> then would it be acceptable to REQUIRE the ISO subset > David> mandatory-to-implement-for-compliance for interoperability > David> purposes, and implementations MAY support other languages > David> in BCP047 with no assurance of interoperability with > David> standard-compliant implementations? > > No, I'd really need a fairly strong justification that went through > the languages you were not supporting and explained why that was > appropriate for syslog. > > BCP 47 is by definition the IETF's best current practice for language > tagging. Absent a compelling reason to do something else, you should > identify languages that way. Tom has not (so far) presented a > compelling reason. > Pity, I had hoped that David's compromise would be acceptable. RFC4646 (the current BCP0047) is a magnificent piece of work and does enable the generator of text to specify quite precisely how it should be interpreted. I love the differentiation between the dotted letter I of Azerbaijan and Turkey, in fact all the comments about Azerbaijani, Mongolian and Icelandic. What concerns me is conformance, what does it mean that a parameter MUST conform to this BCP or any other, an issue that has surfaced on this list before. If we just changed the reference so that the I-D were to read "it MUST contain a two letter language identifier as defined in BCP0047 [13}" then I have no problem but this does rather negate the intent of the BCP. The BCP defines two levels of conformance (s.2.2.9) and I suspect that even the lower level requires online access to the IANA website so what does a receiver of a syslog message do? Take it as an opaque character string? Check the ABNF? Do as RFC4646 specifies, for well-formed or validating conformance? I suggest anyone considering this question look at the current online registry as well as RFC4646, and note such comments as '"en-a-bbb-a-ccc" is invalid' whereas 'the tag "en-a-bbb-x-a-ccc"' is valid; or "sl-IT-nedis" is suitable but "it-IT-nedis" is not. It is beautiful. The issue I see is conformance. What can we expect the recipient of a syslog message to do without placing a significant burden thereon? Note too that RFC4646 defines a character string so we also have to specify an encoding thereof, another issue that has surfaced on this list before. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 13:18:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8Po-0000ry-MF; Mon, 05 Feb 2007 13:18:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8Pn-0000rR-BN for syslog@ietf.org; Mon, 05 Feb 2007 13:18:07 -0500 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE8Pm-0006NF-4Q for syslog@ietf.org; Mon, 05 Feb 2007 13:18:07 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9AA48E00B3; Mon, 5 Feb 2007 13:18:03 -0500 (EST) From: Sam Hartman To: "tom.petch" Subject: Re: [Syslog] An early last call comment on protocol-19 References: <577465F99B41C842AAFBE9ED71E70ABA1F8D3C@grfint2.intern.adiscon.com> <028d01c74612$9b144120$0601a8c0@pc6> <08ef01c7461f$d598cd40$0600a8c0@china.huawei.com> <003301c74948$435eaea0$0601a8c0@pc6> Date: Mon, 05 Feb 2007 13:18:03 -0500 In-Reply-To: <003301c74948$435eaea0$0601a8c0@pc6> (tom petch's message of "Mon, 5 Feb 2007 17:15:26 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 >>>>> "tom" == tom petch writes: tom> Pity, I had hoped that David's compromise would be tom> acceptable. RFC4646 (the current BCP0047) is a magnificent tom> piece of work and does enable the generator of text to tom> specify quite precisely how it should be interpreted. I love tom> the differentiation between the dotted letter I of Azerbaijan tom> and Turkey, in fact all the comments about Azerbaijani, tom> Mongolian and Icelandic. tom> What concerns me is conformance, what does it mean that a tom> parameter MUST conform to this BCP or any other, an issue tom> that has surfaced on this list before. If we just changed tom> the reference so that the I-D were to read "it MUST contain a tom> two letter language identifier as defined in BCP0047 [13}" tom> then I have no problem but this does rather negate the intent tom> of the BCP. First you need to remove the two-letter restriction; language tags can be longer than two letters, but besides that, this is exactly what I think you should do. tom> The BCP defines two levels of conformance (s.2.2.9) and I tom> suspect that even the lower level requires online access to tom> the IANA website so what does a receiver of a syslog message tom> do? Take it as an opaque character string? Check the ABNF? tom> Do as RFC4646 specifies, for well-formed or validating tom> conformance? The lower level (well-formed) does not require online access to the registry. Imho for syslog, receivers MAY|SHOULD check that a tag is well-formed. That's probably best as a MAY. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 13:21:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8SU-0001kn-T6; Mon, 05 Feb 2007 13:20:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8ST-0001kJ-0V for syslog@ietf.org; Mon, 05 Feb 2007 13:20:53 -0500 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE8SR-0007BD-Qq for syslog@ietf.org; Mon, 05 Feb 2007 13:20:52 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0DE95E00B3; Mon, 5 Feb 2007 13:20:42 -0500 (EST) From: Sam Hartman To: "Moehrke, John (GE Healthcare)" Subject: Re: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls References: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com> <031d01c74560$cebe3f60$0601a8c0@pc6> <0c2701c74940$9a745bc0$0600a8c0@china.huawei.com> Date: Mon, 05 Feb 2007 13:20:42 -0500 In-Reply-To: (John Moehrke's message of "Mon, 5 Feb 2007 11:57:14 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 >>>>> "Moehrke," == Moehrke, John (GE Healthcare) writes: Moehrke,> I would recommend against constraining the key Moehrke,> management in -tls-. This is a POLICY decision, not a Moehrke,> protocol decision. (as highlighted by RFC4107) I'm not sure I disagree with your recommendation although I do disagree with the claim that RFC 4107 treats key management as a policy rather than a protocol matter. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 13:24:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8Vr-0002rW-4Q; Mon, 05 Feb 2007 13:24:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8Vp-0002qn-VI for syslog@ietf.org; Mon, 05 Feb 2007 13:24:21 -0500 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE8Vo-0007xJ-PS for syslog@ietf.org; Mon, 05 Feb 2007 13:24:21 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D5E11E00B3; Mon, 5 Feb 2007 13:24:10 -0500 (EST) From: Sam Hartman To: "Rainer Gerhards" Subject: Re: Relays was Re: [Syslog] AD Reviewfordraft-ietf-syslog-transport-tls References: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com> <031d01c74560$cebe3f60$0601a8c0@pc6> <0c2701c74940$9a745bc0$0600a8c0@china.huawei.com> <0c2901c74948$975e6f90$0600a8c0@china.huawei.com> <577465F99B41C842AAFBE9ED71E70ABA1F8DD7@grfint2.intern.adiscon.com> Date: Mon, 05 Feb 2007 13:24:10 -0500 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8DD7@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Mon, 5 Feb 2007 18:25:44 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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" == Rainer Gerhards writes: >> I wonder why an operator would choose to use a TLS transport >> without authentication, rather than simply using a non-secure >> transport. Rainer> To prevent casual observation. In my experience, this is Rainer> the primary driving force behing syslog/ssl Rainer> deployments. And, yes, I agree we should educate operators Rainer> to use authentication, too. Rainer> Rainer To be more specific, passive attackers cannot influence the integrity or confidentiality of messages. In addition, active attackers who do not attack existing connections are unaware of the contents of syslog messages that are sent. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 15:43:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEAfs-0004Nc-IG; Mon, 05 Feb 2007 15:42:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEAfq-0004LV-PX for syslog@ietf.org; Mon, 05 Feb 2007 15:42:50 -0500 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEAfo-0004rg-Ck for syslog@ietf.org; Mon, 05 Feb 2007 15:42:50 -0500 Received: from pc6 (1Cust49.tnt104.lnd4.gbr.da.uu.net [213.116.56.49]) by galaxy.systems.pipex.net (Postfix) with SMTP id 04BF1E0007C4; Mon, 5 Feb 2007 20:42:45 +0000 (GMT) Message-ID: <026201c7495d$9cefdce0$0601a8c0@pc6> From: "tom.petch" To: "Sam Hartman" References: <577465F99B41C842AAFBE9ED71E70ABA1F8D3C@grfint2.intern.adiscon.com><028d01c74612$9b144120$0601a8c0@pc6> <08ef01c7461f$d598cd40$0600a8c0@china.huawei.com> <003301c74948$435eaea0$0601a8c0@pc6> Subject: Re: [Syslog] An early last call comment on protocol-19 Date: Mon, 5 Feb 2007 20:40:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Tom Petch ----- Original Message ----- From: "Sam Hartman" To: "tom.petch" Cc: "David Harrington" ; Sent: Monday, February 05, 2007 7:18 PM Subject: Re: [Syslog] An early last call comment on protocol-19 > >>>>> "tom" == tom petch writes: > > tom> Pity, I had hoped that David's compromise would be > tom> acceptable. RFC4646 (the current BCP0047) is a magnificent > tom> piece of work and does enable the generator of text to > tom> specify quite precisely how it should be interpreted. I love > tom> the differentiation between the dotted letter I of Azerbaijan > tom> and Turkey, in fact all the comments about Azerbaijani, > tom> Mongolian and Icelandic. > > tom> What concerns me is conformance, what does it mean that a > tom> parameter MUST conform to this BCP or any other, an issue > tom> that has surfaced on this list before. If we just changed > tom> the reference so that the I-D were to read "it MUST contain a > tom> two letter language identifier as defined in BCP0047 [13}" > tom> then I have no problem but this does rather negate the intent > tom> of the BCP. > > First you need to remove the two-letter restriction; language tags can be longer than two letters, > but besides that, this is exactly what I think you should do. > > tom> The BCP defines two levels of conformance (s.2.2.9) and I > tom> suspect that even the lower level requires online access to > tom> the IANA website so what does a receiver of a syslog message > tom> do? Take it as an opaque character string? Check the ABNF? > tom> Do as RFC4646 specifies, for well-formed or validating > tom> conformance? > > The lower level (well-formed) does not require online access to the registry. > > Imho for syslog, receivers MAY|SHOULD check that a tag is well-formed. > That's probably best as a MAY. Specifying in -protocol 'MAY check that a tag is well-formed' would allay my concerns. We still need to think about the encoding (which RFC4646 pointedly excludes). At first sight, the existing text and ABNF about parameter values is unaffected (UTF-8 plus escaping for PARAM-VALUE) Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 16:45:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBdr-0003Yf-Ol; Mon, 05 Feb 2007 16:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBdq-0003VT-BY for syslog@ietf.org; Mon, 05 Feb 2007 16:44:50 -0500 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEBdn-0000eV-5M for syslog@ietf.org; Mon, 05 Feb 2007 16:44:50 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 59380E00B3; Mon, 5 Feb 2007 16:44:37 -0500 (EST) From: Sam Hartman To: "tom.petch" Subject: Re: [Syslog] An early last call comment on protocol-19 References: <577465F99B41C842AAFBE9ED71E70ABA1F8D3C@grfint2.intern.adiscon.com> <028d01c74612$9b144120$0601a8c0@pc6> <08ef01c7461f$d598cd40$0600a8c0@china.huawei.com> <003301c74948$435eaea0$0601a8c0@pc6> <026201c7495d$9cefdce0$0601a8c0@pc6> Date: Mon, 05 Feb 2007 16:44:37 -0500 In-Reply-To: <026201c7495d$9cefdce0$0601a8c0@pc6> (tom petch's message of "Mon, 5 Feb 2007 20:40:26 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 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 What part of 4646 allows non-ASCII characters? How is encoding an issue? _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Feb 05 22:04:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEGc1-0005Kt-QO; Mon, 05 Feb 2007 22:03:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEGc0-0005IZ-Uk for syslog@ietf.org; Mon, 05 Feb 2007 22:03:16 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEGbv-0002YH-EY for syslog@ietf.org; Mon, 05 Feb 2007 22:03:16 -0500 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 <0JD000JT6TSA9J@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 06 Feb 2007 11:02:34 +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 <0JD000K8PTS8ZP@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 06 Feb 2007 11:02:33 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD00074YTS4NG@szxml03-in.huawei.com> for syslog@ietf.org; Tue, 06 Feb 2007 11:02:32 +0800 (CST) Date: Tue, 06 Feb 2007 11:02:28 +0800 From: Miao Fuyou Subject: RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA1F8DD5@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' , 'David Harrington' , "'tom.petch'" , 'Sam Hartman' , syslog@ietf.org Message-id: <001601c7499b$3ca71590$800c6f0a@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: AcdFaW3WNbqR4F+cTSmg9ESbMza7XwD0Xh4gAAG6hbAAFS3JUA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 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 think there are other things to consider to decide SHOULD or MUST an authentication:: 1, From deployment perspective, it is not very difficult to enable server authentication because the population of servers is usually not as many as that of clients, the certificates are only required to be created for the server rather than plenty of clients: printers, routers and hosts. So, I think server authentication is not a major reason for the operator to not deploy TLS. However, client authentication is highly possible the reason because the considerable effort for device certificate deployment. 2, If no authentication exists, it is possible for an adversary to launch a MITM attack when TLS connection initializes, it talks with server pretending to be client and client to server. In this case, no confidentiality and integrity is conserved. So, I would like server authenticaiton to be a MUST rather than SHOULD. For client authentication, it may be SHOULD, even MAY. Thanks, Miao > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Tuesday, February 06, 2007 12:32 AM > To: David Harrington; tom.petch; Miao Fuyou; Sam Hartman; > syslog@ietf.org > Subject: RE: Relays was Re: [Syslog] AD Review > fordraft-ietf-syslog-transport-tls > > David, > > let me start with the relays: given the recent discussion, I > think it would be much more advisible to add a few sentences > to -protocol (I already made a proposal) that clarifies the > situation. It is not much that needs to be added. It would > resolve all those other issues. > > Regarding generic certificates, I do not see an overwhelming > reason to have them (and I was one of them who liked them). I > agree with Sam that there can be placed unique certificates > on the device during the manufacturing process. Another > story, however, is the need to authenticate/verify a device. > Without any doubt, there is more than one scenario where > authentication based on the device is mandatory. > > However, syslog is also often deployed in (low end) scenarios > where the > (part-time) operator is simply interested receiving log > messages from his 5 or so routers. This admin is often not > very knowledgable. If we now require that admin to either > > a) configure access rules for all (though few) devices or > b) use unencrypted UDP syslog > > I am sure many of these admins will resort to b) because a) > requires too much learning. In the essence, strong > security/authentication would bring us less real-world > security (pretty much the same thing with strong passwords > ... so strong that they are "stored" on post-it notes under > the keyboard). > > So I would not like to see client and server authentication > to be a MUST. Well ... a MUST for an implementation to have > that capability would be OK. But an admin must be capable to > configure sender and/or receiver to work without > authentication. No matter what we specify in -protocol, that > capability will be available in all implementations that I > foresee. IMHO an uncoditional MUST would create a false sense > of security ... and the most insecure thing is false sense of > security. > > Rainer > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Monday, February 05, 2007 5:14 PM > > To: 'tom.petch'; 'Miao Fuyou'; 'Sam Hartman'; syslog@ietf.org > > Subject: RE: Relays was Re: [Syslog] AD Review > fordraft-ietf-syslog- > > transport-tls > > > > Hi WG, > > > > [speaking as co-chair] > > > > As co-chair, I will need to advise Miao to remove support > for generic > > certificates unless there is overwhelming WG consensus to > keep them, > > and the explanation of why reuse of private keys is necessary will > > need to be compelling. Please read RFC4107 (which is short). > > > > There are ambiguities in the TLS document regarding who MUST > > authenticate that will need to be tightened up. As the > email from Tom > > reflects, part of the problem is the ambiguity in the definition of > > relay; I think it needs to be made clearer in the > -protocol- document > > that a relay is a receiver and is a sender, and clearer in > the -tls- > > document that authentication is hop-by-hop. > > > > Personally, I think we should make authentication more > mandatory than > > is currently described, but the WG needs to reach such a > consensus. If > > we keep the optional authentication(s), then the WG should > justify in > > the document why it makes "protocol sense" for the > authentication(s) > > to be optional. > > > > The WG needs to develop the table showing how the various > > authentication options mitigate threats, especially MITM > threats, and > > we should have text that describes this as well. > > > > Please work with Miao to address these issues. > > > > Thanks, > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > co-chair, Syslog WG > > > > > > > -----Original Message----- > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > Sent: Wednesday, January 31, 2007 12:53 PM > > > To: Miao Fuyou; 'Sam Hartman'; syslog@ietf.org > > > Subject: Relays was Re: [Syslog] AD Review for > > > draft-ietf-syslog-transport-tls > > > > > > > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Miao Fuyou" > > > To: "'Sam Hartman'" ; > > > Sent: Wednesday, January 31, 2007 5:50 AM > > > Subject: RE: [Syslog] AD Review for > draft-ietf-syslog-transport-tls > > > > > > > Hi Sam, > > > > > > > > Thanks for the review! My response is inline. > > > > > > > > Regards, > > > > Miao > > > > > > > > > -----Original Message----- > > > > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > > > > Sent: Wednesday, January 31, 2007 7:23 AM > > > > > To: syslog@ietf.org > > > > > Subject: [Syslog] AD Review for > draft-ietf-syslog-transport-tls > > > > > > > > > > Hi, folks. I had no comments on the UDP draft or the main > > > > > protocol draft so I have forwarded them to IETF last call. > > > > > > > > > > I do have some concerns with the TLS draft. > > > > > > > > > > > > > > > > > > > > > Are senders and relays required to have a certificate > and to use > > > > > that certificate? > > > > > > > > > > > > > It is not required, but it is preferrable for some deployment > > where > > > > malicious senders may send lots of messages to overwhelm > > > the receiver. > > > > > > > Sam > > > > > > I have a slightly different view. To quote the I-D, > where it says > > > "The sender/relay should initiate a connection to the receiver" > > > I take that as the sender initiates a connection to the > receiver if > > > no relay is present or to the relay (when present), the > relay (when > > > present) initiates the > > > connection to the receiver (collector). Relay and > receiver become > > > TLS Servers and insofar as TLS Servers have certificates, > the relay > > > will have > > one! > > > > > > When the next paragraph says > > > "When a sender/ relay authenticates a receiver it MUST > validate the > > > certificate" > > > I take that to mean that the sender authenticates the > receiver if no > > > relay is present or the sender authenticates the relay (when > > > present) and the relay authenticates the receiver. > > > > > > relay and sender are TLS clients. > > > > > > I appreciate that this is hop by hop security and not > ideal end to > > > end security. > > > > > > Tom Petch > > > > > --Sam > > > > > > > > > > > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > Syslog@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > _______________________________________________ > > > 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 Mon Feb 05 23:48:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEIEk-0001Ql-3m; Mon, 05 Feb 2007 23:47:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEIEi-0001QH-Mx for syslog@ietf.org; Mon, 05 Feb 2007 23:47:20 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEIEh-0005ue-DW for syslog@ietf.org; Mon, 05 Feb 2007 23:47:20 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9EA29E00B3; Mon, 5 Feb 2007 23:47:01 -0500 (EST) From: Sam Hartman To: Miao Fuyou Subject: Re: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls References: <001601c7499b$3ca71590$800c6f0a@china.huawei.com> Date: Mon, 05 Feb 2007 23:47:01 -0500 In-Reply-To: <001601c7499b$3ca71590$800c6f0a@china.huawei.com> (Miao Fuyou's message of "Tue, 06 Feb 2007 11:02:28 +0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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" == Miao Fuyou writes: Miao> Hi, I think there are other things to consider to decide Miao> SHOULD or MUST an authentication:: Miao> 1, From deployment perspective, it is not very difficult to Miao> enable server authentication because the population of Miao> servers is usually not as many as that of clients, the Miao> certificates are only required to be created for the server Miao> rather than plenty of clients: printers, routers and Miao> hosts. So, I think server authentication is not a major Miao> reason for the operator to not deploy TLS. Keep in mind that if you deploy server authentication you need to configure all the clients with a trusted set of CAs. Miao> However, client Miao> authentication is highly possible the reason because the Miao> considerable effort for device certificate deployment. Miao> 2, If no authentication exists, it is possible for an Miao> adversary to launch a MITM attack when TLS connection Miao> initializes, it talks with server pretending to be client Miao> and client to server. In this case, no confidentiality and Miao> integrity is conserved. True. Miao> So, I would like server authenticaiton to be a MUST rather Miao> than SHOULD. For client authentication, it may be SHOULD, Miao> even MAY. So, you believe that observers seeing messages in transit and modifying those messages is a more important threat for syslog than attackers being able to inject fake messages or servers being unable to determine which device a message comes from? Also, please remember to structure your thoughts in terms of what options are mandatory to implement rather than what is mandatory to deploy. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Feb 06 03:43:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELuD-0004FI-7X; Tue, 06 Feb 2007 03:42:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HELuC-0004F6-EH for syslog@ietf.org; Tue, 06 Feb 2007 03:42:24 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HELuA-0004yQ-EY for syslog@ietf.org; Tue, 06 Feb 2007 03:42:24 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD100LL39CHJ8@szxga04-in.huawei.com> for syslog@ietf.org; Tue, 06 Feb 2007 16:38:41 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD1006659CHY6@szxga04-in.huawei.com> for syslog@ietf.org; Tue, 06 Feb 2007 16:38:41 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD1002C19CDRG@szxml03-in.huawei.com> for syslog@ietf.org; Tue, 06 Feb 2007 16:38:40 +0800 (CST) Date: Tue, 06 Feb 2007 16:38:37 +0800 From: Miao Fuyou Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls In-reply-to: To: 'Sam Hartman' Message-id: <002a01c749ca$32247520$800c6f0a@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: AcdFG09J1/2P/qkZQf+Rnc/hahwF9gErnwkA X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Sam, The following paragraphs are on how well different authentications address the security threats for syslog. Masquerade, modification and disclosure are identified in the draft as primary threats and message stream modification as secondary threat. Mutual Authentication: Masquerade: fully addressed Modification: fully addressed Disclosure: fully addressed Message Stream Modification: fully addressed Server Authenticaiton Only: Masquerade: partly addressed, the client is left without being authenticated Modification: fully addressed Disclosure: fully addressed Message Stream Modification: fully addressed No Authentication: Masquerade: not addessed Modification: not well addressed because of MITM Disclosure: not well addressed because of MITM Message Stream Modification: not well addressed because of MITM Thanks, Miao > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, January 31, 2007 5:37 PM > To: Miao Fuyou > Cc: syslog@ietf.org > Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > I'll get back to you on the generic certificates issue. For > now, I recommend you read RFC 4107. Also note that each > device needs a unique MAC address so the manufacturing > process tends to have a step for making a device unique. > > > > So, it sounds like all forms of authentication are optional > in this spec. > > You need a clear table describing what attacks are protected > against given each authentication choice. > > > Wording that table so that man-in-the-middle issues are dealt > with correctly and it is still informative will be tricky. > > --Sam > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Feb 06 06:22:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEONY-0008VW-1m; Tue, 06 Feb 2007 06:20:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEONW-0008UN-OZ for syslog@ietf.org; Tue, 06 Feb 2007 06:20:50 -0500 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEONU-000170-E4 for syslog@ietf.org; Tue, 06 Feb 2007 06:20:50 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id A010C9C00D; Tue, 6 Feb 2007 12:37:20 +0100 (CET) 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 11020-10; Tue, 6 Feb 2007 12:37:16 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id E1D2A9C00B; Tue, 6 Feb 2007 12:37:16 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 6 Feb 2007 12:20:41 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8DF3@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls Thread-Index: AcdJUHCSmClAv+q0Tk+mstR0Hx+dygAkDOCw References: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com><031d01c74560$cebe3f60$0601a8c0@pc6><0c2701c74940$9a745bc0$0600a8c0@china.huawei.com><577465F99B41C842AAFBE9ED71E70ABA1F8DD5@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Sam Hartman" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Sam, thanks for the clarification. > What I'm asking for is >=20 > 1) Mandatory behavior such that all implementations can work > together. This includes things like if authentication is going to > be optional to implement, then there must be an option not to > require it. I think it is no problem at all to mandate that implementations implement mutual authentication capabilities. It is a good thing and it is also trivial to do using the current libraries. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Feb 06 09:30:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERJr-0004Az-9j; Tue, 06 Feb 2007 09:29:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERJp-0004Al-Pm for syslog@ietf.org; Tue, 06 Feb 2007 09:29:13 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HERJm-0004lV-6P for syslog@ietf.org; Tue, 06 Feb 2007 09:29:13 -0500 Received: from pc6 (1Cust67.tnt28.lnd4.gbr.da.uu.net [62.188.156.67]) by blaster.systems.pipex.net (Postfix) with SMTP id 00A6EE00077A; Tue, 6 Feb 2007 14:29:05 +0000 (GMT) Message-ID: <017c01c749f2$945bb5a0$0601a8c0@pc6> From: "tom.petch" To: "Sam Hartman" , "Miao Fuyou" References: <001601c7499b$3ca71590$800c6f0a@china.huawei.com> Subject: Re: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls Date: Tue, 6 Feb 2007 11:33:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Tom Petch ----- Original Message ----- From: "Sam Hartman" To: "Miao Fuyou" Cc: "'Rainer Gerhards'" ; "'David Harrington'" ; "'tom.petch'" ; Sent: Tuesday, February 06, 2007 5:47 AM Subject: Re: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls > >>>>> "Miao" == Miao Fuyou writes: > > Miao> Hi, I think there are other things to consider to decide > Miao> SHOULD or MUST an authentication:: > > Miao> 1, From deployment perspective, it is not very difficult to > Miao> enable server authentication because the population of > Miao> servers is usually not as many as that of clients, the > Miao> certificates are only required to be created for the server > Miao> rather than plenty of clients: printers, routers and > Miao> hosts. So, I think server authentication is not a major > Miao> reason for the operator to not deploy TLS. > > Keep in mind that if you deploy server authentication you need to > configure all the clients with a trusted set of CAs. > > Miao> However, client > Miao> authentication is highly possible the reason because the > Miao> considerable effort for device certificate deployment. > > Miao> 2, If no authentication exists, it is possible for an > Miao> adversary to launch a MITM attack when TLS connection > Miao> initializes, it talks with server pretending to be client > Miao> and client to server. In this case, no confidentiality and > Miao> integrity is conserved. > > True. > > Miao> So, I would like server authenticaiton to be a MUST rather > Miao> than SHOULD. For client authentication, it may be SHOULD, > Miao> even MAY. > So, you believe that observers seeing messages in transit and > modifying those messages is a more important threat for syslog than > attackers being able to inject fake messages or servers being unable to determine which device a message comes from? > > Also, please remember to structure your thoughts in terms of what > options are mandatory to implement rather than what is mandatory to > deploy. > For me, it is message origin authentication that is the part of security that matters most; confidentiality is less an issue, although I know that there are others on this list for whom the reverse is true. One way I see of achieving this is to make the syslog Device the TLS server and the syslog Collector the TLS client. All syslog devices are given certificates but the role of checking their validity, of identifying trusted CAs, handling certificate chains etc falls on the syslog Collector, which I see as the more powerful engine, with better infrastructure, better able to perform these checks and to reject a TLS server certificate as and when it has doubts. After all, it is the syslog Collector that is misled by faked messages so I see no problem with making it do the work of authentication. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Feb 06 09:30:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERJr-0004Au-5i; Tue, 06 Feb 2007 09:29:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERJp-0004Ag-IK for syslog@ietf.org; Tue, 06 Feb 2007 09:29:13 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HERJo-0004lr-3N for syslog@ietf.org; Tue, 06 Feb 2007 09:29:13 -0500 Received: from pc6 (1Cust67.tnt28.lnd4.gbr.da.uu.net [62.188.156.67]) by blaster.systems.pipex.net (Postfix) with SMTP id E54B9E0001C7; Tue, 6 Feb 2007 14:29:09 +0000 (GMT) Message-ID: <017d01c749f2$954e5300$0601a8c0@pc6> From: "tom.petch" To: "Sam Hartman" References: <577465F99B41C842AAFBE9ED71E70ABA1F8D3C@grfint2.intern.adiscon.com><028d01c74612$9b144120$0601a8c0@pc6> <08ef01c7461f$d598cd40$0600a8c0@china.huawei.com> <003301c74948$435eaea0$0601a8c0@pc6> <026201c7495d$9cefdce0$0601a8c0@pc6> Subject: Re: [Syslog] An early last call comment on protocol-19 Date: Tue, 6 Feb 2007 11:58:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: "Sam Hartman" To: "tom.petch" Cc: "David Harrington" ; Sent: Monday, February 05, 2007 10:44 PM Subject: Re: [Syslog] An early last call comment on protocol-19 > What part of 4646 allows non-ASCII characters? How is encoding an > issue? Sam In section 3.1. " Format of the IANA Language Subtag Registry" it says " Characters from outside the US-ASCII [ISO646] repertoire, as well as the AMPERSAND character ("&", %x26) when it occurs in a field-body, are represented by a "Numeric Character Reference" using hexadecimal notation in the style used by [XML10" which suggests to me that characters outside the US-ASCII repertoire may occur in a language subtag. . This section does define the encoding within the IANA Language Subtag Registry but I do not see that as necessarily defining encodings to be used elsewhere and I see benefits in using UTF-8 in -protocol should encoding be needed. I am conscious that section 2.1 of RFC4646 says "Note that although [RFC4234] refers to octets, the language tags described in this document are sequences of characters from the US-ASCII [ISO646] repertoire. Language tags MAY be used in documents and applications that use other encodings, so long as these encompass the US-ASCII repertoire." which supports my view language tags are characters, not an encoding thereof. I cannot reconcile the reference in 2.1 to US-ASCII repertoire with 3.1 and its reference to encoding when outside the US-ASCII repertoire. I note that section 4.4. "Canonicalization of Language Tags" refers to "Case folding of ASCII letters in certain locales, unless carefully handled, sometimes produces non-ASCII character values." with the delightful example of "the letter 'i' (U+0069) in Turkish and Azerbaijani is uppercased to U+0130" so on balance, I think that characters outside the US-ASCII repertoire may occur. It may be that this is considered too low a probability to consider and that we limit the language subtags to ASCII, in which case, encoding is not an issue. I have checked draft-ietf-ltru-4646bis and the wording is unchanged there. As I said to start with, I do find RFC4646 magnificently powerful, perhaps too much so, in its entirety, for some use cases. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Feb 06 10:15:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HES2F-0002YL-Jf; Tue, 06 Feb 2007 10:15:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HES2E-0002Xj-2C for syslog@ietf.org; Tue, 06 Feb 2007 10:15:06 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HES2C-00062l-F2 for syslog@ietf.org; Tue, 06 Feb 2007 10:15:06 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3A9AEE00B3; Tue, 6 Feb 2007 10:14:45 -0500 (EST) From: Sam Hartman To: "tom.petch" Subject: Re: [Syslog] An early last call comment on protocol-19 References: <577465F99B41C842AAFBE9ED71E70ABA1F8D3C@grfint2.intern.adiscon.com> <028d01c74612$9b144120$0601a8c0@pc6> <08ef01c7461f$d598cd40$0600a8c0@china.huawei.com> <003301c74948$435eaea0$0601a8c0@pc6> <026201c7495d$9cefdce0$0601a8c0@pc6> <017d01c749f2$954e5300$0601a8c0@pc6> Date: Tue, 06 Feb 2007 10:14:45 -0500 In-Reply-To: <017d01c749f2$954e5300$0601a8c0@pc6> (tom petch's message of "Tue, 6 Feb 2007 11:58:47 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 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 The description of non-ascii characters in the registry refers to non-ascii characters in the description field, etc. The subtags are ascii. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Feb 06 10:39:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESOq-0003wZ-BN; Tue, 06 Feb 2007 10:38:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESOo-0003w0-Qz for syslog@ietf.org; Tue, 06 Feb 2007 10:38:26 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HESOn-0001Yr-Eq for syslog@ietf.org; Tue, 06 Feb 2007 10:38:26 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 34EC2E00B4; Tue, 6 Feb 2007 10:38:23 -0500 (EST) From: Sam Hartman To: "tom.petch" Subject: Re: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls References: <001601c7499b$3ca71590$800c6f0a@china.huawei.com> <017c01c749f2$945bb5a0$0601a8c0@pc6> Date: Tue, 06 Feb 2007 10:38:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 So, I shouldn't have asked my question and tom shouldn't have replied: the answer is in the charter. The threats that this WG will primarily address are modification, disclosure, and masquerading. A secondary threat is message stream modification. Threats that will not be addressed by this WG are DoS and traffic analysis. I knew there was a good reason I asked you guys to come up with that text before we started:-) So, Tom's proposal to focus on data origin authentication as the primary attack is out of charter. Also, the current TLS document seems to have inconsistent terminology with the charter. The charter seems to describe message stream modification as an end-to-end property solved by syslog-sign, while integrity is a hop-by-hop property. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Feb 06 10:55:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESfT-0003YZ-Dk; Tue, 06 Feb 2007 10:55:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESfS-0003YR-Du for syslog@ietf.org; Tue, 06 Feb 2007 10:55:38 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HESfR-0005gf-79 for syslog@ietf.org; Tue, 06 Feb 2007 10:55:38 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A7D0CE00B4; Tue, 6 Feb 2007 10:55:34 -0500 (EST) From: Sam Hartman To: Miao Fuyou Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls References: <002a01c749ca$32247520$800c6f0a@china.huawei.com> Date: Tue, 06 Feb 2007 10:55:34 -0500 In-Reply-To: <002a01c749ca$32247520$800c6f0a@china.huawei.com> (Miao Fuyou's message of "Tue, 06 Feb 2007 16:38:37 +0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 recommend that you drop message stream modification if my analysis [At this point, we're still figuring out what we want to say. I'm speaking as an individual not an AD.] of the charter is a correct analysis and we meant for that to apply to syslog-sign. I recommend you split out peer entity authentication as a separate service from integrity. And point out that by integrity, you mean that the sender knows that the data is not modified between the sender and the receiver; by peer entity authentication in this case we want to focus on whether the receiver knows who its peer is. So, perhaps we should cll that sender authentication. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 04:15:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEish-00024P-PC; Wed, 07 Feb 2007 04:14:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEisg-00024K-A8 for syslog@ietf.org; Wed, 07 Feb 2007 04:14:22 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEise-0002Im-P1 for syslog@ietf.org; Wed, 07 Feb 2007 04:14:22 -0500 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 <0JD3009IA5MR91@szxga01-in.huawei.com> for syslog@ietf.org; Wed, 07 Feb 2007 17:13:39 +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 <0JD300ELW5MQVH@szxga01-in.huawei.com> for syslog@ietf.org; Wed, 07 Feb 2007 17:13:38 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD30099A5MNFW@szxml04-in.huawei.com> for syslog@ietf.org; Wed, 07 Feb 2007 17:13:38 +0800 (CST) Date: Wed, 07 Feb 2007 17:13:33 +0800 From: Miao Fuyou Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls In-reply-to: To: 'Sam Hartman' Message-id: <006501c74a98$3dc0fa10$800c6f0a@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: AcdKBz9Ef4fcwUdXSh+dES8wCVzdGwAjNA+A 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 Yes, peer entity authentication is seperate from integrity, this is addressed in section 3 of the current document. Client only authenticaiton is not available in TLS, so I think it is safe to say "peer entity authention" instead of sender authenticaiton. Probably it is appropriate to say something in section 3 of the document like "Secure transport only secures syslog in a hop by hop manner, end to end message stream modificationis threat is not addressed in this document". Thanks, Miao > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Tuesday, February 06, 2007 11:56 PM > To: Miao Fuyou > Cc: syslog@ietf.org > Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > I recommend that you drop message stream modification if my analysis > > [At this point, we're still figuring out what we want to say. > I'm speaking as an individual not an AD.] > > of the charter is a correct analysis and we meant for that to > apply to syslog-sign. > > I recommend you split out peer entity authentication as a > separate service from integrity. And point out that by > integrity, you mean that the sender knows that the data is > not modified between the sender and the receiver; by peer > entity authentication in this case we want to focus on > whether the receiver knows who its peer is. So, perhaps we > should cll that sender authentication. > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 07:13:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElfc-0007Ci-LB; Wed, 07 Feb 2007 07:13:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElfb-0007Cc-5T for syslog@ietf.org; Wed, 07 Feb 2007 07:13:03 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HElfZ-0000lb-TA for syslog@ietf.org; Wed, 07 Feb 2007 07:13:03 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id CD9A8E00B3; Wed, 7 Feb 2007 07:13:01 -0500 (EST) From: Sam Hartman To: Miao Fuyou Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls References: <006501c74a98$3dc0fa10$800c6f0a@china.huawei.com> Date: Wed, 07 Feb 2007 07:13:01 -0500 In-Reply-To: <006501c74a98$3dc0fa10$800c6f0a@china.huawei.com> (Miao Fuyou's message of "Wed, 07 Feb 2007 17:13:33 +0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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" == Miao Fuyou writes: Miao> Yes, peer entity authentication is seperate from integrity, Miao> this is addressed in section 3 of the current Miao> document. Client only authenticaiton is not available in Miao> TLS, so I think it is safe to say "peer entity authention" Miao> instead of sender authenticaiton. No, because peer entity authentication confuses server auth and client+server auth. Also, TLS does have client only auth: any case where the server cert is not actually verified but the client certificate is. It's important for the TLS document to point out that authentication is as much about whether you actually check the certificates as whether you exchange them at a protocol level. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 11:19:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEpV8-0006SJ-Bl; Wed, 07 Feb 2007 11:18:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEpV6-0006Pm-Co for syslog@ietf.org; Wed, 07 Feb 2007 11:18:28 -0500 Received: from smtp5.agfa.be ([134.54.1.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEpV2-0001TV-Qa for syslog@ietf.org; Wed, 07 Feb 2007 11:18:28 -0500 Received: from morswa037.be.local (morswa037.agfa.be [10.232.220.21] (may be forged)) by smtp5.agfa.be (8.13.6/8.13.6) with ESMTP id l17GIKQI009372; Wed, 7 Feb 2007 17:18:21 +0100 (MET) Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls To: "'Sam Hartman'" Message-ID: From: robert.horn@agfa.com Date: Wed, 7 Feb 2007 11:18:18 -0500 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.54 on 10.232.180.79 X-Spam-Score: 0.4 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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: , Content-Type: multipart/mixed; boundary="===============1425046369==" Errors-To: syslog-bounces@lists.ietf.org --===============1425046369== Content-type: multipart/alternative; Boundary="0__=0ABBF8E8DFCA06BF8f9e8a93df938690918c0ABBF8E8DFCA06BF" Content-Disposition: inline --0__=0ABBF8E8DFCA06BF8f9e8a93df938690918c0ABBF8E8DFCA06BF Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable transport-tls should be designed to enable policy decisions. This grou= p is not able to make policy decisions. Some of this discussion is really policy making. Policy discussions within syslog should be oriented tow= ards ensuring that any reasonable policy can be properly supported. For example, in my real world situations, the primary policy concern is= disclosure of audit information to unauthorized recipients. This means= that the encryption aspect is most important, not the authentications. = I can deal with a degree of uncertainty about the source and destination authentications. If you look inside what authentication really means to us you find seve= ral kinds of authentication to manage: - Is the source machine authenticated and authorized to be on the netw= ork? - Is the source machine/process authenticated and authorized to be a source of audit information? - The symetric questions for the destination machine. My destination accepts all connections and has different processing policies for incoming syslog information for the categories: - unauthenticated machine source - authenticated machine source, unauthenticated process - authenticated machine source and process The differences are a degree of confidence about various source characteristics. No authentication ensures complete confidence, becaus= e it is possible that both the source machine and process have been penetrat= ed by a hostile attacker. The chain of trust to the various root certificate authorities is not important. Suppose I get a good certificate signed by the ABA. What d= oes that mean? Does the ABA know what machines are authorized to be on my network? no. It means that someone with good credentials paid the ABA= money to get a certificate for that identity. I will treat is as an unauthenticated machine. Suppose I get a certificate with a chain of signatures, the last of whi= ch is my local hospital administration. All those earlier signatures mean= as little as the ABA signature. But that signature from the local hospita= l administration means something. Now I will consider this machine to be= an authenticated machine source. (Process might still be unclear.) I don= 't need the rest of the chain. A self-signed hospital administration CA i= s good enough. This can save money and bother. The source side rule gets even stricter. A hospital administration CA signature is not enough. They sign all the internal machine certificat= es. I need the cert contents to be right. Or, (more commonly) I demand tha= t the destination certificate match the single public cert that I provide= to authenticated source processes for logging. This cert is self-signed b= y the syslog destination machine. The authorized internal machines and processes use this to ensure that they have connected to the right destination. Now I have all three different categories that derive from my policies.= The chain of trust back to root CAs was not used much. What I really n= eed is just the portion to the CA for the hospital. It might happen to be traceable to a root CA, but that doesn't matter in this situation. I c= an even live without it on a small network, by inverting the relationship = and copying the self-signed public certs of the authorized source systems = over to the destination server. This doesn't scale well, but for small netw= orks it can be easier than setting up the local CA. R Horn= --0__=0ABBF8E8DFCA06BF8f9e8a93df938690918c0ABBF8E8DFCA06BF Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

transport-tls should be designed to enable policy decisions. This g= roup is not able to make policy decisions. Some of this discussion is = really policy making. Policy discussions within syslog should be orien= ted towards ensuring that any reasonable policy can be properly support= ed.

For example, in my real world situations, the primary policy concern is= disclosure of audit information to unauthorized recipients. This mean= s that the encryption aspect is most important, not the authentications= . I can deal with a degree of uncertainty about the source and destina= tion authentications.

If you look inside what authentication really means to us you find seve= ral kinds of authentication to manage:
- Is the source machine authenticated and authorized to be on the netw= ork?
- Is the source machine/process authenticated and authorized to be a s= ource of audit information?
- The symetric questions for the destination machine.

My destination accepts all connections and has different processing pol= icies for incoming syslog information for the categories:
- unauthenticated machine source
- authenticated machine source, unauthenticated process
- authenticated machine source and process

The differences are a degree of confidence about various source charact= eristics. No authentication ensures complete confidence, because it is= possible that both the source machine and process have been penetrated= by a hostile attacker.

The chain of trust to the various root certificate authorities is not i= mportant. Suppose I get a good certificate signed by the ABA. What do= es that mean? Does the ABA know what machines are authorized to be on = my network? no. It means that someone with good credentials paid the = ABA money to get a certificate for that identity. I will treat is as a= n unauthenticated machine.

Suppose I get a certificate with a chain of signatures, the last of whi= ch is my local hospital administration. All those earlier signatures m= ean as little as the ABA signature. But that signature from the local = hospital administration means something. Now I will consider this mach= ine to be an authenticated machine source. (Process might still be unc= lear.) I don't need the rest of the chain. A self-signed hospital adm= inistration CA is good enough. This can save money and bother.

The source side rule gets even stricter. A hospital administration CA = signature is not enough. They sign all the internal machine certificat= es. I need the cert contents to be right. Or, (more commonly) I deman= d that the destination certificate match the single public cert that I = provide to authenticated source processes for logging. This cert is se= lf-signed by the syslog destination machine. The authorized internal m= achines and processes use this to ensure that they have connected to th= e right destination.

Now I have all three different categories that derive from my policies.= The chain of trust back to root CAs was not used much. What I really= need is just the portion to the CA for the hospital. It might happen = to be traceable to a root CA, but that doesn't matter in this situation= . I can even live without it on a small network, by inverting the rela= tionship and copying the self-signed public certs of the authorized so= urce systems over to the destination server. This doesn't scale well, = but for small networks it can be easier than setting up the local CA.
R Horn= --0__=0ABBF8E8DFCA06BF8f9e8a93df938690918c0ABBF8E8DFCA06BF-- --===============1425046369== 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 --===============1425046369==-- From syslog-bounces@lists.ietf.org Wed Feb 07 11:53:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEq2o-0006Ow-VG; Wed, 07 Feb 2007 11:53:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEq2n-0006O7-N0 for syslog@ietf.org; Wed, 07 Feb 2007 11:53:17 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEq2m-0000wX-H2 for syslog@ietf.org; Wed, 07 Feb 2007 11:53:17 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 15559E00B3; Wed, 7 Feb 2007 11:53:03 -0500 (EST) From: Sam Hartman To: robert.horn@agfa.com Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls References: Date: Wed, 07 Feb 2007 11:53:03 -0500 In-Reply-To: (robert horn's message of "Wed, 7 Feb 2007 11:18:18 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 It sounds like trust anchor selection (what security people talk about when the rest of the world talks about set of root CAs) is actually very important to you. It's just that you don't actually consider the traditional root CAs part of your trust anchor set; you have a much smaller trust anchor set. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 12:29:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEqbG-0005nx-DG; Wed, 07 Feb 2007 12:28:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEqbE-0005lC-VN for syslog@ietf.org; Wed, 07 Feb 2007 12:28:52 -0500 Received: from smtp5.agfa.be ([134.54.1.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEqbD-0000aI-G0 for syslog@ietf.org; Wed, 07 Feb 2007 12:28:52 -0500 Received: from morswa037.be.local (morswa037.agfa.be [10.232.220.21] (may be forged)) by smtp5.agfa.be (8.13.6/8.13.6) with ESMTP id l17HSnNO016795; Wed, 7 Feb 2007 18:28:50 +0100 (MET) Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls To: hartmans-ietf@mit.edu Message-ID: From: robert.horn@agfa.com Date: Wed, 7 Feb 2007 12:28:43 -0500 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.54 on 10.232.180.79 X-Spam-Score: 1.3 (+) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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: , Content-Type: multipart/mixed; boundary="===============1789186773==" Errors-To: syslog-bounces@lists.ietf.org --===============1789186773== Content-type: multipart/related; Boundary="0__=0ABBF8E8DFCCB7148f9e8a93df938690918c0ABBF8E8DFCCB714" --0__=0ABBF8E8DFCCB7148f9e8a93df938690918c0ABBF8E8DFCCB714 Content-type: multipart/alternative; Boundary="1__=0ABBF8E8DFCCB7148f9e8a93df938690918c0ABBF8E8DFCCB714" --1__=0ABBF8E8DFCCB7148f9e8a93df938690918c0ABBF8E8DFCCB714 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Correct. So I just need to make sure that the various MUST/SHALL/SHOULD/etc decisions continue to support our policy needs. I suspect that a diversity of trust anchor sets and a diversity of trus= t purposes will be increasing in the authentication process when people s= tart making operational use of security instead of using it as theater. The= standards just need to acknowledge and support this. R Horn |---------+----------------------------> | | Sam Hartman | | | | | | | | | 02/07/2007 11:53 | | | AM | | | | |---------+----------------------------> >--------------------------------------------------------------------= --------------------------------------------------------------------| | = | | To: Robert Horn/MOPOO/AGFA@AGFA = | | cc: syslog@ietf.org = | | Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transp= ort-tls | >--------------------------------------------------------------------= --------------------------------------------------------------------| It sounds like trust anchor selection (what security people talk about when the rest of the world talks about set of root CAs) is actually very important to you. It's just that you don't actually consider the traditional root CAs part of your trust anchor set; you have a much smaller trust anchor set. --Sam = --1__=0ABBF8E8DFCCB7148f9e8a93df938690918c0ABBF8E8DFCCB714 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Correct. So I just need to make sure that the various MUST/SHALL/SH= OULD/etc decisions continue to support our policy needs.

I suspect that a diversity of trust anchor sets and a diversity of trus= t purposes will be increasing in the authentication process when people= start making operational use of security instead of using it as theate= r. The standards just need to acknowledge and support this.

R Horn
3D"InactiveSam Hartman <hartmans-ietf@mit.edu>




          Sam Hartman <hartmans-ietf@mit.edu>

          02/07/2007 11:53 AM

3D""

To: Robert Horn/MOPOO/AGFA@AG= FA
cc: syslog@ietf.org Subject: Re: [Syslog] AD Revi= ew for draft-ietf-syslog-transport-tls


It sounds like trust anchor selection (what = security people talk about
when the rest of the world talks about set of root CAs) is actually
= very important to you. It's just that you don't actually consider the<= br> traditional root CAs part of your trust anchor set; you have a much
= smaller trust anchor set.

--Sam
 = --1__=0ABBF8E8DFCCB7148f9e8a93df938690918c0ABBF8E8DFCCB714-- --0__=0ABBF8E8DFCCB7148f9e8a93df938690918c0ABBF8E8DFCCB714 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBF8E8DFCCB7148f9e8a93df93869@agfa.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF8E8DFCCB7148f9e8a93df938690918c0ABBF8E8DFCCB714 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBF8E8DFCCB7148f9e8a93df93869@agfa.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBF8E8DFCCB7148f9e8a93df938690918c0ABBF8E8DFCCB714 Content-type: image/gif; name="pic27756.gif" Content-Disposition: inline; filename="pic27756.gif" Content-ID: <30__=0ABBF8E8DFCCB7148f9e8a93df93869@agfa.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBF8E8DFCCB7148f9e8a93df938690918c0ABBF8E8DFCCB714-- --===============1789186773== 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 --===============1789186773==-- From syslog-bounces@lists.ietf.org Wed Feb 07 13:00:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEr5O-0006Aq-R2; Wed, 07 Feb 2007 13:00:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEr5N-0006Al-Pg for syslog@ietf.org; Wed, 07 Feb 2007 13:00:01 -0500 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEr5M-0000to-Fo for syslog@ietf.org; Wed, 07 Feb 2007 13:00:01 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007020718000001200i2pfde>; Wed, 7 Feb 2007 18:00:00 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 12:55:59 -0500 Message-ID: <0d1201c74ae1$397367b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0D13_01C74AB7.509D5FB0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcdGLehoVgs37OVlT5611TjpvhrJMgEsxFoA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable delivery considered harmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 This is a multi-part message in MIME format. ------=_NextPart_000_0D13_01C74AB7.509D5FB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Forwarded from ietf@ietf.org mailing list. Please ensure that responses also go to the ietf@ietf.org list. dbh -----Original Message----- From: David W. Hankins [mailto:David_Hankins@isc.org] Sent: Thursday, February 01, 2007 1:09 PM To: ietf@ietf.org Subject: draft-ietf-syslog-protocol: "Reliable delivery considered harmful." On Thu, Feb 01, 2007 at 08:09:29AM -0500, Sam Hartman wrote: > >>>>> "Mark" == Mark Andrews writes: > >> - 'The syslog Protocol ' as > >> a Proposed Standard > > Mark> draft-ietf-syslog-protocol-19.txt recommends using a > Mark> reliable protocol. Existing implementations of syslog do > Mark> this and deadlock with nameservers which are logging via > Mark> syslog. > > > Please explain the deadlock in more detail. One of the primary > reasons for the syslog working group is reliable syslog, so I think we > need to focus on how to avoid the deadlock in other ways rather than > avoiding reliability. If you have 50,000 syslog lines to put out, and only enough network/disk/something bandwidth for 5,000 within the same time frame, that's a problem. If you insist on keeping all 50,000 lines of output, there is no solution to that problem. If you block, that's a big problem as it ultimatley totally disables the service attempting to log information. If you write to a growing backing store, well you'll run out of space eventually (even disk is not infinite). Compression can only get you so far. Ultimately you have to drop something, and if it's not the syslog output, it's the service's output. Reliability is the problem, and the advice we give our users is not to log reliably (or even to configure servers to log to a local file, circumventing syslog entirely). Note that reliable network transport of syslog information is equally damaging as reliable local storage of syslog output (eg by forcing disk synchronization of each line). At least one of today's syslog implementations insists that you prefix your filenames with a "-" if you /don't/ want it to fsync() every line. This default cripples DHCP servers. The current words in the draft; It may be desirable to use a transport with guaranteed delivery to mitigate congestion. May be adequate to the point of suggesting that reliable delivery might not be desirable. But on the whole the draft doesn't read that way, and it doesn't state the truth: reliable delivery of syslog output is always harmful. The point of bothering with reliable syslog delivery, if there is one, is for those very rare cases where losing the data is more harmful than harming system services. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins ------=_NextPart_000_0D13_01C74AB7.509D5FB0 Content-Type: application/pgp-signature; name="ATT02307.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT02307.dat" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFwiyncXeLeWu2vmoRAhMbAJ9gvVBaDpzRrSm222H7UhqpxIZVyQCbBRxQ B5MegWNDsbcsOo2gVwGFFtw= =tcVi -----END PGP SIGNATURE----- ------=_NextPart_000_0D13_01C74AB7.509D5FB0 Content-Type: text/plain; name="ATT02310.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT02310.txt" _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------=_NextPart_000_0D13_01C74AB7.509D5FB0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ------=_NextPart_000_0D13_01C74AB7.509D5FB0-- From syslog-bounces@lists.ietf.org Wed Feb 07 13:05:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErAR-00085x-L6; Wed, 07 Feb 2007 13:05:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErAO-00084F-OX for syslog@ietf.org; Wed, 07 Feb 2007 13:05:13 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErAN-0001pe-Fj for syslog@ietf.org; Wed, 07 Feb 2007 13:05:12 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007020718050801500lp4vue>; Wed, 7 Feb 2007 18:05:08 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:01:02 -0500 Message-ID: <0d1801c74ae1$f02f7ed0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0D19_01C74AB8.075976D0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcdGUgzW5KCrazW/T1e0N+uK/CriGQEj2iXQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 This is a multi-part message in MIME format. ------=_NextPart_000_0D19_01C74AB8.075976D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Forwarded from iet@ietf.org; please ietf@iet.org in any responses. dbh -----Original Message----- From: David W. Hankins [mailto:David_Hankins@isc.org] Sent: Thursday, February 01, 2007 5:32 PM To: ietf@ietf.org Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." On Thu, Feb 01, 2007 at 10:30:17PM +0200, Pekka Savola wrote: > It's acceptable for the syslog sender to replace overflowing lines of > syslog (if some messages need to be dropped due to lack of resources) > with a message about rate-limiting, messages being dropped, or > whatever -- just the same way as messages might get dropped when > syslogging to a local media. Then the word that should be used here is not "reliable" without any exceptions tagged on. > As long as a) there is a message about syslogs getting dropped, and b) > this is infrequent in a well operated system (i.e. the system log > levels are set so that typically the amount of logging is OK), this > should be no problem. I should note that while this would be just fine, this is not in fact what presently deployed syslog implementations that implement "reliable" delivery (wether to network sockets or local files) do. Today they block. To use the world 'reliable' without illuminating clearly that exceptions must be made is dangerous. > IMHO, "reliable delivery of syslog output is always harmful" is very > much an over-statement. Well, I wasn't counting on shifting the definition of "reliable" to "somewhat reliable". Sure, "somewhat reliable delivery of syslog output is always harmful" is very much an over-statement, I'll agree with that. But I stand by what I said. > get even more syslog to send. While this is a serious problem when it > occurs, it should be easily solvable: just drop the messages (with a > suitable note in syslog or in the local log) that exceed the buffer > size or prune messages from the buffer using some more advanced > strategy. That would be fine. But again, this is not what current implementations do, and that is not "reliable" without exception. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins ------=_NextPart_000_0D19_01C74AB8.075976D0 Content-Type: application/pgp-signature; name="ATT02592.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT02592.dat" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFwmpOcXeLeWu2vmoRAoznAJ9RnLAg67leySpabJ1ppy7lbWHAfACfdRlm 5uJuRrCqaQlUxFHh59z8lqs= =VfBi -----END PGP SIGNATURE----- ------=_NextPart_000_0D19_01C74AB8.075976D0 Content-Type: text/plain; name="ATT02595.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT02595.txt" _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------=_NextPart_000_0D19_01C74AB8.075976D0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ------=_NextPart_000_0D19_01C74AB8.075976D0-- From syslog-bounces@lists.ietf.org Wed Feb 07 13:05:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErAO-000843-GC; Wed, 07 Feb 2007 13:05:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErAM-00083d-FX for syslog@ietf.org; Wed, 07 Feb 2007 13:05:10 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErAK-0001pe-7x for syslog@ietf.org; Wed, 07 Feb 2007 13:05:10 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007020718050801500lp4vte>; Wed, 7 Feb 2007 18:05:08 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:01:02 -0500 Message-ID: <0d1701c74ae1$f017b110$0600a8c0@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.2962 Thread-index: AcdGnXnD7bamqJ8ZSme9mJ8yB8lmMQERB7ig X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 Forwraded from ietf@ietf.org; please include ietf@ietf.org in responses. dbh -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Friday, February 02, 2007 2:32 AM To: David W. Hankins Cc: ietf@ietf.org Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." On Thu, Feb 01, 2007 at 10:08:39AM -0800, David W. Hankins wrote a message of 98 lines which said: > If you block, that's a big problem as it ultimatley totally disables > the service attempting to log information. Wether it is a bug or a feature depends on your requirments. On some high-security environments, people prefer to suspend the service rather than not being able to log it. (Otherwise, an attacker could easily attempt many attacks, fill in the hard disk and then perform the real attack unlogged). > reliable delivery of syslog output is always harmful. Clearly, "always" is too much. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 13:05:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErAR-00085x-L6; Wed, 07 Feb 2007 13:05:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErAO-00084F-OX for syslog@ietf.org; Wed, 07 Feb 2007 13:05:13 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErAN-0001pe-Fj for syslog@ietf.org; Wed, 07 Feb 2007 13:05:12 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007020718050801500lp4vue>; Wed, 7 Feb 2007 18:05:08 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:01:02 -0500 Message-ID: <0d1801c74ae1$f02f7ed0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0D19_01C74AB8.075976D0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcdGUgzW5KCrazW/T1e0N+uK/CriGQEj2iXQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 This is a multi-part message in MIME format. ------=_NextPart_000_0D19_01C74AB8.075976D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Forwarded from iet@ietf.org; please ietf@iet.org in any responses. dbh -----Original Message----- From: David W. Hankins [mailto:David_Hankins@isc.org] Sent: Thursday, February 01, 2007 5:32 PM To: ietf@ietf.org Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." On Thu, Feb 01, 2007 at 10:30:17PM +0200, Pekka Savola wrote: > It's acceptable for the syslog sender to replace overflowing lines of > syslog (if some messages need to be dropped due to lack of resources) > with a message about rate-limiting, messages being dropped, or > whatever -- just the same way as messages might get dropped when > syslogging to a local media. Then the word that should be used here is not "reliable" without any exceptions tagged on. > As long as a) there is a message about syslogs getting dropped, and b) > this is infrequent in a well operated system (i.e. the system log > levels are set so that typically the amount of logging is OK), this > should be no problem. I should note that while this would be just fine, this is not in fact what presently deployed syslog implementations that implement "reliable" delivery (wether to network sockets or local files) do. Today they block. To use the world 'reliable' without illuminating clearly that exceptions must be made is dangerous. > IMHO, "reliable delivery of syslog output is always harmful" is very > much an over-statement. Well, I wasn't counting on shifting the definition of "reliable" to "somewhat reliable". Sure, "somewhat reliable delivery of syslog output is always harmful" is very much an over-statement, I'll agree with that. But I stand by what I said. > get even more syslog to send. While this is a serious problem when it > occurs, it should be easily solvable: just drop the messages (with a > suitable note in syslog or in the local log) that exceed the buffer > size or prune messages from the buffer using some more advanced > strategy. That would be fine. But again, this is not what current implementations do, and that is not "reliable" without exception. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins ------=_NextPart_000_0D19_01C74AB8.075976D0 Content-Type: application/pgp-signature; name="ATT02592.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT02592.dat" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFwmpOcXeLeWu2vmoRAoznAJ9RnLAg67leySpabJ1ppy7lbWHAfACfdRlm 5uJuRrCqaQlUxFHh59z8lqs= =VfBi -----END PGP SIGNATURE----- ------=_NextPart_000_0D19_01C74AB8.075976D0 Content-Type: text/plain; name="ATT02595.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT02595.txt" _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------=_NextPart_000_0D19_01C74AB8.075976D0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ------=_NextPart_000_0D19_01C74AB8.075976D0-- From syslog-bounces@lists.ietf.org Wed Feb 07 13:05:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErAO-000843-GC; Wed, 07 Feb 2007 13:05:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErAM-00083d-FX for syslog@ietf.org; Wed, 07 Feb 2007 13:05:10 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErAK-0001pe-7x for syslog@ietf.org; Wed, 07 Feb 2007 13:05:10 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007020718050801500lp4vte>; Wed, 7 Feb 2007 18:05:08 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:01:02 -0500 Message-ID: <0d1701c74ae1$f017b110$0600a8c0@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.2962 Thread-index: AcdGnXnD7bamqJ8ZSme9mJ8yB8lmMQERB7ig X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 Forwraded from ietf@ietf.org; please include ietf@ietf.org in responses. dbh -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Friday, February 02, 2007 2:32 AM To: David W. Hankins Cc: ietf@ietf.org Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." On Thu, Feb 01, 2007 at 10:08:39AM -0800, David W. Hankins wrote a message of 98 lines which said: > If you block, that's a big problem as it ultimatley totally disables > the service attempting to log information. Wether it is a bug or a feature depends on your requirments. On some high-security environments, people prefer to suspend the service rather than not being able to log it. (Otherwise, an attacker could easily attempt many attacks, fill in the hard disk and then perform the real attack unlogged). > reliable delivery of syslog output is always harmful. Clearly, "always" is too much. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 13:05:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErAR-000869-Pl; Wed, 07 Feb 2007 13:05:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErAQ-00085H-2l for syslog@ietf.org; Wed, 07 Feb 2007 13:05:14 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErAO-0001pe-Ot for syslog@ietf.org; Wed, 07 Feb 2007 13:05:14 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007020718050901500lp4vve>; Wed, 7 Feb 2007 18:05:09 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:01:02 -0500 Message-ID: <0d1c01c74ae1$f16c92b0$0600a8c0@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.2962 Thread-index: AcdGQK5UAYhmqpT/REeBeeu5fKtlJwEoJLRg X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable delivery considered harmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 Forwardede from ietf@ietf.org; please include ietf@ietf.org in responses. dbh -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Thursday, February 01, 2007 3:30 PM To: David W. Hankins Cc: ietf@ietf.org Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery considered harmful." On Thu, 1 Feb 2007, David W. Hankins wrote: > If you insist on keeping all 50,000 lines of output, there is no > solution to that problem. If you block, that's a big problem as > it ultimatley totally disables the service attempting to log > information. If you write to a growing backing store, well you'll > run out of space eventually (even disk is not infinite). > Compression can only get you so far. As an operator, I would find a reliable syslog useful. However, I do not see this as a problem. 95% of the problem (from our perspective) is solved if no messages are lost _on the wire_ between the sender and the recipient of syslog messages. It's acceptable for the syslog sender to replace overflowing lines of syslog (if some messages need to be dropped due to lack of resources) with a message about rate-limiting, messages being dropped, or whatever -- just the same way as messages might get dropped when syslogging to a local media. As long as a) there is a message about syslogs getting dropped, and b) this is infrequent in a well operated system (i.e. the system log levels are set so that typically the amount of logging is OK), this should be no problem. > May be adequate to the point of suggesting that reliable delivery > might not be desirable. But on the whole the draft doesn't read > that way, and it doesn't state the truth: reliable delivery of > syslog output is always harmful. The point of bothering with > reliable syslog delivery, if there is one, is for those very > rare cases where losing the data is more harmful than harming > system services. IMHO, "reliable delivery of syslog output is always harmful" is very much an over-statement. It seems your concern is limited to the corner case where the syslog sender would already have a full syslog buffer, and the sender would get even more syslog to send. While this is a serious problem when it occurs, it should be easily solvable: just drop the messages (with a suitable note in syslog or in the local log) that exceed the buffer size or prune messages from the buffer using some more advanced strategy. As a particular example, we'd be very interested in getting reliable syslog from our routers to cover for messages lost due to network outages (fixed usually quickly with rerouting). We are talking of 1-200 messages being lost within a 10 minute period -- a very reasonable packet rate in average. A 1,000 or 10,000 line buffer in the router should be very reasonable in recent control processors. I'd rather the control processor reserve 0.1% of its memory (or CPU) to store and transmit these messages rather than try to use the last 0.1% when it's already chugging at 99.9%; the last 0.1% would not make a meaningful difference anyway for whatever it's using almost all of its resources. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 13:06:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErBq-0000dJ-Jm; Wed, 07 Feb 2007 13:06:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErBp-0000dD-F5 for syslog@ietf.org; Wed, 07 Feb 2007 13:06:41 -0500 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErBn-000260-LM for syslog@ietf.org; Wed, 07 Feb 2007 13:06:41 -0500 Received: from pc6 (1Cust27.tnt101.lnd4.gbr.da.uu.net [213.116.50.27]) by galaxy.systems.pipex.net (Postfix) with SMTP id BDA49E00038D for ; Wed, 7 Feb 2007 18:06:25 +0000 (GMT) Message-ID: <006301c74ada$18738ba0$0601a8c0@pc6> From: "tom.petch" To: Subject: Fw: senders and receivers nothing to do with Mibs was Re: [Syslog] Mib-13 Date: Wed, 7 Feb 2007 18:03:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b 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 Ah. lost the syslog address off this one; my comments are at the beginning. Tom Petch ----- Original Message ----- From: "tom.petch" To: "David Harrington" Sent: Monday, February 05, 2007 8:37 PM Subject: Re: senders and receivers nothing to do with Mibs was Re: [Syslog] Mib-13 > David > > Yes, I am with you on this, the key is to resolve the ambiguity.. > > I believe that the collector/relay/device terminology has a life outside the > IETF that we should respect, as we are documenting that life, rather than > creating something new within the IETF. > > For example, look at the liaison from the OIF, 'file228' in the IETF repository, > which says > "The three operational roles for the syslog service are designated devices, > relays and collectors" > and goes on to explain those terms in the same way as RFC3164 does. This > reference comes immediately to hand, but I recall seeing others from different > organisations. Perhaps they all derived from RFC3164; no matter, they still > have a life. > > So while collector/relay/device may not be the ideal terminology, I believe it > has currency and we should stay with it. The corollary, for me, is that sender > encompasses relay and device, receiver encompasses collector and relay and I > would then write -mib, -tls et al. based on that understanding. > > Tom Petch > > ----- Original Message ----- > From: "David Harrington" > To: "'tom.petch'" > Cc: "'Glenn M. Keeni'" ; > Sent: Monday, February 05, 2007 6:42 PM > Subject: RE: senders and receivers nothing to do with Mibs was Re: [Syslog] > Mib-13 > > > > Hi, > > > > [speaking as a contributor] > > > > My main concern is that if we are going to use three terms or four, > > then we need to make it clear which roles are responsible for > > incrementing counters regarding received messages, and for > > incrementing counters regarding sent messages. As currently written, > > only receivers (and not relays or collectors) increment the counters > > regarding received messages, and only senders (not relays) increment > > the counters regarding sent messages. > > > > Our definitions are missing the crucial info about which roles are > > senders and which are receivers; the description in your email does > > include this info: > > > sender sends, device or relay > > > receiver receives, relay or collector > > But Glenn's email says this: > > > We basically have syslog senders and syslog > > > receivers. A syslog relay is a special case - it "forwards some of > > the > > > received syslog messages to other syslog entities." > > > > Should a relay be incrementing the counters for received messages? > > Should a collector be incrementing the counters for received messages? > > Does a relay "forward" a syslog message by **sending** it to other > > syslog "entities"? > > Should a relay be incrementing the counters for sent messages? > > > > The answers to these questions are ambiguous given the current text in > > the protocol and in the mib documents. > > > > I don't care which way we modify the text to resolve the ambiguity; I > > care that we DO resolve the ambiguity. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > > -----Original Message----- > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > Sent: Monday, February 05, 2007 5:32 AM > > > To: David Harrington > > > Cc: 'Glenn M. Keeni'; syslog@ietf.org > > > Subject: senders and receivers nothing to do with Mibs was > > > Re: [Syslog] Mib-13 > > > > > > David > > > > > > I disagree with you here. I think that we should use four > > > terms, sender, > > > receiver, relay, collector. > > > > > > RFC3164 I find very clear. > > > > > > collector receives and does not forward > > > relay receives and forwards > > > > > > -protocol started off life with identical definitions but by > > > -10, two key > > > phrases had vanished leaving > > > > > > sender sends, > > > receiver receives, > > > > > > which would be ambiguous except that further down it says > > > " Senders send messages to receivers with no knowledge of > > > whether they are > > > collectors or relays" > > > which again I find very clear - receiver receives, relay or > > collector. > > > > > > So while the present text is not as clear as it used to be, I > > > still believe that > > > what we are saying is what we always have said, namely > > > > > > collector receives and does not forward > > > relay receives and forwards > > > sender sends, device or relay > > > receiver receives, relay or collector > > > > > > and I see this implicitly endorsed in the documentation of > > > other bodies; > > > collector, in particular, I see used, if not as precisely > > > defined as we used to. > > > > > > So, I conclude that we have four well-defined terms, in use > > > for many years, and > > > need a good reason to change them. Of course we could do > > > things differently, > > > but at the risk of confusing those who have not followed this WG. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "David Harrington" > > > To: "'Glenn M. Keeni'" ; > > > Sent: Friday, February 02, 2007 7:27 PM > > > Subject: RE: [Syslog] Mib-13 > > > > > > > > > > Hi Glenn, > > > > > > > > Some comments. > > > > > > > > First let me start out by noting that MIB modules are frequently > > > > implemented by junior developers, since the senior developers > > don't > > > > want to waste their time working on management stuff; they > > > want to go > > > > design new hardware and new protocols. So the implementer > > > of a syslog > > > > MIB module may not have much experience with syslog. > > > > > > > > As a result, it is important to be unambiguous in our terminology. > > > > This is especially true when describing what should be counted in > > a > > > > counter. This is a common problem in MIB module implementations - > > > > different implementations interpret the instructions slightly > > > > differently, and end up counting slightly different things, and as > > a > > > > result, the counters cannot be interpreted in an interoperable way > > > > across implementations. > > > > > > > > Protocol says there are three application types - senders, > > > receivers, > > > > and relays. -protocol- does NOT say that a relay is a > > > special case and > > > > that a relay IS a receiver and IS a sender: > > > > > > > > Per the protocol document: > > > > > > o A syslog application that can generate a syslog > > > message is > > > > > > called a "sender". > > > > > > > > > > > > o A syslog application that can receive a syslog message > > is > > > > > > called a "receiver". > > > > > > > > > > > > o A syslog application that can receive syslog messages > > and > > > > > > forward them to another receiver is called a "relay". > > > > > > > > > > > > > > Here's where ambiguity comes in as the result of terminology > > > > differences between -protocol- and -mib-. > > > > > > > > You know and I know that a relay really both recieves and > > > sends and it > > > > does some stuff in between, but protocol does not say that > > > a relay is > > > > both a receiver and a sender, and nothing says that when counting > > > > things, a relay should count things relevant to a receiver AND > > > > relevant to a sender. > > > > > > > > SyslogRoles is not clear on this point: If I am a relay, > > > then do I set > > > > all three bits ON (sender, receiver, relay) or do I only > > > set the relay > > > > BIT ON? > > > > > > > > Malformed says "The number of messages received by the syslog > > > > receiver which had malformed header. > > > > If this syslog entity is not a syslog receiver > > > > the this object will have a zero value.", > > > > Well, if I am a relay am I also a reciever? Protocol does not say > > > > that! In fact, protocol says there are three types of > > > applications, so > > > > if I am a relay then I can interpret this to mean I am not a > > > > "reciever" and I am not a "sender"; I am a "relay". Therefore, as > > a > > > > relay, I should not count malformed headers, because only > > receivers > > > > should count malformed headers. > > > > > > > > Am I just thick? No. I fully understand that a relay both > > > receives and > > > > sends; but the text in our specififcations does not say that this > > > > means a relay is both a "receiver" and a "sender". I am an > > > experienced > > > > MIB Doctor that has dealt with this same type of ambiguity > > > in WG after > > > > WG, where the WG members understand, but they are sloppy in > > > their MIB > > > > module specification work. > > > > > > > > We have an ambiguity: Does the Malformed counter include malformed > > > > headers received by a relay or not? This can be interpreted > > > as "relays > > > > should not count malformed headers that it receives; only > > receivers > > > > should count them." I think that would be a bad interpretation, > > but > > > > the ambiguity of the terminology allows for this interpretation. > > We > > > > need to modify the text so that such an interpretation is > > > not allowed. > > > > I recommend changing the text to: > > > > "The number of messages received by the syslog > > > > receiver or relay which had malformed header. > > > > If this syslog entity is not a syslog receiver > > > > or relay the this object will have a zero value." > > > > This way, whether the implementer interprets the terminology > > > > differences to be "I am a relay therefore I am NOT a receiver" or > > "I > > > > am a relay therefore I AM a receiver" makes no difference. > > > > > > > > An alternative is to change the protocol document to be clear that > > > > there are only two basic types of application- a sender and a > > > > receiver, and the relay is a special case that is both a > > > receiver and > > > > a sender plus other stuff. Right now the protocol document > > > definitions > > > > do not state that clearly. > > > > > > > > (also note the "the this" s/b "then this" > > > > (also note "had malformed" s/b "had a malformed") > > > > > > > > > > > > > > 8. > > > > > >8) Malformed - The WG distinguishes between receivers > > > and relays; > > > > > >should we have both receivers and relays count > > > malformed headers? > > > > > > > > > > I recommend that we do not. I would say that the > > > administrator is > > > > > interested in knowing that his/her syslog is receiving too > > many > > > > > malformed messages. The administrator is less interested in > > > > knowing > > > > > whether the malformed message was meant for local consumption > > or > > > > for > > > > > forwarding. (I am not saying that the information is useless. > > We > > > > are > > > > > trying to look at the cost benefits.) > > > > > > > > I think you misinterpreted me here. I was not suggesting > > > two separate > > > > counters, one for receivers and one for relays; I am trying to > > make > > > > sure the relays also increment this counter when they receive a > > > > malformed header. > > > > > > > > > > > > > > > > dbh > > > > > > > > > > _______________________________________________ > > > > > 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 Feb 07 13:10:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErFQ-0002cG-L9; Wed, 07 Feb 2007 13:10:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErFQ-0002cB-39 for syslog@ietf.org; Wed, 07 Feb 2007 13:10:24 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErFL-0003MI-Pd for syslog@ietf.org; Wed, 07 Feb 2007 13:10:24 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007020718101901400htg69e>; Wed, 7 Feb 2007 18:10:19 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:06:19 -0500 Message-ID: <0d2301c74ae2$ab260b50$0600a8c0@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.2962 Thread-index: AcdG07rWG2RGyWjKQcWON5HvVLqqjAEDjMsg X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 Forwarded from ietf@ietf.org; please include ietf@ietf.org in any responses. dbh -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com] Sent: Friday, February 02, 2007 9:04 AM To: Pekka Savola Cc: ietf@ietf.org Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." I'd have to agree with Pekka. We've just gone through this with ATIS and "reliable" accounting, which is quite a bit messier than this problem. So long as the log indicates that something bad has happened, it seems to me that you're covered. Of course, with reliability comes some amount of complexity. If an implementation detects the problem, say, through the other side not ACKing data, it's probably a good idea to switch to one's backup log server, right? I know of no syslogger that behaves in this manner today, although perhaps there are some out there. That doesn't mean we should not provide the function. Finally, it seems to me we are all arguing over non-normative text. Choice of level of reliability is generally a deployment concern. Eliot _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 13:16:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErKZ-0004dv-Tz; Wed, 07 Feb 2007 13:15:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErKY-0004dY-M9 for syslog@ietf.org; Wed, 07 Feb 2007 13:15:42 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErKX-00059x-Fu for syslog@ietf.org; Wed, 07 Feb 2007 13:15:42 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007020718153901500lr58fe>; Wed, 7 Feb 2007 18:15:39 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:11:36 -0500 Message-ID: <0d3201c74ae3$686e28f0$0600a8c0@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.2962 Thread-index: AcdK4vUrKrg5c9s1TC+u+XhmLFF2TQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Syslog] Last Call happens on ietf@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, [speaking as co-chair] WG members should understand why there are discussions on ietf@ietf.org. Our documents are advancing to IETF Last Calls, and IETF Last Calls are posted to the ietf@ietf.org mailing list to ensure that anybody in the ietf has an opportunity to review and comment on our documents. The editors of our documents should certainly subscribe to the ietf@ietf.org mailing list during this period so they are aware of points raised there and not copied to the WG. Others in this WG should also subscribe, so they can see what is being discussed and contribute to the discussions, if you choose. Caveat: the ietf@ietf.org is a very active list with a high noise-to-signal ratio. You will get to see vacuous discussions about establishing a mailing list for spouses of those planning to attend the Prague meeting, so wives can make plans to sightsee together, etc. You'll have a good opportunity to see wht mail clients have delete buttons ;-) 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 Feb 07 13:21:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErPS-0007gH-Tr; Wed, 07 Feb 2007 13:20:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErPR-0007g9-KC for syslog@ietf.org; Wed, 07 Feb 2007 13:20:45 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErPQ-0006TJ-D4 for syslog@ietf.org; Wed, 07 Feb 2007 13:20:45 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007020718204301300s9hpne>; Wed, 7 Feb 2007 18:20:43 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:16:43 -0500 Message-ID: <0d3301c74ae4$1eddf4d0$0600a8c0@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.2962 Thread-index: AcdJEkPa4rJkvcShQmyA1zfjlQREegB0ZT2g X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 Forwarded from ietf@ietf.org; please include ietf@ietf.org in any responses. dbh -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Monday, February 05, 2007 5:33 AM To: David W. Hankins Cc: ietf@ietf.org Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." On Fri, Feb 02, 2007 at 09:59:45AM -0800, David W. Hankins wrote a message of 60 lines which said: > I'd just like to point out that you're choosing one bug over > another. Not at all (a disk which is full is *not* a bug). I simply want to emphasize that security is ALWAYS a compromise. And that the draft should explain this compromise so the system administrator may make an informed choice. (The text proposed by Harald seems OK.) _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 13:21:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErPX-0007hL-RT; Wed, 07 Feb 2007 13:20:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErPX-0007hG-E8 for syslog@ietf.org; Wed, 07 Feb 2007 13:20:51 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErPW-0006TJ-6D for syslog@ietf.org; Wed, 07 Feb 2007 13:20:51 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007020718204701300s9hpre>; Wed, 7 Feb 2007 18:20:47 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:16:43 -0500 Message-ID: <0d3701c74ae4$1f0b4660$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0D38_01C74ABA.36353E60" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcdG9UdFWLfYURtoRnq1HiVjzzdbYAD7hR8g X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 This is a multi-part message in MIME format. ------=_NextPart_000_0D38_01C74ABA.36353E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Forwarded from ietf@ietf.org; please include ietf@ietf.org in any responses. dbh -----Original Message----- From: David W. Hankins [mailto:David_Hankins@isc.org] Sent: Friday, February 02, 2007 1:00 PM To: ietf@ietf.org Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." On Fri, Feb 02, 2007 at 08:31:49AM +0100, Stephane Bortzmeyer wrote: > Wether it is a bug or a feature depends on your requirments. On some > high-security environments, people prefer to suspend the service > rather than not being able to log it. (Otherwise, an attacker could > easily attempt many attacks, fill in the hard disk and then perform > the real attack unlogged). I'd just like to point out that you're choosing one bug over another. A DOS in preference to lack of observance of events. In my opinion, that's a bad selection, but it's your selection to make. That kind of preference, that kind of choice, is a good thing to have, but it would be unwise to apply to the general case a systematic selection of DOS over observation. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins ------=_NextPart_000_0D38_01C74ABA.36353E60 Content-Type: application/pgp-signature; name="ATT02693.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT02693.dat" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFw3wRcXeLeWu2vmoRAvHBAJ93JuQWgr3eCQ+0MwoyOa1mcAlzDwCfWHGL 4a/Kp2V5zGyOydJ9ojQD2+g= =g8C/ -----END PGP SIGNATURE----- ------=_NextPart_000_0D38_01C74ABA.36353E60 Content-Type: text/plain; name="ATT02696.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT02696.txt" _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------=_NextPart_000_0D38_01C74ABA.36353E60 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ------=_NextPart_000_0D38_01C74ABA.36353E60-- From syslog-bounces@lists.ietf.org Wed Feb 07 13:21:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErPV-0007gn-Im; Wed, 07 Feb 2007 13:20:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErPT-0007gY-UN for syslog@ietf.org; Wed, 07 Feb 2007 13:20:47 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErPS-0006TJ-Km for syslog@ietf.org; Wed, 07 Feb 2007 13:20:47 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007020718204501300s9hpoe>; Wed, 7 Feb 2007 18:20:45 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:16:43 -0500 Message-ID: <0d3401c74ae4$1eea02c0$0600a8c0@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.2962 Thread-index: AcdJMAviyP2n+Z7WRomXlFBuQ72WhgBs7zQg X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable deliveryconsidered harmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 Forwarded from ietf@ietf.org; please include ietf@ietf.org in any responses. dbh -----Original Message----- From: Tom.Petch [mailto:sisyphus@dial.pipex.com] Sent: Monday, February 05, 2007 8:06 AM To: Harald Tveit Alvestrand; ietf Subject: Re: draft-ietf-syslog-protocol: "Reliable deliveryconsidered harmful." Tom Petch ----- Original Message ----- From: "Harald Tveit Alvestrand" To: "David W. Hankins" ; Sent: Sunday, February 04, 2007 9:43 PM Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery considered harmful." > Daring to rush in without having read the documents.... > > it seems to me that somewhere one needs a NOTE, something along the lines > of: > > NOTE: In some situations, for instance when a destination disk is full or > damaged, a syslog facility may be unable to process all messages, despite > the message transport being reliable. In such a case, it is reasonable for > the logger of a message to have the option of either not logging more > messages or ceasing its own operation. This document does not specify which > option to take. > > Or words to that effect. > > Harald > Harald It might be worth reading the I-D:-) I am not clear which piece of text in the I-D provoked the original comment. I do not see the I-D recommending reliable transport, with all the problems that have been identified with that. Rather, under security, the I-D points out that with an unreliable transport, losing critical messages may adversely impact operation. It then goes on to say " It may be desirable to use a transport with guaranteed delivery to mitigate congestion. It may also be desirable to include rate-limiting features in syslog senders. This can reduce potential congestion problems when message bursts happen." I find it hard to square this with the original statement that 'draft-ietf-syslog-protocol-19.txt recommends using a reliable protocol' If we were to put in a comment about reliable transports introducing problems with blocking, then I think that that should be in an I-D which specifies a reliable transport, eg the soon to be completed one on TLS (there are no plans for one with TCP). Tom Petch > > --On 2. februar 2007 09:59 -0800 "David W. Hankins" > wrote: > > > On Fri, Feb 02, 2007 at 08:31:49AM +0100, Stephane Bortzmeyer wrote: > >> Wether it is a bug or a feature depends on your requirments. On some > >> high-security environments, people prefer to suspend the service > >> rather than not being able to log it. (Otherwise, an attacker could > >> easily attempt many attacks, fill in the hard disk and then perform > >> the real attack unlogged). > > > > I'd just like to point out that you're choosing one bug over > > another. A DOS in preference to lack of observance of events. > > > > In my opinion, that's a bad selection, but it's your selection to > > make. > > > > That kind of preference, that kind of choice, is a good thing to > > have, but it would be unwise to apply to the general case a > > systematic selection of DOS over observation. > > > > -- > > David W. Hankins "If you don't do it right the first time, > > Software Engineer you'll just have to do it again." > > Internet Systems Consortium, Inc. -- Jack T. Hankins > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 13:21:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErPW-0007h4-N0; Wed, 07 Feb 2007 13:20:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErPV-0007gg-5w for syslog@ietf.org; Wed, 07 Feb 2007 13:20:49 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErPT-0006TJ-V3 for syslog@ietf.org; Wed, 07 Feb 2007 13:20:49 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007020718204601300s9hppe>; Wed, 7 Feb 2007 18:20:46 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:16:43 -0500 Message-ID: <0d3501c74ae4$1ef378a0$0600a8c0@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.2962 Thread-index: AcdJEkPa4rJkvcShQmyA1zfjlQREegB0VRrA X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 Forwarded from ietf@ietf.org; please include ietf@ietf.org in any responses. dbh -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Monday, February 05, 2007 5:33 AM To: David W. Hankins Cc: ietf@ietf.org Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery consideredharmful." On Fri, Feb 02, 2007 at 09:59:45AM -0800, David W. Hankins wrote a message of 60 lines which said: > I'd just like to point out that you're choosing one bug over > another. Not at all (a disk which is full is *not* a bug). I simply want to emphasize that security is ALWAYS a compromise. And that the draft should explain this compromise so the system administrator may make an informed choice. (The text proposed by Harald seems OK.) _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 13:21:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErPa-0007hc-04; Wed, 07 Feb 2007 13:20:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HErPY-0007hX-Mm for syslog@ietf.org; Wed, 07 Feb 2007 13:20:52 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HErPX-0006TJ-Ed for syslog@ietf.org; Wed, 07 Feb 2007 13:20:52 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007020718204601300s9hpqe>; Wed, 7 Feb 2007 18:20:46 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 13:16:43 -0500 Message-ID: <0d3601c74ae4$1eff5f80$0600a8c0@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.2962 Thread-index: AcdInxASDkF3/7vqRWOdQc2345QQ/wCRHMDg X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: [Syslog] FW: draft-ietf-syslog-protocol: "Reliable delivery considered harmful." X-BeenThere: syslog@lists.ietf.org X-Mailman-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 Forwarded from ietf@ietf.org; please include ietf@ietf.org in any responses. dbh -----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: Sunday, February 04, 2007 3:44 PM To: David W. Hankins; ietf@ietf.org Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery considered harmful." Daring to rush in without having read the documents.... it seems to me that somewhere one needs a NOTE, something along the lines of: NOTE: In some situations, for instance when a destination disk is full or damaged, a syslog facility may be unable to process all messages, despite the message transport being reliable. In such a case, it is reasonable for the logger of a message to have the option of either not logging more messages or ceasing its own operation. This document does not specify which option to take. Or words to that effect. Harald --On 2. februar 2007 09:59 -0800 "David W. Hankins" wrote: > On Fri, Feb 02, 2007 at 08:31:49AM +0100, Stephane Bortzmeyer wrote: >> Wether it is a bug or a feature depends on your requirments. On some >> high-security environments, people prefer to suspend the service >> rather than not being able to log it. (Otherwise, an attacker could >> easily attempt many attacks, fill in the hard disk and then perform >> the real attack unlogged). > > I'd just like to point out that you're choosing one bug over > another. A DOS in preference to lack of observance of events. > > In my opinion, that's a bad selection, but it's your selection to > make. > > That kind of preference, that kind of choice, is a good thing to > have, but it would be unwise to apply to the general case a > systematic selection of DOS over observation. > > -- > David W. Hankins "If you don't do it right the first time, > Software Engineer you'll just have to do it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Feb 07 14:44:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEshm-0006u7-0C; Wed, 07 Feb 2007 14:43:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEshk-0006tz-Uv for syslog@ietf.org; Wed, 07 Feb 2007 14:43:44 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEshi-0007At-PA for syslog@ietf.org; Wed, 07 Feb 2007 14:43:44 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007020719434201100f0dm5e>; Wed, 7 Feb 2007 19:43:42 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 14:39:38 -0500 Message-ID: <0d5601c74aef$b69c3c40$0600a8c0@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.2962 Thread-index: AcdK70kfRL8F1CgkQWqzYTCu+ShOIg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Syslog] Chris X-BeenThere: syslog@lists.ietf.org X-Mailman-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, FYI. Chris is travelling heavily for work at this point, so has not had time to participate much in the recent discussions. He begs your indulgence, and hopes to get back into participation mode in the next few weeks. 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 Feb 07 16:45:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEuaE-0001B8-B5; Wed, 07 Feb 2007 16:44:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEuEC-0002tH-Jn for syslog@ietf.org; Wed, 07 Feb 2007 16:21:20 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEtp3-0004zJ-2u for syslog@ietf.org; Wed, 07 Feb 2007 15:55:54 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007020720552001100ev00ue>; Wed, 7 Feb 2007 20:55:20 +0000 From: "David Harrington" To: Date: Wed, 7 Feb 2007 15:51:19 -0500 Message-ID: <0d5701c74af9$b7e32fa0$0600a8c0@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.2962 Thread-index: AcdK+RZDRu8j5cUeQSii4IKvWETIZg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Syslog] Mib issues and resolutions X-BeenThere: syslog@lists.ietf.org X-Mailman-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 Glenn and Alex, Can you provide a quick summary for the WG of the issues that have been raised regarding the mib document and the sign document since the beginning of the WGLC (which started 9-11-06 and 8-28-06 respectively), pointers to the threads where discussions of the issues were held, the list of names for people who specifically took a posiiton on the issue, and what you percieve to be the WG consensus on the issues based on the stated positions? As we near the end of the work on these documents, we will need these summaries for AD review. Thanks, 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 Feb 07 23:43:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF16g-0002H6-Dx; Wed, 07 Feb 2007 23:42:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF16f-0002H1-6x for syslog@ietf.org; Wed, 07 Feb 2007 23:42:01 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF16c-00059s-IY for syslog@ietf.org; Wed, 07 Feb 2007 23:42:01 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l184fiJW020878 for ; Thu, 8 Feb 2007 13:41:44 +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 l184fdsN022642 for ; Thu, 8 Feb 2007 13:41:44 +0900 (JST) Message-ID: <45CAAA02.80203@cysols.com> Date: Thu, 08 Feb 2007 13:41:38 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Mib issues and resolutions References: <0d5701c74af9$b7e32fa0$0600a8c0@china.huawei.com> In-Reply-To: <0d5701c74af9$b7e32fa0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 David, Got it. I will prepare the summary and mail it - tentatively by 16/2. Thanks and cheers Glenn David Harrington wrote: > Hi Glenn and Alex, > > Can you provide a quick summary for the WG of the issues that have > been raised regarding the mib document and the sign document since the > beginning of the WGLC (which started 9-11-06 and 8-28-06 > respectively), pointers to the threads where discussions of the issues > were held, the list of names for people who specifically took a > posiiton on the issue, and what you percieve to be the WG consensus on > the issues based on the stated positions? > > As we near the end of the work on these documents, we will need these > summaries for AD review. > > Thanks, > 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 Thu Feb 08 03:17:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4Sf-0008WK-KZ; Thu, 08 Feb 2007 03:16:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4Sd-0008W8-H2 for syslog@ietf.org; Thu, 08 Feb 2007 03:16:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF4Sb-0002cX-Vf for syslog@ietf.org; Thu, 08 Feb 2007 03:16:55 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2007 09:16:53 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l188Gric017413; Thu, 8 Feb 2007 09:16:53 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp152.cisco.com [10.61.64.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l188GqC8005213; Thu, 8 Feb 2007 09:16:52 +0100 (MET) Message-ID: <45CADC70.2040701@cisco.com> Date: Thu, 08 Feb 2007 09:16:48 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: robert.horn@agfa.com Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4652; t=1170922613; x=1171786613; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20AD=20Review=20for=20draft-ietf-syslog-tran sport-tls |Sender:=20; bh=lK85rwe7jJWB91Lrp6ytLk9s2d8MxXfareAM3HD+w4s=; b=IhXSJ0b7O2dgqir3/RvKxmbNvT6xIFeOxgz+fs+O+HCjVjgGxz97Jc08iaeMpYZ5iAIPopOO FlbZBrEg6VnHtyRGwNIYY3zaBgbi3hJpYRK6ODvnDYYreoMQ8BGdQwQ+; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: syslog@ietf.org, 'Sam Hartman' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is precisely the sort of thing that RFC 3195 attempted. You want authenticated source? You can have it. You want authenticated server? You can have that too. You can even have unauthenticated server with authenticated client. As we've just released a revision draft, I suggest people look that over. My guess is that the security considerations and the choices made here will require at least some additional review. Please draft-lear-ietf-syslog-rfc3195bis-00.txt. And that leads to my other question. Why are we implementing a separate TLS protocol when 3195 and its successor both exists and has been implemented? That seems to me rather redundant, and violates a tenant that we really should observe more: don't reinvent the wheel. Eliot robert.horn@agfa.com wrote: > > transport-tls should be designed to enable policy decisions. This > group is not able to make policy decisions. Some of this discussion is > really policy making. Policy discussions within syslog should be > oriented towards ensuring that any reasonable policy can be properly > supported. > > For example, in my real world situations, the primary policy concern > is disclosure of audit information to unauthorized recipients. This > means that the encryption aspect is most important, not the > authentications. I can deal with a degree of uncertainty about the > source and destination authentications. > > If you look inside what authentication really means to us you find > several kinds of authentication to manage: > - Is the source machine authenticated and authorized to be on the network? > - Is the source machine/process authenticated and authorized to be a > source of audit information? > - The symetric questions for the destination machine. > > My destination accepts all connections and has different processing > policies for incoming syslog information for the categories: > - unauthenticated machine source > - authenticated machine source, unauthenticated process > - authenticated machine source and process > > The differences are a degree of confidence about various source > characteristics. No authentication ensures complete confidence, > because it is possible that both the source machine and process have > been penetrated by a hostile attacker. > > The chain of trust to the various root certificate authorities is not > important. Suppose I get a good certificate signed by the ABA. What > does that mean? Does the ABA know what machines are authorized to be > on my network? no. It means that someone with good credentials paid > the ABA money to get a certificate for that identity. I will treat is > as an unauthenticated machine. > > Suppose I get a certificate with a chain of signatures, the last of > which is my local hospital administration. All those earlier > signatures mean as little as the ABA signature. But that signature > from the local hospital administration means something. Now I will > consider this machine to be an authenticated machine source. (Process > might still be unclear.) I don't need the rest of the chain. A > self-signed hospital administration CA is good enough. This can save > money and bother. > > The source side rule gets even stricter. A hospital administration CA > signature is not enough. They sign all the internal machine > certificates. I need the cert contents to be right. Or, (more > commonly) I demand that the destination certificate match the single > public cert that I provide to authenticated source processes for > logging. This cert is self-signed by the syslog destination machine. > The authorized internal machines and processes use this to ensure that > they have connected to the right destination. > > Now I have all three different categories that derive from my > policies. The chain of trust back to root CAs was not used much. What > I really need is just the portion to the CA for the hospital. It might > happen to be traceable to a root CA, but that doesn't matter in this > situation. I can even live without it on a small network, by inverting > the relationship and copying the self-signed public certs of the > authorized source systems over to the destination server. This doesn't > scale well, but for small networks it can be easier than setting up > the local CA. > > R Horn > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Feb 08 07:27:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8Lt-0007DS-26; Thu, 08 Feb 2007 07:26:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8Ls-0007DC-3d for syslog@ietf.org; Thu, 08 Feb 2007 07:26:12 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF8Lp-0006JP-RE for syslog@ietf.org; Thu, 08 Feb 2007 07:26:12 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 215D5E00B3; Thu, 8 Feb 2007 07:26:09 -0500 (EST) From: Sam Hartman To: Eliot Lear References: <45CADC70.2040701@cisco.com> Date: Thu, 08 Feb 2007 07:26:09 -0500 In-Reply-To: <45CADC70.2040701@cisco.com> (Eliot Lear's message of "Thu, 08 Feb 2007 09:16:48 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: syslog@ietf.org Subject: [Syslog] Why we're doing TLS X-BeenThere: syslog@lists.ietf.org X-Mailman-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 >>>>> "Eliot" == Eliot Lear writes: Eliot> And that leads to my other question. Why are we Eliot> implementing a separate TLS protocol when 3195 and its Eliot> successor both exists and has been implemented? That seems Eliot> to me rather redundant, and violates a tenant that we Eliot> really should observe more: don't reinvent the wheel. Eliot, at this point we're doing TLS because we're chartered to do it. There was a long discussion within the WG about what direction to take. I don't know if you participated in that discussion but you were certainly welcome to have done so. That discussion resulted in a charter which explicitly called out TLS. That charter was sent out for IETF wide review with additional text specifically calling attention to the fact that this charter needed extra review. Again, you were welcome to read that charter and comment on it. I do think the question of why we're doing TLS has some good answers in the WG archive. You may not agree with them, but they are there in the archive for you to explore. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 08 09:02:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF9q0-0000XB-0B; Thu, 08 Feb 2007 09:01:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF9pv-0000O1-04 for syslog@ietf.org; Thu, 08 Feb 2007 09:01:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF9mL-0000FK-UV for syslog@ietf.org; Thu, 08 Feb 2007 08:57:41 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2007 14:57:36 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l18DvZQe029833; Thu, 8 Feb 2007 14:57:35 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp152.cisco.com [10.61.64.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l18DvYC8014377; Thu, 8 Feb 2007 14:57:34 +0100 (MET) Message-ID: <45CB2C4A.7070704@cisco.com> Date: Thu, 08 Feb 2007 14:57:30 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Sam Hartman References: <45CADC70.2040701@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=873; t=1170943055; x=1171807055; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Why=20we're=20doing=20TLS |Sender:=20; bh=BUYcgXzbzi5zcokrFCRqF4NUYTSCLnGzRULmCA9pwa8=; b=TvcvwGVvB8ZyjvnJQiEI96BnyNdVj9e+oYCJ1W/3MFy/ti88D+I4L2wN17BXpxdjX6XoHwyS MNZD/1sZRUn9v3xIFsLhYyAYF1AZvgS7iZEc4dU3vJLmrOcI2bQB1JqN; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: syslog@ietf.org Subject: [Syslog] Re: Why we're doing TLS X-BeenThere: syslog@lists.ietf.org X-Mailman-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 Sam, I got involved recently because both chairs asked me to submit a draft to revise 3195 to reflect the work of -protocol-19. I have done so. And so perhaps you can help me. The charter calls for a secure transport. The milestones say TLS (something that could easily be changed without community review, mind you). A reasonable person could believe that perhaps we might actually *build* on the work that was already done with SYSLOG/BEEP/TLS. As I'm relatively new to the party, I'll accept a pointer to the logic of the choice. There being an IPR claim against the new work, and the fact that multiple interoperable implementations of a proposed standard that could easily go to draft exist, I am hoping that pointer explains why this group is has put aside both interoperability and basic engineering principles of reuse. Eliot _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 08 09:16:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFA4e-000054-GN; Thu, 08 Feb 2007 09:16:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFA4c-00004u-Lp for syslog@ietf.org; Thu, 08 Feb 2007 09:16:30 -0500 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFA4b-0005LG-3I for syslog@ietf.org; Thu, 08 Feb 2007 09:16:30 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 99E899C00C; Thu, 8 Feb 2007 15:33:10 +0100 (CET) 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 14534-10; Thu, 8 Feb 2007 15:33:02 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 377349C00B; Thu, 8 Feb 2007 15:33:02 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Re: Why we're doing TLS X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 Feb 2007 15:16:13 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8E4F@grfint2.intern.adiscon.com> In-Reply-To: <45CB2C4A.7070704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Re: Why we're doing TLS Thread-Index: AcdLid//GOHcBEZIT0qNsN/98xaJRgAAJdxw References: <45CADC70.2040701@cisco.com> <45CB2C4A.7070704@cisco.com> From: "Rainer Gerhards" To: "Eliot Lear" , "Sam Hartman" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Eliot, TLS vs. 3195 *was* a community request and very though decision. You can not simply change that bullet point. Just a few quick pointers before I need to leave for a meeting: http://www.mail-archive.com/syslog%40lists.ietf.org/msg00643.html probably this: http://www.mail-archive.com/syslog%40lists.ietf.org/msg00379.html and then messages up to: http://www.mail-archive.com/syslog%40lists.ietf.org/msg00182.html This is eventually also relevant: http://www.mail-archive.com/syslog@lists.ietf.org/msg00015.html And this is probably the ultimate link, though quite time-consuming: http://www.mail-archive.com/search?q=3D3195%20tcp&l=3Dsyslog@lists.ietf.o= rg& start=3D0 Sorry for that much reading material, but this has been discussed quite controversal. Rainer > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Thursday, February 08, 2007 2:58 PM > To: Sam Hartman > Cc: syslog@ietf.org > Subject: [Syslog] Re: Why we're doing TLS >=20 > Sam, >=20 > I got involved recently because both chairs asked me to submit a draft > to revise 3195 to reflect the work of -protocol-19. I have done so. > And so perhaps you can help me. >=20 > The charter calls for a secure transport. The milestones say TLS > (something that could easily be changed without community review, mind > you). A reasonable person could believe that perhaps we might actually > *build* on the work that was already done with SYSLOG/BEEP/TLS. As I'm > relatively new to the party, I'll accept a pointer to the logic of the > choice. There being an IPR claim against the new work, and the fact > that multiple interoperable implementations of a proposed standard that > could easily go to draft exist, I am hoping that pointer explains why > this group is has put aside both interoperability and basic engineering > principles of reuse. >=20 > Eliot >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 08 09:29:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAGu-00083z-KF; Thu, 08 Feb 2007 09:29:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAGt-00081p-KK for syslog@ietf.org; Thu, 08 Feb 2007 09:29:11 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFAGs-0008QH-C7 for syslog@ietf.org; Thu, 08 Feb 2007 09:29:11 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2007 15:29:10 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l18ET95W025380; Thu, 8 Feb 2007 15:29:09 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp152.cisco.com [10.61.64.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l18ET9C8023878; Thu, 8 Feb 2007 15:29:09 +0100 (MET) Message-ID: <45CB33B1.5040504@cisco.com> Date: Thu, 08 Feb 2007 15:29:05 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Rainer Gerhards Subject: Re: [Syslog] Re: Why we're doing TLS References: <45CADC70.2040701@cisco.com> <45CB2C4A.7070704@cisco.com> <577465F99B41C842AAFBE9ED71E70ABA1F8E4F@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8E4F@grfint2.intern.adiscon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=41; t=1170944949; x=1171808949; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20Re=3A=20Why=20we're=20doing=20TLS |Sender:=20; bh=4RcYukvUa/63RKqTaeCLqZI+k7dw/THystGmJAxVcqc=; b=ReE+eKScN7vmnkrJKz6EiJrIj19lPDlZUjJg4c04QFr/37uCgkpnAeTsVxw+/NDkt54RjlfD eSvMwwOvSqHUN5zkU1ov/upwNhg3dRygvpdr7XZS7g15bTx6ZcdwyCwi; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: syslog@ietf.org, Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Rainer, Thanks. Will read. Eliot _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 08 09:30:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAHm-0000EH-8u; Thu, 08 Feb 2007 09:30:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAHl-0000EA-OV for syslog@ietf.org; Thu, 08 Feb 2007 09:30:05 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFAHk-0000QC-Fx for syslog@ietf.org; Thu, 08 Feb 2007 09:30:05 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BAD03E00B3; Thu, 8 Feb 2007 09:29:55 -0500 (EST) From: Sam Hartman To: Eliot Lear References: <45CADC70.2040701@cisco.com> <45CB2C4A.7070704@cisco.com> Date: Thu, 08 Feb 2007 09:29:54 -0500 In-Reply-To: <45CB2C4A.7070704@cisco.com> (Eliot Lear's message of "Thu, 08 Feb 2007 14:57:30 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: syslog@ietf.org Subject: [Syslog] Re: Why we're doing TLS X-BeenThere: syslog@lists.ietf.org X-Mailman-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 >>>>> "Eliot" == Eliot Lear writes: Eliot> Sam, I got involved recently because both chairs asked me Eliot> to submit a draft to revise 3195 to reflect the work of Eliot> -protocol-19. I have done so. And so perhaps you can help Eliot> me. I'll try! Eliot> The charter calls for a secure transport. The milestones Eliot> say TLS (something that could easily be changed without Eliot> community review, mind you). Hmm. I thought that was in the text of the charter, but you're correct that it is not. It was circulated to the community though with the charter text. I agree it would not require community review to change, although it would be revisiting a WG decision. Eliot> A reasonable person could Eliot> believe that perhaps we might actually *build* on the work Eliot> that was already done with SYSLOG/BEEP/TLS. As I'm Eliot> relatively new to the party, I'll accept a pointer to the Eliot> logic of the choice. There being an IPR claim against the Eliot> new work, and the fact that multiple interoperable Eliot> implementations of a proposed standard that could easily go Eliot> to draft exist, I am hoping that pointer explains why this Eliot> group is has put aside both interoperability and basic Eliot> engineering principles of reuse. I'd recommend asking the chairs here. It's there job to call consensus and to the extent that there is consensus on reasons for decisions (not just the decisions themselves) to be able to explain that. I think that the implementers said they would implement syslog-tls, but not something 3195-based. But I was not heavily involved in that discussion other than to make sure it took place. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 08 12:20:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFCvg-0000w4-JL; Thu, 08 Feb 2007 12:19:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFCve-0000vz-TV for syslog@ietf.org; Thu, 08 Feb 2007 12:19:26 -0500 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFCvc-0000Ez-Rd for syslog@ietf.org; Thu, 08 Feb 2007 12:19:26 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <20070208171924012001despe>; Thu, 8 Feb 2007 17:19:24 +0000 From: "David Harrington" To: "'Sam Hartman'" , "'Eliot Lear'" References: <45CADC70.2040701@cisco.com> <45CB2C4A.7070704@cisco.com> Subject: RE: [Syslog] Re: Why we're doing TLS Date: Thu, 8 Feb 2007 12:15:18 -0500 Message-ID: <0f3f01c74ba4$b5281090$0600a8c0@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.2962 In-reply-to: Thread-index: AcdLjaCVlsLS8aVgScWb0y3DoM1aFwABnbiw 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 Hi, [speaking as co-chair] Rainer has provided the links to the email discussions of this topic. >From my point of view this was pretty straightforward. We have implementers very involved in this WG, and the implementers expressed a strong interest in TLS. They did not express a strong interest in BEEP. The interest in TLS was so strong, it withstood the challenge of overcoming an IPR disclosure and was preferred over proposals for using SSH or DTLS instead. I think there is a fallacy involved in claiming this is a reinvention of the wheel. BEEP offers certain functionality **in addition** to the functionality provided by using TLS. The WG decided the functionality provided by TLS is important; the additional functionality provided by having a BEEP layer between syslog and TLS is just not as important to most users, and it is seen as unnecessary complexity for most syslog usages. The WG consensus was very clear that TLS alone was preferred over BEEP/TLS. As co-chair, I struggle with whether there is enough interest in BEEP to justify doing 3195bis rather than just moving 3195 to experimental or historic. I see much less WG consensus on the importance of updating 3195. The one segment of the syslog industry that has shown an interest in 3195 is the IHE, an organization whose mission is to promote the adoption of standards for the healthcare industry. According to comments posted to the syslog WG, they have seen little actual deployment of 3195 despite their efforts to promote it. So if we are going to question whether one or the other solution should be dropped, it is pretty clear to me as co-chair which one should go. I have deliberately NOT looked to see if WG consensus is to drop 3195 because the dialogue about whether 3195 is in use is still ongoing, and 3195bis is not yet part of our charter. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Thursday, February 08, 2007 9:30 AM > To: Eliot Lear > Cc: syslog@ietf.org > Subject: [Syslog] Re: Why we're doing TLS > > >>>>> "Eliot" == Eliot Lear writes: > > Eliot> Sam, I got involved recently because both chairs asked me > Eliot> to submit a draft to revise 3195 to reflect the work of > Eliot> -protocol-19. I have done so. And so perhaps you can help > Eliot> me. > > I'll try! > > Eliot> The charter calls for a secure transport. The milestones > Eliot> say TLS (something that could easily be changed without > Eliot> community review, mind you). > > Hmm. I thought that was in the text of the charter, but you're > correct that it is not. It was circulated to the community though > with the charter text. I agree it would not require community review > to change, although it would be revisiting a WG decision. > > > Eliot> A reasonable person could > Eliot> believe that perhaps we might actually *build* on the work > Eliot> that was already done with SYSLOG/BEEP/TLS. As I'm > Eliot> relatively new to the party, I'll accept a pointer to the > Eliot> logic of the choice. There being an IPR claim against the > Eliot> new work, and the fact that multiple interoperable > Eliot> implementations of a proposed standard that could easily go > Eliot> to draft exist, I am hoping that pointer explains why this > Eliot> group is has put aside both interoperability and basic > Eliot> engineering principles of reuse. > > I'd recommend asking the chairs here. It's there job to call > consensus and to the extent that there is consensus on reasons for > decisions (not just the decisions themselves) to be able to explain > that. > > I think that the implementers said they would implement syslog-tls, > but not something 3195-based. But I was not heavily involved in that > discussion other than to make sure it took place. > > > _______________________________________________ > 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 Feb 08 12:35:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFDAZ-0002Bk-CF; Thu, 08 Feb 2007 12:34:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFDAY-0002Be-0U for syslog@ietf.org; Thu, 08 Feb 2007 12:34:50 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFDAW-0004LL-Nw for syslog@ietf.org; Thu, 08 Feb 2007 12:34:49 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007020817344801500dng1ce>; Thu, 8 Feb 2007 17:34:48 +0000 From: "David Harrington" To: "'Sam Hartman'" , "'Eliot Lear'" References: <45CADC70.2040701@cisco.com> <45CB2C4A.7070704@cisco.com> Subject: RE: [Syslog] Re: Why we're doing TLS Date: Thu, 8 Feb 2007 12:30:43 -0500 Message-ID: <0f4101c74ba6$dcc04170$0600a8c0@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.2962 In-reply-to: Thread-index: AcdLjaCVlsLS8aVgScWb0y3DoM1aFwAFyj1g X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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, [speaking as a contributor] I learned a lesson about standards while working on SNMPv3. The cost of added features required by only a segment of the market should be borne only by that segment of the market. Just because one segment of the market wants the functionality of an extra feature, that is not a strong argument for forcing everybody to support the extra feature. A standard is better when the core functionailty wanted by everybody is made mandatory, and add-on features are optional, to be implemented/deployed only by those who want those features. As we discussed message sizes in syslog, members of the IHE community pushed for very large messages. The WG questioned whether the usage proposed by IHE was within the applicability scope of syslog, which is primarily designed for logging small messages to alert operators of system anomalies. The WG chose to recommend the use of small messsages, but to allow for implementations to choose to support large messages, to meet this demand from one segment of the syslog community. I have not argued against doing 3195bis because that same segment of the syslog community, members of the IHE, has stated there is no viable alternative to 3195, and they would rather use a standard protocol than invent a new one. They like the reliability provided by BEEP. In my opinion, the rest of the community should not be forced to implement BEEP to get TLS just because there is a special interest group that wants BEEP. My impression as a contributor is that the WG is willing to allow the option of BEEP as a supplement to TLS, although some implementers have said they would not support it in their products until there was customer demand for it. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Thursday, February 08, 2007 9:30 AM > To: Eliot Lear > Cc: syslog@ietf.org > Subject: [Syslog] Re: Why we're doing TLS > > >>>>> "Eliot" == Eliot Lear writes: > > Eliot> Sam, I got involved recently because both chairs asked me > Eliot> to submit a draft to revise 3195 to reflect the work of > Eliot> -protocol-19. I have done so. And so perhaps you can help > Eliot> me. > > I'll try! > > Eliot> The charter calls for a secure transport. The milestones > Eliot> say TLS (something that could easily be changed without > Eliot> community review, mind you). > > Hmm. I thought that was in the text of the charter, but you're > correct that it is not. It was circulated to the community though > with the charter text. I agree it would not require community review > to change, although it would be revisiting a WG decision. > > > Eliot> A reasonable person could > Eliot> believe that perhaps we might actually *build* on the work > Eliot> that was already done with SYSLOG/BEEP/TLS. As I'm > Eliot> relatively new to the party, I'll accept a pointer to the > Eliot> logic of the choice. There being an IPR claim against the > Eliot> new work, and the fact that multiple interoperable > Eliot> implementations of a proposed standard that could easily go > Eliot> to draft exist, I am hoping that pointer explains why this > Eliot> group is has put aside both interoperability and basic > Eliot> engineering principles of reuse. > > I'd recommend asking the chairs here. It's there job to call > consensus and to the extent that there is consensus on reasons for > decisions (not just the decisions themselves) to be able to explain > that. > > I think that the implementers said they would implement syslog-tls, > but not something 3195-based. But I was not heavily involved in that > discussion other than to make sure it took place. > > > _______________________________________________ > 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 Feb 08 12:40:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFDFm-0004b4-Vo; Thu, 08 Feb 2007 12:40:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFDFl-0004ay-AN for syslog@ietf.org; Thu, 08 Feb 2007 12:40:13 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFDFk-0005GP-1i for syslog@ietf.org; Thu, 08 Feb 2007 12:40:13 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2007 18:40:10 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l18He9TE019232; Thu, 8 Feb 2007 18:40:09 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp152.cisco.com [10.61.64.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l18He8C8018994; Thu, 8 Feb 2007 18:40:08 +0100 (MET) Message-ID: <45CB6074.9020703@cisco.com> Date: Thu, 08 Feb 2007 18:40:04 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: David Harrington Subject: Re: [Syslog] Re: Why we're doing TLS References: <45CADC70.2040701@cisco.com> <45CB2C4A.7070704@cisco.com> <0f3f01c74ba4$b5281090$0600a8c0@china.huawei.com> In-Reply-To: <0f3f01c74ba4$b5281090$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=405; t=1170956409; x=1171820409; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20Re=3A=20Why=20we're=20doing=20TLS |Sender:=20; bh=40qYTbYCzm3Dyr/2QBvtHFde7HZ4J+Ff+2DwxViTY+w=; b=Sk1zQpz8pfgdxxc6a4WPROujmuhB0KFlEbTPZAt6SCBi90JXoh9HEPvDJvA2Y4PB0Q849kx8 nU26SKZi4UY3rGL8hcBLfhY4DrPU7R5sgrLx6CpSsHGp3RrxNCkZgNrg; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: syslog@ietf.org, 'Sam Hartman' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Dave, I have read over not only the mailing list but the drafts involved. The result quite frankly is perverse. By implementing framing on top of TLS you are in fact REINVENTING BEEP only without the profile, mandatory TLS, and without the possibility for use of SASL. You may not have started at this point - but that's where you are today. So you *are* reinventing the wheel. Eliot _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 08 12:40:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFDGN-0004gP-RB; Thu, 08 Feb 2007 12:40:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFDGM-0004gG-8f for syslog@ietf.org; Thu, 08 Feb 2007 12:40:50 -0500 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFDGJ-0005M8-QN for syslog@ietf.org; Thu, 08 Feb 2007 12:40:50 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 403749C00C; Thu, 8 Feb 2007 18:57:32 +0100 (CET) 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 14840-05; Thu, 8 Feb 2007 18:57:23 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id E71779C00B; Thu, 8 Feb 2007 18:57:23 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Re: Why we're doing TLS X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 Feb 2007 18:40:34 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8E50@grfint2.intern.adiscon.com> In-Reply-To: <0f4101c74ba6$dcc04170$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Re: Why we're doing TLS Thread-Index: AcdLjaCVlsLS8aVgScWb0y3DoM1aFwAFyj1gAADTKYA= References: <45CADC70.2040701@cisco.com><45CB2C4A.7070704@cisco.com> <0f4101c74ba6$dcc04170$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" , "Sam Hartman" , "Eliot Lear" X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 can fully back David's statement as someone who actually *has* implemented 3195. We will not do any further 3195 implementation efforts until some real market demand manifests. The current number of deployments (after 3 or 4 years) is ... zero! We are interested in TLS and will implement it when available. I have already implemented the framing from syslog-tls and seen that it solves real-world problems. The primary reason for implementig it was the need for some (non-standardized) features that I could not get without it or with the traditional LF-based framing. Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, February 08, 2007 6:31 PM > To: 'Sam Hartman'; 'Eliot Lear' > Cc: syslog@ietf.org > Subject: RE: [Syslog] Re: Why we're doing TLS >=20 > Hi, >=20 > [speaking as a contributor] >=20 > I learned a lesson about standards while working on SNMPv3. The cost > of added features required by only a segment of the market should be > borne only by that segment of the market. >=20 > Just because one segment of the market wants the functionality of an > extra feature, that is not a strong argument for forcing everybody to > support the extra feature. A standard is better when the core > functionailty wanted by everybody is made mandatory, and add-on > features are optional, to be implemented/deployed only by those who > want those features. >=20 > As we discussed message sizes in syslog, members of the IHE community > pushed for very large messages. The WG questioned whether the usage > proposed by IHE was within the applicability scope of syslog, which is > primarily designed for logging small messages to alert operators of > system anomalies. The WG chose to recommend the use of small > messsages, but to allow for implementations to choose to support large > messages, to meet this demand from one segment of the syslog > community. >=20 > I have not argued against doing 3195bis because that same segment of > the syslog community, members of the IHE, has stated there is no > viable alternative to 3195, and they would rather use a standard > protocol than invent a new one. They like the reliability provided by > BEEP. >=20 > In my opinion, the rest of the community should not be forced to > implement BEEP to get TLS just because there is a special interest > group that wants BEEP. My impression as a contributor is that the WG > is willing to allow the option of BEEP as a supplement to TLS, > although some implementers have said they would not support it in > their products until there was customer demand for it. >=20 > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: Thursday, February 08, 2007 9:30 AM > > To: Eliot Lear > > Cc: syslog@ietf.org > > Subject: [Syslog] Re: Why we're doing TLS > > > > >>>>> "Eliot" =3D=3D Eliot Lear writes: > > > > Eliot> Sam, I got involved recently because both chairs asked me > > Eliot> to submit a draft to revise 3195 to reflect the work of > > Eliot> -protocol-19. I have done so. And so perhaps you can > help > > Eliot> me. > > > > I'll try! > > > > Eliot> The charter calls for a secure transport. The milestones > > Eliot> say TLS (something that could easily be changed without > > Eliot> community review, mind you). > > > > Hmm. I thought that was in the text of the charter, but you're > > correct that it is not. It was circulated to the community though > > with the charter text. I agree it would not require community > review > > to change, although it would be revisiting a WG decision. > > > > > > Eliot> A reasonable person could > > Eliot> believe that perhaps we might actually *build* on the > work > > Eliot> that was already done with SYSLOG/BEEP/TLS. As I'm > > Eliot> relatively new to the party, I'll accept a pointer to the > > Eliot> logic of the choice. There being an IPR claim against > the > > Eliot> new work, and the fact that multiple interoperable > > Eliot> implementations of a proposed standard that could easily > go > > Eliot> to draft exist, I am hoping that pointer explains why > this > > Eliot> group is has put aside both interoperability and basic > > Eliot> engineering principles of reuse. > > > > I'd recommend asking the chairs here. It's there job to call > > consensus and to the extent that there is consensus on reasons for > > decisions (not just the decisions themselves) to be able to explain > > that. > > > > I think that the implementers said they would implement syslog-tls, > > but not something 3195-based. But I was not heavily involved in > that > > discussion other than to make sure it took place. > > > > > > _______________________________________________ > > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Feb 08 13:57:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFERz-0004x5-Tn; Thu, 08 Feb 2007 13:56:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFERz-0004uU-1m for syslog@ietf.org; Thu, 08 Feb 2007 13:56:55 -0500 Received: from ext-nj2ut-2.online-age.net ([64.14.54.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFERc-0007aA-Rp for syslog@ietf.org; Thu, 08 Feb 2007 13:56:55 -0500 Received: from int-nj2ut-2.online-age.net (int-nj2ut-2.online-age.net [3.159.237.71]) by ext-nj2ut-2.online-age.net (8.13.6/8.13.6/20051114-SVVS-TLS-DNSBL) with ESMTP id l18IuRTQ008288 for ; Thu, 8 Feb 2007 13:56:27 -0500 Received: from cinmlef11.e2k.ad.ge.com (int-nj2ut-2.online-age.net [3.159.237.71]) by int-nj2ut-2.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP id l18IuQjL008711 for ; Thu, 8 Feb 2007 13:56:27 -0500 Received: from ALPMLVEM07.e2k.ad.ge.com ([3.159.17.65]) by cinmlef11.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 8 Feb 2007 13:56:26 -0500 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] Re: Why we're doing TLS Date: Thu, 8 Feb 2007 13:56:23 -0500 Message-ID: In-Reply-To: <0f4101c74ba6$dcc04170$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Re: Why we're doing TLS Thread-Index: AcdLjaCVlsLS8aVgScWb0y3DoM1aFwAFyj1gAAN+UxA= References: <45CADC70.2040701@cisco.com><45CB2C4A.7070704@cisco.com> <0f4101c74ba6$dcc04170$0600a8c0@china.huawei.com> From: "Moehrke, John \(GE Healthcare\)" To: "David Harrington" , "Sam Hartman" , "Eliot Lear" X-OriginalArrivalTime: 08 Feb 2007 18:56:26.0339 (UTC) FILETIME=[D59C2330:01C74BB2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 Healthcare doesn't demand beep, actually beep has been a problem for us as well. We choose 3195 because there was no viable alternative. We have paid the price of no implementations. I think that the current path of syslog is ok with us. The MTU is sensitive, and I like your proposal to deal with that. We eagerly await and encourage the current syslog-protocol work. John=20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, February 08, 2007 11:31 AM > To: 'Sam Hartman'; 'Eliot Lear' > Cc: syslog@ietf.org > Subject: RE: [Syslog] Re: Why we're doing TLS >=20 > Hi, >=20 > [speaking as a contributor] >=20 > I learned a lesson about standards while working on SNMPv3. The cost > of added features required by only a segment of the market should be > borne only by that segment of the market.=20 >=20 > Just because one segment of the market wants the functionality of an > extra feature, that is not a strong argument for forcing everybody to > support the extra feature. A standard is better when the core > functionailty wanted by everybody is made mandatory, and add-on > features are optional, to be implemented/deployed only by those who > want those features.=20 >=20 > As we discussed message sizes in syslog, members of the IHE community > pushed for very large messages. The WG questioned whether the usage > proposed by IHE was within the applicability scope of syslog, which is > primarily designed for logging small messages to alert operators of > system anomalies. The WG chose to recommend the use of small > messsages, but to allow for implementations to choose to support large > messages, to meet this demand from one segment of the syslog > community. >=20 > I have not argued against doing 3195bis because that same segment of > the syslog community, members of the IHE, has stated there is no > viable alternative to 3195, and they would rather use a standard > protocol than invent a new one. They like the reliability provided by > BEEP.=20 >=20 > In my opinion, the rest of the community should not be forced to > implement BEEP to get TLS just because there is a special interest > group that wants BEEP. My impression as a contributor is that the WG > is willing to allow the option of BEEP as a supplement to TLS, > although some implementers have said they would not support it in > their products until there was customer demand for it.=20 >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > > Sent: Thursday, February 08, 2007 9:30 AM > > To: Eliot Lear > > Cc: syslog@ietf.org > > Subject: [Syslog] Re: Why we're doing TLS > >=20 > > >>>>> "Eliot" =3D=3D Eliot Lear writes: > >=20 > > Eliot> Sam, I got involved recently because both chairs asked me > > Eliot> to submit a draft to revise 3195 to reflect the work of > > Eliot> -protocol-19. I have done so. And so perhaps you can > help > > Eliot> me. > >=20 > > I'll try! > >=20 > > Eliot> The charter calls for a secure transport. The milestones > > Eliot> say TLS (something that could easily be changed without > > Eliot> community review, mind you). =20 > >=20 > > Hmm. I thought that was in the text of the charter, but you're > > correct that it is not. It was circulated to the community though > > with the charter text. I agree it would not require community > review > > to change, although it would be revisiting a WG decision. > >=20 > >=20 > > Eliot> A reasonable person could > > Eliot> believe that perhaps we might actually *build* on the > work > > Eliot> that was already done with SYSLOG/BEEP/TLS. As I'm > > Eliot> relatively new to the party, I'll accept a pointer to the > > Eliot> logic of the choice. There being an IPR claim against > the > > Eliot> new work, and the fact that multiple interoperable > > Eliot> implementations of a proposed standard that could easily > go > > Eliot> to draft exist, I am hoping that pointer explains why > this > > Eliot> group is has put aside both interoperability and basic > > Eliot> engineering principles of reuse. > >=20 > > I'd recommend asking the chairs here. It's there job to call > > consensus and to the extent that there is consensus on reasons for > > decisions (not just the decisions themselves) to be able to explain > > that. > >=20 > > I think that the implementers said they would implement syslog-tls, > > but not something 3195-based. But I was not heavily involved in > that > > discussion other than to make sure it took place. > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Feb 09 06:34:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFU0E-0007Nq-Ni; Fri, 09 Feb 2007 06:33:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFU0B-0007NM-NA for syslog@ietf.org; Fri, 09 Feb 2007 06:33:16 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFU0A-0008PY-7B for syslog@ietf.org; Fri, 09 Feb 2007 06:33:15 -0500 Received: from pc6 (1Cust218.tnt28.lnd4.gbr.da.uu.net [62.188.156.218]) by ranger.systems.pipex.net (Postfix) with SMTP id 6E08EE000636; Fri, 9 Feb 2007 11:33:00 +0000 (GMT) Message-ID: <024d01c74c35$770bfb00$0601a8c0@pc6> From: "tom.petch" To: References: Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls Date: Fri, 9 Feb 2007 11:03:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 Robert I am unclear how you achieve authentication of the process as opposed to the source machine and what demands, if any, that makes on syslog-transport-tls. I see certificates sent by TLS as authenticating 'TLS' (omitting discussions about what ever is authenticated, identity, person, process, machine ...) and only authenticating something else to the extent that that is securely bound to TLS so your choice lies outside the scope of syslog-transport-tls. Or is there some requirement on this I-D that I have not grasped, such as having syslog-specific information in the certs? Tom Petch ----- Original Message ----- From: To: "'Sam Hartman'" Cc: Sent: Wednesday, February 07, 2007 5:18 PM Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls transport-tls should be designed to enable policy decisions. This group is not able to make policy decisions. Some of this discussion is really policy making. Policy discussions within syslog should be oriented towards ensuring that any reasonable policy can be properly supported. For example, in my real world situations, the primary policy concern is disclosure of audit information to unauthorized recipients. This means that the encryption aspect is most important, not the authentications. I can deal with a degree of uncertainty about the source and destination authentications. If you look inside what authentication really means to us you find several kinds of authentication to manage: - Is the source machine authenticated and authorized to be on the network? - Is the source machine/process authenticated and authorized to be a source of audit information? - The symetric questions for the destination machine. My destination accepts all connections and has different processing policies for incoming syslog information for the categories: - unauthenticated machine source - authenticated machine source, unauthenticated process - authenticated machine source and process The differences are a degree of confidence about various source characteristics. No authentication ensures complete confidence, because it is possible that both the source machine and process have been penetrated by a hostile attacker. The chain of trust to the various root certificate authorities is not important. Suppose I get a good certificate signed by the ABA. What does that mean? Does the ABA know what machines are authorized to be on my network? no. It means that someone with good credentials paid the ABA money to get a certificate for that identity. I will treat is as an unauthenticated machine. Suppose I get a certificate with a chain of signatures, the last of which is my local hospital administration. All those earlier signatures mean as little as the ABA signature. But that signature from the local hospital administration means something. Now I will consider this machine to be an authenticated machine source. (Process might still be unclear.) I don't need the rest of the chain. A self-signed hospital administration CA is good enough. This can save money and bother. The source side rule gets even stricter. A hospital administration CA signature is not enough. They sign all the internal machine certificates. I need the cert contents to be right. Or, (more commonly) I demand that the destination certificate match the single public cert that I provide to authenticated source processes for logging. This cert is self-signed by the syslog destination machine. The authorized internal machines and processes use this to ensure that they have connected to the right destination. Now I have all three different categories that derive from my policies. The chain of trust back to root CAs was not used much. What I really need is just the portion to the CA for the hospital. It might happen to be traceable to a root CA, but that doesn't matter in this situation. I can even live without it on a small network, by inverting the relationship and copying the self-signed public certs of the authorized source systems over to the destination server. This doesn't scale well, but for small networks it can be easier than setting up the local CA. R Horn -------------------------------------------------------------------------------- > _______________________________________________ > 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 Feb 14 13:28:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOqn-0003qZ-PI; Wed, 14 Feb 2007 13:27:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOqm-0003qU-NG for syslog@ietf.org; Wed, 14 Feb 2007 13:27:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHOql-0006Uj-13 for syslog@ietf.org; Wed, 14 Feb 2007 13:27:28 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2007 10:27:24 -0800 X-IronPort-AV: i="4.14,170,1170662400"; d="scan'208"; a="39479451:sNHT51144507" 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/8.12.11) with ESMTP id l1EIROup002668; Wed, 14 Feb 2007 10:27:24 -0800 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 l1EIRMUx021179; Wed, 14 Feb 2007 10:27:22 -0800 (PST) Date: Wed, 14 Feb 2007 10:27:21 -0800 (PST) From: Chris Lonvick To: David Harrington Subject: RE: [Syslog] Re: Why we're doing TLS In-Reply-To: <0f3f01c74ba4$b5281090$0600a8c0@china.huawei.com> Message-ID: References: <45CADC70.2040701@cisco.com> <45CB2C4A.7070704@cisco.com> <0f3f01c74ba4$b5281090$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5181; t=1171477644; x=1172341644; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20RE=3A=20[Syslog]=20Re=3A=20Why=20we're=20doing=20TLS |Sender:=20; bh=57hujGUtObGJdZ54g1es5m5lyfl5u32AWwTm0RFXjPI=; b=bw5NrPtmMfym46pn+AXq0pzZ8vIVNl3KijHSonAU9KlYutQ3slZy/2kPn1MPwGdYhF+C5S90 jR+g5k8CLVo+5LBG2D9jyHkIvo4sA2Q/pWEbD0Zzh8TmywpJBbqUngO+; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: syslog@ietf.org, 'Sam Hartman' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi All, Apologies for the delay - I've still got a very heavy travel schedule for the rest of this week and most of next. I agree that the WG consensus is to produce syslog-transport-tls. Alex is re-drafting syslog-sign to ride atop syslog-protocol. This will remove the dependencies of 3164 and 3195 from syslog-sign. I would like to see the work on 3195bis proceed to complete that effort and allow it to be used as another transport for syslog-protocol. I believe that it has beneficial characteristics that are not covered in syslog-transport-tls nor syslog-transport-udp. Thanks, Chris On Thu, 8 Feb 2007, David Harrington wrote: > Hi, > > [speaking as co-chair] > > Rainer has provided the links to the email discussions of this topic. > >> From my point of view this was pretty straightforward. We have > implementers very involved in this WG, and the implementers expressed > a strong interest in TLS. They did not express a strong interest in > BEEP. The interest in TLS was so strong, it withstood the challenge of > overcoming an IPR disclosure and was preferred over proposals for > using SSH or DTLS instead. > > I think there is a fallacy involved in claiming this is a reinvention > of the wheel. BEEP offers certain functionality **in addition** to the > functionality provided by using TLS. The WG decided the functionality > provided by TLS is important; the additional functionality provided by > having a BEEP layer between syslog and TLS is just not as important to > most users, and it is seen as unnecessary complexity for most syslog > usages. > > The WG consensus was very clear that TLS alone was preferred over > BEEP/TLS. > > As co-chair, I struggle with whether there is enough interest in BEEP > to justify doing 3195bis rather than just moving 3195 to experimental > or historic. I see much less WG consensus on the importance of > updating 3195. The one segment of the syslog industry that has shown > an interest in 3195 is the IHE, an organization whose mission is to > promote the adoption of standards for the healthcare industry. > According to comments posted to the syslog WG, they have seen little > actual deployment of 3195 despite their efforts to promote it. > > So if we are going to question whether one or the other solution > should be dropped, it is pretty clear to me as co-chair which one > should go. > > I have deliberately NOT looked to see if WG consensus is to drop 3195 > because the dialogue about whether 3195 is in use is still ongoing, > and 3195bis is not yet part of our charter. > > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > >> -----Original Message----- >> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >> Sent: Thursday, February 08, 2007 9:30 AM >> To: Eliot Lear >> Cc: syslog@ietf.org >> Subject: [Syslog] Re: Why we're doing TLS >> >>>>>>> "Eliot" == Eliot Lear writes: >> >> Eliot> Sam, I got involved recently because both chairs asked me >> Eliot> to submit a draft to revise 3195 to reflect the work of >> Eliot> -protocol-19. I have done so. And so perhaps you can > help >> Eliot> me. >> >> I'll try! >> >> Eliot> The charter calls for a secure transport. The milestones >> Eliot> say TLS (something that could easily be changed without >> Eliot> community review, mind you). >> >> Hmm. I thought that was in the text of the charter, but you're >> correct that it is not. It was circulated to the community though >> with the charter text. I agree it would not require community > review >> to change, although it would be revisiting a WG decision. >> >> >> Eliot> A reasonable person could >> Eliot> believe that perhaps we might actually *build* on the > work >> Eliot> that was already done with SYSLOG/BEEP/TLS. As I'm >> Eliot> relatively new to the party, I'll accept a pointer to the >> Eliot> logic of the choice. There being an IPR claim against > the >> Eliot> new work, and the fact that multiple interoperable >> Eliot> implementations of a proposed standard that could easily > go >> Eliot> to draft exist, I am hoping that pointer explains why > this >> Eliot> group is has put aside both interoperability and basic >> Eliot> engineering principles of reuse. >> >> I'd recommend asking the chairs here. It's there job to call >> consensus and to the extent that there is consensus on reasons for >> decisions (not just the decisions themselves) to be able to explain >> that. >> >> I think that the implementers said they would implement syslog-tls, >> but not something 3195-based. But I was not heavily involved in > that >> discussion other than to make sure it took place. >> >> >> _______________________________________________ >> 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 Feb 18 03:44:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIhe6-0004yU-H3; Sun, 18 Feb 2007 03:43:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIhe5-0004yO-Eu for syslog@ietf.org; Sun, 18 Feb 2007 03:43:45 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIhe3-0003WK-3Z for syslog@ietf.org; Sun, 18 Feb 2007 03:43:45 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l1I8hEpE011399 for ; Sun, 18 Feb 2007 17:43:14 +0900 (JST) Received: from [127.0.0.1] (kiras8.priv.cysol.co.jp [192.168.0.158]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l1I8hCsN024125 for ; Sun, 18 Feb 2007 17:43:13 +0900 (JST) Message-ID: <45D8119F.6000208@cysols.com> Date: Sun, 18 Feb 2007 17:43:11 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Mib issues and resolutions References: <0d5701c74af9$b7e32fa0$0600a8c0@china.huawei.com> In-Reply-To: <0d5701c74af9$b7e32fa0$0600a8c0@china.huawei.com> Content-Type: multipart/mixed; boundary="------------060600090007020502000104" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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 This is a multi-part message in MIME format. --------------060600090007020502000104 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi, David asked for a "quick summary" for the WG. I have prepared a document which is not quick and is not much of a summary. It provides - pointers to the mails where issues were raised, - the originator of the mail, - the main issues, - the action and, - the conclusion. It will be useful if you use this "summary" along with some mail archive tool (the wg archive covers only the last few days, you may try http://www.cysol.co.jp/contrib/syslogmib/threads.html) Please note: a. It covers only discussions related to the MIB, issues related to other documents are not covered. b. It covers the period starting from the WGLC c. The list of main issues for each mail is not exhaustive. The positions of individuals and the pros and cons are not included. Please refer to the original the mail if you are looking for a detailed list. Please let me know if I have missed some threads. Cheers Glenn David Harrington wrote: > Hi Glenn and Alex, > > Can you provide a quick summary for the WG of the issues that have > been raised regarding the mib document and the sign document since the > beginning of the WGLC (which started 9-11-06 and 8-28-06 > respectively), pointers to the threads where discussions of the issues > were held, the list of names for people who specifically took a > posiiton on the issue, and what you percieve to be the WG consensus on > the issues based on the stated positions? > > As we near the end of the work on these documents, we will need these > summaries for AD review. > > Thanks, > 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 --------------060600090007020502000104 Content-Type: text/plain; name="QuickSummaryOfComments.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="QuickSummaryOfComments.txt" CgpbU3lzbG9nXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbDogc3lzbG9nLW1pYiBkb2N1bWVu dCwgRGF2aWQgQiBIYXJyaW5ndG9uIAogICBSZTogW1N5c2xvZ10gV29ya2luZyBHcm91cCBM YXN0IENhbGw6IHN5c2xvZy1taWIgZG9jdW1lbnQsIHRvbS5wZXRjaCAKICAgCiAgIFRoZSAi c3ViamVjdCIgb2YgdGhlIE1JQiAgICAgICAgICAgICAgPT4gIkVudGl0eSIgCiAgIE9uZSBv ciBtb3JlIHN5c2xvZyBlbnRpdGllcyBwZXIgTUlCID8gPT4gTXVsdGlwbGUgZW50aXRpZXMu IAoKUkU6IFtTeXNsb2ddIE1JQiBkb2N1bWVudCBkZWNpc2lvbiwgQWxleGFuZGVyIENsZW1t IChhbGV4KSAKICAgVG8gaGFuZGxlIFN5c2xvZ1NpZ24gb3Igbm90LgogICBXRyBwb2xsZWQu IE5vIHJlc3BvbnNlLiAgICAgICAgICAgICAgID0+IExlYXZlIGZvciBsYXRlciAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICggU2VwYXJhdGUgRG9jdW1l bnQpCiAgICAgICAgICAgICAgICAgICAKW1N5c2xvZ10gV0dMQyByZXN1bHRzIDogU3lzbG9n LU1JQiwgR2xlbm4gTS4gS2VlbmkgCltTeXNsb2ddIFJFOiBSZXF1ZXN0IGZvciBSZXZpZXdl cnMgLSBkcmFmdC1pZXRmLXN5c2xvZy1kZXZpY2UtbWliLTA5LnR4dCwgV2lqbmVuLCBCZXJ0 IChCZXJ0KSAKICAgU01JQ25nIGVycm9ycyAgICAgICAgICAgICAgICAgICAgICAgICA9PiBE b25lIAogICBNSUIgbml0cyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0+IERvbmUK ICAgc3lzbG9nLXRyYW5zcG9ydCBvdmVyIHRscyAgICAgICAgICAgICAtPiBkaXNjdXNzZWQg PT4gcmV2aXNlZAogICAKW1N5c2xvZ10gRGJoIFJldmlldyBvZiAtbWliLTA5LCBwYXJ0IDEs IERhdmlkIEhhcnJpbmd0b24gCiAgIElELW5pdHMKICAgVGVybWlub2xvZ3k6IHNlbmRlciwg cmVjZWl2ZXIsIHJlbGF5ICAtPiBEaXNjdXNzZWQgPT4gRW50aXR5CiAgIFN5c2xvZ1NldmVy aXR5OiAib3RoZXIiICAgICAgICAgICAgICAgLT4gRGlzY3Vzc2VkIAogICBzeXNsb2ctdHJh bnNwb3J0ICAgICAgICAgICAgICAgICAgICAgIC0+IERpc2N1c3NlZCA9PiByZXZpc2UgICAg ICAgIAogICBzeXNsRW50T3BzTXNnc0lnbm9yZWQ6IHVuY2xlYXIgICAgICAgIC0+IERpc2N1 c3NlZCA9PiByZXZpc2UKICAgc3lzbEVudE9wc0xhc3RFcnJvcjogdW5jbGVhciAgICAgICAg ICAtPiBEaXNjdXNzZWQgPT4gcmV2aXNlCiAgIHN5c2xFbnRPcHNSZWZlcmVuY2U6IHVuY2xl YXIgICAgICAgICAgLT4gRGlzY3Vzc2VkID0+IHJldmlzZQoKW1N5c2xvZ10gRGJoIHJlLVJl dmlldyBvZiAtbWliLTExLCBwYXJ0IDEsIERhdmlkIEhhcnJpbmd0b24gCiAgIFRlcm1pbm9s b2d5OiBzZW5kZXIsIHJlY2VpdmVyLCByZWxheSAgLT4gRGlzY3Vzc2VkID0+IEVudGl0eQog ICBTeXNsb2dTZXZlcml0eTogIm90aGVyIiB1c2FnZSA/ICAgICAgIC0+IERpc2N1c3NlZAog ICBTeXNsb2dTZXJ2aWNlOiBVRFAvVENQID8gICAgICAgICAgICAgIC0+IERpc2N1c3NlZCAK ICAgRGVzY3JpcHRpdmUgSW5kaWNlcyAgICAgICAgICAgICAgICAgICAtPiBEaXNjdXNzZWQg PT4gVXNlIERlc2NyaXB0aW9uIE1PcyAKICAgc3lzbEVudE9wc01zZ3NJZ25vcmVkOiBBbGxv d2VkIFNwZWNzPyAtPiBEaXNjdXNzZWQgCiAgIHN5c2xFbnRPcHNMYXN0RXJyb3I6IHVuY2xl YXIgICAgICAgICAgLT4gQ2xhcmlmaWVkID0+IHJldmlzZQoKW1N5c2xvZ10gRGJoIHJlLXJl dmlldyBvZiBNaWItMTEtLCBwYXJ0IDIsIERhdmlkIEIgSGFycmluZ3RvbiAKICAgdHJhbnNw b3J0QWRkcmVzc1R5cGUvU2VydmljZSB1bmNsZWFyICAtPiBEaXNjdXNzZWQKICAgc3lzbG9n RW50aXR5Q29udHJvbFN0b3JhZ2VUeXBlICAgICAgICAtPiBEaXNjdXNzZWQgPT4gcmV2aXNl CiAgIG5vdGlmaWNhdGlvbnM6IERlc2NyaXB0aW9uIHVuY2xlYXIgICAgLT4gRGlzY3Vzc2Vk ID0+IHJldmlzZQogICBub3RpZmljYXRpb25zOiBtYW5kYXRvcnkvb3B0aW9uYWwgPyAgIC0+ IENsYXJpZmllZCA9PiBvcHRpb25hbAogICB0cmFuc3BvcnQgc2VjdXJpdHk6IGRpc2N1c3Mg PyAgICAgICAgIC0+IERpc2N1c3NlZCA9PiBjb21tZW50IHdpdGhkcmF3bgoKW1N5c2xvZ10g LW1pYi0sIHBhcnQgMywgRGF2aWQgSGFycmluZ3RvbiAKICAgQWRkIGNvbmdlc3Rpb24gYXZv aWRhbmNlID8gICAgICAgICAgICAtPiBObyByZWFjdGlvbiBmcm9tIFdHCgpbU3lzbG9nXSBS ZXZpZXcgb2YgTWliLTEwLCBwYXJ0IDEsIERhdmlkIEhhcnJpbmd0b24gCiAgIG1haW5seSBJ RCwgTUlCIG5pdHMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0+IGZpeAoKW1N5 c2xvZ10gTWliIC0xMC0sIHBhcnQgMiwgRGF2aWQgSGFycmluZ3RvbiAKICAgVGVybWlub2xv Z3kgICAgICAgICAgICAgICAgICAgICAgICAgICAtPiBEaXNjdXNzZWQgZWFybGllcgogICBP bmUgb3IgbW9yZSBzeXNsb2cgZW50aXRpZXMgcGVyIE1JQiA/IC0+IERpc2N1c3NlZCBlYXJs aWVyCgpbU3lzbG9nXSBSZXZpZXcgb2YgbWliLTExLCBwYXJ0IDMsIERhdmlkIEhhcnJpbmd0 b24gCiAgIFB1cnBvc2Ugb2YgRGVmYXVsdCBwYXJhbWV0ZXJzICAgICAgICAgLT4gRXhwbGFp bmVkCgpbU3lzbG9nXSBTeXNsb2ctbWliLTExLCBEYXZpZCBIYXJyaW5ndG9uIAogICBPbmUg b3IgbW9yZSBzeXNsb2cgZW50aXRpZXMgcGVyIE1JQiA/IC0+IERpc2N1c3NlZCA9PiBtdWx0 aXBsZSBlbnRpdGllcyAKCltTeXNsb2ddIFN5c2xvZy1taWItMTIsIERhdmlkIEhhcnJpbmd0 b24gCiAgIFRvIFdHOiBGaWcxLCBUZXJtaW5vbG9neSAKClJlOiBbU3lzbG9nXSBTdWJtaXNz aW9uIG9mIGRyYWZ0LWlldGYtc3lzbG9nLWRldmljZS1taWItMTIudHh0LCBKdWVyZ2VuIFNj aG9lbndhZWxkZXIKICAgVHJhbnNwb3J0IERvbWFpbiBtYXR0ZXIgICAgICAgICAgICAgICAt PiBEaXNjdXNzZWQgPT4gUmV2aXNlCgpbU3lzbG9nXSBSZmMzMTY0IGFuZCBtaWIsIERhdmlk IEhhcnJpbmd0b24gCiAgIFJGQzMxNjQgdG8gYmUgb2Jzb2xldGVkICAgICAgICAgICAgICAg ICAgICAgICAgICAgID0+IFJldmlzZQoKW1N5c2xvZ10gTUlCIElzc3VlICMxIC0gb25lIG9y IG11bHRpcGxlPyBTZWVraW5nIGNvbnNlbnN1cywgRGF2aWQgSGFycmluZ3RvbiAKICAgT25l IG9yIG11bHRpcGxlIGVudGl0eSBwZXIgTUlCICAgICAgICAtPiBEaXNjdXNzZWQgPT4gTXVs dGlwbGUgZW50aXRpZXMKCltTeXNsb2ddIE1JQiBJc3N1ZSAjMjogZG9jdW1lbnQgdGVybWlu b2xvZ3kuLCBEYXZpZCBIYXJyaW5ndG9uIAogICBUZXJtaW5vbG9neSAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0+IERpc2N1c3NlZCAKCltTeXNsb2ddIE1pYi0xMywgRGF2aWQgSGFy cmluZ3RvbiAKICAgIkVudGl0eSIgdW5uZWNlc3NhcnkgYWJzdHJhY3Rpb24gICAgICAtPiBF eHBsYWluZWQgPT4gV2FpdGluZyBmb3IgV0cgaW5wdXQgCiAgIHJlc3RydWN0dXJlIG1pYiB0 cmVlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0+IFJldmlzZQogICBGaWctMSB1 bmNsZWFyID8gSW5jb21wbGV0ZSA/ICAgICAgICAgIC0+IEV4cGxhaW5lZAogICBNc2dzU2Vu dCA/ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9PiBBZGQgTU8K ICAgdW5jbGVhci9pbmNvbXBsZXRlIERlc2NyaXB0aW9ucyAgICAgICAtPiBFeHBsYWluZWQg PT4gUmV2aXNlCgplbnRpdHkgYFJlOiBbU3lzbG9nXSBNaWItMTMsIHRvbS5wZXRjaCAKICAg RW50aXR5IHZzIGFwcGxpY2F0aW9uICAgICAgICAgICAgICAgICAtPiBEaXNjdXNzZWQKCg== --------------060600090007020502000104 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 --------------060600090007020502000104-- From syslog-bounces@lists.ietf.org Fri Feb 23 09:08:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKb56-0002Sm-0Q; Fri, 23 Feb 2007 09:07:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKb54-0002Qs-EC for syslog@ietf.org; Fri, 23 Feb 2007 09:07:26 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKb4z-0005CX-Vf for syslog@ietf.org; Fri, 23 Feb 2007 09:07:26 -0500 Received: from pc6 (1Cust87.tnt9.lnd4.gbr.da.uu.net [62.188.138.87]) by ranger.systems.pipex.net (Postfix) with SMTP id 81A65E0008AD; Fri, 23 Feb 2007 14:07:05 +0000 (GMT) Message-ID: <025b01c7574b$45b063e0$0601a8c0@pc6> From: "tom.petch" To: "Glenn M. Keeni" , References: <0d5701c74af9$b7e32fa0$0600a8c0@china.huawei.com> <45D8119F.6000208@cysols.com> Subject: Re: [Syslog] Mib issues and resolutions Date: Fri, 23 Feb 2007 11:00:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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: 68ba2b07ef271dba6ee42a93832cfa4c 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 Glenn One issue that occurred to me that I do not think has surfaced before is the nature of references in the MIB module which must make sense outside the wrapper of the RFC, so that [RFCUDPX], [RFCTLSX] and [RFCBEEP] won't do. . Look at how this is handled in, for example, draft-ietf-pwe3-pw-mib-09, RFC4273 or RFC4750. Tom Petch ----- Original Message ----- From: "Glenn M. Keeni" To: Sent: Sunday, February 18, 2007 9:43 AM Subject: Re: [Syslog] Mib issues and resolutions > Hi, > David asked for a "quick summary" for the WG. I have prepared > a document which is not quick and is not much of a summary. > It provides > - pointers to the mails where issues were raised, > - the originator of the mail, > - the main issues, > - the action and, > - the conclusion. > It will be useful if you use this "summary" along with some mail > archive tool (the wg archive covers only the last few days, > you may try http://www.cysol.co.jp/contrib/syslogmib/threads.html) > Please note: > a. It covers only discussions related to the MIB, issues > related to other documents are not covered. > b. It covers the period starting from the WGLC > c. The list of main issues for each mail is not exhaustive. > The positions of individuals and the pros and cons are not > included. > Please refer to the original the mail if you are looking > for a detailed list. > Please let me know if I have missed some threads. > > Cheers > > Glenn > > ======================================================== > > [Syslog] Working Group Last Call: syslog-mib document, David B Harrington > Re: [Syslog] Working Group Last Call: syslog-mib document, tom.petch > > The "subject" of the MIB => "Entity" > One or more syslog entities per MIB ? => Multiple entities. > > RE: [Syslog] MIB document decision, Alexander Clemm (alex) > To handle SyslogSign or not. > WG polled. No response. => Leave for later > ( Separate Document) > > [Syslog] WGLC results : Syslog-MIB, Glenn M. Keeni > [Syslog] RE: Request for Reviewers - draft-ietf-syslog-device-mib-09.txt, Wijnen, Bert (Bert) > SMICng errors => Done > MIB nits => Done > syslog-transport over tls -> discussed => revised > > [Syslog] Dbh Review of -mib-09, part 1, David Harrington > ID-nits > Terminology: sender, receiver, relay -> Discussed => Entity > SyslogSeverity: "other" -> Discussed > syslog-transport -> Discussed => revise > syslEntOpsMsgsIgnored: unclear -> Discussed => revise > syslEntOpsLastError: unclear -> Discussed => revise > syslEntOpsReference: unclear -> Discussed => revise > > [Syslog] Dbh re-Review of -mib-11, part 1, David Harrington > Terminology: sender, receiver, relay -> Discussed => Entity > SyslogSeverity: "other" usage ? -> Discussed > SyslogService: UDP/TCP ? -> Discussed > Descriptive Indices -> Discussed => Use Description MOs > syslEntOpsMsgsIgnored: Allowed Specs? -> Discussed > syslEntOpsLastError: unclear -> Clarified => revise > > [Syslog] Dbh re-review of Mib-11-, part 2, David B Harrington > transportAddressType/Service unclear -> Discussed > syslogEntityControlStorageType -> Discussed => revise > notifications: Description unclear -> Discussed => revise > notifications: mandatory/optional ? -> Clarified => optional > transport security: discuss ? -> Discussed => comment withdrawn > > [Syslog] -mib-, part 3, David Harrington > Add congestion avoidance ? -> No reaction from WG > > [Syslog] Review of Mib-10, part 1, David Harrington > mainly ID, MIB nits => fix > > [Syslog] Mib -10-, part 2, David Harrington > Terminology -> Discussed earlier > One or more syslog entities per MIB ? -> Discussed earlier > > [Syslog] Review of mib-11, part 3, David Harrington > Purpose of Default parameters -> Explained > > [Syslog] Syslog-mib-11, David Harrington > One or more syslog entities per MIB ? -> Discussed => multiple entities > > [Syslog] Syslog-mib-12, David Harrington > To WG: Fig1, Terminology > > Re: [Syslog] Submission of draft-ietf-syslog-device-mib-12.txt, Juergen Schoenwaelder > Transport Domain matter -> Discussed => Revise > > [Syslog] Rfc3164 and mib, David Harrington > RFC3164 to be obsoleted => Revise > > [Syslog] MIB Issue #1 - one or multiple? Seeking consensus, David Harrington > One or multiple entity per MIB -> Discussed => Multiple entities > > [Syslog] MIB Issue #2: document terminology., David Harrington > Terminology -> Discussed > > [Syslog] Mib-13, David Harrington > "Entity" unnecessary abstraction -> Explained => Waiting for WG input > restructure mib tree => Revise > Fig-1 unclear ? Incomplete ? -> Explained > MsgsSent ? => Add MO > unclear/incomplete Descriptions -> Explained => Revise > > entity `Re: [Syslog] Mib-13, tom.petch > Entity vs application -> Discussed > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Feb 23 20:12:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKlRb-0005aE-Rm; Fri, 23 Feb 2007 20:11:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKlRa-0005a6-TC for syslog@ietf.org; Fri, 23 Feb 2007 20:11:22 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKlRZ-0004dj-6e for syslog@ietf.org; Fri, 23 Feb 2007 20:11:22 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l1O1BJpE004661 for ; Sat, 24 Feb 2007 10:11:19 +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 l1O1BCsN029351 for ; Sat, 24 Feb 2007 10:11:18 +0900 (JST) Message-ID: <45DF90B0.2050004@cysols.com> Date: Sat, 24 Feb 2007 10:11:12 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Mib issues and resolutions References: <0d5701c74af9$b7e32fa0$0600a8c0@china.huawei.com> <45D8119F.6000208@cysols.com> <025b01c7574b$45b063e0$0601a8c0@pc6> In-Reply-To: <025b01c7574b$45b063e0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 tom.petch wrote: > Glenn > > One issue that occurred to me that I do not think has surfaced before is the > nature of references in the MIB module which must make sense outside the wrapper > of the RFC, so that [RFCUDPX], [RFCTLSX] and [RFCBEEP] won't do. > . > Look at how this is handled in, for example, draft-ietf-pwe3-pw-mib-09, RFC4273 > or RFC4750. Thanks. Glenn > > Tom Petch > > ----- Original Message ----- > From: "Glenn M. Keeni" > To: > Sent: Sunday, February 18, 2007 9:43 AM > Subject: Re: [Syslog] Mib issues and resolutions > > >> Hi, >> David asked for a "quick summary" for the WG. I have prepared >> a document which is not quick and is not much of a summary. >> It provides >> - pointers to the mails where issues were raised, >> - the originator of the mail, >> - the main issues, >> - the action and, >> - the conclusion. >> It will be useful if you use this "summary" along with some mail >> archive tool (the wg archive covers only the last few days, >> you may try http://www.cysol.co.jp/contrib/syslogmib/threads.html) >> Please note: >> a. It covers only discussions related to the MIB, issues >> related to other documents are not covered. >> b. It covers the period starting from the WGLC >> c. The list of main issues for each mail is not exhaustive. >> The positions of individuals and the pros and cons are not >> included. >> Please refer to the original the mail if you are looking >> for a detailed list. >> Please let me know if I have missed some threads. >> >> Cheers >> >> Glenn >> >> ======================================================== >> >> [Syslog] Working Group Last Call: syslog-mib document, David B Harrington >> Re: [Syslog] Working Group Last Call: syslog-mib document, tom.petch >> >> The "subject" of the MIB => "Entity" >> One or more syslog entities per MIB ? => Multiple entities. >> >> RE: [Syslog] MIB document decision, Alexander Clemm (alex) >> To handle SyslogSign or not. >> WG polled. No response. => Leave for later >> ( Separate Document) >> >> [Syslog] WGLC results : Syslog-MIB, Glenn M. Keeni >> [Syslog] RE: Request for Reviewers - draft-ietf-syslog-device-mib-09.txt, > Wijnen, Bert (Bert) >> SMICng errors => Done >> MIB nits => Done >> syslog-transport over tls -> discussed => revised >> >> [Syslog] Dbh Review of -mib-09, part 1, David Harrington >> ID-nits >> Terminology: sender, receiver, relay -> Discussed => Entity >> SyslogSeverity: "other" -> Discussed >> syslog-transport -> Discussed => revise >> syslEntOpsMsgsIgnored: unclear -> Discussed => revise >> syslEntOpsLastError: unclear -> Discussed => revise >> syslEntOpsReference: unclear -> Discussed => revise >> >> [Syslog] Dbh re-Review of -mib-11, part 1, David Harrington >> Terminology: sender, receiver, relay -> Discussed => Entity >> SyslogSeverity: "other" usage ? -> Discussed >> SyslogService: UDP/TCP ? -> Discussed >> Descriptive Indices -> Discussed => Use Description MOs >> syslEntOpsMsgsIgnored: Allowed Specs? -> Discussed >> syslEntOpsLastError: unclear -> Clarified => revise >> >> [Syslog] Dbh re-review of Mib-11-, part 2, David B Harrington >> transportAddressType/Service unclear -> Discussed >> syslogEntityControlStorageType -> Discussed => revise >> notifications: Description unclear -> Discussed => revise >> notifications: mandatory/optional ? -> Clarified => optional >> transport security: discuss ? -> Discussed => comment withdrawn >> >> [Syslog] -mib-, part 3, David Harrington >> Add congestion avoidance ? -> No reaction from WG >> >> [Syslog] Review of Mib-10, part 1, David Harrington >> mainly ID, MIB nits => fix >> >> [Syslog] Mib -10-, part 2, David Harrington >> Terminology -> Discussed earlier >> One or more syslog entities per MIB ? -> Discussed earlier >> >> [Syslog] Review of mib-11, part 3, David Harrington >> Purpose of Default parameters -> Explained >> >> [Syslog] Syslog-mib-11, David Harrington >> One or more syslog entities per MIB ? -> Discussed => multiple entities >> >> [Syslog] Syslog-mib-12, David Harrington >> To WG: Fig1, Terminology >> >> Re: [Syslog] Submission of draft-ietf-syslog-device-mib-12.txt, Juergen > Schoenwaelder >> Transport Domain matter -> Discussed => Revise >> >> [Syslog] Rfc3164 and mib, David Harrington >> RFC3164 to be obsoleted => Revise >> >> [Syslog] MIB Issue #1 - one or multiple? Seeking consensus, David Harrington >> One or multiple entity per MIB -> Discussed => Multiple entities >> >> [Syslog] MIB Issue #2: document terminology., David Harrington >> Terminology -> Discussed >> >> [Syslog] Mib-13, David Harrington >> "Entity" unnecessary abstraction -> Explained => Waiting for WG input >> restructure mib tree => Revise >> Fig-1 unclear ? Incomplete ? -> Explained >> MsgsSent ? => Add MO >> unclear/incomplete Descriptions -> Explained => Revise >> >> entity `Re: [Syslog] Mib-13, tom.petch >> Entity vs application -> Discussed >> >> >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Feb 23 21:56:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKn45-0005TD-PZ; Fri, 23 Feb 2007 21:55:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKn44-0005Sv-M7 for syslog@ietf.org; Fri, 23 Feb 2007 21:55:12 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKn42-0003uL-Nk for syslog@ietf.org; Fri, 23 Feb 2007 21:55:12 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l1O2sspE006328 for ; Sat, 24 Feb 2007 11:54:54 +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 l1O2sqsN000492 for ; Sat, 24 Feb 2007 11:54:54 +0900 (JST) Message-ID: <45DFA8FC.1020402@cysols.com> Date: Sat, 24 Feb 2007 11:54:52 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Mib issues and resolutions References: <0d5701c74af9$b7e32fa0$0600a8c0@china.huawei.com> <45D8119F.6000208@cysols.com> <025b01c7574b$45b063e0$0601a8c0@pc6> <45DF90B0.2050004@cysols.com> In-Reply-To: <45DF90B0.2050004@cysols.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Glenn M. Keeni wrote: > tom.petch wrote: >> Glenn >> >> One issue that occurred to me that I do not think has surfaced before is the >> nature of references in the MIB module which must make sense outside the wrapper >> of the RFC, so that [RFCUDPX], [RFCTLSX] and [RFCBEEP] won't do. >> . >> Look at how this is handled in, for example, draft-ietf-pwe3-pw-mib-09, RFC4273 >> or RFC4750. draft-ietf-pwe3-pw-mib-09 does not seem to exist on internet-drafts archives or on google. > > Thanks. > > Glenn >> Tom Petch Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Feb 23 22:00:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKn9J-0008Pp-3L; Fri, 23 Feb 2007 22:00:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKn9I-0008M3-0o for syslog@ietf.org; Fri, 23 Feb 2007 22:00:36 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKn9G-0005LY-DL for syslog@ietf.org; Fri, 23 Feb 2007 22:00:36 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l1O30XpE006455 for ; Sat, 24 Feb 2007 12:00:33 +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 l1O30WsN000690 for ; Sat, 24 Feb 2007 12:00:33 +0900 (JST) Message-ID: <45DFAA50.5010201@cysols.com> Date: Sat, 24 Feb 2007 12:00:32 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Mib issues and resolutions References: <0d5701c74af9$b7e32fa0$0600a8c0@china.huawei.com> <45D8119F.6000208@cysols.com> <025b01c7574b$45b063e0$0601a8c0@pc6> <45DF90B0.2050004@cysols.com> <45DFA8FC.1020402@cysols.com> In-Reply-To: <45DFA8FC.1020402@cysols.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) 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 Glenn M. Keeni wrote: > Glenn M. Keeni wrote: >> tom.petch wrote: >>> Glenn >>> >>> One issue that occurred to me that I do not think has surfaced before is the >>> nature of references in the MIB module which must make sense outside the wrapper >>> of the RFC, so that [RFCUDPX], [RFCTLSX] and [RFCBEEP] won't do. >>> . >>> Look at how this is handled in, for example, draft-ietf-pwe3-pw-mib-09, RFC4273 >>> or RFC4750. > > draft-ietf-pwe3-pw-mib-09 does not seem to exist on internet-drafts > archives or on google. OK. I got draft-ietf-pwe3-pw-mib-10.txt >> Thanks. >> >> Glenn >>> Tom Petch > > Glenn > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog