From syslog-bounces@lists.ietf.org Wed Jan 02 12:13:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA79W-0000Yf-EU; Wed, 02 Jan 2008 12:13:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA79V-0000YL-6t for syslog@ietf.org; Wed, 02 Jan 2008 12:13:13 -0500 Received: from qmta06.westchester.pa.mail.comcast.net ([76.96.62.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA79U-0005iq-5l for syslog@ietf.org; Wed, 02 Jan 2008 12:13:13 -0500 Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA06.westchester.pa.mail.comcast.net with comcast id YDs91Y00Q0Fqzac050CP00; Wed, 02 Jan 2008 17:13:11 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id YHD41Y00J4HwxpC3U00000; Wed, 02 Jan 2008 17:13:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=uDJo42uGIx9DoF4fuMQA:9 a=NrV5zs2vmRhrWZ5bq7lp_Su_K0UA:4 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 a=48vgC7mUAAAA:8 a=M2SJfFBsU7hV4ppmpVAA:9 a=0whX6s-HZRRhiPp5FCYA:7 a=THOADpiXM8nqXAgvs7hnAMa_pbwA:4 a=UdOppG_W7G0A:10 a=Jt_XODvWL-WTFskFmgYA:9 a=T1DeheSJLieQcWWXuZcA:7 a=qq1wbHYBQzxG6zqApLIR4PsuokIA:4 From: "David Harrington" To: "'Sam Hartman'" , Date: Wed, 2 Jan 2008 12:12:37 -0500 Message-ID: <0e9a01c84d62$ac894470$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0E9B_01C84D38.C3B33C70" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AchNYqwZa4UUoCMVTYCQsT4r1mbldA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: syslog@ietf.org Subject: [Syslog] syslog WG documents X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0E9B_01C84D38.C3B33C70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sam, We are submitting a shepherding document for advancemnet of syslog-sign to PS. We are submitting a shepherding document for advancement of syslog-tc-mib to PS. David Harrington dbharrington@comcast.net ietfdbh@comcast.net ------=_NextPart_000_0E9B_01C84D38.C3B33C70 Content-Type: text/plain; name="syslog-sign-shepherd.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="syslog-sign-shepherd.txt" shepherding submission for syslog-sign =20 Having passed a WG Last Call, and been updated to meet the comments from the WGLC, draft-ietf-syslog-sign-23.txt is ready for AD review. =20 [Area] SECURITY [AD] Sam Hartman [WG] syslog [I-D] draft-ietf-syslog-sign-23.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-07.txt [Shep] David Harrington =20 =20 The WG last call turned up no major comments or discussion. =20 =20 1.a) Have the chairs personally reviewed this version of=20 the Internet Draft (ID), and in particular, do they believe this=20 ID is ready to forward to the IESG for publication? =20 Yes. =20 =20 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? =20 Adequate review has occurred from WG members, and it has been reviewed by others. I am satisfied about the level of review. =20 =20 1.c) Do you have concerns that the document needs more=20 review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? =20 No. =20 =20 1.d) Do you have any specific concerns/issues with this=20 document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. =20 In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. =20 No. =20 =20 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? =20 There is strong consensus to publish this document. =20 =20 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. =20 No. =20 =20 1.g) Have the chairs verified that the document adheres=20 to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). =20 Yes. =20 =20 1.h) Is the document split into normative and informative=20 references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until = all such IDs are also ready for publication as RFCs.) =20 The references are split into normative and informational references. The document has normative dependencies on = draft-ietf-syslog-protocol-23.txt and = draft-ietf-syslog-transport-udp-12.txt, which have been approved, and on = draft-ietf-syslog-transport-tls-10.txt which has not yet been approved. = =20 =20 1.ijk) Write-up section: =20 * Technical Summary =20 This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC xxxx, "The syslog Protocol". =20 =20 * Working Group Summary =20 The consensus of the working group was to publish this as a standards-track document. =20 * Protocol Quality =20 It is possible that there are implementations of this document in various stages of completion at this time. Some equipment=20 vendors have indicated interest in supporting this document, and some=20 non-commercial implementations are also expected. =20 =20 ------=_NextPart_000_0E9B_01C84D38.C3B33C70 Content-Type: text/plain; name="syslog-tc-mib-shepherd.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="syslog-tc-mib-shepherd.txt" shepherding submission for syslog-tc-mib =20 draft-ietf-syslog-tc-mib-04.txt is ready for AD review. =20 [Area] SECURITY [AD] Sam Hartman [WG] syslog [I-D] draft-ietf-syslog-tc-mib-04.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-07.txt [Shep] David Harrington =20 =20 1.a) Have the chairs personally reviewed this version of=20 the Internet Draft (ID), and in particular, do they believe this=20 ID is ready to forward to the IESG for publication? =20 Yes. =20 =20 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? =20 Adequate review has occurred from WG members, and it has been reviewed by others. I am satisfied about the level of review. It passes IDnits.=20 The document meets the guidelines of RFC4181 for MIB documents. It passes libsmi MIB validation. The security considerations is appropriate to documents containing only = TCs. =20 =20 1.c) Do you have concerns that the document needs more=20 review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? =20 No. Dan Romascanu has agreed to perform a MIB Doctor review. =20 =20 1.d) Do you have any specific concerns/issues with this=20 document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. =20 In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. =20 No. The ADs should be aware that syslog is a defacto standard widely used in = the industry, and supported by standard POSIX APIs. The syslog WG = discussed whether to standardize the use of the labels in the facilities = TC. WG consensus is that the labels are normative, but irrelevant.=20 The chairs are comfortable with this decision. The following text is included in the document, with references, and the = MIB module itself, without references, to explain what this means. " For interoperability and backwards compatibility reasons, the = mapping specified in this document between a label which represents a Facility or a Severity, and the value which represents the corresponding code, is normative. So the mapping from a label configured by operators in syslog.conf or equivalent will consistently map to the same Facility code regardless of implementation, but the label itself is often semantically meaningless, because it is impractical to attempt to enumerate all possible facilities, and the mapping (label and corresponding value) that is used for an actual facility is, and has historically been, implementation-dependent. For example, the foobar application might log messages as having come from local7, even though there is no "local" process on the device, and the operator can configure syslog.conf to have local7.critical messages be relayed, even though there might be multiple facilities using Facility local7. This is typical current practice, and originators, relays and collectors know how to handle this situation. For improved accuracy, the foobar application can also include an APPNAME Structured Data Element [RFCPROT]." =20 =20 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? =20 The WG cares little about having MIB support. There is strong consensus = to publish this document from those WG members who want MIB support, = from the MIB Doctors, and from other WGs who are developing = syslog-related MIB modules, so there will be consistency in the = definition of MIB objects representing Facility and Severity. =20 =20 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. =20 No. =20 =20 1.g) Have the chairs verified that the document adheres=20 to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). =20 Yes. =20 =20 1.h) Is the document split into normative and informative=20 references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until = all such IDs are also ready for publication as RFCs.) =20 Yes, it is split. draft-ietf-syslog-protocol has already been approved for advancement. =20 1.ijk) Write-up section: =20 * Technical Summary =20 This document contains a MIB module that defines textual conventions to = represent facility and severity information commonly used in syslog = messages. The intent is that these textual conventions will be imported = and used in MIB modules that would otherwise define their own = representations.=20 * Working Group Summary =20 The consensus of the working group was to publish this as a standards-track document. =20 * Protocol Quality =20 These textual conventions standardize MIB representation of facility and = severity, concepts which are widely used in existing implementations of = syslog.=20 =20 ------=_NextPart_000_0E9B_01C84D38.C3B33C70 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_0E9B_01C84D38.C3B33C70-- From syslog-bounces@lists.ietf.org Wed Jan 09 12:26:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCehD-000069-BH; Wed, 09 Jan 2008 12:26:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBpJq-0001Gh-Ie; Mon, 07 Jan 2008 05:34:58 -0500 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBpJq-0002j2-6D; Mon, 07 Jan 2008 05:34:58 -0500 X-IronPort-AV: E=Sophos;i="4.24,253,1196658000"; d="scan'208";a="84515203" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Jan 2008 05:34:54 -0500 X-IronPort-AV: E=Sophos;i="4.24,253,1196658000"; d="scan'208";a="147170980" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Jan 2008 05:34:12 -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 Date: Mon, 7 Jan 2008 11:34:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB Doctor review of draft-ietf-syslog-tc-mib-04.txt Thread-Index: AchRGNbSZEMwBKHJQuKKZmyWqzMFFQ== From: "Romascanu, Dan (Dan)" To: , "David B Harrington" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Wed, 09 Jan 2008 12:26:30 -0500 Cc: mib-doctors@ietf.org, syslog@ietf.org, Sam Hartman Subject: [Syslog] MIB Doctor review of draft-ietf-syslog-tc-mib-04.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 The document is in good shape, it compiles cleanly and passes idnits checks.=20 I have a few editorial comments: 1. I do not believe that it is necessary to carry all the duplicated text in the MIB module as commented text, as it does not provide any significant implementation information. 2. It would be good to mention in the TC definition or by using the REFERENCE clause that the enumerated values replicate the values defined respectively in tables 1 and 2 of [RFCPROT].=20 3. The document carries the standard security considerations section for documents defining Textual Conventions. This text states correctly that the TCs themselves do not introduce security concerns, but in this case most probably objects defined by using these TCs will. To be on the strict side I would add a phrase that says 'Objects defined using the TCs defined in this document may introduce security issues, and the user of these TCs should read the security considerations section of [RFCPROT].' Dan =20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 09 18:01:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCjvK-0001lv-Ti; Wed, 09 Jan 2008 18:01:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCjvK-0001ln-1o for syslog@ietf.org; Wed, 09 Jan 2008 18:01:26 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCjvH-0003v1-Fv for syslog@ietf.org; Wed, 09 Jan 2008 18:01:26 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUE00KULFXEFL@szxga03-in.huawei.com> for syslog@ietf.org; Thu, 10 Jan 2008 07:00:50 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUE001AAFXD1I@szxga03-in.huawei.com> for syslog@ietf.org; Thu, 10 Jan 2008 07:00:50 +0800 (CST) Received: from M19684Z ([10.124.17.104]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUE00023FX66Y@szxml03-in.huawei.com> for syslog@ietf.org; Thu, 10 Jan 2008 07:00:49 +0800 (CST) Date: Wed, 09 Jan 2008 15:00:45 -0800 From: Miao Fuyou Subject: RE: [Syslog] transport-tls-11 review In-reply-to: <005301c831e3$f559cf20$0601a8c0@pc6> To: "'tom.petch'" , 'Rainer Gerhards' , syslog@ietf.org Message-id: <013101c85313$79016e00$68117c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acgx7HcVoVFcuCxPQUmPIfGs9LK0zwhJG8PQ References: <577465F99B41C842AAFBE9ED71E70ABA308495@grfint2.intern.adiscon.com> <00a801c83149$7149e160$6a117c0a@china.huawei.com> <005301c831e3$f559cf20$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 Thanks for your comments! Response inline. > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, November 28, 2007 9:13 AM > To: Miao Fuyou; 'Rainer Gerhards'; syslog@ietf.org > Subject: Re: [Syslog] transport-tls-11 review > > > > > > > > === > > > The server MUST be implemented to support certificate and > certificate > > > generation, > > > === > > > > > > I do not think it is a MUST that a server must contain code to > > > generate certificates. This should be left to the implementation. > > > There is already the requirement to use certificates, so > IMHO it is > > > not the business of an IETF document to specify how they are > > > provided. For example, I would provide a helper app with > my syslog > > > implementations, but not include it in the core app - it doesn't > > > belong there. > > > > > > > Need more opinion from the working group. > > > > I agree with Rainer OK, to be updated in new revision. > > And I see some idiosynchratic wordings that MIGHT be changed. > > 2. Security Requirements for Syslog > > syslog messages may pass several hops > ** not really pass, suggest transit > > It is recommended to use dNSName in the certificate rather than any > other type subjectAltName for certificate verification, such as > ipAddress. > **suggest iPAddress (ie PKI not SNMP) Ok, thanks! > > 4.2.2. Client Identity > > If a server authenticates a client and the client presents a > certificate to the server, the server MUST validate the > certificate. > Validation includes constructing a certificate path to one of the > configured trust anchors and validating that path. > However, identity > check is not required even if subjectAltName is presented in the > certificate. > **I do not understand how failing to check the identity > provides protection against Masquerade, as we claim in s.2 > > SubjectAltName is not necessarily unique for different > certificates. > ** suggest The subjectAltName OK, thanks! > > 5.1. Authentication and Certificates > > Mutual authentication means the TLS client and server are > provisioned with necessary trust roots > > **suggest trust anchors as in the next paragraph OK, thanks! > > . If a server does not > have a certificate and key/pair configured **unclear what > the solidus is doing - '/' usually means either/or Typo, should be key pair. > > The server MUST be implemented to support certificate and > certificate > generation, and certificate validation MUST be implemented for all > clients. The Syslog client SHOULD be implementated to > support **implemented > certificate and certificate generation, and certificate validation > SHOULD be inplemented for Syslog server. > > **These both read oddly to me - what is the support for certificate > (certificates?) as distinct from support for certificate > generation and certificate validation? If I support > certificate (without qualification), then I expect that to > convey support for every aspect thereof so the validation and > generation is redundant but, as I agreed with Rainer above, I > think that generation should not be a MUST. There are two way for a server to have a certificate: be configured with one, or generate one by itself. The "support certificate" is actually to cover the first case. I agree that is not a exact terminology. What is your suggestion? > > Since a receiver may act upon received data, for syslog over > TLS, it is recommended that the server authenticate the client to > ensure that information received is authentic. > > **this seems to weaken the claim earlier that TLS defends > against the listed threats - by now I am feeling confused > about what protection is being offered by what. To meet the > claims of s.2, I think we need both server and client to > check certificates for suitable identities and to follow a > chain to a trust anchor - I have no problem with describing > other scenarios but think that each such scenario should then > be qualified with a comment to the effect that this MAY not > defend against threats ... as identified in s.2 Perhaps "authentic" is not an exact term, how about "it is recommended that the server authenticate the client to ensure that information received is from trusted client." > > 5.2. Cipher Suites > > Operators MAY choose to disable older/weaker cipher > suites for TLS > despite the tradeoff of interoperability, for example, if > the cipher > suite specified in the specification is found weak in the future. > > **suggest > > Operators MAY choose to disable cipher suites for TLS > that are regarded as too weak for the environment in which > this specification is being used, especially older cipher > suites. This MAY lead to a reduction of interoperability. > It is likely that, in time, the cipher suite specified here > will become subject to attack and the use of it will too be > deprecated. OK, thanks! > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 09 21:02:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCmkJ-000080-K2; Wed, 09 Jan 2008 21:02:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCmkH-00007e-RK; Wed, 09 Jan 2008 21:02:13 -0500 Received: from niseko.cysol.co.jp ([210.233.3.236] helo=aso.priv.cysol.co.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCmkH-0006zq-67; Wed, 09 Jan 2008 21:02:13 -0500 Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.13.8/8.13.8) with ESMTP id m0A21qIl098297; Thu, 10 Jan 2008 11:01:55 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <47857C8F.70708@cysols.com> Date: Thu, 10 Jan 2008 11:01:51 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: David B Harrington , syslog@ietf.org, Sam Hartman , mib-doctors@ietf.org Subject: [Syslog] Re: MIB Doctor review of draft-ietf-syslog-tc-mib-04.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 Dan, Thanks. Comments are inline. Romascanu, Dan (Dan) wrote: > The document is in good shape, it compiles cleanly and passes idnits > checks. > > I have a few editorial comments: > > 1. I do not believe that it is necessary to carry all the duplicated > text in the MIB module as commented text, as it does not provide any > significant implementation information. I will agree with this. Are there any other opinions / suggestions on this issue ? > Syslog-WG > > 2. It would be good to mention in the TC definition or by using the > REFERENCE clause that the enumerated values replicate the values defined > respectively in tables 1 and 2 of [RFCPROT]. OK. > 3. The document carries the standard security considerations section for > documents defining Textual Conventions. This text states correctly that > the TCs themselves do not introduce security concerns, but in this case > most probably objects defined by using these TCs will. To be on the > strict side I would add a phrase that says 'Objects defined using the > TCs defined in this document may introduce security issues, and the user > of these TCs should read the security considerations section of > [RFCPROT].' OK. > I will update the document and post a revised draft on the 16th of January. Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 10 02:47:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCs8V-0000mB-VE; Thu, 10 Jan 2008 02:47:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCs8V-0000m6-1D for syslog@ietf.org; Thu, 10 Jan 2008 02:47:35 -0500 Received: from qmta04.emeryville.ca.mail.comcast.net ([76.96.30.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCs8U-0003kp-Jz for syslog@ietf.org; Thu, 10 Jan 2008 02:47:34 -0500 Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id bKif1Y0081HpZEs0A00B00; Thu, 10 Jan 2008 07:47:34 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id bKn21Y0014HwxpC8a00000; Thu, 10 Jan 2008 07:47:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=oq4kKO-3YYLVmdOklCYA:9 a=Ea1vByA2LP-CJJFKzLMA:7 a=btFH5aSme16t1XWzSVq2E541g20A:4 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Glenn M. Keeni'" , "'Romascanu, Dan \(Dan\)'" References: <47857C8F.70708@cysols.com> Date: Thu, 10 Jan 2008 02:47:27 -0500 Message-ID: <010c01c8535d$0cf759a0$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47857C8F.70708@cysols.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AchTLM8zUiZkqQChQFqV/AWeHSZuKAAKWkXw X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: mib-doctors@ietf.org, syslog@ietf.org, 'Sam Hartman' Subject: [Syslog] RE: MIB Doctor review of draft-ietf-syslog-tc-mib-04.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 Hi, > Romascanu, Dan (Dan) wrote: > > > > 1. I do not believe that it is necessary to carry all the duplicated > > text in the MIB module as commented text, as it does not provide any > > significant implementation information. > I will agree with this. > Are there any other opinions / suggestions on this issue ? > Syslog-WG I believe the normative nature of the labels and values, and the non-normative nature of the mappings to applications, is important information for implementation and interpretation. If the MIB module is separated from the document, we want to make sure this information stays with the MIB module. Therefeore, I would keep the text about the normative nature of the labels and values in the MIB module and remove the duplicate text from the surrounding document, if you are going to remove one of the duplicates. David Harrington 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 Thu Jan 10 02:54:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCsEw-0007Zo-OP; Thu, 10 Jan 2008 02:54:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCsEt-0007Pc-U7; Thu, 10 Jan 2008 02:54:11 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCsEr-0001nI-Mg; Thu, 10 Jan 2008 02:54:11 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA6838A3CB; Thu, 10 Jan 2008 08:54:08 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13093-06; Thu, 10 Jan 2008 08:54:04 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF2818A238; Thu, 10 Jan 2008 08:54:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BBC7E460688; Thu, 10 Jan 2008 08:54:01 +0100 (CET) Date: Thu, 10 Jan 2008 08:54:01 +0100 From: Juergen Schoenwaelder To: David B Harrington Message-ID: <20080110075401.GA5872@elstar.local> Mail-Followup-To: David B Harrington , "'Glenn M. Keeni'" , "'Romascanu, Dan (Dan)'" , mib-doctors@ietf.org, syslog@ietf.org, 'Sam Hartman' References: <47857C8F.70708@cysols.com> <010c01c8535d$0cf759a0$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010c01c8535d$0cf759a0$6502a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "'Romascanu, Dan \(Dan\)'" , syslog@ietf.org, 'Sam Hartman' , mib-doctors@ietf.org Subject: [Syslog] Re: [MIB-DOCTORS] RE: MIB Doctor review of draft-ietf-syslog-tc-mib-04.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de 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, Jan 10, 2008 at 02:47:27AM -0500, David B Harrington wrote: > Hi, > > > Romascanu, Dan (Dan) wrote: > > > > > > 1. I do not believe that it is necessary to carry all the > duplicated > > > text in the MIB module as commented text, as it does not provide > any > > > significant implementation information. > > I will agree with this. > > Are there any other opinions / suggestions on this issue ? > > Syslog-WG > > I believe the normative nature of the labels and values, and the > non-normative nature of the mappings to applications, is important > information for implementation and interpretation. If the MIB module > is separated from the document, we want to make sure this information > stays with the MIB module. > > Therefeore, I would keep the text about the normative nature of the > labels and values in the MIB module and remove the duplicate text from > the surrounding document, if you are going to remove one of the > duplicates. If the text is important (and I tend to agree it is), then it should be in the DESCRIPTION clause and not comments. This also requires to split the text into the text relevant for facilities and the text relevant for severities. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 10 03:47:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCt3x-0005zo-2F; Thu, 10 Jan 2008 03:46:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCt3w-0005zj-3y for syslog@ietf.org; Thu, 10 Jan 2008 03:46:56 -0500 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCt3v-0002RK-LH for syslog@ietf.org; Thu, 10 Jan 2008 03:46:56 -0500 Received: by wa-out-1112.google.com with SMTP id k40so1250572wah.25 for ; Thu, 10 Jan 2008 00:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=CEEAcWha6laluXQ32PODnlsp+nCZb1BsBY3RT413MPs=; b=uIR61+Zjt9ehKrzKFjbKB2LpfPDZOsDOQ/eF+kzXm1GSyiuwfu7uMU+5KpaO6QjJelTA3+x9lIGBiIXT6XblWFfTlMO4fDXHc87W5XKOuF7TG4BUEXiao9dH/DlF1FCzD5spFt2R5PVSan2YByL728/bQVxOSF9qcsR8SoZ2vWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=WCeVbkfly6gM+fNSLAYw44IYNTlfOg2G3tU/gUwyj2HQryAevpl6ZvYAg4nMAwuiRSxYWtobbmPeniBr0CykkZ5G/vrNMobzwFXGlMXbDh+pey2mVdBmiTPcylbIuZWvyk8Nh9bIYKh3JSAMSMOFgoUG+MQ70ucJtmt6fLOA7JY= Received: by 10.115.58.1 with SMTP id l1mr1977031wak.110.1199954814801; Thu, 10 Jan 2008 00:46:54 -0800 (PST) Received: by 10.115.60.2 with HTTP; Thu, 10 Jan 2008 00:46:54 -0800 (PST) Message-ID: <45c8c21a0801100046m839f13s39fcad56f92c4dae@mail.gmail.com> Date: Thu, 10 Jan 2008 03:46:54 -0500 From: "Richard Graveman" To: "Miao Fuyou" Subject: Re: [Syslog] transport-tls-11 review In-Reply-To: <013101c85313$79016e00$68117c0a@china.huawei.com> MIME-Version: 1.0 References: <577465F99B41C842AAFBE9ED71E70ABA308495@grfint2.intern.adiscon.com> <00a801c83149$7149e160$6a117c0a@china.huawei.com> <005301c831e3$f559cf20$0601a8c0@pc6> <013101c85313$79016e00$68117c0a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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="===============1716820279==" Errors-To: syslog-bounces@lists.ietf.org --===============1716820279== Content-Type: multipart/alternative; boundary="----=_Part_25150_26138799.1199954814791" ------=_Part_25150_26138799.1199954814791 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > > > > > 5.2. Cipher Suites > > > > Operators MAY choose to disable older/weaker cipher > > suites for TLS > > despite the tradeoff of interoperability, for example, if > > the cipher > > suite specified in the specification is found weak in the future. > > > > **suggest > > > > Operators MAY choose to disable cipher suites for TLS > > that are regarded as too weak for the environment in which > > this specification is being used, especially older cipher > > suites. This MAY lead to a reduction of interoperability. > > It is likely that, in time, the cipher suite specified here > > will become subject to attack and the use of it will too be > > deprecated. > > OK, thanks! First sentence, just: "Implementations MUST allow operators to disable cipher suites." Why operators do this and how old the suites are are totally irrelevant. Second sentence: MAY -> may Just my $.02, Richard ------=_Part_25150_26138799.1199954814791 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

>
> 5.2.  Cipher Suites
>
>      Operators MAY choose to disable older/weaker cipher
> suites for TLS
>    despite the tradeoff of interoperability, for example, if
> the cipher
>    suite specified in the specification is found weak in the future.
>
> **suggest
>
>     Operators MAY choose to disable cipher suites for TLS
> that are regarded as too weak for the environment in which
> this specification is being used, especially older cipher
> suites.  This MAY lead to a reduction of interoperability.
> It is likely that, in time, the cipher suite specified here
> will become subject to attack and the use of it will too be
> deprecated.

OK, thanks!

First sentence, just: "Implementations MUST allow operators to disable cipher suites."
Why operators do this and how old the suites are are totally irrelevant.

Second sentence: MAY -> may

Just my $.02,

Richard

------=_Part_25150_26138799.1199954814791-- --===============1716820279== 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 --===============1716820279==-- From syslog-bounces@lists.ietf.org Thu Jan 10 05:13:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCuQ4-000404-9H; Thu, 10 Jan 2008 05:13:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCuQ2-0003xZ-HG; Thu, 10 Jan 2008 05:13:50 -0500 Received: from niseko.cysol.co.jp ([210.233.3.236] helo=aso.priv.cysol.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCuPv-0003h6-QM; Thu, 10 Jan 2008 05:13:50 -0500 Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.13.8/8.13.8) with ESMTP id m0AAD9Xv006039; Thu, 10 Jan 2008 19:13:11 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4785EFB6.3020209@cysols.com> Date: Thu, 10 Jan 2008 19:13:10 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Bert Wijnen - IETF References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: David B Harrington , syslog@ietf.org, 'Sam Hartman' , mib-doctors@ietf.org, "'Romascanu, Dan \(Dan\)'" Subject: [Syslog] Re: [MIB-DOCTORS] RE: MIB Doctor review ofdraft-ietf-syslog-tc-mib-04.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 OK. The general consensus seems to be that the commented text be moved to the DESCRIPTION clause. I will do that. I will also propose to leave the text in the "Background" section as it is. It is an important part of the Background. Let me know if there is disagreement. Glenn Bert Wijnen - IETF wrote: > If so, then I would propose to move the text into DESCRIPTION > caluses, and not have them as comment lines. > > Bert Wijnen > >> -----Oorspronkelijk bericht----- >> Van: David B Harrington [mailto:dbharrington@comcast.net] >> Verzonden: donderdag 10 januari 2008 8:47 >> Aan: 'Glenn M. Keeni'; 'Romascanu, Dan (Dan)' >> CC: mib-doctors@ietf.org; syslog@ietf.org; 'Sam Hartman' >> Onderwerp: [MIB-DOCTORS] RE: MIB Doctor review >> ofdraft-ietf-syslog-tc-mib-04.txt >> >> >> Hi, >> >>> Romascanu, Dan (Dan) wrote: >>>> 1. I do not believe that it is necessary to carry all the >> duplicated >>>> text in the MIB module as commented text, as it does not provide >> any >>>> significant implementation information. >>> I will agree with this. >>> Are there any other opinions / suggestions on this issue ? > >> Syslog-WG >> >> I believe the normative nature of the labels and values, and the >> non-normative nature of the mappings to applications, is important >> information for implementation and interpretation. If the MIB module >> is separated from the document, we want to make sure this information >> stays with the MIB module. >> >> Therefeore, I would keep the text about the normative nature of the >> labels and values in the MIB module and remove the duplicate text from >> the surrounding document, if you are going to remove one of the >> duplicates. >> >> David Harrington >> dbharrington@comcast.net >> ietfdbh@comcast.net >> >> >> >> >> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www1.ietf.org/mailman/listinfo/mib-doctors >> _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 11 10:21:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDLhI-00043d-4q; Fri, 11 Jan 2008 10:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCtYG-000656-II for syslog@ietf.org; Thu, 10 Jan 2008 04:18:16 -0500 Received: from relay.versatel.net ([62.250.3.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JCtYE-00032b-TI for syslog@ietf.org; Thu, 10 Jan 2008 04:18:16 -0500 Received: (qmail 35742 invoked from network); 10 Jan 2008 09:18:13 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 10 Jan 2008 09:18:13 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Glenn M. Keeni'" , "'Romascanu, Dan \(Dan\)'" Date: Thu, 10 Jan 2008 10:18:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <010c01c8535d$0cf759a0$6502a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Fri, 11 Jan 2008 10:21:26 -0500 Cc: mib-doctors@ietf.org, syslog@ietf.org, 'Sam Hartman' Subject: [Syslog] RE: [MIB-DOCTORS] RE: MIB Doctor review ofdraft-ietf-syslog-tc-mib-04.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 If so, then I would propose to move the text into DESCRIPTION caluses, and not have them as comment lines. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: David B Harrington [mailto:dbharrington@comcast.net] > Verzonden: donderdag 10 januari 2008 8:47 > Aan: 'Glenn M. Keeni'; 'Romascanu, Dan (Dan)' > CC: mib-doctors@ietf.org; syslog@ietf.org; 'Sam Hartman' > Onderwerp: [MIB-DOCTORS] RE: MIB Doctor review > ofdraft-ietf-syslog-tc-mib-04.txt > > > Hi, > > > Romascanu, Dan (Dan) wrote: > > > > > > 1. I do not believe that it is necessary to carry all the > duplicated > > > text in the MIB module as commented text, as it does not provide > any > > > significant implementation information. > > I will agree with this. > > Are there any other opinions / suggestions on this issue ? > > Syslog-WG > > I believe the normative nature of the labels and values, and the > non-normative nature of the mappings to applications, is important > information for implementation and interpretation. If the MIB module > is separated from the document, we want to make sure this information > stays with the MIB module. > > Therefeore, I would keep the text about the normative nature of the > labels and values in the MIB module and remove the duplicate text from > the surrounding document, if you are going to remove one of the > duplicates. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > > > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/mib-doctors > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 11 13:13:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDONe-00005k-81; Fri, 11 Jan 2008 13:13:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDONc-00005f-UK for syslog@ietf.org; Fri, 11 Jan 2008 13:13:20 -0500 Received: from mk-outboundfilter-2.mail.uk.tiscali.com ([212.74.114.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDONb-00021H-9E for syslog@ietf.org; Fri, 11 Jan 2008 13:13:20 -0500 X-Trace: 10640141/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.6 X-SBRS: None X-RemoteIP: 62.241.163.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPNAh0c+8aMG/2dsb2JhbACRcJhf Received: from astro.systems.pipex.net ([62.241.163.6]) by smtp.pipex.tiscali.co.uk with ESMTP; 11 Jan 2008 18:13:17 +0000 Received: from pc6 (1Cust9.tnt7.lnd4.gbr.da.uu.net [62.188.136.9]) by astro.systems.pipex.net (Postfix) with SMTP id 9F98BE00008C; Fri, 11 Jan 2008 18:12:54 +0000 (GMT) Message-ID: <015d01c85475$0cc1e680$0601a8c0@pc6> From: "tom.petch" To: "Miao Fuyou" , "'Rainer Gerhards'" , References: <577465F99B41C842AAFBE9ED71E70ABA308495@grfint2.intern.adiscon.com> <00a801c83149$7149e160$6a117c0a@china.huawei.com> <005301c831e3$f559cf20$0601a8c0@pc6> <013101c85313$79016e00$68117c0a@china.huawei.com> Subject: Re: [Syslog] transport-tls-11 review Date: Fri, 11 Jan 2008 17:43:30 +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: -100.0 (---------------------------------------------------) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Snipping out the agreements, and taking dbh's point about this I-D being in A-D Evaluation and so may be beyond comment:-), see inline Tom Petch ----- Original Message ----- From: "Miao Fuyou" To: "'tom.petch'" ; "'Rainer Gerhards'" ; Sent: Thursday, January 10, 2008 12:00 AM Subject: RE: [Syslog] transport-tls-11 review > > Thanks for your comments! Response inline. > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Wednesday, November 28, 2007 9:13 AM > > To: Miao Fuyou; 'Rainer Gerhards'; syslog@ietf.org > > Subject: Re: [Syslog] transport-tls-11 review > > > > The server MUST be implemented to support certificate and > > certificate > > generation, and certificate validation MUST be implemented for all > > clients. The Syslog client SHOULD be implementated to > > support **implemented > > certificate and certificate generation, and certificate validation > > SHOULD be inplemented for Syslog server. > > > > **These both read oddly to me - what is the support for certificate > > (certificates?) as distinct from support for certificate > > generation and certificate validation? If I support > > certificate (without qualification), then I expect that to > > convey support for every aspect thereof so the validation and > > generation is redundant but, as I agreed with Rainer above, I > > think that generation should not be a MUST. > > There are two way for a server to have a certificate: be configured with > one, or generate one by itself. The "support certificate" is actually to > cover the first case. I agree that is not a exact terminology. What is your > suggestion? > Weell, by certificate validation I mean following a chain of certificates back until one reaches a trusted certificate, such as a root CA or trust anchor. OK, many - most? - people don't do that but I am not sure we should connive with them. I prefer certificate validation and certificate generation. RFC2828 is a fun read for this. > > > > Since a receiver may act upon received data, for syslog over > > TLS, it is recommended that the server authenticate the client to > > ensure that information received is authentic. > > > > **this seems to weaken the claim earlier that TLS defends > > against the listed threats - by now I am feeling confused > > about what protection is being offered by what. To meet the > > claims of s.2, I think we need both server and client to > > check certificates for suitable identities and to follow a > > chain to a trust anchor - I have no problem with describing > > other scenarios but think that each such scenario should then > > be qualified with a comment to the effect that this MAY not > > defend against threats ... as identified in s.2 > > Perhaps "authentic" is not an exact term, how about "it is recommended that > the server authenticate the client to ensure that information received is > from trusted client." > suggest " it is recommended that the server authenticate the client to confirm the identity of the client from which the information is received." or something similar, that is that (any kind of) authentication authenticates an identity that the other party is asserting, no more; trusted involves rather more than that, that is having confirmed what the identity is, then that identity is one that can be trusted. Authentication may be 100% successful after which you have established that the client is totally untrustworthy and that this is a phishing attack:-) Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 16 08:31:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8Mm-0005pE-Sj; Wed, 16 Jan 2008 08:31:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8Ml-0005mS-Eg for syslog@ietf.org; Wed, 16 Jan 2008 08:31:39 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF8Mk-0005T0-Q1 for syslog@ietf.org; Wed, 16 Jan 2008 08:31:39 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 16 Jan 2008 05:31:38 -0800 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 m0GDVcwN001802 for ; Wed, 16 Jan 2008 05:31:38 -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 m0GDVcsk026319 for ; Wed, 16 Jan 2008 13:31:38 GMT Date: Wed, 16 Jan 2008 05:31:38 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2656; t=1200490298; x=1201354298; 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:=20Documenting=20the=20configuration=20of=20syslog |Sender:=20; bh=mfRZVRMHKXlNIY+1rAE5mtkbD8izuxykSDVJEBGPhvQ=; b=wdGrAaSViUzkNUHkUyPo+yaKtUz3L5UySSTRn/ldVVVTVvPqlRcmD0wrnD DQcgkSDQ9noHOcSzJCWZiTPhPwszbhjTPRHBXZT5X53Xp1wVL9uyGlA8+2b5 N1V4+jynf1; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [Syslog] Documenting the configuration of syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi WG, Things are changing in the IETF around documenting the management and operations of protocols. The OPS Area WG has been documenting a change of approach, in which SNMP and MIBs are not the only way to configure, manage and operate a protocol, and existing practices are taken into greater consideration when choosing the right tool for a task. We'd like to open that discussion to the WG to get some opinions on this. If we can get a sense of direction on this from the WG, then we'll discuss this with our Advisor (Sam) and our ADs. Documenting the current operational practices for configuring syslog (i.e. syslog.conf) might be much more useful to the operator community than developing a MIB module to do syslog configuration. Is standardizing aspects of the common syslog.conf configuration file the best way to show how to configure a device to send syslog messages securely across the wire? Another approach would be to define some standard Netconf data models for configuring secure syslog, but that is likely to get into serious scope discussions that would bog down such an approach. Our chartered focus is to resolve security issues in logging, so we need to stay focused on defining management to support the work we have done here. It is not in scope to define a comnplete syslog.conf file format, nor to standardize aspects of the file not related to configuring secure logging. Common syslog.conf files already address udp transport but we would need to define how to also utilize tls and RFC3195 transports in this work, and possibly how to configure syslog.conf to support syslog signing. The OpSec WG is discussing whether to document best current practices for syslog operations. If they do so, we may need to coordinate with the OpSec WG about configuring security for syslog. If syslog.conf is covered in the standards of other standards development organizations, such as POSIX, we also may need to liaison with those SDOs to get support for our modifications to syslog.conf. If we do propose standard content for a configuration file for syslog, we will still need to make the WG designs manageable for purposes of monitoring. A MIB module is the current IETF best practice for providing information for fault and performance monitoring and for notifications. Please respond to this and let us know if you think that documenting some standardized content for syslog.conf is going to be a better way to clarify the configuration of syslog rather than writing a MIB module that includes configuration functionality. Thanks, Chris & David _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 16 15:22:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEm9-0000Wk-7N; Wed, 16 Jan 2008 15:22:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEm8-0000Wc-0W for syslog@ietf.org; Wed, 16 Jan 2008 15:22:16 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFEm7-0001Xg-CC for syslog@ietf.org; Wed, 16 Jan 2008 15:22:15 -0500 X-IronPort-AV: E=Sophos;i="4.24,297,1196658000"; d="scan'208";a="83559685" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Jan 2008 15:22:14 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0GKMDnZ014753 for ; Wed, 16 Jan 2008 15:22:13 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0GKMDN8023042 for ; Wed, 16 Jan 2008 20:22:13 GMT Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 15:21:57 -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] Documenting the configuration of syslog Date: Wed, 16 Jan 2008 15:23:50 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B7312204422E1B@xmb-rtp-20d.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Documenting the configuration of syslog thread-index: AchYRF9Tk2bjte7mRlK2b3hH+8+K9gAN+NmQ References: From: "Anton Okmyanskiy (aokmians)" To: X-OriginalArrivalTime: 16 Jan 2008 20:21:57.0010 (UTC) FILETIME=[7100E720:01C8587D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4567; t=1200514933; x=1201378933; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=20=22Anton=20Okmyanskiy=20(aokmians)=22=20 |Subject:=20RE=3A=20[Syslog]=20Documenting=20the=20configur ation=20of=20syslog |Sender:=20 |To:=20; bh=oLcIDIRcB1XQyqYAKG13EGUfhxa0Vv4TLluWirtN+fU=; b=jrhYAS8AOB+Ds+7tzKjNJ5jgYKcbLg8ywpPqrl6p7M0xYYElft4ZcECM3w pNTZxbLKusv8XakoVfapNZZ9Clq4yFUXORrnmDJb60qABQMFAFbvq0CFC8VS qP+q6j7byC; Authentication-Results: rtp-dkim-1; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 Does defining configuration concepts require that you define the functional aspects of syslog application? =20 I can see many different uses of syslog, each requiring different configuration. It all depends on the context it is used in. It can be stand-along, it can be embedded, it can be part of a logging library. It can be a forwarder, a receiver or both. A receiver can write to file or database. It can be configured to ignore some messages based message names or whatever patterns. Forwarder can buffer things in various ways, throttle them, etc. A receiver can do de-duplication, correlation, etc. There is not end of features an syslog application may have. =20 The UNIX syslog daemon is just one example application using syslog protocol. The original one is pretty trivial one and mostly geared towards local logging by OS sub-systems. Even Solaris and Linux syslog daemons have slightly different features. =20 Another question is what kind of interop do we accomplish with standard configuration of syslog? Is it important? My gut feel is that defining standard configuration for syslog application is a dead-end because it requires us to define the specific application. IMO, we should let the specific application designers do that. =20 Regards, Anton. =20 > -----Original Message----- > From: Chris Lonvick (clonvick)=20 > Sent: Wednesday, January 16, 2008 5:32 AM > To: syslog@ietf.org > Subject: [Syslog] Documenting the configuration of syslog >=20 > Hi WG, >=20 > Things are changing in the IETF around documenting the=20 > management and operations of protocols. The OPS Area WG has=20 > been documenting a change of approach, in which SNMP and MIBs=20 > are not the only way to configure, manage and operate a=20 > protocol, and existing practices are taken into greater=20 > consideration when choosing the right tool for a task. >=20 > We'd like to open that discussion to the WG to get some=20 > opinions on this.=20 > If we can get a sense of direction on this from the WG, then=20 > we'll discuss this with our Advisor (Sam) and our ADs. >=20 > Documenting the current operational practices for configuring=20 > syslog (i.e.=20 > syslog.conf) might be much more useful to the operator=20 > community than developing a MIB module to do syslog=20 > configuration. Is standardizing aspects of the common=20 > syslog.conf configuration file the best way to show how to=20 > configure a device to send syslog messages securely across the wire? >=20 > Another approach would be to define some standard Netconf=20 > data models for configuring secure syslog, but that is likely=20 > to get into serious scope discussions that would bog down=20 > such an approach. >=20 > Our chartered focus is to resolve security issues in logging,=20 > so we need to stay focused on defining management to support=20 > the work we have done here. It is not in scope to define a=20 > comnplete syslog.conf file format, nor to standardize aspects=20 > of the file not related to configuring secure logging. >=20 > Common syslog.conf files already address udp transport but we=20 > would need to define how to also utilize tls and RFC3195=20 > transports in this work, and possibly how to configure=20 > syslog.conf to support syslog signing. >=20 > The OpSec WG is discussing whether to document best current=20 > practices for syslog operations. If they do so, we may need=20 > to coordinate with the OpSec WG about configuring security=20 > for syslog. If syslog.conf is covered in the standards of=20 > other standards development organizations, such as POSIX, we=20 > also may need to liaison with those SDOs to get support for=20 > our modifications to syslog.conf. >=20 > If we do propose standard content for a configuration file=20 > for syslog, we will still need to make the WG designs=20 > manageable for purposes of monitoring. A MIB module is the=20 > current IETF best practice for providing information for=20 > fault and performance monitoring and for notifications. >=20 > Please respond to this and let us know if you think that=20 > documenting some standardized content for syslog.conf is=20 > going to be a better way to clarify the configuration of=20 > syslog rather than writing a MIB module that includes=20 > configuration functionality. >=20 > Thanks, > Chris & David >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 16 15:49:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFFCf-0008AI-TQ; Wed, 16 Jan 2008 15:49:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFFCe-00085a-5c for syslog@ietf.org; Wed, 16 Jan 2008 15:49:40 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFFCd-00017P-66 for syslog@ietf.org; Wed, 16 Jan 2008 15:49:40 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Jan 2008 12:49:38 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0GKnccP003907 for ; Wed, 16 Jan 2008 12:49:38 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0GKncnj012027 for ; Wed, 16 Jan 2008 20:49:38 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 12:49:38 -0800 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] Documenting the configuration of syslog Date: Wed, 16 Jan 2008 12:49:28 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB050F354D@xmb-sjc-236.amer.cisco.com> In-Reply-To: <98AE08B66FAD1742BED6CB9522B7312204422E1B@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Documenting the configuration of syslog Thread-Index: AchYRF9Tk2bjte7mRlK2b3hH+8+K9gAN+NmQAADBV7A= References: <98AE08B66FAD1742BED6CB9522B7312204422E1B@xmb-rtp-20d.amer.cisco.com> From: "Alexander Clemm (alex)" To: "Anton Okmianski (aokmians)" , X-OriginalArrivalTime: 16 Jan 2008 20:49:38.0436 (UTC) FILETIME=[4F4A6440:01C85881] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6580; t=1200516578; x=1201380578; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Documenting=20the=20configur ation=20of=20syslog |Sender:=20; bh=m3NA10gv/DZJG9oUbFeKQLq/yhvRnalFgGKnI9TmGTA=; b=R1IX8EkJcX/JUzIg7e6opE8b/riB3vcZ3MCMSou1QFnZ9v2nyF8pwQ2hjc 2Sy1cuHfGbmUEMVuUC9eihIc8meO81SFjQCvOosr5E2u8ivY3UEmN24oWIXr yX0G5Rfv+Si/s8r2E1IO9G98/PQLUrGb2VyqSGmOkwcAv+ZdFT4n0=; Authentication-Results: sj-dkim-1; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 share similar sentiment as Anton. First of all, I agree that it may be a good idea reflecting current best practices to let MIB focus on monitoring aspects, not configuration aspects. Second, I am not sure how much standardization of configuration aspects is really needed to facilitate interoperability. In general, there are many aspects that _could_ be configurable, but whether they are indeed made configurable may be a matter of implementation differentiation - some products may offer some extra "bells and whistles" in making certain aspects configurable that others do not, then again some vendors may decide to not offer those bells and whistles but do things in a certain way in order to make the corresponding product simpler to use and not overwhelm users. In any event, those are local decisions with little impact of how different syslog implementations would interoperate. =20 I think it is fine in some cases to indicate what aspects would constitute valid knobs, as has for example been done with syslog-sign. If the intent of specifying a .conf file is to provide a menu of such knobs, that's fine. However, I would stop short of mandating that all those knobs actually have to be implemented, and implemented in a certain fashion. If we wanted to go that route, then I would assume going down the route of defining this as a data model for Netconf is the right way, but as mentioned this leads to some issue regarding scope of the working group, in addition to the fact that we'd be getting ahead of ourselves as Netconf isn't quite there yet as it is my understanding that work on Netconf data models is still far from a conclusion.=20 --- Alex -----Original Message----- From: Anton Okmyanskiy (aokmians)=20 Sent: Wednesday, January 16, 2008 12:24 PM To: syslog@ietf.org Subject: RE: [Syslog] Documenting the configuration of syslog Does defining configuration concepts require that you define the functional aspects of syslog application? =20 I can see many different uses of syslog, each requiring different configuration. It all depends on the context it is used in. It can be stand-along, it can be embedded, it can be part of a logging library. It can be a forwarder, a receiver or both. A receiver can write to file or database. It can be configured to ignore some messages based message names or whatever patterns. Forwarder can buffer things in various ways, throttle them, etc. A receiver can do de-duplication, correlation, etc. There is not end of features an syslog application may have. =20 The UNIX syslog daemon is just one example application using syslog protocol. The original one is pretty trivial one and mostly geared towards local logging by OS sub-systems. Even Solaris and Linux syslog daemons have slightly different features. =20 Another question is what kind of interop do we accomplish with standard configuration of syslog? Is it important? My gut feel is that defining standard configuration for syslog application is a dead-end because it requires us to define the specific application. IMO, we should let the specific application designers do that. =20 Regards, Anton. =20 > -----Original Message----- > From: Chris Lonvick (clonvick) > Sent: Wednesday, January 16, 2008 5:32 AM > To: syslog@ietf.org > Subject: [Syslog] Documenting the configuration of syslog >=20 > Hi WG, >=20 > Things are changing in the IETF around documenting the management and=20 > operations of protocols. The OPS Area WG has been documenting a=20 > change of approach, in which SNMP and MIBs are not the only way to=20 > configure, manage and operate a protocol, and existing practices are=20 > taken into greater consideration when choosing the right tool for a=20 > task. >=20 > We'd like to open that discussion to the WG to get some opinions on=20 > this. > If we can get a sense of direction on this from the WG, then we'll=20 > discuss this with our Advisor (Sam) and our ADs. >=20 > Documenting the current operational practices for configuring syslog=20 > (i.e. > syslog.conf) might be much more useful to the operator community than=20 > developing a MIB module to do syslog configuration. Is standardizing=20 > aspects of the common syslog.conf configuration file the best way to=20 > show how to configure a device to send syslog messages securely across > the wire? >=20 > Another approach would be to define some standard Netconf data models=20 > for configuring secure syslog, but that is likely to get into serious=20 > scope discussions that would bog down such an approach. >=20 > Our chartered focus is to resolve security issues in logging, so we=20 > need to stay focused on defining management to support the work we=20 > have done here. It is not in scope to define a comnplete syslog.conf=20 > file format, nor to standardize aspects of the file not related to=20 > configuring secure logging. >=20 > Common syslog.conf files already address udp transport but we would=20 > need to define how to also utilize tls and RFC3195 transports in this=20 > work, and possibly how to configure syslog.conf to support syslog=20 > signing. >=20 > The OpSec WG is discussing whether to document best current practices=20 > for syslog operations. If they do so, we may need to coordinate with=20 > the OpSec WG about configuring security for syslog. If syslog.conf is=20 > covered in the standards of other standards development organizations, > such as POSIX, we also may need to liaison with those SDOs to get=20 > support for our modifications to syslog.conf. >=20 > If we do propose standard content for a configuration file for syslog, > we will still need to make the WG designs manageable for purposes of=20 > monitoring. A MIB module is the current IETF best practice for=20 > providing information for fault and performance monitoring and for=20 > notifications. >=20 > Please respond to this and let us know if you think that documenting=20 > some standardized content for syslog.conf is going to be a better way=20 > to clarify the configuration of syslog rather than writing a MIB=20 > module that includes configuration functionality. >=20 > Thanks, > Chris & David >=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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 16 15:59:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFFM8-0004so-KU; Wed, 16 Jan 2008 15:59:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFFM7-0004si-GF for syslog@ietf.org; Wed, 16 Jan 2008 15:59:27 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFFM6-0002Mt-KD for syslog@ietf.org; Wed, 16 Jan 2008 15:59:27 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Jan 2008 12:59:26 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0GKxP6M018480; Wed, 16 Jan 2008 12:59:25 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0GKxPnk020404; Wed, 16 Jan 2008 20:59:25 GMT Date: Wed, 16 Jan 2008 12:59:25 -0800 (PST) From: Chris Lonvick To: "Anton Okmyanskiy (aokmians)" Subject: RE: [Syslog] Documenting the configuration of syslog In-Reply-To: <98AE08B66FAD1742BED6CB9522B7312204422E1B@xmb-rtp-20d.amer.cisco.com> Message-ID: References: <98AE08B66FAD1742BED6CB9522B7312204422E1B@xmb-rtp-20d.amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6833; t=1200517165; x=1201381165; c=relaxed/simple; s=sjdkim1004; 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]=20Documenting=20the=20configur ation=20of=20syslog |Sender:=20; bh=3za42dT11GD4fBkCELzjspaPj18BEyzYmlxs3eqgOY8=; b=I+psu823r49dpZ8w+HqefLF+Z4l0fABvSNFlXQd1iX13S4YB9t+J8Wq4cw qwz9M7CBQXmOgoGYWvSW0deLynrpQ17kjRoRNNXejiQqqS/4O/fI4HYt2kxO mSoXeeNZpM4SPYttJEdQBZJdLO9Rn/7j4v5KLU/zLWOYiOdK1zdkQ=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 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 Anton, Perhaps I wasn't so verbose in my original posting. Documenting the SNMP MIBs will give us counters and a way to configure syslog via SNMP. We've had many discussions of what we want to count, and how it _should_ add up. We've also had discussions on how to tell a syslog device how it should enable the transmission of messages and what Facilities and Severities it should send to where. From those discussions, however, David and I are not sure that anyone will ever use those counters, or will ever use SNMP to configure syslog. If that's the case, then we don't feel that we should go through the effort to produce such a document. On the other hand, we know that many people edit syslog.conf. Perhaps we should document how to enable the sending of syslog messages as it has historically been done, and forget about counters if no one here objects. If we go this route then we do not see the need in the syslog WG to fully document how to filter received messages nor how to select messages for transmission. We think that we can provide the Operator community a good service by describing how lpr.* messages can be transmitted to "loghost@example.org" via udp, and how to transmit kern.* messages to a different machine via tls. The interoperability we hope to achieve by documenting syslog.conf (in it's most generic form) will be to demonstrate the configuration aspects that an operator will have to address to make it work. For simple udp transport, it is to just assign an address. For tls, someone will need to think through the aspects of how to designate the certificate that will be presented by the server, and what policy decisions will need to be made on the sender. Similar thoughts will need to be done for 3195 configurations. I agree that documenting all of the potential features of the syslog appliation is out of scope for this WG. We're merely asking if the WG feels that a simpler document on how to configure and use syslog would be more beneficial than documenting a MIB. Thanks, Chris On Wed, 16 Jan 2008, Anton Okmyanskiy (aokmians) wrote: > Does defining configuration concepts require that you define the > functional aspects of syslog application? > > I can see many different uses of syslog, each requiring different > configuration. It all depends on the context it is used in. It can be > stand-along, it can be embedded, it can be part of a logging library. > It can be a forwarder, a receiver or both. A receiver can write to file > or database. It can be configured to ignore some messages based message > names or whatever patterns. Forwarder can buffer things in various ways, > throttle them, etc. A receiver can do de-duplication, correlation, etc. > There is not end of features an syslog application may have. > > The UNIX syslog daemon is just one example application using syslog > protocol. The original one is pretty trivial one and mostly geared > towards local logging by OS sub-systems. Even Solaris and Linux syslog > daemons have slightly different features. > > Another question is what kind of interop do we accomplish with standard > configuration of syslog? Is it important? > > My gut feel is that defining standard configuration for syslog > application is a dead-end because it requires us to define the specific > application. IMO, we should let the specific application designers do > that. > > Regards, > Anton. > >> -----Original Message----- >> From: Chris Lonvick (clonvick) >> Sent: Wednesday, January 16, 2008 5:32 AM >> To: syslog@ietf.org >> Subject: [Syslog] Documenting the configuration of syslog >> >> Hi WG, >> >> Things are changing in the IETF around documenting the >> management and operations of protocols. The OPS Area WG has >> been documenting a change of approach, in which SNMP and MIBs >> are not the only way to configure, manage and operate a >> protocol, and existing practices are taken into greater >> consideration when choosing the right tool for a task. >> >> We'd like to open that discussion to the WG to get some >> opinions on this. >> If we can get a sense of direction on this from the WG, then >> we'll discuss this with our Advisor (Sam) and our ADs. >> >> Documenting the current operational practices for configuring >> syslog (i.e. >> syslog.conf) might be much more useful to the operator >> community than developing a MIB module to do syslog >> configuration. Is standardizing aspects of the common >> syslog.conf configuration file the best way to show how to >> configure a device to send syslog messages securely across the wire? >> >> Another approach would be to define some standard Netconf >> data models for configuring secure syslog, but that is likely >> to get into serious scope discussions that would bog down >> such an approach. >> >> Our chartered focus is to resolve security issues in logging, >> so we need to stay focused on defining management to support >> the work we have done here. It is not in scope to define a >> comnplete syslog.conf file format, nor to standardize aspects >> of the file not related to configuring secure logging. >> >> Common syslog.conf files already address udp transport but we >> would need to define how to also utilize tls and RFC3195 >> transports in this work, and possibly how to configure >> syslog.conf to support syslog signing. >> >> The OpSec WG is discussing whether to document best current >> practices for syslog operations. If they do so, we may need >> to coordinate with the OpSec WG about configuring security >> for syslog. If syslog.conf is covered in the standards of >> other standards development organizations, such as POSIX, we >> also may need to liaison with those SDOs to get support for >> our modifications to syslog.conf. >> >> If we do propose standard content for a configuration file >> for syslog, we will still need to make the WG designs >> manageable for purposes of monitoring. A MIB module is the >> current IETF best practice for providing information for >> fault and performance monitoring and for notifications. >> >> Please respond to this and let us know if you think that >> documenting some standardized content for syslog.conf is >> going to be a better way to clarify the configuration of >> syslog rather than writing a MIB module that includes >> configuration functionality. >> >> Thanks, >> Chris & David >> >> >> _______________________________________________ >> 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 Jan 16 17:15:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGXv-0007CL-T8; Wed, 16 Jan 2008 17:15:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGXv-0007B3-ED for syslog@ietf.org; Wed, 16 Jan 2008 17:15:43 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFGXt-0003pF-DZ for syslog@ietf.org; Wed, 16 Jan 2008 17:15:43 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44B208A3B7; Wed, 16 Jan 2008 23:15:40 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20327-07-2; Wed, 16 Jan 2008 23:15:35 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E8E18A39B; Wed, 16 Jan 2008 23:15:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F34164683D8; Wed, 16 Jan 2008 23:15:19 +0100 (CET) Date: Wed, 16 Jan 2008 23:15:19 +0100 From: Juergen Schoenwaelder To: Chris Lonvick Subject: Re: [Syslog] Documenting the configuration of syslog Message-ID: <20080116221519.GA28500@elstar.local> Mail-Followup-To: Chris Lonvick , "Anton Okmyanskiy (aokmians)" , syslog@ietf.org References: <98AE08B66FAD1742BED6CB9522B7312204422E1B@xmb-rtp-20d.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Wed, Jan 16, 2008 at 12:59:25PM -0800, Chris Lonvick wrote: [...] I do not understand whether this is a discussion for re-chartering the syslog WG or whether this is a discussion to clarify the current charter or something else. Taking the charter question aside for the moment, I personally can see value in having an information model defined (what are the conceptual knobs you have and what do they affect in the processing of syslog messages). I am not sure what the value of trying a standard .conf file is or whether this is feasible at all. (Like we found out that traditional syslog implementations are very different, we might find out that the .conf files that go along with traditional syslog implementations have a similar degree of differences). Turning back to the existing charter, I also note that this WG is in the security area and one can of course raise the question whether syslog configuration is a subject for this WG in this area. So perhaps it is sufficient list the things an implementation needs to know in order to use the security mechanism and the rest can be left to the OPSEC WG to work out. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 16 17:43:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGz2-0002Cs-9Q; Wed, 16 Jan 2008 17:43:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGz0-00024n-QT for syslog@ietf.org; Wed, 16 Jan 2008 17:43:42 -0500 Received: from qmta02.emeryville.ca.mail.comcast.net ([76.96.30.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFGyy-0004Lr-Hr for syslog@ietf.org; Wed, 16 Jan 2008 17:43:42 -0500 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id dvva1Y00B17UAYk0A0CY00; Wed, 16 Jan 2008 22:43:39 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id dyiz1Y0024HwxpC8Z00000; Wed, 16 Jan 2008 22:43:04 +0000 X-Authority-Analysis: v=1.0 c=1 a=xbbhop4STboA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=cRrD69k0k2-7uMNOyoYA:9 a=pcaHvzydFvkQV4CSa2pzllI6o38A:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Chris Lonvick'" References: <98AE08B66FAD1742BED6CB9522B7312204422E1B@xmb-rtp-20d.amer.cisco.com> <20080116221519.GA28500@elstar.local> Subject: RE: [Syslog] Documenting the configuration of syslog Date: Wed, 16 Jan 2008 17:43:33 -0500 Message-ID: <02bb01c85891$3a451fd0$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchYjWNRhBEZXx35RX+h3Xt8jv4oQAAArHPw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <20080116221519.GA28500@elstar.local> 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 List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [as co-chair] This discussion started between Chris and I concerning the remaining charter item of submitting the Syslog Device MIB. The existing MIB has been rather controversial, and has knobs for configuring syslog using the MIB, when osme implementers say they have no demand for a MIB for syslog, and there has been lots of discussion in the IETF that SNMP is often not the preferred way to do configuration. So we started discussing whether to approach manageability differently. And we are looking for WG input. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 16, 2008 5:15 PM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: [Syslog] Documenting the configuration of syslog > > On Wed, Jan 16, 2008 at 12:59:25PM -0800, Chris Lonvick wrote: > > [...] > > I do not understand whether this is a discussion for re-chartering the > syslog WG or whether this is a discussion to clarify the current > charter or something else. > > Taking the charter question aside for the moment, I personally can see > value in having an information model defined (what are the conceptual > knobs you have and what do they affect in the processing of syslog > messages). I am not sure what the value of trying a standard .conf > file is or whether this is feasible at all. (Like we found out that > traditional syslog implementations are very different, we might find > out that the .conf files that go along with traditional syslog > implementations have a similar degree of differences). > > Turning back to the existing charter, I also note that this WG is in > the security area and one can of course raise the question whether > syslog configuration is a subject for this WG in this area. So perhaps > it is sufficient list the things an implementation needs to know in > order to use the security mechanism and the rest can be left to the > OPSEC WG to work out. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > 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 Jan 16 17:58:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFHDS-0005tu-1S; Wed, 16 Jan 2008 17:58:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFHDQ-0005tY-Sq for syslog@ietf.org; Wed, 16 Jan 2008 17:58:36 -0500 Received: from qmta02.emeryville.ca.mail.comcast.net ([76.96.30.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFHDQ-00045U-7y for syslog@ietf.org; Wed, 16 Jan 2008 17:58:36 -0500 Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id dpoJ1Y00B0vp7WL0A0s700; Wed, 16 Jan 2008 22:58:35 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id dyy81Y00A4HwxpC8R00000; Wed, 16 Jan 2008 22:58:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=xbbhop4STboA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=0rM31aw3RBHIWikXZXUA:9 a=Bg5RwKnQfyxDkoIQXckA:7 a=7YU6xWzmKgV9X2T4HI_LDzEgoOoA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Chris Lonvick'" References: <98AE08B66FAD1742BED6CB9522B7312204422E1B@xmb-rtp-20d.amer.cisco.com> <20080116221519.GA28500@elstar.local> Subject: RE: [Syslog] Documenting the configuration of syslog Date: Wed, 16 Jan 2008 17:58:29 -0500 Message-ID: <02c501c85893$5082df10$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchYjWNRhBEZXx35RX+h3Xt8jv4oQAAA9nig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <20080116221519.GA28500@elstar.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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, [as contributor] Traditionally, standards are based on some level of agreement across multiple implementations about what should be standardized. I have looked at syslog MIB modules from multiple vendors and have not found any that model the same concepts that the current syslog MIB models. Our current Devcice MIB is about configuring and monitoring the applications that use syslog. I have concerns about having this WG produce a MIB module that nobody seems to want. The industry doesn't seem to have "rough consensus" that this is the MIB that is needed. Vendor-specific MIB modules seems to focus on one of two approaches towards monitoring syslog activity - modeling a single syslog daemon, or capturing syslog messages in a MIB table so the logged information can also be accessed via SNMP. My limited research indicates that syslog.conf is the defacto standard for configuration of syslog. I wonder if there is enough similarity between vendors to develop a standard for those aspects related to the work of this WG. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 16, 2008 5:15 PM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: [Syslog] Documenting the configuration of syslog > > On Wed, Jan 16, 2008 at 12:59:25PM -0800, Chris Lonvick wrote: > > [...] > > I do not understand whether this is a discussion for re-chartering the > syslog WG or whether this is a discussion to clarify the current > charter or something else. > > Taking the charter question aside for the moment, I personally can see > value in having an information model defined (what are the conceptual > knobs you have and what do they affect in the processing of syslog > messages). I am not sure what the value of trying a standard .conf > file is or whether this is feasible at all. (Like we found out that > traditional syslog implementations are very different, we might find > out that the .conf files that go along with traditional syslog > implementations have a similar degree of differences). > > Turning back to the existing charter, I also note that this WG is in > the security area and one can of course raise the question whether > syslog configuration is a subject for this WG in this area. So perhaps > it is sufficient list the things an implementation needs to know in > order to use the security mechanism and the rest can be left to the > OPSEC WG to work out. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > 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 Jan 16 18:00:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFHEy-0006p3-Di; Wed, 16 Jan 2008 18:00:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFHEw-0006ow-OH for syslog@ietf.org; Wed, 16 Jan 2008 18:00:10 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFHEw-00047E-5N for syslog@ietf.org; Wed, 16 Jan 2008 18:00:10 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72D878A3B7; Thu, 17 Jan 2008 00:00:08 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 23625-05; Thu, 17 Jan 2008 00:00:03 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98A8C8A2FA; Thu, 17 Jan 2008 00:00:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CEC084686DD; Thu, 17 Jan 2008 00:00:02 +0100 (CET) Date: Thu, 17 Jan 2008 00:00:02 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Syslog] Documenting the configuration of syslog Message-ID: <20080116230002.GE28500@elstar.local> Mail-Followup-To: David Harrington , 'Chris Lonvick' , syslog@ietf.org References: <20080116221519.GA28500@elstar.local> <02bb01c85891$3a451fd0$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02bb01c85891$3a451fd0$6502a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de 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 Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Wed, Jan 16, 2008 at 05:43:33PM -0500, David Harrington wrote: > [as co-chair] > This discussion started between Chris and I concerning the remaining > charter item of submitting the Syslog Device MIB. > > The existing MIB has been rather controversial, and has knobs for > configuring syslog using the MIB, when osme implementers say they have > no demand for a MIB for syslog, and there has been lots of discussion > in the IETF that SNMP is often not the preferred way to do > configuration. So we started discussing whether to approach > manageability differently. And we are looking for WG input. The charter says: - A document will be produced to describe the MIB for syslog entities. This text (whether on purpose or by accident) does not define what function the MIB should support nor did I find the work configuration in the charter text. Most people seem to agree that producing a read-only monitoring MIB is (a) much easier to do than a writable MIB, (b) much easier to reach consensus on, and (c) much easier to implement, I would take a rather pragmatic approach: Take the device MIB and trim it down to the bare essential counters needed to monitor the activity of syslog entities (or whatever the right term is). This will make the MIB small and increase the chances that it actually gets implemented. At the same time, the WG has accomplished its charter. I somehow feel that addressing syslog configuration within this WG at this point in time may not be the right thing to do. But I am happy to be proven wrong by lots of reply emails where people commit serious resources to take on this task and commit themself to implement the result... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 17 02:25:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFP7s-0007xM-Vp; Thu, 17 Jan 2008 02:25:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFP7r-0007xG-I3 for syslog@ietf.org; Thu, 17 Jan 2008 02:25:23 -0500 Received: from mailin.adiscon.com ([85.10.198.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFP7p-0003FR-BI for syslog@ietf.org; Thu, 17 Jan 2008 02:25:23 -0500 Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 65F297AC358; Thu, 17 Jan 2008 08:25:20 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw5st1Gx2olt; Thu, 17 Jan 2008 08:25:20 +0100 (CET) Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by mailin.adiscon.com (Postfix) with ESMTP id 175C97AC356; Thu, 17 Jan 2008 08:25: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: [Syslog] Documenting the configuration of syslog X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 17 Jan 2008 08:25:15 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30878C@grfint2.intern.adiscon.com> In-Reply-To: <02c501c85893$5082df10$6502a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Documenting the configuration of syslog Thread-Index: AchYjWNRhBEZXx35RX+h3Xt8jv4oQAAA9nigABHPq7A= References: <98AE08B66FAD1742BED6CB9522B7312204422E1B@xmb-rtp-20d.amer.cisco.com><20080116221519.GA28500@elstar.local> <02c501c85893$5082df10$6502a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" , , "Chris Lonvick" X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, [speaking as a syslog implementor] let me compare a few well known implementations when it comes to syslog.conf: Solaris - supports base format Sysklogd - supports base format with some platform-specific extensions (e.g. BSD) Syslog-ng totally different format Rsyslog - supports base format with *a lot* of extensions, new format under review WinSyslog/MonitorWare - no syslog.conf at all Kiwi Syslog - no syslog.conf at all Pure syslog senders tend to have a different format, syslog.conf is more for collectors. Which also manifests in the fact that there are no originating rules. The concepts of syslog.conf could probably be applied to all above-mentioned collectors. A subset probably applies to all originators. The plus is it is well known. The con is it is ugly and feature-less. In rsyslog, I have chosen to support that format because everyone knows it and it is a de-facto standard. In rsyslog, I will introduce another format because rsyslog.conf is not powerful and user-friendly enough. Bottom line: I don't like it, but the base rsyslog.conf format is the closest thing to a common configuration format, or at least concept of such a format. Modern syslog applications can only very partly configured via it. If we standardize it, it would be nice to define a standard way of doing extensions, because every capable syslog app needs them. However, that can be done (I have done it in an ugly way in rsyslog). Even with its limited scope, standardizing syslog.conf is multiple times more useful than creating a MIB module for syslog configuration. I share the doubt that anybody will implement it. At least I do not intend to and do not see any market need. My 2 cts... Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, January 16, 2008 11:58 PM > To: j.schoenwaelder@jacobs-university.de; 'Chris Lonvick' > Cc: syslog@ietf.org > Subject: RE: [Syslog] Documenting the configuration of syslog >=20 > Hi, >=20 > [as contributor] > Traditionally, standards are based on some level of agreement across > multiple implementations about what should be standardized. >=20 > I have looked at syslog MIB modules from multiple vendors and have not > found any that model the same concepts that the current syslog MIB > models. Our current Devcice MIB is about configuring and monitoring > the applications that use syslog. I have concerns about having this WG > produce a MIB module that nobody seems to want. The industry doesn't > seem to have "rough consensus" that this is the MIB that is needed. >=20 > Vendor-specific MIB modules seems to focus on one of two approaches > towards monitoring syslog activity - modeling a single syslog daemon, > or capturing syslog messages in a MIB table so the logged information > can also be accessed via SNMP. >=20 > My limited research indicates that syslog.conf is the defacto standard > for configuration of syslog. I wonder if there is enough similarity > between vendors to develop a standard for those aspects related to the > work of this WG. >=20 > dbh >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, January 16, 2008 5:15 PM > > To: Chris Lonvick > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] Documenting the configuration of syslog > > > > On Wed, Jan 16, 2008 at 12:59:25PM -0800, Chris Lonvick wrote: > > > > [...] > > > > I do not understand whether this is a discussion for re-chartering > the > > syslog WG or whether this is a discussion to clarify the current > > charter or something else. > > > > Taking the charter question aside for the moment, I personally can > see > > value in having an information model defined (what are the > conceptual > > knobs you have and what do they affect in the processing of syslog > > messages). I am not sure what the value of trying a standard .conf > > file is or whether this is feasible at all. (Like we found out that > > traditional syslog implementations are very different, we might find > > out that the .conf files that go along with traditional syslog > > implementations have a similar degree of differences). > > > > Turning back to the existing charter, I also note that this WG is in > > the security area and one can of course raise the question whether > > syslog configuration is a subject for this WG in this area. So > perhaps > > it is sufficient list the things an implementation needs to know in > > order to use the security mechanism and the rest can be left to the > > OPSEC WG to work out. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > 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 Jan 17 03:45:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQNf-0004nQ-Cf; Thu, 17 Jan 2008 03:45:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQNd-0004nL-VT for syslog@ietf.org; Thu, 17 Jan 2008 03:45:45 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFQNc-0004VT-SK for syslog@ietf.org; Thu, 17 Jan 2008 03:45:45 -0500 X-IronPort-AV: E=Sophos;i="4.24,300,1196668800"; d="scan'208";a="8477332" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 17 Jan 2008 00:45:44 -0800 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 m0H8jiTf021379; Thu, 17 Jan 2008 00:45:44 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m0H8jhsj022065; Thu, 17 Jan 2008 08:45:43 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 00:45:43 -0800 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] Documenting the configuration of syslog Date: Thu, 17 Jan 2008 00:45:36 -0800 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA30878C@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Documenting the configuration of syslog Thread-Index: AchYjWNRhBEZXx35RX+h3Xt8jv4oQAAA9nigABHPq7AAAqmvcA== From: "Steve Chang (schang99)" To: "Rainer Gerhards" , "David Harrington" , , "Chris Lonvick (clonvick)" X-OriginalArrivalTime: 17 Jan 2008 08:45:43.0051 (UTC) FILETIME=[58325DB0:01C858E5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6732; t=1200559544; x=1201423544; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=schang99@cisco.com; z=From:=20=22Steve=20Chang=20(schang99)=22=20 |Subject:=20RE=3A=20[Syslog]=20Documenting=20the=20configur ation=20of=20syslog |Sender:=20; bh=yEOj0Qcfzi3Qo0oZk36Y5NyJhrU8Zo1dCpjY0ITqqQc=; b=gqe8OEnwhL9xEy1SVsnd9AacleGre+Dp/0k/Vzft2krPkuRkd17pqkcNKD J2skXPzt5o9QirEUiHrVi2nDOW/YN9LvTBEGM3rGwnqCDoQJ9AhfyFy+HiYd Wp2MVU7UwV; Authentication-Results: sj-dkim-2; header.From=schang99@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org As a syslog implementer myself, I think Rainer offered many good points=20 and summarized it well. Even lots of effort were to be poured into this new initiative, syslog.conf=20 will probably only address a minimal set of features that most would agree=20 to. However, as time goes by, many new features will come along and will=20 be added in and those new features may require totally new way or new format to support their configurations. Plus, standardization of syslog.conf will not stop vendors from adding their proprietary way of doing configurations=20 in order to gain an edge in the market place. Therefore, I would conclude the same as Rainer - why bother! Steve Chang > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Wednesday, January 16, 2008 11:25 PM > To: David Harrington; j.schoenwaelder@jacobs-university.de; Chris Lonvick > (clonvick) > Cc: syslog@ietf.org > Subject: RE: [Syslog] Documenting the configuration of syslog >=20 > David, >=20 > [speaking as a syslog implementor] >=20 > let me compare a few well known implementations when it comes to > syslog.conf: >=20 > Solaris - supports base format > Sysklogd - supports base format with some platform-specific extensions > (e.g. BSD) > Syslog-ng totally different format > Rsyslog - supports base format with *a lot* of extensions, new format > under review > WinSyslog/MonitorWare - no syslog.conf at all > Kiwi Syslog - no syslog.conf at all >=20 > Pure syslog senders tend to have a different format, syslog.conf is more > for collectors. Which also manifests in the fact that there are no > originating rules. >=20 > The concepts of syslog.conf could probably be applied to all > above-mentioned collectors. A subset probably applies to all > originators. The plus is it is well known. The con is it is ugly and > feature-less. In rsyslog, I have chosen to support that format because > everyone knows it and it is a de-facto standard. In rsyslog, I will > introduce another format because rsyslog.conf is not powerful and > user-friendly enough. >=20 > Bottom line: I don't like it, but the base rsyslog.conf format is the > closest thing to a common configuration format, or at least concept of > such a format. Modern syslog applications can only very partly > configured via it. If we standardize it, it would be nice to define a > standard way of doing extensions, because every capable syslog app needs > them. However, that can be done (I have done it in an ugly way in > rsyslog). >=20 > Even with its limited scope, standardizing syslog.conf is multiple times > more useful than creating a MIB module for syslog configuration. I share > the doubt that anybody will implement it. At least I do not intend to > and do not see any market need. >=20 > My 2 cts... >=20 > Rainer >=20 > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Wednesday, January 16, 2008 11:58 PM > > To: j.schoenwaelder@jacobs-university.de; 'Chris Lonvick' > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] Documenting the configuration of syslog > > > > Hi, > > > > [as contributor] > > Traditionally, standards are based on some level of agreement across > > multiple implementations about what should be standardized. > > > > I have looked at syslog MIB modules from multiple vendors and have not > > found any that model the same concepts that the current syslog MIB > > models. Our current Devcice MIB is about configuring and monitoring > > the applications that use syslog. I have concerns about having this WG > > produce a MIB module that nobody seems to want. The industry doesn't > > seem to have "rough consensus" that this is the MIB that is needed. > > > > Vendor-specific MIB modules seems to focus on one of two approaches > > towards monitoring syslog activity - modeling a single syslog daemon, > > or capturing syslog messages in a MIB table so the logged information > > can also be accessed via SNMP. > > > > My limited research indicates that syslog.conf is the defacto standard > > for configuration of syslog. I wonder if there is enough similarity > > between vendors to develop a standard for those aspects related to the > > work of this WG. > > > > dbh > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Wednesday, January 16, 2008 5:15 PM > > > To: Chris Lonvick > > > Cc: syslog@ietf.org > > > Subject: Re: [Syslog] Documenting the configuration of syslog > > > > > > On Wed, Jan 16, 2008 at 12:59:25PM -0800, Chris Lonvick wrote: > > > > > > [...] > > > > > > I do not understand whether this is a discussion for re-chartering > > the > > > syslog WG or whether this is a discussion to clarify the current > > > charter or something else. > > > > > > Taking the charter question aside for the moment, I personally can > > see > > > value in having an information model defined (what are the > > conceptual > > > knobs you have and what do they affect in the processing of syslog > > > messages). I am not sure what the value of trying a standard .conf > > > file is or whether this is feasible at all. (Like we found out that > > > traditional syslog implementations are very different, we might find > > > out that the .conf files that go along with traditional syslog > > > implementations have a similar degree of differences). > > > > > > Turning back to the existing charter, I also note that this WG is in > > > the security area and one can of course raise the question whether > > > syslog configuration is a subject for this WG in this area. So > > perhaps > > > it is sufficient list the things an implementation needs to know in > > > order to use the security mechanism and the rest can be left to the > > > OPSEC WG to work out. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 21 12:10:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH0AO-0003Nm-HR; Mon, 21 Jan 2008 12:10:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH0AK-0003KS-FX; Mon, 21 Jan 2008 12:10:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JH0AK-0007Od-3U; Mon, 21 Jan 2008 12:10:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 0C8062AC77; Mon, 21 Jan 2008 17:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JH09p-0005KQ-QF; Mon, 21 Jan 2008 12:10:01 -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: Mon, 21 Jan 2008 12:10:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D Action:draft-ietf-syslog-tc-mib-05.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Textual Conventions for Syslog Management Author(s) : G. Mansfield Filename : draft-ietf-syslog-tc-mib-05.txt Pages : 14 Date : 2008-01-21 This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-tc-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-tc-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2008-01-21120715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-tc-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-tc-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-21120715.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Mon Jan 21 13:52:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH1lF-000346-VD; Mon, 21 Jan 2008 13:52:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH1lE-00033q-MK for syslog@ietf.org; Mon, 21 Jan 2008 13:52:44 -0500 Received: from qmta02.westchester.pa.mail.comcast.net ([76.96.62.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JH1lE-0003lS-C9 for syslog@ietf.org; Mon, 21 Jan 2008 13:52:44 -0500 Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA02.westchester.pa.mail.comcast.net with comcast id fupx1Y00A0xGWP80500N00; Mon, 21 Jan 2008 18:52:44 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA12.westchester.pa.mail.comcast.net with comcast id fusg1Y00Z4HwxpC3Y00000; Mon, 21 Jan 2008 18:52:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=uLzrDk7aJ0HVehgPoVwA:9 a=eyufMHhgf_sWGvTMF0LuYoEtijQA:4 a=wHQWJa5vkQYA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Mon, 21 Jan 2008 13:52:40 -0500 Message-ID: <009b01c85c5e$ccb8bf40$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.3138 Thread-Index: AchcXsxsCrgTe1s3TUif3ZzlXoH2qQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Syslog] OpSec logging draft X-BeenThere: syslog@lists.ietf.org X-Mailman-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, It is the intent of the OpSec WG to develop a draft about log event taxonomy (what to log). They are planning to have Tina Bird be involved in this work. To ease the pressure on Tina, they are considering finding a co-author to help edit the draft. If you are interested in helping on such a draft, you should contact Joel Jaeggli, the chair of OpSec. (Joel Jaeggli [joelja@bogus.com]) David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 22 08:54:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHJaD-0002sV-Ck; Tue, 22 Jan 2008 08:54:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHJaB-0002rn-QE for syslog@ietf.org; Tue, 22 Jan 2008 08:54:31 -0500 Received: from mk-outboundfilter-1.mail.uk.tiscali.com ([212.74.114.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHJaB-0002Uq-1h for syslog@ietf.org; Tue, 22 Jan 2008 08:54:31 -0500 X-Trace: 24279116/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.6 X-SBRS: None X-RemoteIP: 62.241.163.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIOElUc+8aMG/2dsb2JhbACsQw X-IP-Direction: IN Received: from astro.systems.pipex.net ([62.241.163.6]) by smtp.pipex.tiscali.co.uk with ESMTP; 22 Jan 2008 13:54:24 +0000 Received: from pc6 (1Cust239.tnt29.lnd3.gbr.da.uu.net [62.188.120.239]) by astro.systems.pipex.net (Postfix) with SMTP id A5421E000098; Tue, 22 Jan 2008 13:54:22 +0000 (GMT) Message-ID: <017301c85cf5$ac04d580$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Chris Lonvick'" References: <98AE08B66FAD1742BED6CB9522B7312204422E1B@xmb-rtp-20d.amer.cisco.com><20080116221519.GA28500@elstar.local> <02c501c85893$5082df10$6502a8c0@china.huawei.com> Subject: Re: [Syslog] Documenting the configuration of syslog Date: Tue, 22 Jan 2008 12:09:29 +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: -100.0 (---------------------------------------------------) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I too have looked at proprietary syslog MIB modules and have noticed how much simpler they are. For myself, the essential part of a syslog MIB is the statistics and that only for the device in which it resides. I would not throw away the other parts of the current MIB module, just make the COMPLIANCE optional. Tom Petch ----- Original Message ----- From: "David Harrington" To: ; "'Chris Lonvick'" Cc: Sent: Wednesday, January 16, 2008 11:58 PM Subject: RE: [Syslog] Documenting the configuration of syslog > Hi, > > [as contributor] > Traditionally, standards are based on some level of agreement across > multiple implementations about what should be standardized. > > I have looked at syslog MIB modules from multiple vendors and have not > found any that model the same concepts that the current syslog MIB > models. Our current Devcice MIB is about configuring and monitoring > the applications that use syslog. I have concerns about having this WG > produce a MIB module that nobody seems to want. The industry doesn't > seem to have "rough consensus" that this is the MIB that is needed. > > Vendor-specific MIB modules seems to focus on one of two approaches > towards monitoring syslog activity - modeling a single syslog daemon, > or capturing syslog messages in a MIB table so the logged information > can also be accessed via SNMP. > > My limited research indicates that syslog.conf is the defacto standard > for configuration of syslog. I wonder if there is enough similarity > between vendors to develop a standard for those aspects related to the > work of this WG. > > dbh > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From gdxx@ehsice.endress.com Fri Jan 25 01:07:37 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIHiz-0005Ev-BW for syslog-archive@lists.ietf.org; Fri, 25 Jan 2008 01:07:37 -0500 Received: from [59.91.207.132] (helo=slgk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JIHix-0004jD-RA for syslog-archive@lists.ietf.org; Fri, 25 Jan 2008 01:07:37 -0500 Received: from tkcx ([128.236.123.64]) by slgk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 11:37:41 +0530 Message-ID: <47997CAD.1010202@ehsice.endress.com> Date: Fri, 25 Jan 2008 11:37:41 +0530 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: syslog-archive@lists.ietf.org Subject: Come Relax with Me Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.4 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Inside My Heart http://69.243.130.234/ From koniga@theonboardgroup.com Sun Jan 27 03:20:18 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ2kU-000841-Gt for syslog-archive@lists.ietf.org; Sun, 27 Jan 2008 03:20:18 -0500 Received: from [85.107.163.106] (helo=hdyyqi) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JJ2kT-0008I4-UJ for syslog-archive@lists.ietf.org; Sun, 27 Jan 2008 03:20:18 -0500 Message-ID: <000901c860bc$4fdc1280$0100007f@sqxtywe> From: "Roger Hartman" To: Subject: Mlcrosoft V!s+a U1timate 89, Retail 399 (save 310) Date: Sun, 27 Jan 2008 10:20:17 +0200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 12.0.4210 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de discreet combustion 4.0 for windows - 69 intuit quicken premier 2008 - 29 adobe encore dvd 2 - 49 stuffit deluxe 11 for mac - 29 microsoft sql server developer edition 2005 - 69 microsoft money home & business 7 - 39 avid xpress pro 5.7 - 119 avid xpress pro 5.7 - 119 microsoft onenote pro 2003 - 29 v!slt 'softfactorysale . com' in your Internet Exp1orer From ocky.p.dalessandri@vistaprint.com Tue Jan 29 02:55:55 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJlJz-0000PA-Ks for syslog-archive@lists.ietf.org; Tue, 29 Jan 2008 02:55:55 -0500 Received: from pool-71-110-76-123.lsanca.dsl-w.verizon.net ([71.110.76.123]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJlJt-0002sa-3y for syslog-archive@lists.ietf.org; Tue, 29 Jan 2008 02:55:49 -0500 Received: from iowr ([128.152.54.123]) by pool-71-110-76-123.lsanca.dsl-w.verizon.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Jan 2008 23:55:47 -0800 Message-ID: <001901c8624c$5b8ef070$7b369880@iowr> From: To: Subject: Our Love Nest Date: Mon, 28 Jan 2008 23:55:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 When Love Comes Knocking http://71.74.65.25/ From syslog-bounces@lists.ietf.org Thu Jan 31 02:34:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKTvp-0004Fd-OT; Thu, 31 Jan 2008 02:33:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKTvo-0004FR-9N for syslog@ietf.org; Thu, 31 Jan 2008 02:33:56 -0500 Received: from mailin.adiscon.com ([85.10.198.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKTvm-00059M-GL for syslog@ietf.org; Thu, 31 Jan 2008 02:33:56 -0500 Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 804DA7AC4DC; Thu, 31 Jan 2008 08:33:53 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMSBDDFH45yV; Thu, 31 Jan 2008 08:33:52 +0100 (CET) Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by mailin.adiscon.com (Postfix) with ESMTP id 6F2537AC4CB; Thu, 31 Jan 2008 08:33:52 +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] Documenting the configuration of syslog X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 31 Jan 2008 08:33:45 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308839@grfint2.intern.adiscon.com> In-Reply-To: <017301c85cf5$ac04d580$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Documenting the configuration of syslog Thread-Index: Achc/nMonZwc5M+QTDSEu7lJ7hrnPQG3P+6w References: <98AE08B66FAD1742BED6CB9522B7312204422E1B@xmb-rtp-20d.amer.cisco.com><20080116221519.GA28500@elstar.local><02c501c85893$5082df10$6502a8c0@china.huawei.com> <017301c85cf5$ac04d580$0601a8c0@pc6> From: "Rainer Gerhards" To: "tom.petch" , "David Harrington" , "Chris Lonvick" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi all, I came across this discussion: http://groups.google.com/group/linux.debian.devel/msg/a35cfe80eeac3c3d There seems to be a valid point/demand in standardizing rsyslog.conf format, even though it has limited power. I thought I share the link. Rainer > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Tuesday, January 22, 2008 12:09 PM > To: David Harrington; 'Chris Lonvick' > Cc: syslog@ietf.org > Subject: Re: [Syslog] Documenting the configuration of syslog >=20 > I too have looked at proprietary syslog MIB modules and have noticed > how much > simpler they are. For myself, the essential part of a syslog MIB is > the > statistics and that only for the device in which it resides. >=20 > I would not throw away the other parts of the current MIB module, just > make the > COMPLIANCE optional. >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "David Harrington" > To: ; "'Chris Lonvick'" > > Cc: > Sent: Wednesday, January 16, 2008 11:58 PM > Subject: RE: [Syslog] Documenting the configuration of syslog >=20 >=20 > > Hi, > > > > [as contributor] > > Traditionally, standards are based on some level of agreement across > > multiple implementations about what should be standardized. > > > > I have looked at syslog MIB modules from multiple vendors and have > not > > found any that model the same concepts that the current syslog MIB > > models. Our current Devcice MIB is about configuring and monitoring > > the applications that use syslog. I have concerns about having this > WG > > produce a MIB module that nobody seems to want. The industry doesn't > > seem to have "rough consensus" that this is the MIB that is needed. > > > > Vendor-specific MIB modules seems to focus on one of two approaches > > towards monitoring syslog activity - modeling a single syslog daemon, > > or capturing syslog messages in a MIB table so the logged information > > can also be accessed via SNMP. > > > > My limited research indicates that syslog.conf is the defacto > standard > > for configuration of syslog. I wonder if there is enough similarity > > between vendors to develop a standard for those aspects related to > the > > work of this WG. > > > > dbh > > >=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@chol.com Thu Jan 31 02:34:25 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKTwH-0006ve-4S for syslog-archive@lists.ietf.org; Thu, 31 Jan 2008 02:34:25 -0500 Received: from 85-90-209-134.adsl.sta.dn.velton.ua ([85.90.209.134] helo=buh11) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKTwF-00081c-TW for syslog-archive@lists.ietf.org; Thu, 31 Jan 2008 02:34:25 -0500 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 4904 by uid 220); Thu, 31 Jan 2008 09:34:35 +0200 Message-Id: <20080131113435.4906.qmail@buh11> To: Subject: January 76% OFF From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b
From saki_ki@ocn.co.jp Thu Jan 31 22:40:52 2008 Return-Path: X-Original-To: ietfarch-syslog-archive@core3.amsl.com Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF32B3A6806 for ; Thu, 31 Jan 2008 22:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 90.105 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=90.105 tagged_above=-999 required=5 tests=[BAYES_99=3.5, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, GAPPY_SUBJECT=1.02, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HS_INDEX_PARAM=0.001, HTML_MESSAGE=1, MANGLED_LIST=2.3, MSOE_MID_WRONG_CASE=0.82, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_SUB_CASH_CHAR=0.747, SARE_SUB_ENC_ISO2022JP=0.413, SARE_SUB_OBFU_Q0=0.303, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, XMAILER_MIMEOLE_OL_EF20B=2.522] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.2 HELO_EQ_JP HELO_EQ_JP * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.2 HELO_EQ_NE_JP HELO_EQ_NE_JP * 1.0 GAPPY_SUBJECT Subject: contains G.a.p.p.y-T.e.x.t * 0.3 SARE_SUB_OBFU_Q0 FVGT - subject contains odd letter combination * 0.7 SARE_SUB_CASH_CHAR Subject has letter then $ then letter * 0.4 SARE_SUB_ENC_ISO2022JP Subject specifies display in non-English lang * 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers * 2.3 MANGLED_LIST BODY: mangled list * 0.0 HS_INDEX_PARAM URI: Link contains a common tracker pattern. * 1.0 HTML_MESSAGE BODY: HTML included in message * 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: pure-love.biz] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: pure-love.biz] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: pure-love.biz] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: pure-love.biz] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: pure-love.biz] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [58.253.176.169 listed in zen.spamhaus.org] * 2.5 XMAILER_MIMEOLE_OL_EF20B XMAILER_MIMEOLE_OL_EF20B * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.8 MSOE_MID_WRONG_CASE MSOE_MID_WRONG_CASE * 3.1 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvPFacL9Qbd9 for ; Thu, 31 Jan 2008 22:40:52 -0800 (PST) Received: from so-net.ne.jp (unknown [58.253.176.169]) by core3.amsl.com (Postfix) with ESMTP id 8C3DD3A67CF for ; Thu, 31 Jan 2008 22:40:45 -0800 (PST) Received: from OELgv (unknown [226.16.42.82]) by so-net.ne.jp (Coremail) with SMTP id fJfroylbTqKpmnuc.1 for ; Fri, 01 Feb 2008 15:42:27 +0800 (CST) X-Originating-IP: [226.16.42.82] Subject: ***SPAM*** 90.105 (5) =?iso-2022-jp?B?GyRCJDMkcyRKSlEkSk02JCRKfSRiJEokJCRIO1ckJCReJDkkMSRJGyhC?= From: "" To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C844A6.4C552ED0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20080201064045.8C3DD3A67CF@core3.amsl.com> Date: Thu, 31 Jan 2008 22:40:45 -0800 (PST) This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C844A6.4C552ED0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B$3$&$$$&%H%3%m$G$*M6$$$9$k$N$K!"$I$&$7$?$i$$$$$N$+$o$+$j$^$;$s!#(B $B;d$O%9%$!<%D%+%U%'$r7P1D$7$F$k$s$G$9$,!"85!9%Q%F%#%7%($+$i;O$a$?$b$N$G%3!<%R!<$NH~L#$7$5$,$h$/$o$+$j$^$;$s!#!J>P!K(B $B$*E9$O$9$4$/=gD4$G!"4r$7$$8B$j$J$s$G$9$,!"4N?4$N7P1Du67$G$O$$$1$J$$$H;W$$!"l=j$GC5$;$l$P$$$$$J$C$F;W$C$F$$$^$9!#(B $B$G$9$N$G!"H~L#$7$$%3!<%R!<$d!"%W%m$NGc$$IU$1$F$k%7%g%C%W$J$I$r65$($F$/$l$kJ}$O$$$^$;$s$+!)(B $B0l=o$K%9%$!<%D=d$j=PMh$k?M$,5o$J$$$G$9!&!&(B $B0l=o$K%1!<%-$r?)$Y$K9T$C$F2<$5$$!#(B $B$b$A$m$s!"FH?H$GNx?M$b$$$J$$$N$G!"$*Ck$@$1$8$c$J$/!"Lk$b%*%j%8%J%k%9%$!<%D$rMQ0U$7$FBT$C$F$^$9$h"v(B $BJDE98e$N$*E9$GM7$V$C$F$N$b0-$/$J$$$N$+$b$7$l$^$;$s$M(B($B!?(B($B%((B)$B!@(B)$B%-%c%C(B http://pure-love.biz/yu/?zh12 $B$N%9%$!<%D%3%_%e$N4IM}?M$G$9$N$G!J(B*$B!0(B-$B!0(B*$B!K(B $B$=$l$8$cBT$C$F$^$9$C!y(B http://pure-love.biz/yu/?zh12 $BG[?.ITMW(B ever_green_1313@yahoo.fr ------=_NextPart_000_0007_01C844A6.4C552ED0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$B$3$&$$$&%H%3%m$G$*M6$$$9$k$N$K!"$I$&$7$?$i$$$$$N$+$o$+$j$^$= ;$s!#=1B(B
=1B$B;d$O%9%$!<%D%+%U%'$r7P1D$7$F$k$s$G$9$,!"85!9%Q%F%#%7%(= $+$i;O$a$?$b$N$G%3!<%R!<$NH~L#$7$5$,$h$/$o$+$j$^$;$s!#!J>P!K=1B(B
=1B$= B$*E9$O$9$4$/=3DgD4$G!"4r$7$$8B$j$J$s$G$9$,!"4N?4$N7P1Du67$G$O= $$$1$J$$$H;W$$!"l=3Dj$GC5$;$l$P$$$$$J$C$F;W$C$F$$$^$9!#=1B= (B
 
=1B$B$G$9$N$G!"H~L#$7$$%3!<%R!<$d!"%W%m$NGc$$IU$1$F$k%7%g%C%W$J$= I$r65$($F$/$l$kJ}$O$$$^$;$s$+!)=1B(B
 
=1B$B0l=3Do$K%9%$!<%D=3Dd$j=3DPMh$k?M$,5o$J$$$G$9!&!&=1B(B
=1B= $B0l=3Do$K%1!<%-$r?)$Y$K9T$C$F2<$5$$!#=1B(B
 
=1B$B$b$A$m$s!"FH?H$GNx?M$b$$$J$$$N$G!"$*Ck$@$1$8$c$J$/!"Lk$b%*%= j%8%J%k%9%$!<%D$rMQ0U$7$FBT$C$F$^$9$h"v=1B(B
 
=1B$BJDE98e$N$*E9$GM7$V$C$F$N$b0-$/$J$$$N$+$b$7$l$^$;$s$M=1B(B(=1B= $B!?=1B(B(=1B$B%(=1B(B)=1B$B!@=1B(B)=1B$B%-%c%C=1B(B
 
http://pure-love.biz/yu/?zh12
=1B$B$N%9%$!<%D%3%_%= e$N4IM}?M$G$9$N$G!J=1B(B*=1B$B!0=1B(B-=1B$B!0=1B(B*=1B$B!K=1B(B
=1B$B$= =3D$l$8$cBT$C$F$^$9$C!y=1B(B
 
http://pure-love.biz/yu/?zh12<= /DIV>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
=1B$BG[?.ITMW=1B(B
ever_green_1313@yahoo.fr
 
------=_NextPart_000_0007_01C844A6.4C552ED0--