From syslog-bounces@lists.ietf.org Wed Jun 07 13:26:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1nK-0000Mm-Q6; Wed, 07 Jun 2006 13:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1nK-0000Mh-8H for syslog@ietf.org; Wed, 07 Jun 2006 13:26:14 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1nI-0005PD-W2 for syslog@ietf.org; Wed, 07 Jun 2006 13:26:14 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc11) with SMTP id <20060607172611m1100hfk6ke>; Wed, 7 Jun 2006 17:26:11 +0000 From: "David B Harrington" To: Date: Wed, 7 Jun 2006 13:25:10 -0400 Message-ID: <03f401c68a57$54cc2290$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaKVpw3ut0lVTfOR3azoOHvIy3K6A== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Syslog] Draft-ietf-syslog-transport-tls-01.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, As co-chair it is my responsibility to make the WG aware that there has been a disclosure that an unpublished pending patent application might be infringed by the implementation of the specifications in draft-ietf-syslog-transport-tls-01.txt. The disclosure can be found at https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=717. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 07 14:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2ef-0005gI-CX; Wed, 07 Jun 2006 14:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2ee-0005gD-4E for syslog@ietf.org; Wed, 07 Jun 2006 14:21:20 -0400 Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2ec-0004B8-KF for syslog@ietf.org; Wed, 07 Jun 2006 14:21:20 -0400 Subject: Re: [Syslog] Draft-ietf-syslog-transport-tls-01.txt From: Balazs Scheidler To: David B Harrington In-Reply-To: <03f401c68a57$54cc2290$0400a8c0@china.huawei.com> References: <03f401c68a57$54cc2290$0400a8c0@china.huawei.com> Content-Type: text/plain Date: Wed, 07 Jun 2006 20:21:13 +0200 Message-Id: <1149704473.1935.18.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Wed, 2006-06-07 at 13:25 -0400, David B Harrington wrote: > Hi, > > As co-chair it is my responsibility to make the WG aware that there > has been a disclosure that an unpublished pending patent application > might be infringed by the implementation of the specifications in > draft-ietf-syslog-transport-tls-01.txt. > > The disclosure can be found at > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=717. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG This is insane. I just tried google to search for syslog-ng and stunnel, I got 89000 result pages, the contents most probably describing how to combine syslog-ng and TLS, e.g. transfer syslog messages on a TLS encrypted channel I would call that prior art, although the details of the patent is to be seen, but I am not happy. I might even choose not to interoperate with the protocol specified here with syslog-ng. Puzzled. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 07 14:39:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2vv-000838-W2; Wed, 07 Jun 2006 14:39:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2vv-00082r-6M for syslog@ietf.org; Wed, 07 Jun 2006 14:39:11 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2vs-00075S-Nv for syslog@ietf.org; Wed, 07 Jun 2006 14:39:11 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 11:38:08 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="290803885:sNHT32287116" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k57Ic7I4013941; Wed, 7 Jun 2006 11:38:07 -0700 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 k57Ic2Iu023772; Wed, 7 Jun 2006 14:38:07 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 14:38:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Date: Wed, 7 Jun 2006 14:38:04 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731220184B746@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Thread-Index: AcaKXzORBYDD7YmUTdyGC7fm1hSppwAAD1kQ From: "Anton Okmianski \(aokmians\)" To: "Balazs Scheidler" , "David B Harrington" X-OriginalArrivalTime: 07 Jun 2006 18:38:05.0727 (UTC) FILETIME=[83F992F0:01C68A61] DKIM-Signature: a=rsa-sha1; q=dns; l=2592; t=1149705488; x=1150569488; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20Draft-ietf-syslog-transport-tls-01.txt; X=v=3Dcisco.com=3B=20h=3DDtgkaBSqSqujIGGM+CfMF8h4Bck=3D; b=G37EqD/RofOEMOKqTKCT0vEgh73vZyqFrXmerSysT7gv6cqntXd49/HlLZ1fNFRxH/kUQdpm mc3NVCUGTX4qMETD74t5UA4pwCSd7dODrbIoJAnLzpbcWUsg2VzpA0fJ; Authentication-Results: sj-dkim-1.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Agree! Syslog over TLS is ancient. Does the patent submission also need = to precede all discussions we had on this public list for years? Years = ago when we decided to split syslog protocol and syslog transport it was = to accommodate support of TLS transport in addition to UDP. =20 This could be a reason to drop TLS and go with SSH. But what would = prevent somebody from claiming a patent on this too regardless of prior = art of these discussions? Does the patent claim cover syslog over any = secure transport?=20 How do we know what the patent actually claims? Does IETF require = disclosure of patent specifics in these cases so that WG can asses the = exact nature of overlap and decide on steps forward? When was the patent = filed?=20 It feels a bit like an abuse to use the IETF WG to do/publicize the = work, then hold their work hostage with a patent threat. Especially on = something so truly trivial. I certainly don't want to waste time = standardizing something that could be covered by a patent.=20 Anton.=20 =20 > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20 > Sent: Wednesday, June 07, 2006 2:21 PM > To: David B Harrington > Cc: syslog@ietf.org > Subject: Re: [Syslog] Draft-ietf-syslog-transport-tls-01.txt >=20 > On Wed, 2006-06-07 at 13:25 -0400, David B Harrington wrote: > > Hi, > >=20 > > As co-chair it is my responsibility to make the WG aware that there > > has been a disclosure that an unpublished pending patent application > > might be infringed by the implementation of the specifications in > > draft-ietf-syslog-transport-tls-01.txt. > >=20 > > The disclosure can be found at > > = https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D717. > >=20 > > David Harrington > > dharrington@huawei.com=20 > > dbharrington@comcast.net > > ietfdbh@comcast.net > > co-chair, Syslog WG=20 >=20 > This is insane. I just tried google to search for syslog-ng=20 > and stunnel, > I got 89000 result pages, the contents most probably describing how to > combine syslog-ng and TLS, e.g. transfer syslog messages on a TLS > encrypted channel >=20 > I would call that prior art, although the details of the=20 > patent is to be > seen, but I am not happy. I might even choose not to interoperate with > the protocol specified here with syslog-ng. >=20 > Puzzled. >=20 > --=20 > Bazsi >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 07 15:06:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3MY-0000lI-Ah; Wed, 07 Jun 2006 15:06:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3MX-0000lD-Jl for syslog@ietf.org; Wed, 07 Jun 2006 15:06:41 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo3MW-0000gf-8I for syslog@ietf.org; Wed, 07 Jun 2006 15:06:41 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 12:06:39 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="1821359171:sNHT31509080" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k57J6d2Y024011; Wed, 7 Jun 2006 12:06:39 -0700 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 k57J6d9t002500; Wed, 7 Jun 2006 12:06:39 -0700 (PDT) Date: Wed, 7 Jun 2006 12:06:38 -0700 (PDT) From: Chris Lonvick To: Balazs Scheidler Subject: Re: [Syslog] Draft-ietf-syslog-transport-tls-01.txt In-Reply-To: <1149704473.1935.18.camel@bzorp.balabit> Message-ID: References: <03f401c68a57$54cc2290$0400a8c0@china.huawei.com> <1149704473.1935.18.camel@bzorp.balabit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=3368; t=1149707199; x=1150571199; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Re=3A=20[Syslog]=20Draft-ietf-syslog-transport-tls-01.txt; X=v=3Dcisco.com=3B=20h=3D7zSNtbZz98rcTSO5aXq/l2ZgEV0=3D; b=HN65xWyfFkmvN/KXvYq4OW64aUJpZ8zNj0kbRmzUctRTvCmQvxiroCYmUACQ7FZp2GzMRsCO iaW58ogWrnwsQ306HcFmhDU22FMF4w0CS4eEExoMycRbTiupmCAcy8x3; Authentication-Results: sj-dkim-4.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: David B Harrington , 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, RFC3979 is our guide here: http://www.ietf.org/rfc/rfc3979.txt >From Section 2 of that document: === RFC 2026, Section 10 established three basic principles regarding the IETF dealing with claims of Intellectual Property Rights: (a) the IETF will make no determination about the validity of any particular IPR claim (b) the IETF following normal processes can decide to use technology for which IPR disclosures have been made if it decides that such a use is warranted (c) in order for the working group and the rest of the IETF to have the information needed to make an informed decision about the use of a particular technology, all those contributing to the working group's discussions must disclose the existence of any IPR the Contributor or other IETF participant believes Covers or may ultimately Cover the technology under discussion. This applies to both Contributors and other participants, and applies whether they contribute in person, via email or by other means. The requirement applies to all IPR of the participant, the participant's employer, sponsor, or others represented by the participants, that is reasonably and personally known to the participant. No patent search is required. === As I see it (IANAL), we can decide to use the IPR, or not. For us to proceed, we will need: 1) to hear what the claim is, and 2) to decide if the terms of use are acceptable. The latter is in the disclosure that David sent around. Section 6.4 of RFC 3979 give specifics about what must be disclosed. I'll ask Miao and Yuhzi to give us what specifics they can at this time - can you update the disclosure notice to include what section of draft-ietf-syslog-transport-tls-01.txt contains the claimed IPR according to RFC 3979 Section 6.4.1. While we're waiting for that, I'll ask for people to look over the licensing terms and provide feedback to the list about its acceptability. Thanks, Chris On Wed, 7 Jun 2006, Balazs Scheidler wrote: > On Wed, 2006-06-07 at 13:25 -0400, David B Harrington wrote: >> Hi, >> >> As co-chair it is my responsibility to make the WG aware that there >> has been a disclosure that an unpublished pending patent application >> might be infringed by the implementation of the specifications in >> draft-ietf-syslog-transport-tls-01.txt. >> >> The disclosure can be found at >> https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=717. >> >> David Harrington >> dharrington@huawei.com >> dbharrington@comcast.net >> ietfdbh@comcast.net >> co-chair, Syslog WG > > This is insane. I just tried google to search for syslog-ng and stunnel, > I got 89000 result pages, the contents most probably describing how to > combine syslog-ng and TLS, e.g. transfer syslog messages on a TLS > encrypted channel > > I would call that prior art, although the details of the patent is to be > seen, but I am not happy. I might even choose not to interoperate with > the protocol specified here with syslog-ng. > > Puzzled. > > -- > Bazsi > > > _______________________________________________ > 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 Jun 07 15:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3UI-0001uN-E7; Wed, 07 Jun 2006 15:14:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3UI-0001uI-0d for syslog@ietf.org; Wed, 07 Jun 2006 15:14:42 -0400 Received: from [216.148.227.155] (helo=rwcrmhc15.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo3UG-0001UT-NP for syslog@ietf.org; Wed, 07 Jun 2006 15:14:41 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc15) with SMTP id <20060607191439m15000pejme>; Wed, 7 Jun 2006 19:14:39 +0000 From: "David Harrington" To: Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Date: Wed, 7 Jun 2006 15:13:38 -0400 Message-ID: <03fa01c68a66$7bcb0dc0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <03f401c68a57$54cc2290$0400a8c0@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaKVpw3ut0lVTfOR3azoOHvIy3K6AADWLTQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Three things: 1) Whether the patent would survive a check into prior art is not something the IETF takes a position on: Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 2) The company has filed a disclosure. You should read the disclosure before losing your cool. The disclosure says (roughly) it will license the technology royalty-free for standards use. The disclosure can be found at https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=717. 3) Since I work for the company filing the disclosure, I will recuse myself from chairing this discussion. I have asked Chris to chair the discussion. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 07 15:50:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo42U-00025d-LR; Wed, 07 Jun 2006 15:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo42U-00025I-6H; Wed, 07 Jun 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo42T-0007Xb-Sa; Wed, 07 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k57Jo1WR007956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fo42T-0002is-KS; Wed, 07 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-02.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : TLS Transport Mapping for SYSLOG Author(s) : F. Miao, M. Yuzhi Filename : draft-ietf-syslog-transport-tls-02.txt Pages : 11 Date : 2006-6-7 This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of Syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-transport-tls-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-transport-tls-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-7114420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-tls-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-tls-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-7114420.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 Wed Jun 07 17:26:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5XU-0005i5-SI; Wed, 07 Jun 2006 17:26:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5XS-0005hz-Vc for syslog@ietf.org; Wed, 07 Jun 2006 17:26:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo5XQ-00057h-Ql for syslog@ietf.org; Wed, 07 Jun 2006 17:26:06 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 14:26:04 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="290945516:sNHT40308548" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k57LQ44X012773; Wed, 7 Jun 2006 14:26:04 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k57LQ3cN025014; Wed, 7 Jun 2006 14:26:03 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 17:26:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Date: Wed, 7 Jun 2006 17:26:01 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731220184B84F@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Thread-Index: AcaKVpw3ut0lVTfOR3azoOHvIy3K6AADWLTQAASK59A= From: "Anton Okmianski \(aokmians\)" To: "David Harrington" , X-OriginalArrivalTime: 07 Jun 2006 21:26:03.0197 (UTC) FILETIME=[FA9D76D0:01C68A78] DKIM-Signature: a=rsa-sha1; q=dns; l=3247; t=1149715564; x=1150579564; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20Draft-ietf-syslog-transport-tls-01.txt; X=v=3Dcisco.com=3B=20h=3Dl1DoCOJFg5xmbOtV8CPT5B5GiPA=3D; b=QxA/LC0TPl1JEkD6Z8nphG6ATENAgWyd191t4b9qXURuHk377RG4sShv3cal6qZj6o0B7egU 9qnh1FHXLdVNZymVBDGIPvl7VWspFuKt2slhncl8+Qj2tsncdGdeTRRp; Authentication-Results: sj-dkim-7.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Royalty-free does not generally mean free! It means you don't charge = per-end-user, per-server fee. But it does not mean there is not fee. = Plus, license terms suggest "other reasonable, non-discriminations = terms" and refer to reciprocal license needed to implement standards. = Notice plural.=20 I know the giants like Cisco and Huawei will find a common ground as = they can sue each other silly with their patent portfolios. My concern = is more from the perspective of having an open standard for everybody to = use. I think some companies will be reluctant to use it given a law = suit threat or the hustle of extra licensing. =20 I think clarification on what is claimed are in order before investing = more effort into this.=20 Anton. =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Wednesday, June 07, 2006 3:14 PM > To: syslog@ietf.org > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt >=20 > Hi, >=20 > Three things: >=20 > 1) Whether the patent would survive a check into prior art is not > something the IETF takes a position on: >=20 > Intellectual Property >=20 > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed > to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. >=20 > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use > of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository > at > http://www.ietf.org/ipr. >=20 > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. >=20 > 2) The company has filed a disclosure. You should read the disclosure > before losing your cool.=20 > The disclosure says (roughly) it will license the technology > royalty-free for standards use. >=20 > The disclosure can be found at > = https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D717. >=20 > 3) Since I work for the company filing the disclosure, I will recuse > myself from chairing this discussion. I have asked Chris to chair the > discussion. >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 08 04:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoG78-0005z9-8U; Thu, 08 Jun 2006 04:43:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoG6m-0005Sf-I4 for syslog@ietf.org; Thu, 08 Jun 2006 04:43:16 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFut-0002NF-2w for syslog@ietf.org; Thu, 08 Jun 2006 04:31:00 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id ED44E27C065 for ; Thu, 8 Jun 2006 10:28:11 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30869-10 for ; Thu, 8 Jun 2006 10:28:11 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id AE6AE27C061 for ; Thu, 8 Jun 2006 10:28:11 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 10:30:52 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 Jun 2006 10:30:59 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174881@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: syslog-protocol thread-index: AcaK1d50TsTy86lXTNSjY3LpnX7bbw== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 08 Jun 2006 08:30:52.0719 (UTC) FILETIME=[DA9F7BF0:01C68AD5] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Syslog] syslog-protocol X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi all, Chris helped me brush up the ID, which I really appreciate. I am about to publish a new version soon. There is one thing that Chris recommended: --- I'd like to suggest that Section 6.2.1.1 (Relation to Alarm=20 MIB) be dropped from this document. We discussed the request for this=20 relationship between the ITU labels and syslog severities long before you=20 introduced the concept of structured data. Right now, I would suggest=20 that Sharon write a very short document to explicitly define the ITU Alarm=20 MIB severities as an SDID and Params. This would entirely eliminate the confusion between syslog Notice and ITU Indeterminate and Cleared. What do you think? ---- I like this suggestion. Is there anyone opposed to it? If I do not hear anything against it, I will remove that section with the next update. Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 08 04:57:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoGKw-0006Cq-L6; Thu, 08 Jun 2006 04:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoGKv-0006Cg-3X for syslog@ietf.org; Thu, 08 Jun 2006 04:57:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFQu-0008Cz-4t for syslog@ietf.org; Thu, 08 Jun 2006 04:00:00 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoF6e-0000X0-PC for syslog@ietf.org; Thu, 08 Jun 2006 03:39:07 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 1CFF527C065; Thu, 8 Jun 2006 09:36:21 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30869-04; Thu, 8 Jun 2006 09:36:21 +0200 (CEST) Received: from fmint2.intern.adiscon.com (unknown [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id B4CAA27C061; Thu, 8 Jun 2006 09:36:20 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 09:38:55 +0200 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] Draft-ietf-syslog-transport-tls-01.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 Jun 2006 09:38:59 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17487E@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Draft-ietf-syslog-transport-tls-01.txt thread-index: AcaKVpw3ut0lVTfOR3azoOHvIy3K6AADWLTQAASK59AAFdhIQA== From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , X-OriginalArrivalTime: 08 Jun 2006 07:38:55.0996 (UTC) FILETIME=[98E94BC0:01C68ACE] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi all, I agree with Anton on all important issues. I've read the IPR claim and what disturbs me the most is "unpublished pending patent application". This sounds like someone took what we have been discussing (and is widely deployed), brought it to a lawyer and is now trying to make some patent out of it. This smells very bad. Without knowing what exactly is claimed to be invented by the claimer, I can not judge the effect it will have on my work. Anyhow, I do not intend to invest any of my time into something that somebody else claims exclusive rights too. If I did, I'd end up with the need to "pay" (money-wise or other) for the right to use my own work. Would I be smart if I did that? ;)=20 The licensing terms themselves sound fair (but are vague enough to do so...). My root concern is that there is nothing that has been invented by that party. I am still waiting for someone to patent the use of the letter "a" ("@" has been tried AFIK)... I think using a patented technology inside a standard will definitely hinder the acceptance of that standard. Especially if it is something as trivial as syslog over tls. So my vote is to put this work on hold until further clarification can be obtained. If that means we'll have no syslog RFC, so be it. That would probably be the better choice... Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Wednesday, June 07, 2006 11:26 PM > To: David Harrington; syslog@ietf.org > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt >=20 > Royalty-free does not generally mean free! It means you don't=20 > charge per-end-user, per-server fee. But it does not mean=20 > there is not fee. Plus, license terms suggest "other=20 > reasonable, non-discriminations terms" and refer to=20 > reciprocal license needed to implement standards. Notice plural.=20 >=20 > I know the giants like Cisco and Huawei will find a common=20 > ground as they can sue each other silly with their patent=20 > portfolios. My concern is more from the perspective of=20 > having an open standard for everybody to use. I think some=20 > companies will be reluctant to use it given a law suit threat=20 > or the hustle of extra licensing. =20 >=20 > I think clarification on what is claimed are in order before=20 > investing more effort into this.=20 >=20 > Anton. =20 >=20 > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > > Sent: Wednesday, June 07, 2006 3:14 PM > > To: syslog@ietf.org > > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt > >=20 > > Hi, > >=20 > > Three things: > >=20 > > 1) Whether the patent would survive a check into prior art is not > > something the IETF takes a position on: > >=20 > > Intellectual Property > >=20 > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights or other rights that might=20 > be claimed > > to > > pertain to the implementation or use of the technology=20 > described in > > this document or the extent to which any license under=20 > such rights > > might or might not be available; nor does it represent=20 > that it has > > made any independent effort to identify any such rights. > > Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > >=20 > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission=20 > for the use > > of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR=20 > repository > > at > > http://www.ietf.org/ipr. > >=20 > > The IETF invites any interested party to bring to its=20 > attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required to=20 > implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > >=20 > > 2) The company has filed a disclosure. You should read the=20 > disclosure > > before losing your cool.=20 > > The disclosure says (roughly) it will license the technology > > royalty-free for standards use. > >=20 > > The disclosure can be found at > > =20 > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D717. > >=20 > > 3) Since I work for the company filing the disclosure, I will recuse > > myself from chairing this discussion. I have asked Chris to=20 > chair the > > discussion. > >=20 > > David Harrington > > dharrington@huawei.com=20 > > dbharrington@comcast.net > > ietfdbh@comcast.net > > co-chair, Syslog WG=20 > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 08 08:38:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoJmi-0002vb-W0; Thu, 08 Jun 2006 08:38:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoJmi-0002vW-89 for syslog@ietf.org; Thu, 08 Jun 2006 08:38:48 -0400 Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoJmf-0007uK-Mz for syslog@ietf.org; Thu, 08 Jun 2006 08:38:48 -0400 Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA17487E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA17487E@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Thu, 08 Jun 2006 14:38:43 +0200 Message-Id: <1149770323.10609.16.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote: > Hi all, > > I agree with Anton on all important issues. I've read the IPR claim and > what disturbs me the most is "unpublished pending patent application". > This sounds like someone took what we have been discussing (and is > widely deployed), brought it to a lawyer and is now trying to make some > patent out of it. This smells very bad. > > Without knowing what exactly is claimed to be invented by the claimer, I > can not judge the effect it will have on my work. Anyhow, I do not > intend to invest any of my time into something that somebody else claims > exclusive rights too. If I did, I'd end up with the need to "pay" > (money-wise or other) for the right to use my own work. Would I be smart > if I did that? ;) > > The licensing terms themselves sound fair (but are vague enough to do > so...). My root concern is that there is nothing that has been invented > by that party. I am still waiting for someone to patent the use of the > letter "a" ("@" has been tried AFIK)... > > I think using a patented technology inside a standard will definitely > hinder the acceptance of that standard. Especially if it is something as > trivial as syslog over tls. So my vote is to put this work on hold until > further clarification can be obtained. If that means we'll have no > syslog RFC, so be it. That would probably be the better choice... My feelings are about the same. I don't really know the US patent system specifics, how long does it take to have something concrete about the patent? -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 08 10:19:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLM0-0003F1-Tz; Thu, 08 Jun 2006 10:19:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLLz-0003Ea-Py for syslog@ietf.org; Thu, 08 Jun 2006 10:19:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoLLz-0008Qz-OX for syslog@ietf.org; Thu, 08 Jun 2006 10:19:19 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoLLa-0008TN-IN for syslog@ietf.org; Thu, 08 Jun 2006 10:18:55 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2006 07:18:54 -0700 X-IronPort-AV: i="4.05,220,1146466800"; d="scan'208"; a="430236387:sNHT32539256" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k58EIrUj014708; Thu, 8 Jun 2006 07:18:53 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k58EIqkw011096; Thu, 8 Jun 2006 10:18:52 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 10:18:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Date: Thu, 8 Jun 2006 10:18:50 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122018A3B12@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Thread-Index: AcaK+IRa7gxSfKdMR0eTJ21gRnE38AADatuQ From: "Anton Okmianski \(aokmians\)" To: "Balazs Scheidler" , "Rainer Gerhards" X-OriginalArrivalTime: 08 Jun 2006 14:18:52.0225 (UTC) FILETIME=[77C74310:01C68B06] DKIM-Signature: a=rsa-sha1; q=dns; l=2299; t=1149776333; x=1150640333; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20Draft-ietf-syslog-transport-tls-01.txt; X=v=3Dcisco.com=3B=20h=3Dl1DoCOJFg5xmbOtV8CPT5B5GiPA=3D; b=TBmhZ132QD9ONWz+A1smixrVQiqR5Am3kD900Esc23MT/Loulgvf/PqXjUY5JxmT8woVyDdE bWVHuRuRF51RSi64xcNPbMEh/mLXulZiZ4mEKhxStzVRp07CG0od6QAR; Authentication-Results: sj-dkim-3.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I don't agree with putting all work on hold. Syslog-protocol and = syslog-transport-udp still make sense to standardize. And we could = explore syslog-transport-ssh, possibly soliciting input from IPR holders = first. =20 Thanks, Anton.=20 > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20 > Sent: Thursday, June 08, 2006 8:39 AM > To: Rainer Gerhards > Cc: Anton Okmianski (aokmians); syslog@ietf.org > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt >=20 > On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote: > > Hi all, > >=20 > > I agree with Anton on all important issues. I've read the=20 > IPR claim and > > what disturbs me the most is "unpublished pending patent=20 > application". > > This sounds like someone took what we have been discussing (and is > > widely deployed), brought it to a lawyer and is now trying=20 > to make some > > patent out of it. This smells very bad. > >=20 > > Without knowing what exactly is claimed to be invented by=20 > the claimer, I > > can not judge the effect it will have on my work. Anyhow, I do not > > intend to invest any of my time into something that=20 > somebody else claims > > exclusive rights too. If I did, I'd end up with the need to "pay" > > (money-wise or other) for the right to use my own work.=20 > Would I be smart > > if I did that? ;)=20 > >=20 > > The licensing terms themselves sound fair (but are vague=20 > enough to do > > so...). My root concern is that there is nothing that has=20 > been invented > > by that party. I am still waiting for someone to patent the=20 > use of the > > letter "a" ("@" has been tried AFIK)... > >=20 > > I think using a patented technology inside a standard will=20 > definitely > > hinder the acceptance of that standard. Especially if it is=20 > something as > > trivial as syslog over tls. So my vote is to put this work=20 > on hold until > > further clarification can be obtained. If that means we'll have no > > syslog RFC, so be it. That would probably be the better choice... >=20 > My feelings are about the same. I don't really know the US=20 > patent system > specifics, how long does it take to have something concrete about the > patent? >=20 > --=20 > Bazsi >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 08 10:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLhg-0006ub-Mi; Thu, 08 Jun 2006 10:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLhf-0006uT-Cx for syslog@ietf.org; Thu, 08 Jun 2006 10:41:43 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoLhd-0002JV-VW for syslog@ietf.org; Thu, 08 Jun 2006 10:41:43 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 07:41:41 -0700 X-IronPort-AV: i="4.05,220,1146466800"; d="scan'208"; a="1822058000:sNHT83767276" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k58EfeCg009027; Thu, 8 Jun 2006 07:41:41 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k58EfeIs021053; Thu, 8 Jun 2006 10:41:40 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 10:41:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Date: Thu, 8 Jun 2006 10:41:39 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122018A3B3B@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Thread-Index: AcaK+IRa7gxSfKdMR0eTJ21gRnE38AADatuQAACQJpAAADnhgA== From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , "Balazs Scheidler" X-OriginalArrivalTime: 08 Jun 2006 14:41:40.0266 (UTC) FILETIME=[A731C0A0:01C68B09] DKIM-Signature: a=rsa-sha1; q=dns; l=4129; t=1149777701; x=1150641701; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20Draft-ietf-syslog-transport-tls-01.txt; X=v=3Dcisco.com=3B=20h=3Dl1DoCOJFg5xmbOtV8CPT5B5GiPA=3D; b=OtmtAYdxt645OTUmsQpa1iz3VuoYrW7eQru8YrH698XWYVxJx+1iVgN9dy5gYLoicCAqbGKw Rzj8iIxMNzhzdmck6DlJIcYf/WPf6pNEls69oExxut0svhZlKAy4p9Ye; Authentication-Results: sj-dkim-2.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Is the expectation that all 3 (protocol, transport-udp and = transport-secure) MUST be delivered together or none at all? Can't we do = the first two first while accommodating pluggable transports as we did? = Then, figure out the secure one. By that time the claims of the pending = unpublished patent may be known.=20 Thanks, Anton.=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Thursday, June 08, 2006 10:36 AM > To: Anton Okmianski (aokmians); Balazs Scheidler > Cc: syslog@ietf.org > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt >=20 > Anton, >=20 > I see your point. But remember that the IESG forced us to provide a > secure transport, which IMHO will be the most-violated part of > syslog-protocol once it is a RFC (meaning that -prototocol and > -transport-udp will be implemented but not -tls). SSH still=20 > seems to be > not a good option in my point of view. I guess we are stuck...=20 >=20 > Given my assumption on the expected seldom implementation of -tls, we > could of course go ahead and put this through with as few effort as > possible, just to fulfil the formal requirement of the IESG... >=20 > Rainer >=20 > > -----Original Message----- > > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > > Sent: Thursday, June 08, 2006 4:19 PM > > To: Balazs Scheidler; Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt > >=20 > > I don't agree with putting all work on hold. Syslog-protocol=20 > > and syslog-transport-udp still make sense to standardize. And=20 > > we could explore syslog-transport-ssh, possibly soliciting=20 > > input from IPR holders first. =20 > >=20 > > Thanks, > > Anton.=20 > >=20 > > > -----Original Message----- > > > From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20 > > > Sent: Thursday, June 08, 2006 8:39 AM > > > To: Rainer Gerhards > > > Cc: Anton Okmianski (aokmians); syslog@ietf.org > > > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt > > >=20 > > > On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote: > > > > Hi all, > > > >=20 > > > > I agree with Anton on all important issues. I've read the=20 > > > IPR claim and > > > > what disturbs me the most is "unpublished pending patent=20 > > > application". > > > > This sounds like someone took what we have been=20 > discussing (and is > > > > widely deployed), brought it to a lawyer and is now trying=20 > > > to make some > > > > patent out of it. This smells very bad. > > > >=20 > > > > Without knowing what exactly is claimed to be invented by=20 > > > the claimer, I > > > > can not judge the effect it will have on my work.=20 > Anyhow, I do not > > > > intend to invest any of my time into something that=20 > > > somebody else claims > > > > exclusive rights too. If I did, I'd end up with the=20 > need to "pay" > > > > (money-wise or other) for the right to use my own work.=20 > > > Would I be smart > > > > if I did that? ;)=20 > > > >=20 > > > > The licensing terms themselves sound fair (but are vague=20 > > > enough to do > > > > so...). My root concern is that there is nothing that has=20 > > > been invented > > > > by that party. I am still waiting for someone to patent the=20 > > > use of the > > > > letter "a" ("@" has been tried AFIK)... > > > >=20 > > > > I think using a patented technology inside a standard will=20 > > > definitely > > > > hinder the acceptance of that standard. Especially if it is=20 > > > something as > > > > trivial as syslog over tls. So my vote is to put this work=20 > > > on hold until > > > > further clarification can be obtained. If that means=20 > we'll have no > > > > syslog RFC, so be it. That would probably be the better=20 > choice... > > >=20 > > > My feelings are about the same. I don't really know the US=20 > > > patent system > > > specifics, how long does it take to have something concrete=20 > > about the > > > patent? > > >=20 > > > --=20 > > > Bazsi > > >=20 > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 08 10:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLky-0008Qm-JF; Thu, 08 Jun 2006 10:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLkx-0008QY-Ss for syslog@ietf.org; Thu, 08 Jun 2006 10:45:07 -0400 Received: from [216.148.227.155] (helo=rwcrmhc15.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoLkw-0002P1-Iq for syslog@ietf.org; Thu, 08 Jun 2006 10:45:07 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc15) with SMTP id <20060608144504m1500k6sqde>; Thu, 8 Jun 2006 14:45:05 +0000 From: "David Harrington" To: "'Balazs Scheidler'" , "'Rainer Gerhards'" Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Date: Thu, 8 Jun 2006 10:44:03 -0400 Message-ID: <051401c68b09$fd3f7a00$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <1149770323.10609.16.camel@bzorp.balabit> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaK+ICOg6FutoltSiqtTXMPy4v2UgAEEmZg X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I am staying out of the debate, but I can answer Balzs's question based on my experiences. In the US patent system, it takes on the order of three to five years for a patent to be granted. I believe the applicant is permitted to not disclose the claims for eighteen months. But I am not a lawyer, so your mileage may vary. dbh > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu] > Sent: Thursday, June 08, 2006 8:39 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt > > On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote: > > Hi all, > > > > I agree with Anton on all important issues. I've read the > IPR claim and > > what disturbs me the most is "unpublished pending patent > application". > > This sounds like someone took what we have been discussing (and is > > widely deployed), brought it to a lawyer and is now trying > to make some > > patent out of it. This smells very bad. > > > > Without knowing what exactly is claimed to be invented by > the claimer, I > > can not judge the effect it will have on my work. Anyhow, I do not > > intend to invest any of my time into something that > somebody else claims > > exclusive rights too. If I did, I'd end up with the need to "pay" > > (money-wise or other) for the right to use my own work. > Would I be smart > > if I did that? ;) > > > > The licensing terms themselves sound fair (but are vague > enough to do > > so...). My root concern is that there is nothing that has > been invented > > by that party. I am still waiting for someone to patent the > use of the > > letter "a" ("@" has been tried AFIK)... > > > > I think using a patented technology inside a standard will > definitely > > hinder the acceptance of that standard. Especially if it is > something as > > trivial as syslog over tls. So my vote is to put this work > on hold until > > further clarification can be obtained. If that means we'll have no > > syslog RFC, so be it. That would probably be the better choice... > > My feelings are about the same. I don't really know the US > patent system > specifics, how long does it take to have something concrete about the > patent? > > -- > Bazsi > > > _______________________________________________ > 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 Jun 08 10:55:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLv1-0007hf-9j; Thu, 08 Jun 2006 10:55:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLv0-0007hL-7P for syslog@ietf.org; Thu, 08 Jun 2006 10:55:30 -0400 Received: from gmpea-pix-1.sun.com ([192.18.1.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoLuy-00048A-QG for syslog@ietf.org; Thu, 08 Jun 2006 10:55:30 -0400 Received: from d1-emea-06.sun.com ([192.18.2.116]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k58EtRD7008607 for ; Thu, 8 Jun 2006 15:55:28 +0100 (BST) Received: from conversion-daemon.d1-emea-06.sun.com by d1-emea-06.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0J00F01Q4YKC00@d1-emea-06.sun.com> (original mail from Darren.Moffat@Sun.COM) for syslog@ietf.org; Thu, 08 Jun 2006 15:55:27 +0100 (BST) Received: from [129.156.173.21] by d1-emea-06.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0J00G37QSDLX70@d1-emea-06.sun.com>; Thu, 08 Jun 2006 15:55:27 +0100 (BST) Date: Thu, 08 Jun 2006 15:55:25 +0100 From: Darren J Moffat Subject: Re: [Syslog] Draft-ietf-syslog-transport-tls-01.txt In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA17487E@grfint2.intern.adiscon.com> To: Rainer Gerhards Message-id: <44883A5D.5000701@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <577465F99B41C842AAFBE9ED71E70ABA17487E@grfint2.intern.adiscon.com> User-Agent: Mail/News 1.5.0.2 (X11/20060515) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I'd vote to go forward with publication to standard to bring this out into the open. This is probably one the sillies patents out and just shows how fundamentally flawed the system really is. -- Darren J Moffat _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 08 11:27:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMPT-0003ar-34; Thu, 08 Jun 2006 11:26:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMPS-0003al-Ne for syslog@ietf.org; Thu, 08 Jun 2006 11:26:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoMPR-0000IP-Df for syslog@ietf.org; Thu, 08 Jun 2006 11:26:58 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2006 08:26:56 -0700 X-IronPort-AV: i="4.05,220,1146466800"; d="scan'208"; a="291499653:sNHT30481988" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k58FQuaq018065; Thu, 8 Jun 2006 08:26:56 -0700 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 k58FQu9t021471; Thu, 8 Jun 2006 08:26:56 -0700 (PDT) Date: Thu, 8 Jun 2006 08:26:56 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org, hartmans-ietf@mit.edu Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt In-Reply-To: <1149770323.10609.16.camel@bzorp.balabit> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA17487E@grfint2.intern.adiscon.com> <1149770323.10609.16.camel@bzorp.balabit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=2658; t=1149780416; x=1150644416; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:RE=3A=20[Syslog]=20Draft-ietf-syslog-transport-tls-01.txt; X=v=3Dcisco.com=3B=20h=3DeXC/j40MJgi6QXb9w+k4UFLVECU=3D; b=ldqTRocZw7szswzaAXrjx0ul6UBF3aHGGKzZn08vAqm1m/nQkBBaQbdejCnhTsi/OkyDKTqT p0vZ4bAxnKutXDbOJK2bHEzQoeu2q6FRz9uG/k+xEQo/j3B8jtnSrZFu; Authentication-Results: sj-dkim-4.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, On Thu, 8 Jun 2006, Balazs Scheidler wrote: > On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote: >> I think using a patented technology inside a standard will definitely >> hinder the acceptance of that standard. Especially if it is something as >> trivial as syslog over tls. So my vote is to put this work on hold until >> further clarification can be obtained. If that means we'll have no >> syslog RFC, so be it. That would probably be the better choice... > > My feelings are about the same. I don't really know the US patent system > specifics, how long does it take to have something concrete about the > patent? [Minor note: I don't think that we can assume that it is being filed within the USPTO.] It appears to me (and I'm willing to take more input) that the general consensus is that an IPR-encumbered syslog/tls document would not gain acceptance within the development community. I would like to do 2 things at this time: 1) I will ask Huawei to update their IPR claim to cover draft-ietf-syslog-transport-tls-02.txt (the current disclosure only covers -01.txt) and, if possible, to give us a bit more of a clue as to what the IPR covers. Specifically from RFC 3979, Section 6.4.1: In addition, if the IETF Document includes multiple parts and it is not reasonably apparent which part of such IETF Document is alleged to be Covered by the IPR in question, it is helpful if the discloser identifies the sections of the IETF Document that are alleged to be so Covered. I believe that Hauwei does not need to fully disclose their IPR claim but a clue would be helpful. I think that the section above was written that way so that it could be possible to remove or modify a section so that the document would no longer be covered by a claim. I don't know that this is possible in this case but I'd like to explore that option. 2) I will ask our Advisor to give us some guidance on this. (Sam is cc'd.) We agreed to a tight timeline for our deliverables without considering that we would get hung up on this. A recommendation has been made on the WG list that we proceed with syslog-transport-udp and syslog-protocol while we see what becomes of the IPR claim of syslog-transport-tls. We CAN submit syslog-transport-tls in a timely fashion, as per our Charter, but I fear that it would not be accepted or deployed by the community until the IPR issue is resolved. Moving forward with the other two IDs would keep our momentum going and we could address the issue of the IPR as soon as we can. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 08 11:59:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMuh-00024E-3M; Thu, 08 Jun 2006 11:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMuf-000243-Pi for syslog@ietf.org; Thu, 08 Jun 2006 11:59:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoM5I-0005HB-Cj for syslog@ietf.org; Thu, 08 Jun 2006 11:06:08 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoLcA-0000kA-6i for syslog@ietf.org; Thu, 08 Jun 2006 10:36:05 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3988C27C065; Thu, 8 Jun 2006 16:33:18 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04624-07; Thu, 8 Jun 2006 16:33:18 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D711827C061; Thu, 8 Jun 2006 16:33:17 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 16:35:54 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jun 2006 16:35:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174889@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Draft-ietf-syslog-transport-tls-01.txt thread-index: AcaK+IRa7gxSfKdMR0eTJ21gRnE38AADatuQAACQJpA= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , "Balazs Scheidler" X-OriginalArrivalTime: 08 Jun 2006 14:35:54.0589 (UTC) FILETIME=[D927A0D0:01C68B08] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Anton, I see your point. But remember that the IESG forced us to provide a secure transport, which IMHO will be the most-violated part of syslog-protocol once it is a RFC (meaning that -prototocol and -transport-udp will be implemented but not -tls). SSH still seems to be not a good option in my point of view. I guess we are stuck...=20 Given my assumption on the expected seldom implementation of -tls, we could of course go ahead and put this through with as few effort as possible, just to fulfil the formal requirement of the IESG... Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Thursday, June 08, 2006 4:19 PM > To: Balazs Scheidler; Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt >=20 > I don't agree with putting all work on hold. Syslog-protocol=20 > and syslog-transport-udp still make sense to standardize. And=20 > we could explore syslog-transport-ssh, possibly soliciting=20 > input from IPR holders first. =20 >=20 > Thanks, > Anton.=20 >=20 > > -----Original Message----- > > From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20 > > Sent: Thursday, June 08, 2006 8:39 AM > > To: Rainer Gerhards > > Cc: Anton Okmianski (aokmians); syslog@ietf.org > > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt > >=20 > > On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote: > > > Hi all, > > >=20 > > > I agree with Anton on all important issues. I've read the=20 > > IPR claim and > > > what disturbs me the most is "unpublished pending patent=20 > > application". > > > This sounds like someone took what we have been discussing (and is > > > widely deployed), brought it to a lawyer and is now trying=20 > > to make some > > > patent out of it. This smells very bad. > > >=20 > > > Without knowing what exactly is claimed to be invented by=20 > > the claimer, I > > > can not judge the effect it will have on my work. Anyhow, I do not > > > intend to invest any of my time into something that=20 > > somebody else claims > > > exclusive rights too. If I did, I'd end up with the need to "pay" > > > (money-wise or other) for the right to use my own work.=20 > > Would I be smart > > > if I did that? ;)=20 > > >=20 > > > The licensing terms themselves sound fair (but are vague=20 > > enough to do > > > so...). My root concern is that there is nothing that has=20 > > been invented > > > by that party. I am still waiting for someone to patent the=20 > > use of the > > > letter "a" ("@" has been tried AFIK)... > > >=20 > > > I think using a patented technology inside a standard will=20 > > definitely > > > hinder the acceptance of that standard. Especially if it is=20 > > something as > > > trivial as syslog over tls. So my vote is to put this work=20 > > on hold until > > > further clarification can be obtained. If that means we'll have no > > > syslog RFC, so be it. That would probably be the better choice... > >=20 > > My feelings are about the same. I don't really know the US=20 > > patent system > > specifics, how long does it take to have something concrete=20 > about the > > patent? > >=20 > > --=20 > > Bazsi > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 08 12:47:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNez-0002js-Rw; Thu, 08 Jun 2006 12:47:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNey-0002jn-Bn for syslog@ietf.org; Thu, 08 Jun 2006 12:47:04 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoNex-0005WK-5s for syslog@ietf.org; Thu, 08 Jun 2006 12:47:04 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C6202E001B; Thu, 8 Jun 2006 12:46:55 -0400 (EDT) To: Chris Lonvick Subject: Re: [Syslog] Draft-ietf-syslog-transport-tls-01.txt References: <577465F99B41C842AAFBE9ED71E70ABA17487E@grfint2.intern.adiscon.com> <1149770323.10609.16.camel@bzorp.balabit> From: Sam Hartman Date: Thu, 08 Jun 2006 12:46:55 -0400 In-Reply-To: (Chris Lonvick's message of "Thu, 8 Jun 2006 08:26:56 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 First, have you looked at the updated IPR disclosure? You can work on udp and -protocol, and you can even update your milestones to reflect that. You can get as far as sending me a publication request for these documents. However I will not take the documents to the IESG without a security solution. So, I'll wait until it seems clear that there will be WG consensus to actually publish the TLS draft (or something else of your choosing) before I bring -protocol to the IESG. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 08 12:54:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNlm-0003fQ-J6; Thu, 08 Jun 2006 12:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNlk-0003fJ-OA for syslog@ietf.org; Thu, 08 Jun 2006 12:54:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoMxV-0006NY-Pq for syslog@ietf.org; Thu, 08 Jun 2006 12:02:09 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoMpK-0002DA-Ph for syslog@ietf.org; Thu, 08 Jun 2006 11:53:47 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id BB51C27C06B; Thu, 8 Jun 2006 17:50:53 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06263-09; Thu, 8 Jun 2006 17:50:53 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 6C43027C061; Thu, 8 Jun 2006 17:50:53 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 17:53:36 +0200 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] Draft-ietf-syslog-transport-tls-01.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 Jun 2006 17:53:33 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17488D@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Draft-ietf-syslog-transport-tls-01.txt thread-index: AcaLEAZ/h0P16EFgRRWjC1GcCZu4lgAA5ooQ From: "Rainer Gerhards" To: "Chris Lonvick" , X-OriginalArrivalTime: 08 Jun 2006 15:53:36.0239 (UTC) FILETIME=[B3B6F7F0:01C68B13] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 FWIW: I agree with Chris proposal and intended course of action. Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Thursday, June 08, 2006 5:27 PM > To: syslog@ietf.org; hartmans-ietf@mit.edu > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt >=20 > Hi, >=20 > On Thu, 8 Jun 2006, Balazs Scheidler wrote: > > On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote: >=20 > > >> I think using a patented technology inside a standard will=20 > definitely > >> hinder the acceptance of that standard. Especially if it=20 > is something as > >> trivial as syslog over tls. So my vote is to put this work=20 > on hold until > >> further clarification can be obtained. If that means we'll have no > >> syslog RFC, so be it. That would probably be the better choice... > > >=20 > > > My feelings are about the same. I don't really know the US=20 > patent system > > specifics, how long does it take to have something concrete=20 > about the > > patent? >=20 >=20 > [Minor note: I don't think that we can assume that it is being filed=20 > within the USPTO.] >=20 > It appears to me (and I'm willing to take more input) that=20 > the general=20 > consensus is that an IPR-encumbered syslog/tls document would=20 > not gain=20 > acceptance within the development community. >=20 > I would like to do 2 things at this time: >=20 > 1) I will ask Huawei to update their IPR claim to cover=20 > draft-ietf-syslog-transport-tls-02.txt (the current disclosure only=20 > covers -01.txt) and, if possible, to give us a bit more of a=20 > clue as to=20 > what the IPR covers. Specifically from RFC 3979, Section 6.4.1: > In addition, if the IETF Document includes multiple > parts and it is not reasonably apparent which part of such IETF > Document is alleged to be Covered by the IPR in question, it is > helpful if the discloser identifies the sections of the=20 > IETF Document > that are alleged to be so Covered. > I believe that Hauwei does not need to fully disclose their IPR claim=20 > but a clue would be helpful. I think that the section above=20 > was written=20 > that way so that it could be possible to remove or modify a=20 > section so=20 > that the document would no longer be covered by a claim. I=20 > don't know=20 > that this is possible in this case but I'd like to explore=20 > that option. >=20 > 2) I will ask our Advisor to give us some guidance on this. (Sam is=20 > cc'd.) We agreed to a tight timeline for our deliverables without=20 > considering that we would get hung up on this. A=20 > recommendation has been=20 > made on the WG list that we proceed with syslog-transport-udp and=20 > syslog-protocol while we see what becomes of the IPR claim of=20 > syslog-transport-tls. We CAN submit syslog-transport-tls in a timely=20 > fashion, as per our Charter, but I fear that it would not be=20 > accepted or=20 > deployed by the community until the IPR issue is resolved. =20 > Moving forward=20 > with the other two IDs would keep our momentum going and we=20 > could address=20 > the issue of the IPR as soon as we can. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 08 16:32:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRAz-0005pC-UQ; Thu, 08 Jun 2006 16:32:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRAy-0005oB-La for syslog@ietf.org; Thu, 08 Jun 2006 16:32:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoQvg-0005Qk-A9 for syslog@ietf.org; Thu, 08 Jun 2006 16:16:32 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoQls-0006Yg-GD for syslog@ietf.org; Thu, 08 Jun 2006 16:06:28 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 834D327C065; Thu, 8 Jun 2006 22:03:39 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10155-06; Thu, 8 Jun 2006 22:03:39 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 264BF27C061; Thu, 8 Jun 2006 22:03:39 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 22:06:16 +0200 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] Draft-ietf-syslog-transport-tls-01.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 Jun 2006 22:06:10 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174894@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Draft-ietf-syslog-transport-tls-01.txt thread-index: AcaLEAZ/h0P16EFgRRWjC1GcCZu4lgAJhxVw From: "Rainer Gerhards" To: "Chris Lonvick" , X-OriginalArrivalTime: 08 Jun 2006 20:06:16.0760 (UTC) FILETIME=[0016E380:01C68B37] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I have been told that Huawei patents date back no longer than 2001. This seems to confirm it: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO2&Sect2=3DHITOFF&p=3D= 2&u =3D%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=3D0&f=3DS&l=3D50&d=3DPG01&s1=3D= HUAWEI&Page =3DNext&OS=3DHUAWEI&RS=3DHUAWEI Also, David said "I believe the applicant is permitted to not disclose the claims for eighteen months.". Assuming this holds true, and speaking only of US patents, this seems to mean that the patent in question can not date back to later than 2004. In contrast, Google has a newsgroup post about syslog-ng and stunnel from 1999: http://groups.google.com/group/comp.security.unix/browse_thread/thread/d 125f044c5f8ba4a/6c87c15ddff26516?lnk=3Dst&q=3Dsyslog-ng+stunnel&rnum=3D11= 8#6c8 7c15ddff26516 I guess there are many more samples of prior art (e.g. during the formation of this WG, some texts I wrote myself in 2004, many more howtows pre-2000 and probably stunnel changelogs and installations). This all brings me to the conclusion that this is not only insane but mostly irrelavant. Of course, someone needs to object the patent if it is awarded (which unfortunately seems to be more than possible). The question is who will do that (and what it costs). But besides that, there should be no problem. What a rotten system the patent system has become... Back to on-topic: I think we can continue with -transport-tls, though I have to admit I am still hesitant to put too much effort into it myself. Probably those claiming rights should also do at least a little work on it ;) Rainer =20 > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Thursday, June 08, 2006 5:27 PM > To: syslog@ietf.org; hartmans-ietf@mit.edu > Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt >=20 > Hi, >=20 > On Thu, 8 Jun 2006, Balazs Scheidler wrote: > > On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote: >=20 > > >> I think using a patented technology inside a standard will=20 > definitely > >> hinder the acceptance of that standard. Especially if it=20 > is something as > >> trivial as syslog over tls. So my vote is to put this work=20 > on hold until > >> further clarification can be obtained. If that means we'll have no > >> syslog RFC, so be it. That would probably be the better choice... > > >=20 > > > My feelings are about the same. I don't really know the US=20 > patent system > > specifics, how long does it take to have something concrete=20 > about the > > patent? >=20 >=20 > [Minor note: I don't think that we can assume that it is being filed=20 > within the USPTO.] >=20 > It appears to me (and I'm willing to take more input) that=20 > the general=20 > consensus is that an IPR-encumbered syslog/tls document would=20 > not gain=20 > acceptance within the development community. >=20 > I would like to do 2 things at this time: >=20 > 1) I will ask Huawei to update their IPR claim to cover=20 > draft-ietf-syslog-transport-tls-02.txt (the current disclosure only=20 > covers -01.txt) and, if possible, to give us a bit more of a=20 > clue as to=20 > what the IPR covers. Specifically from RFC 3979, Section 6.4.1: > In addition, if the IETF Document includes multiple > parts and it is not reasonably apparent which part of such IETF > Document is alleged to be Covered by the IPR in question, it is > helpful if the discloser identifies the sections of the=20 > IETF Document > that are alleged to be so Covered. > I believe that Hauwei does not need to fully disclose their IPR claim=20 > but a clue would be helpful. I think that the section above=20 > was written=20 > that way so that it could be possible to remove or modify a=20 > section so=20 > that the document would no longer be covered by a claim. I=20 > don't know=20 > that this is possible in this case but I'd like to explore=20 > that option. >=20 > 2) I will ask our Advisor to give us some guidance on this. (Sam is=20 > cc'd.) We agreed to a tight timeline for our deliverables without=20 > considering that we would get hung up on this. A=20 > recommendation has been=20 > made on the WG list that we proceed with syslog-transport-udp and=20 > syslog-protocol while we see what becomes of the IPR claim of=20 > syslog-transport-tls. We CAN submit syslog-transport-tls in a timely=20 > fashion, as per our Charter, but I fear that it would not be=20 > accepted or=20 > deployed by the community until the IPR issue is resolved. =20 > Moving forward=20 > with the other two IDs would keep our momentum going and we=20 > could address=20 > the issue of the IPR as soon as we can. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 09 13:24:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foki9-00069V-Db; Fri, 09 Jun 2006 13:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foki7-00069Q-DU for syslog@ietf.org; Fri, 09 Jun 2006 13:23:51 -0400 Received: from dsl-202-45-110-141-static.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foki2-00021P-AS for syslog@ietf.org; Fri, 09 Jun 2006 13:23:51 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k59HNC0x023733; Sat, 10 Jun 2006 03:23:12 +1000 (EST) From: Darren Reed Message-Id: <200606091723.k59HN5Rf025554@firewall.reed.wattle.id.au> In-Reply-To: <03f401c68a57$54cc2290$0400a8c0@china.huawei.com> To: David B Harrington Date: Sat, 10 Jun 2006 03:23:05 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: syslog@ietf.org Subject: [Syslog] Call for David Harrington to resign from syslog as co-chair X-BeenThere: syslog@lists.ietf.org X-Mailman-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 someone who works fr the offending company, I might point out that the lodged IPR statement does not accurately reference the draft at all. It talks about "section IV" and "section V". The current draft has no "section IV" or "section V". The draft does have sections labelled "section 4" and "section 5". If you know anything of legal documents and messages then you will understand that they need to be accurate. Ask your lawyer for more information on this. Given your role as chair and that you are employed by the company involved, I would like to ask you to resign your role as co-chair here because I believe your commercial interests are compromising the direction and role of this group. If you do not wish to voluntarily resign I will ask the group to take a vote on this matter. As it stands, there are a number of people who do not like this move and I can imagine any number of them would feel betrayed by it. Darren > Hi, > > As co-chair it is my responsibility to make the WG aware that there > has been a disclosure that an unpublished pending patent application > might be infringed by the implementation of the specifications in > draft-ietf-syslog-transport-tls-01.txt. > > The disclosure can be found at > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=717. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 09 13:39:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokxC-0007cv-0y; Fri, 09 Jun 2006 13:39:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokxA-0007cq-Qc for syslog@ietf.org; Fri, 09 Jun 2006 13:39:24 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fokx6-00044r-ET for syslog@ietf.org; Fri, 09 Jun 2006 13:39:24 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 09 Jun 2006 10:39:20 -0700 X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="430423229:sNHT34565718" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k59HdJUf015753; Fri, 9 Jun 2006 10:39:19 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k59HdEkf014606; Fri, 9 Jun 2006 10:39:19 -0700 (PDT) Date: Fri, 9 Jun 2006 10:39:14 -0700 (PDT) From: Chris Lonvick To: Darren Reed Subject: Re: [Syslog] Call for David Harrington to resign from syslog as co-chair In-Reply-To: <200606091723.k59HN5Rf025554@firewall.reed.wattle.id.au> Message-ID: References: <200606091723.k59HN5Rf025554@firewall.reed.wattle.id.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=2349; t=1149874759; x=1150738759; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Re=3A=20[Syslog]=20Call=20for=20David=20Harrington=20to=20resign=20from= 20syslog=20as=0A=20co-chair; X=v=3Dcisco.com=3B=20h=3D+VavkFQ7AkYJSft+YNhkHqn4fIg=3D; b=P6jSawuUe9pLyi7f4FwTaJWz0Um6MYqmGiGgEmUgfPKGfT7LMoFrCnxBGEWwEobrdruw/LZt 7yzyAypsU0uITaqjtxf039Eo6Qv/TjnsGXjjpAEvYQK3HF+Go7yr756X; Authentication-Results: sj-dkim-2.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: David B Harrington , 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 Darren, David has recused himself from this discussion because of any possible conflict of interest. As you note, the claim statement does not accurately reflect the sections of the ID, but rather the sections of the claim statement itself. I am working on getting more information about the claim and then we can see what the Working Group wants to do. For now, I will ask for some patience from everyone while we sort this out. Thanks, Chris On Sat, 10 Jun 2006, Darren Reed wrote: > As someone who works fr the offending company, I might point > out that the lodged IPR statement does not accurately reference > the draft at all. It talks about "section IV" and "section V". > The current draft has no "section IV" or "section V". > The draft does have sections labelled "section 4" and "section 5". > If you know anything of legal documents and messages then you will > understand that they need to be accurate. Ask your lawyer for > more information on this. > > Given your role as chair and that you are employed by the > company involved, I would like to ask you to resign your > role as co-chair here because I believe your commercial > interests are compromising the direction and role of this > group. > > If you do not wish to voluntarily resign I will ask the > group to take a vote on this matter. As it stands, there > are a number of people who do not like this move and I > can imagine any number of them would feel betrayed by it. > > Darren > >> Hi, >> >> As co-chair it is my responsibility to make the WG aware that there >> has been a disclosure that an unpublished pending patent application >> might be infringed by the implementation of the specifications in >> draft-ietf-syslog-transport-tls-01.txt. >> >> The disclosure can be found at >> https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=717. >> >> David Harrington >> dharrington@huawei.com >> dbharrington@comcast.net >> ietfdbh@comcast.net >> co-chair, Syslog WG >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 09 13:41:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fokz5-0002mk-EO; Fri, 09 Jun 2006 13:41:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fokz3-0002mf-W3 for syslog@ietf.org; Fri, 09 Jun 2006 13:41:21 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fokz2-0004Bo-MD for syslog@ietf.org; Fri, 09 Jun 2006 13:41:21 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc12) with SMTP id <20060609174117m1200o1kohe>; Fri, 9 Jun 2006 17:41:18 +0000 From: "David B Harrington" To: "'Darren Reed'" Date: Fri, 9 Jun 2006 13:40:14 -0400 Message-ID: <064001c68beb$c4a52310$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200606091723.k59HN5Rf025554@firewall.reed.wattle.id.au> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaL6XMFC/jJioEtSb69qjQ3jAS/gQAAHdgA X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: syslog@ietf.org Subject: [Syslog] RE: Call for David Harrington to resign from syslog as co-chair X-BeenThere: syslog@lists.ietf.org X-Mailman-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 Darren, The disclosure document itself contains a section IV and a section V. Because I work for the company with the claim, I have recused myself from chairing the discussion, have stayed out of the discussion, and have asked Chris to lead the discussion. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au] > Sent: Friday, June 09, 2006 1:23 PM > To: David B Harrington > Cc: syslog@ietf.org > Subject: Call for David Harrington to resign from syslog as co-chair > > As someone who works fr the offending company, I might point > out that the lodged IPR statement does not accurately reference > the draft at all. It talks about "section IV" and "section V". > The current draft has no "section IV" or "section V". > The draft does have sections labelled "section 4" and "section 5". > If you know anything of legal documents and messages then you will > understand that they need to be accurate. Ask your lawyer for > more information on this. > > Given your role as chair and that you are employed by the > company involved, I would like to ask you to resign your > role as co-chair here because I believe your commercial > interests are compromising the direction and role of this > group. > > If you do not wish to voluntarily resign I will ask the > group to take a vote on this matter. As it stands, there > are a number of people who do not like this move and I > can imagine any number of them would feel betrayed by it. > > Darren > > > Hi, > > > > As co-chair it is my responsibility to make the WG aware that there > > has been a disclosure that an unpublished pending patent application > > might be infringed by the implementation of the specifications in > > draft-ietf-syslog-transport-tls-01.txt. > > > > The disclosure can be found at > > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=717. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > co-chair, Syslog WG > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 09 16:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FonOb-00027R-Jn; Fri, 09 Jun 2006 16:15:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FonOa-00027A-Q6 for syslog@ietf.org; Fri, 09 Jun 2006 16:15:52 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FonOZ-00007Z-8M for syslog@ietf.org; Fri, 09 Jun 2006 16:15:52 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id DD0E427C065; Fri, 9 Jun 2006 22:12:54 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02941-08; Fri, 9 Jun 2006 22:12:54 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 7FF2527C061; Fri, 9 Jun 2006 22:12:54 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 22:15:40 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Call for David Harrington to resign from syslog as co-chair MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jun 2006 22:15:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1748AE@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Call for David Harrington to resign from syslog as co-chair thread-index: AcaL6YXLeyDMUASkSO6XuMScFpM1xAAFSpVA From: "Rainer Gerhards" To: "Darren Reed" , "David B Harrington" X-OriginalArrivalTime: 09 Jun 2006 20:15:40.0547 (UTC) FILETIME=[7A8BB530:01C68C01] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 Darren, I think you have mis-read the IPR disclosure. The section numbers in = roman numbers refer to the IPR claim and not the I-D sections. I would also like to voice that I am very happy that David is co-charing = this group. The current discussion has shown how professional and = ethical his leadership of the WG is. There is nothing that would justify = to step back from this position. I also think that you are exaggerating the situation. While I do not = like the move by Huawei (and have voiced that), I also think there is = nothing evil per s=E9 in this move. IMHO Huawei is simply using an = abusive patent system. This is a difference to someone abusing a = non-abusive system. The primary thing to do is fight the abusive system = itself - as we in Europe try to avoid an US-like patent system over = here. As far as I know, even the US is reconsidering the current patent = system. I do not know about China, Australia and Japan, but my = uninformed impression is that it is as bad there as it is in the US. I = also think we shouldn't wonder that the Chineese do what we have told = them for years now: we have ever and ever told them that they must = respect the western way of IPR. Are they really to blame they are doing = it now? Has someone forgotten to think about the situation that they = themselves use it to their advantage? Believe me, a country of this size = and population has lots of (real) inventors... ;) Back to this case: I still see lack of an innovation. The thing also = smells bad if I look at the timing. Anyhow, the action to take is to = clarify the claim and see how to avoid it. Chris is handling this = perfectly. I think it was also important to voice that we are unhappy = with a patent claim. This has been done. David has done his chore of = notifying the WG - exactly as required by IETF policies. A thing left to = do (once we know details) is to make clear that the patent claim is = invalid and there are lots of prior art. As far as I know, you Darren, = had started the WG with syslog/ssl in mind. So you are probably in one = of the best position to proove this prior art. Please do that once the = details are clear. IMHO we should not be overreacting: if that IPR claim is the worst thing = that happens to the WG, we are very lucky. It's a weak one, even though = it is disturbing and eventually time-consuming. I think we've had bigger = problems and we were able to solve them. Having to deal with lawyers is = nothing that make a tech guy happy (at least not me...), but sometimes = this is unavoidable. Having said all this, please let me repeat that I prefer to have no = syslog RFC than to have one that is taken hostage by a nonsense patent = claim. Just to make sure I will not be misunderstood in this regard. But = it is no solution to run away as soon as somebody screams "IPR" into the = crowd... Rainer > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Friday, June 09, 2006 7:23 PM > To: David B Harrington > Cc: syslog@ietf.org > Subject: [Syslog] Call for David Harrington to resign from=20 > syslog as co-chair >=20 > As someone who works fr the offending company, I might point > out that the lodged IPR statement does not accurately reference > the draft at all. It talks about "section IV" and "section V". > The current draft has no "section IV" or "section V". > The draft does have sections labelled "section 4" and "section 5". > If you know anything of legal documents and messages then you will > understand that they need to be accurate. Ask your lawyer for > more information on this. >=20 > Given your role as chair and that you are employed by the > company involved, I would like to ask you to resign your > role as co-chair here because I believe your commercial > interests are compromising the direction and role of this > group. >=20 > If you do not wish to voluntarily resign I will ask the > group to take a vote on this matter. As it stands, there > are a number of people who do not like this move and I > can imagine any number of them would feel betrayed by it. >=20 > Darren >=20 > > Hi, > >=20 > > As co-chair it is my responsibility to make the WG aware that there > > has been a disclosure that an unpublished pending patent application > > might be infringed by the implementation of the specifications in > > draft-ietf-syslog-transport-tls-01.txt. > >=20 > > The disclosure can be found at > > = https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D717. > >=20 > > David Harrington > > dharrington@huawei.com=20 > > dbharrington@comcast.net > > ietfdbh@comcast.net > > co-chair, Syslog WG=20 > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 09 16:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fonxn-0001jO-TR; Fri, 09 Jun 2006 16:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fonxm-0001jJ-SE for syslog@ietf.org; Fri, 09 Jun 2006 16:52:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fonxl-0006LT-Iu for syslog@ietf.org; Fri, 09 Jun 2006 16:52:14 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 09 Jun 2006 13:52:13 -0700 X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="292470164:sNHT30239480" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k59KqCMD024742; Fri, 9 Jun 2006 13:52:13 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k59KqCkf003227; Fri, 9 Jun 2006 13:52:12 -0700 (PDT) Date: Fri, 9 Jun 2006 13:52:12 -0700 (PDT) From: Chris Lonvick To: Sam Hartman Subject: separate - Re: [Syslog] Draft-ietf-syslog-transport-tls-01.txt In-Reply-To: Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA17487E@grfint2.intern.adiscon.com> <1149770323.10609.16.camel@bzorp.balabit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1619; t=1149886333; x=1150750333; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:separate=20-=20Re=3A=20[Syslog]=20Draft-ietf-syslog-transport-tls-01.txt; X=v=3Dcisco.com=3B=20h=3DP6EQFSBsgD1RnRYSDcTDgAQCUfY=3D; b=HKt35WXy1BpjVuwO1uc2ud/IltwfUc7yKlgOEVRgyo2wDBN3FjYAx1OCo2tFvqZ9Pqbj8yex xdrWWtH4oOjbu8zMc99wxn/Mhycc1XeA5WJbsT4rnTFPucEtaNwc2Qc3; Authentication-Results: sj-dkim-1.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Sam, Please keep this between us for the moment. On Thu, 8 Jun 2006, Sam Hartman wrote: > First, have you looked at the updated IPR disclosure? Yes. The Cisco lawyer who deals with IPR says that he is confused by it. He suggests that I ask for a clarification of what is "based on royalty-free with other reasonable non-discriminations terms and conditions". There are other spelling and grammar problems as well. I figure that if my lawyer is confused by it, I can't ask the WG to go along with it. David says that Huawei wants the license to be easy and painless. I'll attempt to get consensus on that. Right now, some people who have been implementing are a bit hurt thinking that Huawei is claiming everything. I figure that there is a claim, or some claims, in the document and that Huawei is not attempting to cover the entire concept of syslog/tls. However, that is not clear from the disclosure so I'm getting some problems in the WG. If there are specific claims and it comes to light then I may be able to get some more acceptance of the terms. Any advice would be appreciated. > > You can work on udp and -protocol, and you can even update your > milestones to reflect that. You can get as far as sending me a > publication request for these documents. However I will not take the > documents to the IESG without a security solution. So, I'll wait > until it seems clear that there will be WG consensus to actually > publish the TLS draft (or something else of your choosing) before I > bring -protocol to the IESG. OK. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 09 16:57:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foo2d-0002a5-6U; Fri, 09 Jun 2006 16:57:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foo2b-0002VB-Mp for syslog@ietf.org; Fri, 09 Jun 2006 16:57:13 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foo2a-0006wk-El for syslog@ietf.org; Fri, 09 Jun 2006 16:57:13 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 09 Jun 2006 13:57:12 -0700 X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="292472489:sNHT36065780" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k59KvBDD027545; Fri, 9 Jun 2006 13:57:11 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k59KvBkf005153; Fri, 9 Jun 2006 13:57:11 -0700 (PDT) Date: Fri, 9 Jun 2006 13:57:11 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Subject: Re: separate - Re: [Syslog] Draft-ietf-syslog-transport-tls-01.txt In-Reply-To: Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA17487E@grfint2.intern.adiscon.com> <1149770323.10609.16.camel@bzorp.balabit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=292; t=1149886631; x=1150750631; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Re=3A=20separate=20-=20Re=3A=20[Syslog]=20Draft-ietf-syslog-transport-tl s-01.txt; X=v=3Dcisco.com=3B=20h=3DFnOrAtrvNgHcTtPpIwknWywR7yk=3D; b=vmFiwqfNV0RfxzxKV75eHU5xvk2cFm5ClH8nmmYn7f4zMZiBRqjtc0lfMzAHhQU9VF76uFMy LU4rFhSKz13jQc9/deBdlAsx67qFadqUCkPLLRKzxxyev/WQXG72/GSg; Authentication-Results: sj-dkim-1.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, OK - I blew it. My apologies to the Working Group and to David for my obvious problem. I had meant that to be an update to Sam only. With sincere apologies, Chris On Fri, 9 Jun 2006, Chris Lonvick wrote: > Hi Sam, > > Please keep this between us for the moment. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 09 17:04:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foo9U-0000x1-II; Fri, 09 Jun 2006 17:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foo9S-0000ww-UR for syslog@ietf.org; Fri, 09 Jun 2006 17:04:18 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foo9S-0007Mg-EI for syslog@ietf.org; Fri, 09 Jun 2006 17:04:18 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Jun 2006 17:04:18 -0400 X-IronPort-AV: i="4.05,224,1146456000"; d="scan'208"; a="89699447:sNHT34043892" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k59L4GYL028865; Fri, 9 Jun 2006 17:04:17 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 17:04:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Call for David Harrington to resign from syslog as co-chair Date: Fri, 9 Jun 2006 17:04:15 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122018A40FA@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Call for David Harrington to resign from syslog as co-chair Thread-Index: AcaL6YXLeyDMUASkSO6XuMScFpM1xAAFSpVAAAGBczA= From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , "Darren Reed" , "David B Harrington" X-OriginalArrivalTime: 09 Jun 2006 21:04:16.0492 (UTC) FILETIME=[44959AC0:01C68C08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I agree that Darren is overreacting in words, but maybe not in = substance. I think that a co-chair generally plays some role within his = own company, and can/should steer it away from behavior disruptive to = the work of the standards body that this co-chair is overseeing. I would = expect that from a co-chair, anyway. Particularly, when it comes to = frivolous patents that serve nothing other than cast a shadow over the = potential standard and hamper enthusiasm of WG members. =20 While I certainly don't have enough information to judge what has gone = on within that company, I would agree that appearance is not good = because it raises doubt about potential co-chair involvement in an = activity which hinders WG work. Let me be clear, I don't question = David's personal character, but if the *appearance* of potential = conflict of interests serves to de-motivate WG members, I don't think it = is a good thing. It is a little bit weird for a group to be led by a = person from company which cast shadow over viability of the standard. =20 I have personally spent a lot of effort on this work over the years. And = if members of WG feel betrayed, rightly or wrongly, I would side with = their point of view, so the work can continue with less friction.=20 Thanks, Anton. =20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Friday, June 09, 2006 4:16 PM > To: Darren Reed; David B Harrington > Cc: syslog@ietf.org > Subject: RE: [Syslog] Call for David Harrington to resign=20 > from syslog asco-chair >=20 > Darren, >=20 > I think you have mis-read the IPR disclosure. The section=20 > numbers in roman numbers refer to the IPR claim and not the=20 > I-D sections. >=20 > I would also like to voice that I am very happy that David is=20 > co-charing this group. The current discussion has shown how=20 > professional and ethical his leadership of the WG is. There=20 > is nothing that would justify to step back from this position. >=20 > I also think that you are exaggerating the situation. While I=20 > do not like the move by Huawei (and have voiced that), I also=20 > think there is nothing evil per s=E9 in this move. IMHO Huawei=20 > is simply using an abusive patent system. This is a=20 > difference to someone abusing a non-abusive system. The=20 > primary thing to do is fight the abusive system itself - as=20 > we in Europe try to avoid an US-like patent system over here.=20 > As far as I know, even the US is reconsidering the current=20 > patent system. I do not know about China, Australia and=20 > Japan, but my uninformed impression is that it is as bad=20 > there as it is in the US. I also think we shouldn't wonder=20 > that the Chineese do what we have told them for years now: we=20 > have ever and ever told them that they must respect the=20 > western way of IPR. Are they really to blame they are doing=20 > it now? Has someone forgotten to think about the situation=20 > that they themselves use it to their advantage? Believe me, a=20 > country of this size and population has lots of (real) inventors... ;) >=20 > Back to this case: I still see lack of an innovation. The=20 > thing also smells bad if I look at the timing. Anyhow, the=20 > action to take is to clarify the claim and see how to avoid=20 > it. Chris is handling this perfectly. I think it was also=20 > important to voice that we are unhappy with a patent claim.=20 > This has been done. David has done his chore of notifying the=20 > WG - exactly as required by IETF policies. A thing left to do=20 > (once we know details) is to make clear that the patent claim=20 > is invalid and there are lots of prior art. As far as I know,=20 > you Darren, had started the WG with syslog/ssl in mind. So=20 > you are probably in one of the best position to proove this=20 > prior art. Please do that once the details are clear. >=20 > IMHO we should not be overreacting: if that IPR claim is the=20 > worst thing that happens to the WG, we are very lucky. It's a=20 > weak one, even though it is disturbing and eventually=20 > time-consuming. I think we've had bigger problems and we were=20 > able to solve them. Having to deal with lawyers is nothing=20 > that make a tech guy happy (at least not me...), but=20 > sometimes this is unavoidable. >=20 > Having said all this, please let me repeat that I prefer to=20 > have no syslog RFC than to have one that is taken hostage by=20 > a nonsense patent claim. Just to make sure I will not be=20 > misunderstood in this regard. But it is no solution to run=20 > away as soon as somebody screams "IPR" into the crowd... >=20 > Rainer >=20 > > -----Original Message----- > > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > > Sent: Friday, June 09, 2006 7:23 PM > > To: David B Harrington > > Cc: syslog@ietf.org > > Subject: [Syslog] Call for David Harrington to resign from=20 > > syslog as co-chair > >=20 > > As someone who works fr the offending company, I might point > > out that the lodged IPR statement does not accurately reference > > the draft at all. It talks about "section IV" and "section V". > > The current draft has no "section IV" or "section V". > > The draft does have sections labelled "section 4" and "section 5". > > If you know anything of legal documents and messages then you will > > understand that they need to be accurate. Ask your lawyer for > > more information on this. > >=20 > > Given your role as chair and that you are employed by the > > company involved, I would like to ask you to resign your > > role as co-chair here because I believe your commercial > > interests are compromising the direction and role of this > > group. > >=20 > > If you do not wish to voluntarily resign I will ask the > > group to take a vote on this matter. As it stands, there > > are a number of people who do not like this move and I > > can imagine any number of them would feel betrayed by it. > >=20 > > Darren > >=20 > > > Hi, > > >=20 > > > As co-chair it is my responsibility to make the WG aware=20 > that there > > > has been a disclosure that an unpublished pending patent=20 > application > > > might be infringed by the implementation of the specifications in > > > draft-ietf-syslog-transport-tls-01.txt. > > >=20 > > > The disclosure can be found at > > >=20 > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D717. > > >=20 > > > David Harrington > > > dharrington@huawei.com=20 > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > co-chair, Syslog WG=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 09 18:58:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fopvb-00053G-7I; Fri, 09 Jun 2006 18:58:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fopva-00053B-88 for syslog@ietf.org; Fri, 09 Jun 2006 18:58:06 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FopvY-0003sg-TZ for syslog@ietf.org; Fri, 09 Jun 2006 18:58:06 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 09 Jun 2006 15:58:05 -0700 X-IronPort-AV: i="4.05,225,1146466800"; d="scan'208"; a="430446936:sNHT28631050" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k59Mw4p8032671 for ; Fri, 9 Jun 2006 15:58:04 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k59Mw4CV011443 for ; Fri, 9 Jun 2006 15:58:04 -0700 (PDT) Date: Fri, 9 Jun 2006 15:58:03 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=2773; t=1149893884; x=1150757884; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Having=20IPR=20in=20IETF=20Documents; X=v=3Dcisco.com=3B=20h=3D8rbKl0YMfDuQPlPSKjQB+Dr5cgE=3D; b=bB0Q76tDS9WjpfEHLk5miWi3iot5JUAz+5KUpqPgUBh0wp3j8J8OMN4ESWYlPT5UzBoZt0fy Qn4pxLbGx5o3LECTV6Yej7NnaLlNcBZT9uU+deJIcFJ+o7uAje7ZjlIY; Authentication-Results: sj-dkim-3.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Syslog] Having IPR in IETF Documents X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, I do want to be clear on this subject. Hauwei is well within their rights to discover something while writing a Working Group document, and then to claim IPR on that discovery. This has happened in the past which was why the IETF started writing BCP 79 - currently RFC 3979. The discussion of the use of IPR in IETF documents has been very rocky but overall, the IETF is really just catching up with other standards developing organizations. Almost all other standards organizations have developed clear rules about bringing IPR into their documents and the IETF has done the same. This is not unique to our Working Group. Please look at the other IPR disclosure statements that have been filed: https://datatracker.ietf.org/public/ipr_list.cgi I also want to note here that Hauwei has done the right thing in filing a disclosure. Please consider what would happen if a company knowingly inserted IPR into a standard without disclosing it. People and companies would implement it and would then be liable for whatever terms were imposed upon them. RFC 3979 clearly states that a disclosure must be made, and Huawei has done that. The IETF will not make any assertions about the validity of any claim. RFC 3979 is clear on this point as well. As a Working Group, we have been informed that some IPR has been claimed and we will need to deal with it without attempting to decide if it is a valid claim or not. Now that we know that IPR is being claimed in one of our documents, we have some options open to us. We can either accept the terms and continue with the document, or we can attempt to work around the claim. There is a process here and we will follow it. I am again asking for your patience while we sort some things out. When we have more information, I will start asking for consensus on the mailing list. The first thing is to ask Hauwei to update their disclosure to address the most recent version of the document. I've sent that request and will notify everyone when I get a response. What David Harrington has done has also been proper and according to form. He has notified the Working Group of an IPR disclosure statement. He called me and we discussed the situation. He felt that he didn't want there to be any question of a conflict of interest between his position as WG Co-Chair and that of a Huawei employee in this matter so he has recused himself of this discussion. I will ask for your coorporation and support in following this process so we can reach consensus and move forward. If you wish to debate the use of IPR in IETF documents, please go to the iprwg. http://www.ietf.org/html.charters/ipr-charter.html Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 10 05:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FozTj-0002rm-Ii; Sat, 10 Jun 2006 05:09:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FozTi-0002kc-09 for syslog@ietf.org; Sat, 10 Jun 2006 05:09:58 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FozTg-00085h-Ia for syslog@ietf.org; Sat, 10 Jun 2006 05:09:57 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id DD4B227C065; Sat, 10 Jun 2006 11:07:01 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13043-08; Sat, 10 Jun 2006 11:07:01 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 933DA27C061; Sat, 10 Jun 2006 11:07:01 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Jun 2006 11:09:45 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Having IPR in IETF Documents MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 10 Jun 2006 11:09:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1748AF@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Having IPR in IETF Documents thread-index: AcaMGDQ9a605Qw2YRbCXk58V9slB9gAUo1Qg From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 10 Jun 2006 09:09:45.0148 (UTC) FILETIME=[9DAF67C0:01C68C6D] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris, ok, you have pointed to the IPR IETF list, anyhow, one comment on this list is due: > I do want to be clear on this subject. Hauwei is well within=20 > their rights=20 > to discover something while writing a Working Group document,=20 > and then to=20 > claim IPR on that discovery. This has happened in the past=20 > which was why=20 > the IETF started writing BCP 79 - currently RFC 3979. The=20 > discussion of=20 > the use of IPR in IETF documents has been very rocky but=20 > overall, the IETF=20 > is really just catching up with other standards developing=20 > organizations. > Almost all other standards organizations have developed clear=20 > rules about=20 > bringing IPR into their documents and the IETF has done the same. There might (might!) be some reasoning for this in some cases. In our case, this is more than frivolous. I thought Huawei claims something the have "invented" before writing the tls document. If it really belongs to the document - I actually feel I shall be ripped of my work. I've just scanned the 3 (!) core pages of syslog-tls. It is nice to hear that Huawei has "discovered" how tls works. The only "novel" thing in the pages is using a byte-counted header. I think I can claim IPR on that because I introduced it in the -tls discussion (of course other people introduced this concept too, but I was the first one to apply it to syslog ;)). Huawei didn't even initially understand how this was supposed to work, so I and others (namely Anton, who could also start the patent race...) needed to explain in detail.=20 Other than these things, there is not even any technical content in the document. It's a stupid simple protcol mapping. I am upset. I think I need to consider applying for a patent on the layered architecture for syslog as well as for using structured data. Sounds silly? I think it's less silly than what Huawei seems to claim. Probably I go for that. Folks, this is not the way I like to work. I have to re-word my mail from yesterday. In this case, Huawei actually seems to *abuse* an already *abusive patent system*. I have no understanding for this and I have a hard time understanding those folks that think this is the right course of action. I am not against patenting *invention* in a general sense. But I would like to see something *invented* (that means you design something that is *new*, aka "did not exist before"). And I definitely do not like to see that my work is stolen by someone else. I've contributed to this WG in the thought that would lead to a freely usable open standard. Looks like the GPL folks are actually right... If the claim is actually arisen out of -transport-tls, I will no longer work with the authors of this draft. I ask the WG to look for some other authors. I am staying tuned if the claim actually *roots* in -transport-tls. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 10 08:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp2wE-00060r-HI; Sat, 10 Jun 2006 08:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp2wD-00060m-FO for syslog@ietf.org; Sat, 10 Jun 2006 08:51:37 -0400 Received: from dsl-202-45-110-141-static.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp2wB-0003S0-5J for syslog@ietf.org; Sat, 10 Jun 2006 08:51:37 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k5ACorpu019785; Sat, 10 Jun 2006 22:50:53 +1000 (EST) From: Darren Reed Message-Id: <200606101250.k5ACol07025431@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Call for David Harrington to resign from syslog as co-chair In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1748AE@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Sat, 10 Jun 2006 22:50:47 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: David B Harrington , syslog@ietf.org, Darren Reed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org [ Charset ISO-8859-1 unsupported, converting... ] > Darren, > .. > > I would also like to voice that I am very happy that David is co-charing > this group. The current discussion has shown how professional and ethical > his leadership of the WG is. There is nothing that would justify to step > back from this position. > > I also think that you are exaggerating the situation. No, I'm not. And other people I've raised this subject with who have a long history of IETF involvement also believed the co-chair should be stepping down. Having him as co-chair removes transparency from the group. He has a clear financial involvement with the group's progress, now, so it is harder to believe any direction he might give would be without bias. The WG needs to be transparent in its operation and its direction must be beyond reproach in terms of conflicts of interest. It is good that David has stayed out of this discussion but if he is to continue with his professionalism, then he must step down as co-chair. I don't mind if he stays involved, but this WG cannot continue if one of the co-chairs belongs to a company that is involved in IPR action regarding the output of this WG. So I suppose that's the other option, dissolve the group if David doesn't or refuses to step down. It needs to be plainly obvious that this group is about developing technology for the Internet and not for any particular company. David's continued involvement as co-chair calls that into question. Given that Huawei has undoubtedly spent $X in this IPR action it is highly unlikely for them to change course and it would be a waste of our time and effort trying to get them to do so. > While I do not like the move by Huawei (and have voiced that), I also > think there is nothing evil per s? in this move. IMHO Huawei is simply > using an abusive patent system. This is a difference to someone abusing > non-abusive system. The primary thing to do is fight the abusive system > itself - as we in Europe try to avoid an US-like patent system over here. > As far as I know, even the US is reconsidering the current patent system. > I do not know about China, Australia and Japan, but my uninformed Having been involved with the patent process in Australia, I can tell you that if your patent lawyers are decent then you have significant obstacles to overcome to convince them that what you're doing is worthwhile. For starters, they will require it to be "novel" (i.e not obvious) and to be inventive, rather than just evolutionary. Whether the patent office itself is liek that, I don't know - this just might be the lawyers trying to stop you patenting something that is rubbish and will get thrown out later. > Back to this case: I still see lack of an innovation. Agreed. > The thing also smells bad if I look at the timing. Agreed. > Having said all this, please let me repeat that I prefer to have no > syslog RFC than to have one that is taken hostage by a nonsense patent > claim. Agreed. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 10 09:29:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp3XF-0004xA-6a; Sat, 10 Jun 2006 09:29:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp3XE-0004wr-It for syslog@ietf.org; Sat, 10 Jun 2006 09:29:52 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp3XE-0005P7-6K for syslog@ietf.org; Sat, 10 Jun 2006 09:29:52 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 10 Jun 2006 06:29:51 -0700 X-IronPort-AV: i="4.05,225,1146466800"; d="scan'208"; a="292709131:sNHT31292288" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5ADTp3q012201; Sat, 10 Jun 2006 06:29:51 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5ADTpcM002066; Sat, 10 Jun 2006 06:29:51 -0700 (PDT) Date: Sat, 10 Jun 2006 06:29:50 -0700 (PDT) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] Having IPR in IETF Documents In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1748AF@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA1748AF@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=3551; t=1149946191; x=1150810191; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:RE=3A=20[Syslog]=20Having=20IPR=20in=20IETF=20Documents; X=v=3Dcisco.com=3B=20h=3DzD4wJipaMZzk7RThjBM5Fm0Vz7w=3D; b=O6P+NOPQsaLc56HJ/JODmRsHV3Qn5jjq7jUDjNdsNPz4ATaXP4gQKIwvhTf66LIh1ioVGuah QcmxKuwnapPaqvssNPS1o5kppNM1Nxq6ncljawfukt7+Xxs7QTHoxQEQ; Authentication-Results: sj-dkim-7.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, On Sat, 10 Jun 2006, Rainer Gerhards wrote: > Chris, > > ok, you have pointed to the IPR IETF list, anyhow, one comment on this > list is due: > >> I do want to be clear on this subject. Hauwei is well within >> their rights >> to discover something while writing a Working Group document, >> and then to >> claim IPR on that discovery. This has happened in the past >> which was why >> the IETF started writing BCP 79 - currently RFC 3979. The >> discussion of >> the use of IPR in IETF documents has been very rocky but >> overall, the IETF >> is really just catching up with other standards developing >> organizations. >> Almost all other standards organizations have developed clear >> rules about >> bringing IPR into their documents and the IETF has done the same. > > There might (might!) be some reasoning for this in some cases. In our > case, this is more than frivolous. I thought Huawei claims something the > have "invented" before writing the tls document. If it really belongs to > the document - I actually feel I shall be ripped of my work. I've just > scanned the 3 (!) core pages of syslog-tls. It is nice to hear that > Huawei has "discovered" how tls works. The only "novel" thing in the > pages is using a byte-counted header. I think I can claim IPR on that > because I introduced it in the -tls discussion (of course other people > introduced this concept too, but I was the first one to apply it to > syslog ;)). Huawei didn't even initially understand how this was > supposed to work, so I and others (namely Anton, who could also start > the patent race...) needed to explain in detail. Right. We don't know what Hauwei is claiming, or even if they discovered something in this document. BCP 79 is more clear than I was, there might be something in the document that was discovered before the authors started writing. > > Other than these things, there is not even any technical content in the > document. It's a stupid simple protcol mapping. > > I am upset. I think I need to consider applying for a patent on the > layered architecture for syslog as well as for using structured data. > Sounds silly? I think it's less silly than what Huawei seems to claim. > Probably I go for that. > > Folks, this is not the way I like to work. I have to re-word my mail > from yesterday. In this case, Huawei actually seems to *abuse* an > already *abusive patent system*. I have no understanding for this and I > have a hard time understanding those folks that think this is the right > course of action. Again, let's please be patient. Hauwei is new to the IETF and, as it's been pointed out on the list already, they are new in the patent filing system. Let's follow the process and see what works out. > > I am not against patenting *invention* in a general sense. But I would > like to see something *invented* (that means you design something that > is *new*, aka "did not exist before"). And I definitely do not like to > see that my work is stolen by someone else. I've contributed to this WG > in the thought that would lead to a freely usable open standard. Looks > like the GPL folks are actually right... > > If the claim is actually arisen out of -transport-tls, I will no longer > work with the authors of this draft. I ask the WG to look for some other > authors. > > I am staying tuned if the claim actually *roots* in -transport-tls. Please do. I will convey information as it happens. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 12 08:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fplod-00073o-BR; Mon, 12 Jun 2006 08:46:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fploc-00073j-6N for syslog@ietf.org; Mon, 12 Jun 2006 08:46:46 -0400 Received: from [82.141.167.23] (helo=balabit.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FploY-0005eV-Gn for syslog@ietf.org; Mon, 12 Jun 2006 08:46:46 -0400 Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174894@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA174894@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Mon, 12 Jun 2006 14:46:47 +0200 Message-Id: <1150116407.6612.45.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Thu, 2006-06-08 at 22:06 +0200, Rainer Gerhards wrote: > Hi, > > I have been told that Huawei patents date back no longer than 2001. This > seems to confirm it: > > http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=2&u > =%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=0&f=S&l=50&d=PG01&s1=HUAWEI&Page > =Next&OS=HUAWEI&RS=HUAWEI > > Also, David said "I believe the applicant is permitted to not disclose > the claims for > eighteen months.". Assuming this holds true, and speaking only of US > patents, this seems to mean that the patent in question can not date > back to later than 2004. > > In contrast, Google has a newsgroup post about syslog-ng and stunnel > from 1999: > > http://groups.google.com/group/comp.security.unix/browse_thread/thread/d > 125f044c5f8ba4a/6c87c15ddff26516?lnk=st&q=syslog-ng+stunnel&rnum=118#6c8 > 7c15ddff26516 > > I guess there are many more samples of prior art (e.g. during the > formation of this WG, some texts I wrote myself in 2004, many more > howtows pre-2000 and probably stunnel changelogs and installations). The problem with the prior art quoted above is that the PTO prefers written and/or presented material, e.g. articles in magazines, or papers presented on conferences. Fortunately we have prior art in this category too: this one dates back to 2001, December from Linuxjournal, issue #92: http://linuxjournal.com/article/5476 So yes, the patent could probably be invalidated even if it is granted, however it costs money and needs someone to actually do it (any takers? :) I am somewhat undecided, I try to list the pros and cons whether to continue work on this matter: Pros: - we were working on this for ages now, and a standard is badly needed - Huawei probably needs the patent for its portfolio and does not care less with me, although Cisco might think differently :) Cons: - anyone could be threatened any time, license terms can be terminated and changed at will, even if it is currently reasonable, a patent is valid for _17_ years (yeah, that's 2023) - a granted patent could also mean that software that implements the patent cannot go into Linux distributions (at least to those which take this question seriously). As I see our first priority is to know more about the patent, but as that takes time, we should continue working with minimum effort, in the hope that the patent is not granted, is irrelevant or someone invalidates it. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 14 06:51:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqSyO-0000Pp-4C; Wed, 14 Jun 2006 06:51:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqSyN-0000Pj-5w for syslog@ietf.org; Wed, 14 Jun 2006 06:51:43 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqSyL-00059x-Te for syslog@ietf.org; Wed, 14 Jun 2006 06:51:43 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6E81C27C065 for ; Wed, 14 Jun 2006 12:48:40 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06036-07 for ; Wed, 14 Jun 2006 12:48:40 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 3521627C061 for ; Wed, 14 Jun 2006 12:48:40 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 12:51:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 14 Jun 2006 12:51:41 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174900@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-syslog-protocol-17 submitted thread-index: AcaPoITfvT7o7QWxTJaWIoNHCojskA== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 14 Jun 2006 10:51:36.0115 (UTC) FILETIME=[81C1F830:01C68FA0] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Syslog] draft-ietf-syslog-protocol-17 submitted X-BeenThere: syslog@lists.ietf.org X-Mailman-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 have just submitted this draft. It is a minor update over the previous version. Most important points for publishing: - -16 expires soon - truncation rules releax - no handling of Unicode etc required (as discussed on list) - langauge brush-up by Chris Lonvik (thanks again, Chris!) Contrary to what was discussed early this year, -17 does not reference nor require transport-tls. I have removed this reference because Sam indicated we might submit -protocol without -transport-tls. Further, I find it highly questionable if -tls will ever find acceptance in this WG given the IPR claim. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 15 16:46:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyjC-0006Px-13; Thu, 15 Jun 2006 16:46:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyjA-0006Pd-Js; Thu, 15 Jun 2006 16:46:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqy6l-0004gD-SS; Thu, 15 Jun 2006 16:06:27 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fqxrq-0004S5-5x; Thu, 15 Jun 2006 15:51:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5FJo1mU000427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fqxqr-0001sZ-Lm; Thu, 15 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 15 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-protocol-17.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-17.txt Pages : 45 Date : 2006-6-15 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the spirit of traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable, and secure syslog extensions suffer from the lack of a standards-track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-protocol-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-protocol-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-15133223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-protocol-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-protocol-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-15133223.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 Fri Jun 16 05:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAZn-0005VD-GA; Fri, 16 Jun 2006 05:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAZk-0005Ul-0k for syslog@ietf.org; Fri, 16 Jun 2006 05:25:12 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrAZi-0006cx-NY for syslog@ietf.org; Fri, 16 Jun 2006 05:25:12 -0400 Received: from pc6 (1Cust160.tnt30.lnd3.gbr.da.uu.net [62.188.122.160]) by galaxy.systems.pipex.net (Postfix) with SMTP id 9BDFEE0006D8; Fri, 16 Jun 2006 10:25:09 +0100 (BST) Message-ID: <002e01c6911d$d9a6bc60$0601a8c0@pc6> From: "Tom Petch" To: "David B Harrington" , References: <072001c679f6$3a0ffd80$0400a8c0@china.huawei.com> Subject: Re: [Syslog] Tls-01 Date: Fri, 16 Jun 2006 10:16:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 We have chosen and used a consistent terminology up until the tls document, so I think that tls should come in line. I think I see its problem, of not wanting to use the phrase 'sender or relay' repeatedly, but in that case, it should generate a new term, not redefine a well-established one. For myself, I am comfortable with reusing 'sender or relay' in each case. Tom Petch ----- Original Message ----- From: "David B Harrington" To: Sent: Wednesday, May 17, 2006 11:09 PM Subject: [Syslog] Tls-01 Hi, The definition of sender in syslog-tls-01 differs from that in syslog-protocol. In -protocol, the "sender" is the message generator. In -tls, the sender is the message sender, whether that entity generated the message or not, and "originator" is the generator of the message. The distinction is important for discussing transport isues common to both senders and relays. Can the WG please take a look at the differences in terminology, so we can settle on terms that can be used consistently in all our documents? Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 16 05:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAZk-0005Uq-AX; Fri, 16 Jun 2006 05:25:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAZj-0005Ug-Fn for syslog@ietf.org; Fri, 16 Jun 2006 05:25:11 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrAZi-0006cu-1s for syslog@ietf.org; Fri, 16 Jun 2006 05:25:11 -0400 Received: from pc6 (1Cust160.tnt30.lnd3.gbr.dFrom syslog-bounces@lists.ietf.org Fri Jun 16 05:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAZn-0005VD-GA; Fri, 16 Jun 2006 05:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAZk-0005Ul-0k for syslog@ietf.org; Fri, 16 Jun 2006 05:25:12 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrAZi-0006cx-NY for syslog@ietf.org; Fri, 16 Jun 2006 05:25:12 -0400 Received: from pc6 (1Cust160.tnt30.lnd3.gbr.da.uu.net [62.188.122.160]) by galaxy.systems.pipex.net (Postfix) with SMTP id 9BDFEE0006D8; Fri, 16 Jun 2006 10:25:09 +0100 (BST) Message-ID: <002e01c6911d$d9a6bc60$0601a8c0@pc6> From: "Tom Petch" To: "David B Harrington" , References: <072001c679f6$3a0ffd80$0400a8c0@china.huawei.com> Subject: Re: [Syslog] Tls-01 Date: Fri, 16 Jun 2006 10:16:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 We have chosen and used a consistent terminology up until the tls document, so I think that tls should come in line. I think I see its problem, of not wanting to use the phrase 'sender or relay' repeatedly, but in that case, it should generate a new term, not redefine a well-established one. For myself, I am comfortable with reusing 'sender or relay' in each case. Tom Petch ----- Original Message ----- From: "David B Harrington" To: Sent: Wednesday, May 17, 2006 11:09 PM Subject: [Syslog] Tls-01 Hi, The definition of sender in syslog-tls-01 differs from that in syslog-protocol. In -protocol, the "sender" is the message generator. In -tls, the sender is the message sender, whether that entity generated the message or not, and "originator" is the generator of the message. The distinction is important for discussing transport isues common to both senders and relays. Can the WG please take a look at the differences in terminology, so we can settle on terms that can be used consistently in all our documents? Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 16 05:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAZk-0005Uq-AX; Fri, 16 Jun 2006 05:25:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAZj-0005Ug-Fn for syslog@ietf.org; Fri, 16 Jun 2006 05:25:11 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrAZi-0006cu-1s for syslog@ietf.org; Fri, 16 Jun 2006 05:25:11 -0400 Received: from pc6 (1Cust160.tnt30.lnd3.gbr.da.uu.net [62.188.122.160]) by galaxy.systems.pipex.net (Postfix) with SMTP id CA339E0006B4; Fri, 16 Jun 2006 10:25:06 +0100 (BST) Message-ID: <002d01c6911d$d8cc8900$0601a8c0@pc6> From: "Tom Petch" To: References: <019001c67374$8d1a27e0$0400a8c0@china.huawei.com> Subject: Re: [Syslog] stream transport was draft-ietf-syslog-transport-tls-01.txt Date: Fri, 16 Jun 2006 10:12:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I think that this document has some way to go. It has introduced, and woven together, both TLS and TCP transport, which I think wrong. Ideally, I think that we should have two separate documents, one dealing with TLS, the other with TCP issues; given that both would be short, it is probably sensible to have only the one, but I still see the need for separation within the document. After all, DTLS exists: an outsider could, should, think that syslog is UDP-based, DTLS provides UDP security so DTLS is the obvious choice, what on earth is this document talking about? We need a section on DTLS (if only justifying why it is not for further consideration). And, for me, that alone justifies teasing out the TLS issues from the TCP issues; is FRAME-LEN needed over DTLS?. That said, I do not think that this document adequately covers the TCP issues, ones that have surfaced on the list before. TLSoTCP can deliver one syslog message, many syslog messages, part of a syslog message or a combination thereof - it is in the nature of a stream protocol. This needs spelling out. A TCP connection takes time to set up, TLSoTCP longer. This needs spelling out; if timely delivery is a concern, then the connection should be established in advance. The section on TCP termination is too weak. If we are recommending a timeout, then we should recommend a value, even specifying that it should be configurable over a range. And if we cannot agree on such values, I do not think we should be specifying a timeout. TCP perforce introduces flow control. This will slow down and rate limit messages; what is the impact of this on the application? TCP failures can terminate the connection! Again, this has an impact on the application with the time taken to become aware that the connection has failed. Tom Petch ----- Original Message ----- From: "David B Harrington" To: Sent: Tuesday, May 09, 2006 4:26 PM Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt Hi, A new revision of the syslog/TLS draft is available. http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 .txt We need reviewers. Can we get 1) a person to check the grammar? 2) a person to check the syslog technical parts? 3) a person to check compatibility with the other WG documents? 4) a person to check the TLS technical parts? We also need general reviews of the document by multiple people. Thanks, David Harrington co-chair, Syslog WG ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog __________________________________________a.uu.net [62.188.122.160]) by galaxy.systems.pipex.net (Postfix) with SMTP id CA339E0006B4; Fri, 16 Jun 2006 10:25:06 +0100 (BST) Message-ID: <002d01c6911d$d8cc8900$0601a8c0@pc6> From: "Tom Petch" To: References: <019001c67374$8d1a27e0$0400a8c0@china.huawei.com> Subject: Re: [Syslog] stream transport was draft-ietf-syslog-transport-tls-01.txt Date: Fri, 16 Jun 2006 10:12:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I think that this document has some way to go. It has introduced, and woven together, both TLS and TCP transport, which I think wrong. Ideally, I think that we should have two separate documents, one dealing with TLS, the other with TCP issues; given that both would be short, it is probably sensible to have only the one, but I still see the need for separation within the document. After all, DTLS exists: an outsider could, should, think that syslog is UDP-based, DTLS provides UDP security so DTLS is the obvious choice, what on earth is this document talking about? We need a section on DTLS (if only justifying why it is not for further consideration). And, for me, that alone justifies teasing out the TLS issues from the TCP issues; is FRAME-LEN needed over DTLS?. That said, I do not think that this document adequately covers the TCP issues, ones that have surfaced on the list before. TLSoTCP can deliver one syslog message, many syslog messages, part of a syslog message or a combination thereof - it is in the nature of a stream protocol. This needs spelling out. A TCP connection takes time to set up, TLSoTCP longer. This needs spelling out; if timely delivery is a concern, then the connection should be established in advance. The section on TCP termination is too weak. If we are recommending a timeout, then we should recommend a value, even specifying that it should be configurable over a range. And if we cannot agree on such values, I do not think we should be specifying a timeout. TCP perforce introduces flow control. This will slow down and rate limit messages; what is the impact of this on the application? TCP failures can terminate the connection! Again, this has an impact on the application with the time taken to become aware that the connection has failed. Tom Petch ----- Original Message ----- From: "David B Harrington" To: Sent: Tuesday, May 09, 2006 4:26 PM Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt Hi, A new revision of the syslog/TLS draft is available. http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 .txt We need reviewers. Can we get 1) a person to check the grammar? 2) a person to check the syslog technical parts? 3) a person to check compatibility with the other WG documents? 4) a person to check the TLS technical parts? We also need general reviews of the document by multiple people. Thanks, David Harrington co-chair, Syslog WG ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _____ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 16 05:28:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAci-0007Zh-Tx; Fri, 16 Jun 2006 05:28:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAch-0007Zc-N9 for syslog@ietf.org; Fri, 16 Jun 2006 05:28:15 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrAcg-0006tw-87 for syslog@ietf.org; Fri, 16 Jun 2006 05:28:15 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id AFF9527C065; Fri, 16 Jun 2006 11:25:00 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01904-07; Fri, 16 Jun 2006 11:25:00 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 6240F27C061; Fri, 16 Jun 2006 11:25:00 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 11:28:06 +0200 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] stream transport wasdraft-ietf-syslog-transport-tls-01.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 16 Jun 2006 11:28:06 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17491A@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt thread-index: AcaRJs1uX145nDUdSsmUw45RzaxolAAADcCQ From: "Rainer Gerhards" To: "Tom Petch" , X-OriginalArrivalTime: 16 Jun 2006 09:28:06.0893 (UTC) FILETIME=[2CDAD9D0:01C69127] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 agree with Tom that a TCP document would be useful and probably needed. Before someone from Huawei comes along and tries to patent this, too, I volunteer to write this document... Rainer=20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Friday, June 16, 2006 10:13 AM > To: syslog@ietf.org > Subject: Re: [Syslog] stream transport=20 > wasdraft-ietf-syslog-transport-tls-01.txt >=20 > I think that this document has some way to go. It has=20 > introduced, and woven > together, both TLS and TCP transport, which I think wrong. =20 > Ideally, I think > that we should have two separate documents, one dealing with=20 > TLS, the other with > TCP issues; given that both would be short, it is probably=20 > sensible to have only > the one, but I still see the need for separation within the=20 > document. After > all, DTLS exists: an outsider could, should, think that=20 > syslog is UDP-based, > DTLS provides UDP security so DTLS is the obvious choice,=20 > what on earth is this > document talking about? We need a section on DTLS (if only=20 > justifying why it is > not for further consideration). And, for me, that alone=20 > justifies teasing out > the TLS issues from the TCP issues; is FRAME-LEN needed over DTLS?. >=20 > That said, I do not think that this document adequately=20 > covers the TCP issues, > ones that have surfaced on the list before. >=20 > TLSoTCP can deliver one syslog message, many syslog messages,=20 > part of a syslog > message or a combination thereof - it is in the nature of a=20 > stream protocol. > This needs spelling out. >=20 > A TCP connection takes time to set up, TLSoTCP longer. This=20 > needs spelling out; > if timely delivery is a concern, then the connection should=20 > be established in > advance. >=20 > The section on TCP termination is too weak. If we are=20 > recommending a timeout, > then we should recommend a value, even specifying that it=20 > should be configurable > over a range. And if we cannot agree on such values, I do=20 > not think we should > be specifying a timeout. >=20 > TCP perforce introduces flow control. This will slow down=20 > and rate limit > messages; what is the impact of this on the application? >=20 > TCP failures can terminate the connection! Again, this has=20 > an impact on the > application with the time taken to become aware that the=20 > connection has failed. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "David B Harrington" > To: > Sent: Tuesday, May 09, 2006 4:26 PM > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt >=20 >=20 > Hi, >=20 > A new revision of the syslog/TLS draft is available. > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > .txt >=20 > We need reviewers. > Can we get > 1) a person to check the grammar? > 2) a person to check the syslog technical parts? > 3) a person to check compatibility with the other WG documents? > 4) a person to check the TLS technical parts? >=20 > We also need general reviews of the document by multiple people. >=20 > Thanks, > David Harrington > co-chair, Syslog WG > ietfdbh@comcast.net > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 16 05:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAjZ-000333-S8; Fri, 16 Jun 2006 05:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAjY-00031i-KP for syslog@ietf.org; Fri, 16 Jun 2006 05:35:20 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrAjX-0007QD-3B for syslog@ietf.org; Fri, 16 Jun 2006 05:35:20 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6FB5D27C065; Fri, 16 Jun 2006 11:32:11 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01904-10; Fri, 16 Jun 2006 11:32:11 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 1DA5227C061; Fri, 16 Jun 2006 11:32:11 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 11:35:17 +0200 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] stream transportwasdraft-ietf-syslog-transport-tls-01.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 16 Jun 2006 11:35:17 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17491B@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt thread-index: AcaRJs1uX145nDUdSsmUw45RzaxolAAADcCQAAA/5sA= From: "Rainer Gerhards" To: "Tom Petch" , X-OriginalArrivalTime: 16 Jun 2006 09:35:17.0632 (UTC) FILETIME=[2D986800:01C69128] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 Oh... and, yes, there is prior Art: This spec was openly discussed some years ago on the loganalysis mailing list. While the text itself can not be used nowadays, I think it conveys many things that need to be considered. http://www.monitorware.com/en/workinprogress/selp.txt=20 Rainer > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Friday, June 16, 2006 11:28 AM > To: Tom Petch; syslog@ietf.org > Subject: RE: [Syslog] stream=20 > transportwasdraft-ietf-syslog-transport-tls-01.txt >=20 > I agree with Tom that a TCP document would be useful and probably > needed. Before someone from Huawei comes along and tries to=20 > patent this, > too, I volunteer to write this document... >=20 > Rainer=20 >=20 > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > Sent: Friday, June 16, 2006 10:13 AM > > To: syslog@ietf.org > > Subject: Re: [Syslog] stream transport=20 > > wasdraft-ietf-syslog-transport-tls-01.txt > >=20 > > I think that this document has some way to go. It has=20 > > introduced, and woven > > together, both TLS and TCP transport, which I think wrong. =20 > > Ideally, I think > > that we should have two separate documents, one dealing with=20 > > TLS, the other with > > TCP issues; given that both would be short, it is probably=20 > > sensible to have only > > the one, but I still see the need for separation within the=20 > > document. After > > all, DTLS exists: an outsider could, should, think that=20 > > syslog is UDP-based, > > DTLS provides UDP security so DTLS is the obvious choice,=20 > > what on earth is this > > document talking about? We need a section on DTLS (if only=20 > > justifying why it is > > not for further consideration). And, for me, that alone=20 > > justifies teasing out > > the TLS issues from the TCP issues; is FRAME-LEN needed over DTLS?. > >=20 > > That said, I do not think that this document adequately=20 > > covers the TCP issues, > > ones that have surfaced on the list before. > >=20 > > TLSoTCP can deliver one syslog message, many syslog messages,=20 > > part of a syslog > > message or a combination thereof - it is in the nature of a=20 > > stream protocol. > > This needs spelling out. > >=20 > > A TCP connection takes time to set up, TLSoTCP longer. This=20 > > needs spelling out; > > if timely delivery is a concern, then the connection should=20 > > be established in > > advance. > >=20 > > The section on TCP termination is too weak. If we are=20 > > recommending a timeout, > > then we should recommend a value, even specifying that it=20 > > should be configurable > > over a range. And if we cannot agree on such values, I do=20 > > not think we should > > be specifying a timeout. > >=20 > > TCP perforce introduces flow control. This will slow down=20 > > and rate limit > > messages; what is the impact of this on the application? > >=20 > > TCP failures can terminate the connection! Again, this has=20 > > an impact on the > > application with the time taken to become aware that the=20 > > connection has failed. > >=20 > > Tom Petch > >=20 > > ----- Original Message ----- > > From: "David B Harrington" > > To: > > Sent: Tuesday, May 09, 2006 4:26 PM > > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > >=20 > >=20 > > Hi, > >=20 > > A new revision of the syslog/TLS draft is available. > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > > .txt > >=20 > > We need reviewers. > > Can we get > > 1) a person to check the grammar? > > 2) a person to check the syslog technical parts? > > 3) a person to check compatibility with the other WG documents? > > 4) a person to check the TLS technical parts? > >=20 > > We also need general reviews of the document by multiple people. > >=20 > > Thanks, > > David Harrington > > co-chair, Syslog WG > > ietfdbh@comcast.net > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 16 11:24:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGBj-00081s-Vs; Fri, 16 Jun 2006 11:24:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGBj-00081n-Cb for syslog@ietf.org; Fri, 16 Jun 2006 11:24:47 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGBi-0006sw-1X for syslog@ietf.org; Fri, 16 Jun 2006 11:24:47 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2006 11:24:46 -0400 X-IronPort-AV: i="4.06,143,1149480000"; d="scan'208"; a="90222717:sNHT31019736" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5GFOjYL001518; Fri, 16 Jun 2006 11:24:45 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 11:24:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt Date: Fri, 16 Jun 2006 11:24:44 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B7312201909803@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt Thread-Index: AcaRJsZmy9+SKaZhT9+KabUVEKsEewAMMLNw From: "Anton Okmianski \(aokmians\)" To: "Tom Petch" , X-OriginalArrivalTime: 16 Jun 2006 15:24:45.0194 (UTC) FILETIME=[FF3C76A0:01C69158] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 was just talking to Rainer about similar concern. =20 I think first of all we need a basic mapping to TCP or more generally = define syslog payload (framing) format for connection-oriented = protocols. This should cover sending multiple messages over the same = connection, obviously. The same payload structure can be used over = various TCP protocols (TLScTCP, SSHoTCP, etc) or even over straight TCP = with IPSec.=20 Connection establishment and tear-down issues should be left to the = actual transport. If we don't introduce anything new in TLS or SSH, I = am not sure why anything extra is needed to be specified. Maybe just to = create a baseline of requirement (minim cipher suite, auth mode, etc), = but even that is questionable. =20 BTW, can IPSec be considered a viable security transport for syslog = using UDP transport? I already mentioned how IPSec can address security = issues in syslog-transport-udp-07. So, do we simply need to provide an = overview of how it does it in that ID to pass the IESG criteria of = secure syslog transport? Thanks, Anton.=20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Friday, June 16, 2006 4:13 AM > To: syslog@ietf.org > Subject: Re: [Syslog] stream transport=20 > wasdraft-ietf-syslog-transport-tls-01.txt >=20 > I think that this document has some way to go. It has=20 > introduced, and woven > together, both TLS and TCP transport, which I think wrong. =20 > Ideally, I think > that we should have two separate documents, one dealing with=20 > TLS, the other with > TCP issues; given that both would be short, it is probably=20 > sensible to have only > the one, but I still see the need for separation within the=20 > document. After > all, DTLS exists: an outsider could, should, think that=20 > syslog is UDP-based, > DTLS provides UDP security so DTLS is the obvious choice,=20 > what on earth is this > document talking about? We need a section on DTLS (if only=20 > justifying why it is > not for further consideration). And, for me, that alone=20 > justifies teasing out > the TLS issues from the TCP issues; is FRAME-LEN needed over DTLS?. >=20 > That said, I do not think that this document adequately=20 > covers the TCP issues, > ones that have surfaced on the list before. >=20 > TLSoTCP can deliver one syslog message, many syslog messages,=20 > part of a syslog > message or a combination thereof - it is in the nature of a=20 > stream protocol. > This needs spelling out. >=20 > A TCP connection takes time to set up, TLSoTCP longer. This=20 > needs spelling out; > if timely delivery is a concern, then the connection should=20 > be established in > advance. >=20 > The section on TCP termination is too weak. If we are=20 > recommending a timeout, > then we should recommend a value, even specifying that it=20 > should be configurable > over a range. And if we cannot agree on such values, I do=20 > not think we should > be specifying a timeout. >=20 > TCP perforce introduces flow control. This will slow down=20 > and rate limit > messages; what is the impact of this on the application? >=20 > TCP failures can terminate the connection! Again, this has=20 > an impact on the > application with the time taken to become aware that the=20 > connection has failed. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "David B Harrington" > To: > Sent: Tuesday, May 09, 2006 4:26 PM > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt >=20 >=20 > Hi, >=20 > A new revision of the syslog/TLS draft is available. > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > .txt >=20 > We need reviewers. > Can we get > 1) a person to check the grammar? > 2) a person to check the syslog technical parts? > 3) a person to check compatibility with the other WG documents? > 4) a person to check the TLS technical parts? >=20 > We also need general reviews of the document by multiple people. >=20 > Thanks, > David Harrington > co-chair, Syslog WG > ietfdbh@comcast.net > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 16 11:36:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGMq-0005Xm-Pp; Fri, 16 Jun 2006 11:36:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGMo-0005Xc-Tr for syslog@ietf.org; Fri, 16 Jun 2006 11:36:14 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGMo-0007G9-9H for syslog@ietf.org; Fri, 16 Jun 2006 11:36:14 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 38A3E27C065; Fri, 16 Jun 2006 17:33:05 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25812-10; Fri, 16 Jun 2006 17:33:05 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id C8EF027C061; Fri, 16 Jun 2006 17:33:04 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 17:36:12 +0200 Subject: RE: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt Date: Fri, 16 Jun 2006 17:36:08 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174935@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <98AE08B66FAD1742BED6CB9522B7312201909803@xmb-rtp-20d.amer.cisco.com> Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-class: urn:content-classes:message Thread-Topic: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Index: AcaRJsZmy9+SKaZhT9+KabUVEKsEewAMMLNwAABpaJA= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , "Tom Petch" , X-OriginalArrivalTime: 16 Jun 2006 15:36:12.0914 (UTC) FILETIME=[99263520:01C6915A] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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 Anton,=20 > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Friday, June 16, 2006 5:25 PM > To: Tom Petch; syslog@ietf.org > Subject: RE: [Syslog] stream=20 > transportwasdraft-ietf-syslog-transport-tls-01.txt >=20 > I was just talking to Rainer about similar concern. =20 You were, but I misunderstood it. I was so focussed on the (objected) plain tcp transport, that I did not realize that you were actually talking of a layer between -protocol and -transport-whatever-secure. > I think first of all we need a basic mapping to TCP or more=20 > generally define syslog payload (framing) format for=20 > connection-oriented protocols. This should cover sending=20 > multiple messages over the same connection, obviously. The=20 > same payload structure can be used over various TCP protocols=20 > (TLScTCP, SSHoTCP, etc) or even over straight TCP with IPSec.=20 >=20 > Connection establishment and tear-down issues should be left=20 > to the actual transport. =20 I think it shouldn't. I actually think we need an app-layer ACK, otherwise we might loose messages without knowing it. This is from the SELP spec I posted earlier: =3D=3D=3D=3D=3D=3D=3D As such, SELP is only reliable as far as the TCP stream is not broken. If the TCP stream breaks, the sender does not exactly know which data has actually been transmitted to the receiver and which not. This is due to the fact that TCP uses a sliding window of variable size. In short, this allows that the sender sends packets, receives an acknowledgement from the OS, but the data is still on the wire. The OS acknowledgment does NOT mean the data is actually received. While the sender continues to send data, the already OS acknowledge data is eventually delivered to the sender. If that succeeds, everthing is fine. If now, however, the TCP stack will detect the problem over time and notify the sender. However, the sender does not know exactly where the problem occured and so does not know what to re-send. Anyhow, it knows at least something went wrong and SHOULD log an event to a local system event repository. =3D=3D=3D=3D=3D=3D I think we should address this need in a tcp (or better: stream) framing. It's not a big deal to add an app-level opening and closing to the protocol - and eventually even an app-level ack/nak (per message), which would relive us of many problems. It can be as simple as Sender: XFERSTART (could be checked against cert!) MSG
(trailer for error-checking, questionable) CLOSE Receiver:=20 SMTP-like status codes (or simply ACK / NAK "reason") No a big deal but a big advantage... > If we don't introduce anything new=20 > in TLS or SSH, I am not sure why anything extra is needed to=20 > be specified. Maybe just to create a baseline of requirement=20 > (minim cipher suite, auth mode, etc), but even that is questionable. =20 I think the parameters should be outlined. >=20 > BTW, can IPSec be considered a viable security transport for=20 > syslog using UDP transport? I already mentioned how IPSec=20 > can address security issues in syslog-transport-udp-07. So,=20 > do we simply need to provide an overview of how it does it in=20 > that ID to pass the IESG criteria of secure syslog transport? This is a very good question, I think one for Sam. Maybe Chris could check it out? Rainer >=20 > Thanks, > Anton.=20 >=20 > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > Sent: Friday, June 16, 2006 4:13 AM > > To: syslog@ietf.org > > Subject: Re: [Syslog] stream transport=20 > > wasdraft-ietf-syslog-transport-tls-01.txt > >=20 > > I think that this document has some way to go. It has=20 > > introduced, and woven > > together, both TLS and TCP transport, which I think wrong. =20 > > Ideally, I think > > that we should have two separate documents, one dealing with=20 > > TLS, the other with > > TCP issues; given that both would be short, it is probably=20 > > sensible to have only > > the one, but I still see the need for separation within the=20 > > document. After > > all, DTLS exists: an outsider could, should, think that=20 > > syslog is UDP-based, > > DTLS provides UDP security so DTLS is the obvious choice,=20 > > what on earth is this > > document talking about? We need a section on DTLS (if only=20 > > justifying why it is > > not for further consideration). And, for me, that alone=20 > > justifies teasing out > > the TLS issues from the TCP issues; is FRAME-LEN needed over DTLS?. > >=20 > > That said, I do not think that this document adequately=20 > > covers the TCP issues, > > ones that have surfaced on the list before. > >=20 > > TLSoTCP can deliver one syslog message, many syslog messages,=20 > > part of a syslog > > message or a combination thereof - it is in the nature of a=20 > > stream protocol. > > This needs spelling out. > >=20 > > A TCP connection takes time to set up, TLSoTCP longer. This=20 > > needs spelling out; > > if timely delivery is a concern, then the connection should=20 > > be established in > > advance. > >=20 > > The section on TCP termination is too weak. If we are=20 > > recommending a timeout, > > then we should recommend a value, even specifying that it=20 > > should be configurable > > over a range. And if we cannot agree on such values, I do=20 > > not think we should > > be specifying a timeout. > >=20 > > TCP perforce introduces flow control. This will slow down=20 > > and rate limit > > messages; what is the impact of this on the application? > >=20 > > TCP failures can terminate the connection! Again, this has=20 > > an impact on the > > application with the time taken to become aware that the=20 > > connection has failed. > >=20 > > Tom Petch > >=20 > > ----- Original Message ----- > > From: "David B Harrington" > > To: > > Sent: Tuesday, May 09, 2006 4:26 PM > > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > >=20 > >=20 > > Hi, > >=20 > > A new revision of the syslog/TLS draft is available. > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > > .txt > >=20 > > We need reviewers. > > Can we get > > 1) a person to check the grammar? > > 2) a person to check the syslog technical parts? > > 3) a person to check compatibility with the other WG documents? > > 4) a person to check the TLS technical parts? > >=20 > > We also need general reviews of the document by multiple people. > >=20 > > Thanks, > > David Harrington > > co-chair, Syslog WG > > ietfdbh@comcast.net > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 16 11:50:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGaH-0005gC-A5; Fri, 16 Jun 2006 11:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGaF-0005g6-RI for syslog@ietf.org; Fri, 16 Jun 2006 11:50:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGaC-0007zi-6Q for syslog@ietf.org; Fri, 16 Jun 2006 11:50:07 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2006 08:50:02 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,143,1149490800"; d="scan'208"; a="29687978:sNHT27112456" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5GFo1YL007955; Fri, 16 Jun 2006 11:50:01 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 11:50:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt Date: Fri, 16 Jun 2006 11:50:00 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731220190982E@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt Thread-Index: AcaRJsZmy9+SKaZhT9+KabUVEKsEewAMMLNwAABpaJAAAH9cgA== From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , "Tom Petch" , X-OriginalArrivalTime: 16 Jun 2006 15:50:01.0121 (UTC) FILETIME=[86CC9110:01C6915C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 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 App-layer ACK is an interesting idea, but I think it opens up a big = discussion. Does the relay ACK? Overlap with RFC 3195 (syslog-beep). = Overlap with SNMP Informs. Etc. =20 Anton.=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Friday, June 16, 2006 11:36 AM > To: Anton Okmianski (aokmians); Tom Petch; syslog@ietf.org > Subject: RE: [Syslog] stream=20 > transportwasdraft-ietf-syslog-transport-tls-01.txt >=20 > Anton,=20 >=20 > > -----Original Message----- > > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > > Sent: Friday, June 16, 2006 5:25 PM > > To: Tom Petch; syslog@ietf.org > > Subject: RE: [Syslog] stream=20 > > transportwasdraft-ietf-syslog-transport-tls-01.txt > >=20 > > I was just talking to Rainer about similar concern. =20 >=20 > You were, but I misunderstood it. I was so focussed on the (objected) > plain tcp transport, that I did not realize that you were actually > talking of a layer between -protocol and -transport-whatever-secure. >=20 > > I think first of all we need a basic mapping to TCP or more=20 > > generally define syslog payload (framing) format for=20 > > connection-oriented protocols. This should cover sending=20 > > multiple messages over the same connection, obviously. The=20 > > same payload structure can be used over various TCP protocols=20 > > (TLScTCP, SSHoTCP, etc) or even over straight TCP with IPSec.=20 > >=20 > > Connection establishment and tear-down issues should be left=20 > > to the actual transport. =20 >=20 > I think it shouldn't. I actually think we need an app-layer ACK, > otherwise we might loose messages without knowing it. This is from the > SELP spec I posted earlier: >=20 > =3D=3D=3D=3D=3D=3D=3D > As such, SELP is only reliable as far as the TCP stream is not > broken. If the TCP stream breaks, the sender does not exactly know > which data has actually been transmitted to the receiver and which > not. This is due to the fact that TCP uses a sliding window of > variable size. In short, this allows that the sender sends packets, > receives an acknowledgement from the OS, but the data is=20 > still on the > wire. The OS acknowledgment does NOT mean the data is actually > received. While the sender continues to send data, the already OS > acknowledge data is eventually delivered to the sender. If that > succeeds, everthing is fine. If now, however, the TCP stack will > detect the problem over time and notify the sender. However, the > sender does not know exactly where the problem occured and so does > not know what to re-send. Anyhow, it knows at least something went > wrong and SHOULD log an event to a local system event repository. > =3D=3D=3D=3D=3D=3D >=20 > I think we should address this need in a tcp (or better: stream) > framing. It's not a big deal to add an app-level opening and=20 > closing to > the protocol - and eventually even an app-level ack/nak (per message), > which would relive us of many problems. >=20 > It can be as simple as >=20 > Sender: > XFERSTART (could be checked against cert!) > MSG
(trailer for error-checking, > questionable) > CLOSE >=20 > Receiver:=20 > SMTP-like status codes (or simply ACK / NAK "reason") >=20 > No a big deal but a big advantage... >=20 > > If we don't introduce anything new=20 > > in TLS or SSH, I am not sure why anything extra is needed to=20 > > be specified. Maybe just to create a baseline of requirement=20 > > (minim cipher suite, auth mode, etc), but even that is=20 > questionable. =20 >=20 > I think the parameters should be outlined. > >=20 > > BTW, can IPSec be considered a viable security transport for=20 > > syslog using UDP transport? I already mentioned how IPSec=20 > > can address security issues in syslog-transport-udp-07. So,=20 > > do we simply need to provide an overview of how it does it in=20 > > that ID to pass the IESG criteria of secure syslog transport? >=20 > This is a very good question, I think one for Sam. Maybe Chris could > check it out? >=20 > Rainer > >=20 > > Thanks, > > Anton.=20 > >=20 > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > > Sent: Friday, June 16, 2006 4:13 AM > > > To: syslog@ietf.org > > > Subject: Re: [Syslog] stream transport=20 > > > wasdraft-ietf-syslog-transport-tls-01.txt > > >=20 > > > I think that this document has some way to go. It has=20 > > > introduced, and woven > > > together, both TLS and TCP transport, which I think wrong. =20 > > > Ideally, I think > > > that we should have two separate documents, one dealing with=20 > > > TLS, the other with > > > TCP issues; given that both would be short, it is probably=20 > > > sensible to have only > > > the one, but I still see the need for separation within the=20 > > > document. After > > > all, DTLS exists: an outsider could, should, think that=20 > > > syslog is UDP-based, > > > DTLS provides UDP security so DTLS is the obvious choice,=20 > > > what on earth is this > > > document talking about? We need a section on DTLS (if only=20 > > > justifying why it is > > > not for further consideration). And, for me, that alone=20 > > > justifies teasing out > > > the TLS issues from the TCP issues; is FRAME-LEN needed=20 > over DTLS?. > > >=20 > > > That said, I do not think that this document adequately=20 > > > covers the TCP issues, > > > ones that have surfaced on the list before. > > >=20 > > > TLSoTCP can deliver one syslog message, many syslog messages,=20 > > > part of a syslog > > > message or a combination thereof - it is in the nature of a=20 > > > stream protocol. > > > This needs spelling out. > > >=20 > > > A TCP connection takes time to set up, TLSoTCP longer. This=20 > > > needs spelling out; > > > if timely delivery is a concern, then the connection should=20 > > > be established in > > > advance. > > >=20 > > > The section on TCP termination is too weak. If we are=20 > > > recommending a timeout, > > > then we should recommend a value, even specifying that it=20 > > > should be configurable > > > over a range. And if we cannot agree on such values, I do=20 > > > not think we should > > > be specifying a timeout. > > >=20 > > > TCP perforce introduces flow control. This will slow down=20 > > > and rate limit > > > messages; what is the impact of this on the application? > > >=20 > > > TCP failures can terminate the connection! Again, this has=20 > > > an impact on the > > > application with the time taken to become aware that the=20 > > > connection has failed. > > >=20 > > > Tom Petch > > >=20 > > > ----- Original Message ----- > > > From: "David B Harrington" > > > To: > > > Sent: Tuesday, May 09, 2006 4:26 PM > > > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > A new revision of the syslog/TLS draft is available. > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > > > .txt > > >=20 > > > We need reviewers. > > > Can we get > > > 1) a person to check the grammar? > > > 2) a person to check the syslog technical parts? > > > 3) a person to check compatibility with the other WG documents? > > > 4) a person to check the TLS technical parts? > > >=20 > > > We also need general reviews of the document by multiple people. > > >=20 > > > Thanks, > > > David Harrington > > > co-chair, Syslog WG > > > ietfdbh@comcast.net > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 16 11:53:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGdP-0007te-3L; Fri, 16 Jun 2006 11:53:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGdN-0007sr-Rs for syslog@ietf.org; Fri, 16 Jun 2006 11:53:21 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGdN-00006F-5t for syslog@ietf.org; Fri, 16 Jun 2006 11:53:21 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id B0A5D27C065; Fri, 16 Jun 2006 17:50:12 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26605-03; Fri, 16 Jun 2006 17:50:12 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 46BD527C061; Fri, 16 Jun 2006 17:50:12 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 17:53:20 +0200 Subject: RE: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt Date: Fri, 16 Jun 2006 17:53:17 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174937@grfint2.intern.adiscon.com> In-Reply-To: <98AE08B66FAD1742BED6CB9522B731220190982E@xmb-rtp-20d.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Index: AcaRJsZmy9+SKaZhT9+KabUVEKsEewAMMLNwAABpaJAAAH9cgAAAYLiQ From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" X-OriginalArrivalTime: 16 Jun 2006 15:53:20.0109 (UTC) FILETIME=[FD67B9D0:01C6915C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba 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 Anton, the ACK should only be from hop to hop - much as in SMTP. It is a method to know if the data has arrived at the next receiver. I think it probably is worth it. I can live without the ACK, but I think a defined closure is needed. An initiation exchange I consider useful, but again not mandotory. Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Friday, June 16, 2006 5:50 PM > To: Rainer Gerhards; Tom Petch; syslog@ietf.org > Subject: RE: [Syslog] stream=20 > transportwasdraft-ietf-syslog-transport-tls-01.txt >=20 > App-layer ACK is an interesting idea, but I think it opens up=20 > a big discussion. Does the relay ACK? Overlap with RFC 3195=20 > (syslog-beep). Overlap with SNMP Informs. Etc. =20 >=20 > Anton.=20 >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Friday, June 16, 2006 11:36 AM > > To: Anton Okmianski (aokmians); Tom Petch; syslog@ietf.org > > Subject: RE: [Syslog] stream=20 > > transportwasdraft-ietf-syslog-transport-tls-01.txt > >=20 > > Anton,=20 > >=20 > > > -----Original Message----- > > > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > > > Sent: Friday, June 16, 2006 5:25 PM > > > To: Tom Petch; syslog@ietf.org > > > Subject: RE: [Syslog] stream=20 > > > transportwasdraft-ietf-syslog-transport-tls-01.txt > > >=20 > > > I was just talking to Rainer about similar concern. =20 > >=20 > > You were, but I misunderstood it. I was so focussed on the=20 > (objected) > > plain tcp transport, that I did not realize that you were actually > > talking of a layer between -protocol and -transport-whatever-secure. > >=20 > > > I think first of all we need a basic mapping to TCP or more=20 > > > generally define syslog payload (framing) format for=20 > > > connection-oriented protocols. This should cover sending=20 > > > multiple messages over the same connection, obviously. The=20 > > > same payload structure can be used over various TCP protocols=20 > > > (TLScTCP, SSHoTCP, etc) or even over straight TCP with IPSec.=20 > > >=20 > > > Connection establishment and tear-down issues should be left=20 > > > to the actual transport. =20 > >=20 > > I think it shouldn't. I actually think we need an app-layer ACK, > > otherwise we might loose messages without knowing it. This=20 > is from the > > SELP spec I posted earlier: > >=20 > > =3D=3D=3D=3D=3D=3D=3D > > As such, SELP is only reliable as far as the TCP stream is not > > broken. If the TCP stream breaks, the sender does not=20 > exactly know > > which data has actually been transmitted to the receiver=20 > and which > > not. This is due to the fact that TCP uses a sliding window of > > variable size. In short, this allows that the sender=20 > sends packets, > > receives an acknowledgement from the OS, but the data is=20 > > still on the > > wire. The OS acknowledgment does NOT mean the data is actually > > received. While the sender continues to send data, the already OS > > acknowledge data is eventually delivered to the sender. If that > > succeeds, everthing is fine. If now, however, the TCP stack will > > detect the problem over time and notify the sender. However, the > > sender does not know exactly where the problem occured=20 > and so does > > not know what to re-send. Anyhow, it knows at least=20 > something went > > wrong and SHOULD log an event to a local system event repository. > > =3D=3D=3D=3D=3D=3D > >=20 > > I think we should address this need in a tcp (or better: stream) > > framing. It's not a big deal to add an app-level opening and=20 > > closing to > > the protocol - and eventually even an app-level ack/nak=20 > (per message), > > which would relive us of many problems. > >=20 > > It can be as simple as > >=20 > > Sender: > > XFERSTART (could be checked against cert!) > > MSG
(trailer for error-checking, > > questionable) > > CLOSE > >=20 > > Receiver:=20 > > SMTP-like status codes (or simply ACK / NAK "reason") > >=20 > > No a big deal but a big advantage... > >=20 > > > If we don't introduce anything new=20 > > > in TLS or SSH, I am not sure why anything extra is needed to=20 > > > be specified. Maybe just to create a baseline of requirement=20 > > > (minim cipher suite, auth mode, etc), but even that is=20 > > questionable. =20 > >=20 > > I think the parameters should be outlined. > > >=20 > > > BTW, can IPSec be considered a viable security transport for=20 > > > syslog using UDP transport? I already mentioned how IPSec=20 > > > can address security issues in syslog-transport-udp-07. So,=20 > > > do we simply need to provide an overview of how it does it in=20 > > > that ID to pass the IESG criteria of secure syslog transport? > >=20 > > This is a very good question, I think one for Sam. Maybe Chris could > > check it out? > >=20 > > Rainer > > >=20 > > > Thanks, > > > Anton.=20 > > >=20 > > > > -----Original Message----- > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > > > Sent: Friday, June 16, 2006 4:13 AM > > > > To: syslog@ietf.org > > > > Subject: Re: [Syslog] stream transport=20 > > > > wasdraft-ietf-syslog-transport-tls-01.txt > > > >=20 > > > > I think that this document has some way to go. It has=20 > > > > introduced, and woven > > > > together, both TLS and TCP transport, which I think wrong. =20 > > > > Ideally, I think > > > > that we should have two separate documents, one dealing with=20 > > > > TLS, the other with > > > > TCP issues; given that both would be short, it is probably=20 > > > > sensible to have only > > > > the one, but I still see the need for separation within the=20 > > > > document. After > > > > all, DTLS exists: an outsider could, should, think that=20 > > > > syslog is UDP-based, > > > > DTLS provides UDP security so DTLS is the obvious choice,=20 > > > > what on earth is this > > > > document talking about? We need a section on DTLS (if only=20 > > > > justifying why it is > > > > not for further consideration). And, for me, that alone=20 > > > > justifies teasing out > > > > the TLS issues from the TCP issues; is FRAME-LEN needed=20 > > over DTLS?. > > > >=20 > > > > That said, I do not think that this document adequately=20 > > > > covers the TCP issues, > > > > ones that have surfaced on the list before. > > > >=20 > > > > TLSoTCP can deliver one syslog message, many syslog messages,=20 > > > > part of a syslog > > > > message or a combination thereof - it is in the nature of a=20 > > > > stream protocol. > > > > This needs spelling out. > > > >=20 > > > > A TCP connection takes time to set up, TLSoTCP longer. This=20 > > > > needs spelling out; > > > > if timely delivery is a concern, then the connection should=20 > > > > be established in > > > > advance. > > > >=20 > > > > The section on TCP termination is too weak. If we are=20 > > > > recommending a timeout, > > > > then we should recommend a value, even specifying that it=20 > > > > should be configurable > > > > over a range. And if we cannot agree on such values, I do=20 > > > > not think we should > > > > be specifying a timeout. > > > >=20 > > > > TCP perforce introduces flow control. This will slow down=20 > > > > and rate limit > > > > messages; what is the impact of this on the application? > > > >=20 > > > > TCP failures can terminate the connection! Again, this has=20 > > > > an impact on the > > > > application with the time taken to become aware that the=20 > > > > connection has failed. > > > >=20 > > > > Tom Petch > > > >=20 > > > > ----- Original Message ----- > > > > From: "David B Harrington" > > > > To: > > > > Sent: Tuesday, May 09, 2006 4:26 PM > > > > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > A new revision of the syslog/TLS draft is available. > > > >=20 > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > > > > .txt > > > >=20 > > > > We need reviewers. > > > > Can we get > > > > 1) a person to check the grammar? > > > > 2) a person to check the syslog technical parts? > > > > 3) a person to check compatibility with the other WG documents? > > > > 4) a person to check the TLS technical parts? > > > >=20 > > > > We also need general reviews of the document by multiple people. > > > >=20 > > > > Thanks, > > > > David Harrington > > > > co-chair, Syslog WG > > > > ietfdbh@comcast.net > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > >=20 > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 17 05:39:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrXH4-0004RC-T5; Sat, 17 Jun 2006 05:39:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrXH3-0004R4-Ez for syslog@ietf.org; Sat, 17 Jun 2006 05:39:25 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrXH2-0006u9-3q for syslog@ietf.org; Sat, 17 Jun 2006 05:39:25 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 1E60B27C065; Sat, 17 Jun 2006 11:36:12 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09642-09; Sat, 17 Jun 2006 11:36:12 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D400427C061; Sat, 17 Jun 2006 11:36:11 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Jun 2006 11:39:19 +0200 Content-class: urn:content-classes:message Date: Sat, 17 Jun 2006 11:39:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17493A@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: draft-shafer-netconf-syslog-00.txt Thread-Index: AcaRxMJrD5azoL0hT82pDPoA1gdZ3QALJgQw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 17 Jun 2006 09:39:19.0092 (UTC) FILETIME=[E7EE0740:01C691F1] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: phil@juniper.net Subject: [Syslog] FW: draft-shafer-netconf-syslog-00.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 all, This posting from the netconf WG seems highly relevant. The page itself uses some crumbersome challenge system, so I could not look at the actual content. I will do so when the draft is posted on the IETF site and recommend that other WG members do so, too. Rainer > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer > Sent: Saturday, June 17, 2006 6:07 AM > To: netconf > Subject: draft-shafer-netconf-syslog-00.txt >=20 > I've finally got an initial version of the draft for a netconf > capability that makes syslog data available over long-lived RPCs. > I just sent it off to the RFC Editor, so it should show up on > ietf.org sometime this weekend, but an advance copy is available. >=20 > http://professional.juniper.net/phil/ietf/draft-shafer-netconf-syslog-00 .txt >=20 > Thanks, > Phil >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 17 10:41:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrbzR-0007an-42; Sat, 17 Jun 2006 10:41:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrbHP-0005sT-3H for syslog@ietf.org; Sat, 17 Jun 2006 09:56:03 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrbHN-0007eV-UC for syslog@ietf.org; Sat, 17 Jun 2006 09:56:03 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k5HDtp1Z059145; Sat, 17 Jun 2006 06:55:52 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5HDtp566486; Sat, 17 Jun 2006 06:55:51 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k5HDtown022179; Sat, 17 Jun 2006 09:55:50 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606171355.k5HDtown022179@idle.juniper.net> To: "Rainer Gerhards" In-Reply-To: Your message of "Sat, 17 Jun 2006 11:39:14 +0200." <577465F99B41C842AAFBE9ED71E70ABA17493A@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <22175.1150552537.0@idle.juniper.net> Date: Sat, 17 Jun 2006 09:55:50 -0400 From: Phil Shafer X-Spam-Score: 0.0 (/) X-Scan-Signature: 908e7c498db66256d5e0db08ac2f5506 X-Mailman-Approved-At: Sat, 17 Jun 2006 10:41:31 -0400 Cc: syslog@ietf.org Subject: [Syslog] Re: FW: draft-shafer-netconf-syslog-00.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 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22175.1150552537.1@idle.juniper.net> "Rainer Gerhards" writes: >This posting from the netconf WG seems highly relevant. The page itself >uses some crumbersome challenge system, so I could not look at the >actual content. I will do so when the draft is posted on the IETF site >and recommend that other WG members do so, too. It's a "don't sue Juniper because of what Phil wrote" disclaimer ;^) The document is attached. Thanks, Phil ------- =_aaaaaaaaaa0 Content-Type: text/plain; name="draft-shafer-netconf-syslog-00.txt"; charset="us-ascii" Content-ID: <22175.1150552537.2@idle.juniper.net> Content-Description: draft-shafer-netconf-syslog-00.txt Network Working Group P. Shafer Internet-Draft Juniper Networks Expires: December 18, 2006 June 16, 2006 A SYSLOG Capability for NETCONF draft-shafer-netconf-syslog-00 Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC 2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 18, 2006. Shafer Expires December 18, 2006 [Page 1] Internet-Draft netconf-syslog June 2006 Table of Contents 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Event Notifications . . . . . . . . . . . . . . . . . . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. #syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. get-syslog-streams . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Parameters . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Response . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. get-syslog-events . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Parameters . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Response . . . . . . . . . . . . . . . . . . . . . . . 13 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 5. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Shafer Expires December 18, 2006 [Page 2] Internet-Draft netconf-syslog June 2006 1. Abstract SYSLOG is the most prevalent mechanism for delivering event notification data off networking devices. NETCONF is intended to provide a standard mechanism for performing configuration operations on networking devices. The two areas will overlap, giving rise to a need for receiving notification data over NETCONF. This document presents a simple mechanism for accessing SYSLOG data over NETCONF, implemented using the existing NETCONF RPC infrastructure. 2. Event Notifications Management of a network depends on timely access to information about the network, including status, alarms, faults, errors, and failures. As events of interest occur in the network, devices detect them and emit event notifications. The notifications are typically emitted as SNMP [1] traps or SYSLOG [2] messages. Both of these notification mechanisms require the destinations for notifications to be pre- configured, which represents an impediment for applications which require a more dynamic way to receive this data. This document defines a NETCONF [3] capability for retrieving SYSLOG data. Network management applications will have access to the rich volume of information currently instrumented in device software over the secure, private, connection-oriented, and reliable communication path offered by NETCONF. An application can see important notifications about the hardware which the user is attempting to configure, or see critical errors to which the user would otherwise be blind. NETCONF gives access to a device's information, both configuration and status, using a simple RPC-based protocol. It allows the definition of "capabilities", which define a contract of behavior and a set of RPCs used to implement that behavior. If a device reports a capability string in its initial message, it is indicating its ability to perform those RPCs and to behave according to the capability definition. These capabilities are the extension mechanism for NETCONF. NETCONF RPCs can be defined to return any data. The volume of data and the duration of the RPC are unlimited. Specifics about the nature of the RPC and the data returned are detailed in the capability definition. SYSLOG is an event notification mechanism widely used among network Shafer Expires December 18, 2006 [Page 3] Internet-Draft netconf-syslog June 2006 service providers. The breadth and depth of content is unmatched. Device vendors have existing embedded code for generating appropriate SYSLOG messages, and have documented the content and cause of these notifications. The integration of SYSLOG with management application seems natural. The SYSLOG protocol lacks security and reliability. But accessing SYSLOG data over NETCONF gives the richness of SYSLOG data over a secure, connection-oriented communications path, giving the application the information it needs about the network with a minimal impact to the device. 2.1. Overview SYSLOG event notifications are made available using NETCONF RPCs. The NETCONF client issues an RPC with a set of parameters detailing the information desired. The NETCONF server replies with the appropriate data. +----+ | c1 |---+ +----+ | +------+ (off-box) +----+ | | | | c2 | +--->|syslog| +-------+ +-------+ +----+ | |daemon|--------->|netconf|<--->|netconf| ... | | | >|server | |client | System | +------+ / +-------+ +-------+ Components| \ / ... | v / +----+ | (----------) | cn |---+ (historical) +----+ ( events ) (e.g. log files) (----------) The model requires that the device support a set of SYSLOG "event streams", which consist of a series of events which match the set of filters given in the streams definition. This allows the device to control what information is available to the client. The stream definition may be provided by the device vendor or be part of the device's configuration. Clients request data from one of these streams, and can supply additional filtering criteria to further constrain the data retrieved. Event notifications are generated by system components and are passed to a central syslog component, which inspects each event and matches the event against the set of stream definitions. When a match occurs, the notification is considered a member of that event stream. A notification may be part of multiple event streams. Shafer Expires December 18, 2006 [Page 4] Internet-Draft netconf-syslog June 2006 In addition to the filters defined on an event stream, the client may request filtering based on syslog header fields, names and value of structured data parameters within the notification, or message content. The client may use date and time ranges to trim recorded data, as needed, and may limit the volume of data in the response. When an event notification matches both the filters for a given stream and the filters for a particular outstanding RPC, it is encoded by the NETCONF server and forwarded to the NETCONF client. The data can be transported as simple SYSLOG messages or using the extended text format defined in the SYSLOG Working Group's Internet- Draft on the SYSLOG protocol [4]. Each notification is wrapped in an XML element. To receive notifications, a NETCONF client makes a RPC, supplying the name of the stream and any filtering to be performed in addition to any filters from the stream definition. The NETCONF server responds with a set of matching notifications. The client may request a continuous feed of SYSLOG events, allowing it to receive them as they are generated. During periods when no messages are being generated, the server will not send data, but will not close the NETCONF rpc-reply, giving a mechanism for a long-lived RPC with an open-ended data stream. The client may include termination criteria in the RPC, given a timestamp to stop, or a count of how many notifications to include in the reply. If no termination criteria are given, the RPC continues until the NETCONF session is terminated. The device may also retain event data for a stream, allowing clients to retrieve historic events. These events may be locally recorded, using locally available resources such as memory or disk. The volume of recorded events may be limited by these resources, allowing the device to keep a certain volume of events in a log file, or the fixed number of records in memory, or perhaps a set number of days worth of events. By defining the presence of historical data in the event stream definition, the control of local resource utilization is placed in the hands of the device. Historical data, if supported, is optional for any particular event stream. If historical events are available, the NETCONF server can include that data in the response. The response can include historical data, new data, or a combination. Shafer Expires December 18, 2006 [Page 5] Internet-Draft netconf-syslog June 2006 3. #syslog The #syslog capability will be defined with the capability string as follows: http://ietf.org/netconf/syslog/1.0 Operations and content defined in this capability definition should appear in a namespace with this URI. This capability defines the following set of RPCs. If this capability is accepted by the NETCONF working group, the namespace should be changed to follow the URN format. 3.1. get-syslog-streams The RPC gives the client the ability to discover the current set of SYSLOG streams the device supports. A stream is a series of SYSLOG events that match a particular set of criteria. The stream may include historic events, which may be recorded locally. 3.1.1. Parameters None. 3.1.1.1. Example The following RPC requests the list of streams supported by the NETCONF server. 3.1.2. Response The reply consists of the top-level element containing a set of elements. The element contains the description of an individual stream of SYSLOG data. This element can contain the following elements: gives the unique name of the stream. This field is mandatory. if the current NETCONF session lacks sufficient permission to read this stream. An implementation is free to omit unreadable streams from the list of streams. Shafer Expires December 18, 2006 [Page 6] Internet-Draft netconf-syslog June 2006 if the stream is recording events locally gives the format of the data available from the stream, and should be one of: o -- "traditional" for traditional RFC 3164 [2] SYSLOG data o -- "structured-data" for the Structured Data Parameter format defined in SYSLOG Working Groups's Internet-Draft [4]. contains two attributes used to match the priority field of the syslog notifications. The "facility" attribute describes the part of the system generating the message, and many are not appropriate to routing devices. The "level" attribute describes the severity of the event. If either attribute is missing, the priority matches all notifications, similar to the "any" match in most SYSLOG implementations. The full set of facilities is specified by SYSLOG. o "authorization" -- The authorization system o "authpriv" -- The same as "auth", but logged to a file readable only by selected individuals o "console" -- Messages written to /dev/console by the kernel console output driver o "cron" -- The unix cron daemon o "daemon" -- System daemons that are not provided for explicitly by other facilities (This is the most common facility for routing devices) o "ftp" -- The file transfer protocol daemon o "kernel" -- Messages generated by the kernel o "lpr" -- The line printer spooling system o "mail" -- The mail system o "news" -- The network news system o "security" -- Security subsystems o "syslog" -- Messages generated internally by the syslog daemon Shafer Expires December 18, 2006 [Page 7] Internet-Draft netconf-syslog June 2006 o "user" -- Messages generated by user processes o "uucp" -- The uucp system o "local0", "local1", .. "local7" -- Reserved for local use The full set of levels is specified by SYSLOG. Any event containing a level equal or greater than this value will be carried in the stream. The following is an ordered list of levels, sorted highest to lowest. o -" emergency" -- A panic condition o "alert" -- A condition that should be corrected immediately o "critical" -- Critical conditions, e.g., hard device errors o "error" -- Errors o "warning" -- Warning messages o "notice" -- Conditions that are not error conditions, but should possibly be handled specially o "info" -- Informational messages o "debug" -- Messages that contain information normally of use only when debugging a program Multiple elements can be used to match multiple conditions. An event notification matches if it matches any of the conditions. contains a regular expression (as defined by IEEE Std 1003.2/POSIX.2 [5]) which the message of the SYSLOG must match. Any event whose message string matches this expression is carried in the stream. contains the name of a system process on which to match. contains a regular expression which the name of an event must match. contains an expression of the form 'name=value', where the name is an SD-Param parameter name and value is a regular expression which the parameter value from the event must match. If multiple elements appear, the event must match all name=value pairs to be carried in the stream. If an event does not Shafer Expires December 18, 2006 [Page 8] Internet-Draft netconf-syslog June 2006 contain the named parameter, it is not a match. The parameter name can be prefix by an optional SD-ID and a colon (":", ABNF %d58) to distinguish the naming authority of the parameter name. This allows a stream to filter in conditions when parameter names are duplicated with different SD-IDs. 3.1.2.1. Example The following response lists three streams, one a typical log file such as /var/log/messages in unix, one a debug stream, and one a structured data stream matching on a specific set of criteria. messages traditional debug traditional today's hot routing issue structured-data rpd .*peer.* peer=10.1.2.3 3.2. get-syslog-events The RPC gives access to the events inside a stream. When a NETCONF server receives this RPC, it will respond with a set of SYSLOG events that match the criteria in the request. The RPC may be long-lived, in that it does not normally complete in a fixed time frame, but continues to forward matching events from the device until the session is terminated. This allows the client to view a continual stream of events coming from the box, similar to a Shafer Expires December 18, 2006 [Page 9] Internet-Draft netconf-syslog June 2006 traditional SYSLOG event stream, but within a secure, connection- oriented NETCONF session. 3.2.1. Parameters contains the name of the stream from which syslog notifications are matched, as given in the element from the reply from . The parameter is mandatory. messages gives the maximum number of events to include in the response, allowing the client to limit the time or memory consumed by the reply. If this parameter is provided, the NETCONF server will close the RPC response when the given number of events have been matched. 100 instructs the device to match only recorded events, and to complete the RPC as soon as the last recorded event is inspected. If this parameter is given, the NETCONF server will close the RPC response when no further recorded events are available. gives the timestamp for the earliest event to be inspected. Events generated before this time are not matched. The format of the time in restricted in accordance with Section 6.2.3 of the SYSLOG [4] Internet-Draft. 2006-04-01T23:20:50.52Z gives the timestamp for the last event to be inspected. Events generated after this time are not matched. If this parameter is provided, the NETCONF server will close the response when the given time passes. 2006-04-01T23:30Z If the is given, the NETCONF server responds with events which have occurred since the given time and match the request's filter criteria. If historical data is available and matches the time constraint, it is included in the response. The NETCONF server will then respond the new events as they occur. If the and parameters are given but the is not, the NETCONF server responds with the most recent events which match the request's filter criteria. If neither or are included in the request, the NETCONF server responds with new events as they occur. Historical data is not used. The RPC reuses a number of elements defined in the response from the RPC. contains the facility and level attributes to match against the SYSLOG notification. Multiple elements can be used to match multiple conditions. contains a regular expression which the message of the SYSLOG must match. Any event whose message string matches this expression is considered a match. ALARM CLEAR:.*fxp0 contains the name of a system process on which to match. rpd contains a regular expression which the name of an event must match. CHASSIS.*DOWN contains an expression of the form 'name=value', where the name is an SD-Param parameter name and value is a regular expression which the parameter value from the event must match. If multiple elements appear, the event must match all name=value pairs to be considered a match. If an event does not contain the named parameter, it is not a match. peer=10.* The parameter name can be prefix by an optional SD-ID and a colon (":", ABNF %d58) to distinguish the naming authority of the parameter name. This allows a stream to filter in conditions when parameter names are duplicated with different SD-IDs. junos@2636.1.1.1.2.13:username=regress The , , and parameters are only Shafer Expires December 18, 2006 [Page 11] Internet-Draft netconf-syslog June 2006 supported if the requested stream is in the "structured-data" format. They are ignored for streams using other formats. 3.2.1.1. Closing the Response The RPC response will be closed when one of the following conditions are met: o the parameter was given and events have been included in the response, or o the parameter was given and the specified time has past, or o the parameter was given and no further recorded events are available If one of these parameters was given, the NETCONF server will continue to emit events until the appropriate condition is fulfilled. If more than one of these parameters are provided, the RPC will complete when any condition is satisfied. If none of there parameters was given, the NETCONF server will continue to emit events until the session is terminated, providing a mechanism for getting ongoing notification data from the server. When an event occurs on the device, the device will forward the event notification to any outstanding RPC which the event matches. 3.2.1.2. Examples messages ^User 'r.*' logout$ mgd UI_CHILD_START username=regress input=configure authentication-level=super-user signal-name=Broken pipe 2006-04-01T23:20:50.52Z 100 Shafer Expires December 18, 2006 [Page 12] Internet-Draft netconf-syslog June 2006 3.2.2. Response The reply consists of a top-level element containing a stream of SYSLOG events. These events are encoded in text strings according to the rules contained in RFC3164 and the SYSLOG Internet- Draft. Each event from a stream that are using the "traditional" format is contained in a element. If the stream is using the "structured-data" format, each event is contained in a element. 3.2.2.1. Examples (Newlines and whitespace were inserted in the text data to make the output in this section more readable and to fit within the IETF document formatting guidelines.) The following example contains three events in "traditional" format. Jun 11 21:34:52 dent chassisd[2971]: CHASSISD_IFDEV_DETACH_ALL_PSEUDO: ifdev_detach(pseudo devices: all) Jun 11 21:35:19 dent chassisd[2971]: CHASSISD_FRU_EVENT: fpc_m40_recv_restart: restarted FPC 0 Jun 11 21:35:19 dent chassisd[2971]: CHASSISD_FRU_EVENT: fpc_m40_recv_restart: restarted FPC 1 The following example contains the same events recorded in "structured-data" format. Shafer Expires December 18, 2006 [Page 13] Internet-Draft netconf-syslog June 2006 1 2006-06-14T08:29:14.397+05:30 kitkat mgd 3993 UI_CHILD_START [junos@2636.1.1.1.2.13 command="/sbin/ifinfo"] Starting child '/sbin/ifinfo' 1 2006-06-14T08:29:14.417+05:30 kitkat mgd 3993 UI_CHILD_STATUS [junos@2636.1.1.1.2.13 command="/sbin/ifinfo" process-id="3996" status="0"] Cleanup child '/sbin/ifinfo', PID 3996, status 0 4. Acknowledgments The author wishes to thank for following people for their most excellent review of this document and the numerous additions, suggestions, and refinements they have made: Pallavi Mahajan, Andy Bierman, Rob Enns, Sri Ram Sankar, Kent Watsen, and Reid Wilson. Comments are solicited and should be addressed to the NETCONF Working Group's mailing list and/or the author. 5. Normative References [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [2] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. [3] Enns, R., "NETCONF Configuration Protocol", draft-ietf-netconf-prot-07 (work in progress), June 2005. [4] Gerhards, R., "The syslog Protocol", draft-ietf-syslog-protocol-14 (work in progress), July 2005. [5] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Standard 1003.2, 1992. Shafer Expires December 18, 2006 [Page 14] Internet-Draft netconf-syslog June 2006 Author's Address Phil Shafer Juniper Networks 940 Main Campus Drive Raleigh, NC 27606 US Email: phil@juniper.net Shafer Expires December 18, 2006 [Page 15] ------- =_aaaaaaaaaa0 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 ------- =_aaaaaaaaaa0-- From syslog-bounces@lists.ietf.org Mon Jun 19 06:31:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsH2m-0005fw-L9; Mon, 19 Jun 2006 06:31:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsH2k-0005fk-Pj for syslog@ietf.org; Mon, 19 Jun 2006 06:31:42 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsH2j-0002Ze-Cm for syslog@ietf.org; Mon, 19 Jun 2006 06:31:42 -0400 Received: from pc6 (1Cust191.tnt24.lnd4.gbr.da.uu.net [62.188.151.191]) by blaster.systems.pipex.net (Postfix) with SMTP id AA77BE0004BE; Mon, 19 Jun 2006 11:31:34 +0100 (BST) Message-ID: <034301c69382$9e6839a0$0601a8c0@pc6> From: "Tom Petch" To: References: <019001c67374$8d1a27e0$0400a8c0@china.huawei.com> Subject: Re: [Syslog] ciphersuites was draft-ietf-syslog-transport-tls-01.txt Date: Mon, 19 Jun 2006 11:27:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Reading this I-D (-02 actually), I seem to recognise wording from the TLS RFC but, I think, not enough to make clear what TLS does and does not offer. The I-D talks of strong mutual authentication, compression and encryption but fails to mention ciphersuites. Compression is negotiated per se but key exchange (eg RSA), authentication (eg SHA) and encryption (eg 3DES-EDE) come as a package, a predefined list of ciphersuites, and if the combination you want is not predefined, tough (go write your own RFC). Equally, NULL, NULL, NULL is a valid TLS ciphersuite, but rather weak on security. This may be all very familiar but I think it needs spelling out because one ciphersuite must be REQUIRED to ensure interoperability. As the I-D stands, this will be TLS_RSA_WITH_3DES_EDE_CBC_SHA which, as the name suggests, calls for a certificate with RSA public key valid for encryption, 3DES_EDE and SHA. Earlier, I queried the support for TLS and was pointed at the 220,000 hits on Google; my follow up question is, what is the commonest ciphersuite in use, amongst those secure enough to satisfy the IESG? (DES40_CBC will not do:-) Is this default what we want? SHA is fine for me. Certificates are not present in all ciphersuites; the I-D takes them for granted but fails to specify which. Is encryption always wanted? As I have said before, it is an irrelevance for the environments I am familiar with (although I accept it is a requirement for others) but do we insist it is always present? Tom Petch ----- Original Message ----- From: "David B Harrington" To: Sent: Tuesday, May 09, 2006 4:26 PM Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt Hi, A new revision of the syslog/TLS draft is available. http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 .txt We need reviewers. Can we get 1) a person to check the grammar? 2) a person to check the syslog technical parts? 3) a person to check compatibility with the other WG documents? 4) a person to check the TLS technical parts? We also need general reviews of the document by multiple people. Thanks, David Harrington co-chair, Syslog WG ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 19 21:47:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVLB-0005hN-Gk; Mon, 19 Jun 2006 21:47:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVLA-0005hF-2J for syslog@ietf.org; Mon, 19 Jun 2006 21:47:40 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsVL8-0001O7-87 for syslog@ietf.org; Mon, 19 Jun 2006 21:47:40 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1400K41YPDWI@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 20 Jun 2006 09:56:02 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1400A40YPDM7@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 20 Jun 2006 09:56:01 +0800 (CST) Received: from m19684 ([10.110.114.232]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1400BR6YRQ93@szxml04-in.huawei.com> for syslog@ietf.org; Tue, 20 Jun 2006 09:57:29 +0800 (CST) Date: Tue, 20 Jun 2006 09:46:44 +0800 From: Miao Fuyou Subject: RE: [Syslog] ciphersuites was draft-ietf-syslog-transport-tls-01.txt In-reply-to: <034301c69382$9e6839a0$0601a8c0@pc6> To: 'Tom Petch' Message-id: <027b01c6940b$62d22c50$e8726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 Thread-index: AcaTi5xhytEuUEfZQZCKwibPxvjz7gAeKT8A Section 9 of RFC4346 says: "In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA." It is OK to mandate a ciphersuite for application profile(Syslog/TLS). But, note that the ciphersuite you suggested is the same one mandated in RFC4346. Maybe it is not necessary to mandate twice. RFC2818(HTTPS) does not specify ciphersuite. I believe TLS_RSA_WITH_3DES_EDE_CBC_SHA is one of the commonest ciphersuite and satisfies IESG, RFC4346 is relatively new and comes after Bellovin-Rescorla analysis. Server certificate is a MUST for non-anonymous key-exchange in section 7.4.2 of RFC4346, in which the relationship between certificate and ciphersuite is defined. This may the same case to whether ciphersuite should be specified in application profile. > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Monday, June 19, 2006 5:27 PM > To: syslog@ietf.org > Subject: Re: [Syslog] ciphersuites was > draft-ietf-syslog-transport-tls-01.txt > > Reading this I-D (-02 actually), I seem to recognise wording > from the TLS RFC but, I think, not enough to make clear what > TLS does and does not offer. The I-D talks of strong mutual > authentication, compression and encryption but fails to > mention ciphersuites. Compression is negotiated per se but > key exchange (eg RSA), authentication (eg SHA) and encryption > (eg 3DES-EDE) come as a package, a predefined list of > ciphersuites, and if the combination you want is not > predefined, tough (go write your own RFC). Equally, NULL, > NULL, NULL is a valid TLS ciphersuite, but rather weak on security. > > This may be all very familiar but I think it needs spelling > out because one ciphersuite must be REQUIRED to ensure > interoperability. As the I-D stands, this will be > TLS_RSA_WITH_3DES_EDE_CBC_SHA which, as the name suggests, > calls for a certificate with RSA public key valid for > encryption, 3DES_EDE and SHA. > > Earlier, I queried the support for TLS and was pointed at the > 220,000 hits on Google; my follow up question is, what is the > commonest ciphersuite in use, amongst those secure enough to > satisfy the IESG? (DES40_CBC will not do:-) > > Is this default what we want? SHA is fine for me. > Certificates are not present in all ciphersuites; the I-D > takes them for granted but fails to specify which. > Is encryption always wanted? As I have said before, it is an > irrelevance for the environments I am familiar with (although > I accept it is a requirement for > others) but do we insist it is always present? > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" > To: > Sent: Tuesday, May 09, 2006 4:26 PM > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > Hi, > > A new revision of the syslog/TLS draft is available. > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > .txt > > We need reviewers. > Can we get > 1) a person to check the grammar? > 2) a person to check the syslog technical parts? > 3) a person to check compatibility with the other WG documents? > 4) a person to check the TLS technical parts? > > We also need general reviews of the document by multiple people. > > Thanks, > David Harrington > co-chair, Syslog WG > ietfdbh@comcast.net > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 19 22:23:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVtq-0000p9-6E; Mon, 19 Jun 2006 22:23:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVto-0000p3-N3 for syslog@ietf.org; Mon, 19 Jun 2006 22:23:28 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsVtn-0005W6-Rs for syslog@ietf.org; Mon, 19 Jun 2006 22:23:28 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1500GMC0D5I4@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 20 Jun 2006 10:31:53 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1500HC00D575@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 20 Jun 2006 10:31:53 +0800 (CST) Received: from m19684 ([10.110.114.232]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1500AG60FIYI@szxml04-in.huawei.com> for syslog@ietf.org; Tue, 20 Jun 2006 10:33:21 +0800 (CST) Date: Tue, 20 Jun 2006 10:22:36 +0800 From: Miao Fuyou Subject: RE: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt In-reply-to: <002d01c6911d$d8cc8900$0601a8c0@pc6> To: 'Tom Petch' Message-id: <027c01c69410$656456a0$e8726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaRJsvDvqeDRu+GRBiGp7K0XeJxhwC5c/cQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I believe when people talks about TLS, he is talking about RFC4346 or RFC2246 rather than DTLS. TLS itself is over TCP, so it is not illogical to include something about TCP. Yes, maybe it is favorable to have Syslog over TCP and Syslog over DTLS for Syslog working group. But, there will be several transport documents for the working group: 1, Syslog over UDP, already there and favorable for implementers 2, Syslog over TCP, what is the benefit? 3, Syslog over TLS 4, Syslog over DTLS, I reckon implementer would like it, but does IESG satisfy to this transport? With so many transport, implementer will be puzzled. Which is recommended by the working group? The current ones are option 1 and 3. > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Friday, June 16, 2006 4:13 PM > To: syslog@ietf.org > Subject: Re: [Syslog] stream transport > wasdraft-ietf-syslog-transport-tls-01.txt > > I think that this document has some way to go. It has > introduced, and woven together, both TLS and TCP transport, > which I think wrong. Ideally, I think that we should have > two separate documents, one dealing with TLS, the other with > TCP issues; given that both would be short, it is probably > sensible to have only the one, but I still see the need for > separation within the document. After all, DTLS exists: an > outsider could, should, think that syslog is UDP-based, DTLS > provides UDP security so DTLS is the obvious choice, what on > earth is this document talking about? We need a section on > DTLS (if only justifying why it is not for further > consideration). And, for me, that alone justifies teasing > out the TLS issues from the TCP issues; is FRAME-LEN needed > over DTLS?. > > That said, I do not think that this document adequately > covers the TCP issues, ones that have surfaced on the list before. > > TLSoTCP can deliver one syslog message, many syslog messages, > part of a syslog message or a combination thereof - it is in > the nature of a stream protocol. > This needs spelling out. > > A TCP connection takes time to set up, TLSoTCP longer. This > needs spelling out; if timely delivery is a concern, then the > connection should be established in advance. > > The section on TCP termination is too weak. If we are > recommending a timeout, then we should recommend a value, > even specifying that it should be configurable over a range. > And if we cannot agree on such values, I do not think we > should be specifying a timeout. > > TCP perforce introduces flow control. This will slow down > and rate limit messages; what is the impact of this on the > application? > > TCP failures can terminate the connection! Again, this has > an impact on the application with the time taken to become > aware that the connection has failed. > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" > To: > Sent: Tuesday, May 09, 2006 4:26 PM > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > Hi, > > A new revision of the syslog/TLS draft is available. > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > .txt > > We need reviewers. > Can we get > 1) a person to check the grammar? > 2) a person to check the syslog technical parts? > 3) a person to check compatibility with the other WG documents? > 4) a person to check the TLS technical parts? > > We also need general reviews of the document by multiple people. > > Thanks, > David Harrington > co-chair, Syslog WG > ietfdbh@comcast.net > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 20 04:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsbz9-000864-V4; Tue, 20 Jun 2006 04:53:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsbz8-00081n-8f for syslog@ietf.org; Tue, 20 Jun 2006 04:53:22 -0400 Received: from gmpea-pix-1.sun.com ([192.18.1.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsbz6-0003Hd-Rr for syslog@ietf.org; Tue, 20 Jun 2006 04:53:22 -0400 Received: from d1-emea-06.sun.com ([192.18.2.116]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5K8rFI9017272 for ; Tue, 20 Jun 2006 09:53:20 +0100 (BST) Received: from conversion-daemon.d1-emea-06.sun.com by d1-emea-06.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1500901HUMHJ00@d1-emea-06.sun.com> (original mail from Darren.Moffat@Sun.COM) for syslog@ietf.org; Tue, 20 Jun 2006 09:53:15 +0100 (BST) Received: from [129.150.120.103] by d1-emea-06.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J15003MKI0QVP00@d1-emea-06.sun.com>; Tue, 20 Jun 2006 09:53:15 +0100 (BST) Date: Tue, 20 Jun 2006 09:51:50 +0100 From: Darren J Moffat Subject: Re: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt In-reply-to: <027c01c69410$656456a0$e8726e0a@china.huawei.com> To: Miao Fuyou Message-id: <4497B726.7000301@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <027c01c69410$656456a0$e8726e0a@china.huawei.com> User-Agent: Mail/News 1.5.0.2 (X11/20060515) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Miao Fuyou wrote: > Yes, maybe it is favorable to have Syslog over TCP and Syslog over DTLS for > Syslog working group. But, there will be several transport documents for the > working group: > 1, Syslog over UDP, already there and favorable for implementers > 2, Syslog over TCP, what is the benefit? > 3, Syslog over TLS > 4, Syslog over DTLS, I reckon implementer would like it, but does IESG > satisfy to this transport? > With so many transport, implementer will be puzzled. Which is recommended by > the working group? The current ones are option 1 and 3. Or what about syslog using GSSAPI since that would allow Kerberos or a DTLS based GSSAPI mechanism. -- Darren J Moffat _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 20 06:48:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdmc-0006ue-4d; Tue, 20 Jun 2006 06:48:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdma-0006uZ-NR for syslog@ietf.org; Tue, 20 Jun 2006 06:48:32 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsdma-0001cW-68 for syslog@ietf.org; Tue, 20 Jun 2006 06:48:32 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 028A627C065; Tue, 20 Jun 2006 12:45:11 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13212-08; Tue, 20 Jun 2006 12:45:10 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 9DEA327C061; Tue, 20 Jun 2006 12:45:10 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 12:48:30 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt Date: Tue, 20 Jun 2006 12:48:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17496E@grfint2.intern.adiscon.com> In-Reply-To: <027c01c69410$656456a0$e8726e0a@china.huawei.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt Thread-Index: AcaRJsvDvqeDRu+GRBiGp7K0XeJxhwC5c/cQABJdi8A= From: "Rainer Gerhards" To: "Miao Fuyou" , "Tom Petch" X-OriginalArrivalTime: 20 Jun 2006 10:48:30.0363 (UTC) FILETIME=[1184F6B0:01C69457] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Miao, the idea of describing syslog over tcp is not to use this as an actual transport, but to provide this as an interim for other stream transport, e.g. for use by ssh. The more I think about it, the more logical it sounds to define how syslog framing works over a stream (not necessarily tcp). Then, other transports can build on this. As a software engineer, this is also like I would use layers in my application. So it sounds quite natural and extensibel. A current practical good reason for this is the patent claim. An interim-layer enables us to drop TLS with relative ease if we decide to do so.=20 I've begun to put together some thoughts on stream framing. Rainer > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Tuesday, June 20, 2006 4:23 AM > To: 'Tom Petch' > Cc: syslog@ietf.org > Subject: RE: [Syslog] stream=20 > transportwasdraft-ietf-syslog-transport-tls-01.txt >=20 > Yes, maybe it is favorable to have Syslog over TCP and Syslog=20 > over DTLS for > Syslog working group. But, there will be several transport=20 > documents for the > working group: > 1, Syslog over UDP, already there and favorable for implementers > 2, Syslog over TCP, what is the benefit?=20 > 3, Syslog over TLS > 4, Syslog over DTLS, I reckon implementer would like it, but does IESG > satisfy to this transport?=20 > With so many transport, implementer will be puzzled. Which is=20 > recommended by > the working group? The current ones are option 1 and 3. >=20 >=20 > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > Sent: Friday, June 16, 2006 4:13 PM > > To: syslog@ietf.org > > Subject: Re: [Syslog] stream transport=20 > > wasdraft-ietf-syslog-transport-tls-01.txt > >=20 > > I think that this document has some way to go. It has=20 > > introduced, and woven together, both TLS and TCP transport,=20 > > which I think wrong. Ideally, I think that we should have=20 > > two separate documents, one dealing with TLS, the other with=20 > > TCP issues; given that both would be short, it is probably=20 > > sensible to have only the one, but I still see the need for=20 > > separation within the document. After all, DTLS exists: an=20 > > outsider could, should, think that syslog is UDP-based, DTLS=20 > > provides UDP security so DTLS is the obvious choice, what on=20 > > earth is this document talking about? We need a section on=20 > > DTLS (if only justifying why it is not for further=20 > > consideration). And, for me, that alone justifies teasing=20 > > out the TLS issues from the TCP issues; is FRAME-LEN needed=20 > > over DTLS?. > >=20 > > That said, I do not think that this document adequately=20 > > covers the TCP issues, ones that have surfaced on the list before. > >=20 > > TLSoTCP can deliver one syslog message, many syslog messages,=20 > > part of a syslog message or a combination thereof - it is in=20 > > the nature of a stream protocol. > > This needs spelling out. > >=20 > > A TCP connection takes time to set up, TLSoTCP longer. This=20 > > needs spelling out; if timely delivery is a concern, then the=20 > > connection should be established in advance. > >=20 > > The section on TCP termination is too weak. If we are=20 > > recommending a timeout, then we should recommend a value,=20 > > even specifying that it should be configurable over a range. =20 > > And if we cannot agree on such values, I do not think we=20 > > should be specifying a timeout. > >=20 > > TCP perforce introduces flow control. This will slow down=20 > > and rate limit messages; what is the impact of this on the=20 > > application? > >=20 > > TCP failures can terminate the connection! Again, this has=20 > > an impact on the application with the time taken to become=20 > > aware that the connection has failed. > >=20 > > Tom Petch > >=20 > > ----- Original Message ----- > > From: "David B Harrington" > > To: > > Sent: Tuesday, May 09, 2006 4:26 PM > > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > >=20 > >=20 > > Hi, > >=20 > > A new revision of the syslog/TLS draft is available. > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > > .txt > >=20 > > We need reviewers. > > Can we get > > 1) a person to check the grammar? > > 2) a person to check the syslog technical parts? > > 3) a person to check compatibility with the other WG documents? > > 4) a person to check the TLS technical parts? > >=20 > > We also need general reviews of the document by multiple people. > >=20 > > Thanks, > > David Harrington > > co-chair, Syslog WG > > ietfdbh@comcast.net > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 20 06:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdrJ-0001D0-Ad; Tue, 20 Jun 2006 06:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdrH-0001BH-SX for syslog@ietf.org; Tue, 20 Jun 2006 06:53:23 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsdrG-0001uJ-Ii for syslog@ietf.org; Tue, 20 Jun 2006 06:53:23 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 299AF27C065 for ; Tue, 20 Jun 2006 12:50:02 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13212-09 for ; Tue, 20 Jun 2006 12:50:02 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id E231327C061 for ; Tue, 20 Jun 2006 12:50:01 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 12:53:20 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jun 2006 12:53:01 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17496F@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: syslog-protocol-17 has been published Thread-Index: AcaUV7Nq/xKnGIzsSmGRPEwWMWav9Q== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 20 Jun 2006 10:53:21.0206 (UTC) FILETIME=[BEE01560:01C69457] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Syslog] syslog-protocol-17 has been published X-BeenThere: syslog@lists.ietf.org X-Mailman-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 http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt I would appreciate comments on the I-D as we are working towards submitting it. Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 20 08:39:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsfVk-0008Ka-8e; Tue, 20 Jun 2006 08:39:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsfVj-0008KV-Il for syslog@ietf.org; Tue, 20 Jun 2006 08:39:15 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsfVi-00022p-0S for syslog@ietf.org; Tue, 20 Jun 2006 08:39:15 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id AC80327C065; Tue, 20 Jun 2006 14:35:52 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16984-01; Tue, 20 Jun 2006 14:35:52 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 4985827C061; Tue, 20 Jun 2006 14:35:52 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:39:10 +0200 Content-class: urn:content-classes:message Date: Tue, 20 Jun 2006 14:39:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174973@grfint2.intern.adiscon.com> In-Reply-To: <200606170407.k5H47Uwn018390@idle.juniper.net> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shafer-netconf-syslog-00.txt Thread-Index: AcaRxMJrD5azoL0hT82pDPoA1gdZ3QCmvrRw From: "Rainer Gerhards" To: "Phil Shafer" , "netconf" X-OriginalArrivalTime: 20 Jun 2006 12:39:10.0835 (UTC) FILETIME=[878C9430:01C69466] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: syslog@ietf.org Subject: [Syslog] RE: draft-shafer-netconf-syslog-00.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 Phil, as promised, I have gone through the netconf-syslog draft from the syslog guy's perspective. I think netconf-syslog is a very useful addition to the syslog community, too. I am cross-posting my message to the syslog WG. The most important thing that strikes me is terminology. Even though syslog terminology might not be familiar (or sound even strange) to the NETCONF WG, I think the draft should stick with it. The reason is that otherwise you will create confusion. One sample already under discussion: In you specify "the message". As a syslog-guy, I would apply the regex to the message as whole and not just the MSG part. Thus, I would find a match e.g. in STRUCTURED-DATA. This is a very natural approach for someone who implements syslog. Using the same terms also eases the work for the implementor. From my understanding, the server to support netconf-syslog must support both netconf as well as syslog. It is quite confusing in code if the thing the syslog code side e.g. calls "severity" becomes "level" as soon as another part of the same code is called. In syslog-protocol, we tried hard to use the most common terms for new header fields. Unfortunately, syslog has a lot a variance, but I think we actually managed to find quite good terms. So I suggest the following term changes: netconf-syslog syslog priority PRI level severity process PROCID event MSGID text MSG (because it works on the MSG field) I also suggest to add APP-NAME as a filter in netconf-syslog. Adding TAG (from RFC 3164 & 3195) will also be useful. Some things of more substance: In syslog-protocol, we have introduced the VERSION field. It denotes the version of syslog-rptocol message format of the message. It deliberately starts at 1 and increases monotonically (if considerable changed new versions of syslog should be specified). I suggest that in netconf-syslog is replaced by , where zero denotes RFC 3164/3195 format and non-zero denotes a version according to syslog-protocol. This also facilitates parsing the actual syslog message on the receiving netconf syslog parser. I suggest to rename it to STRUCTURED-DATA. I understand that the format is quite different from the actual syslog STRUCTURED-DATA format. But it filters on the STURUCTURED-DATA field. This is the same principle I applied above for text/MSG. I think it would be consistent to call the filter properties like the fields they operate on. Names for severity and facility RFC 3164 and syslog-protocol both list names (e.g. "authorization" and "emergency") as well as integer numbers for PRI contents. However, only the integers are normative (see ABNF in syslog-protocol, PRI description in RFC 3164). It has also been observed in practice that the names are not without ambiguity. So I strongly suggest to use the integer values only in netconf-syslog filters. If there is no consensus on this, I propose to support both the names as well as the numbers. Remotly Received Events=20 >From my understanding of netconf-syslog, a netconf-syslog server supports forwarding via netconf both locally generated syslog messages as well remotely received ones. I think the ability to process remotely received messages is a vital asset. It enables a netconf-syslog server to act as a hub/gateway to a number of netconf-unaware syslog clients. To fully support remote syslog clients, a HOSTNAME filter is needed. That would be a (regex?) filter on the hostname. Similar filters are widely deployed on syslogds in practice today. When multiple host message may be present in a single netconf-syslog stream, it might also be that different VERSIONS of the syslog protocol be present in a single stream. The syslog WG expects this to be a frequent scenario once syslog-protocol is finished. syslog-protocol already contains an identification for this (via the VERSION fields) as well as some specifics on transforming RFC 3164 syslog in a syslog-protocol receiver (A.1 in syslog-protocol-17). I suggest that netconf-syslog supports the same. Finally one small correction. On page 4 of netconf-syslog (at the top) it states: "The SYSLOG protocol lacks security and reliability." This is not true. There is RFC 3195 (syslog over BEEP) which supports security and reliability. 3195 is currently only weakly accepted, but there as some implementations of it. I suggest a reference is made to 3195 to clarify on that issue (and so that a casual reader will become aware that there is more to look at then 3164 and syslog-protocol). I hope these comments are useful. Best regards, Rainer Gerhards > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Phil Shafer > Sent: Saturday, June 17, 2006 6:08 AM > To: netconf > Subject: draft-shafer-netconf-syslog-00.txt >=20 > I've finally got an initial version of the draft for a netconf > capability that makes syslog data available over long-lived RPCs. > I just sent it off to the RFC Editor, so it should show up on > ietf.org sometime this weekend, but an advance copy is available. >=20 > http://professional.juniper.net/phil/ietf/draft-shafer-netconf > -syslog-00.txt >=20 > Thanks, > Phil >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 20 09:43:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsgW8-0004kw-2J; Tue, 20 Jun 2006 09:43:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsgW6-0004ka-Sm for syslog@ietf.org; Tue, 20 Jun 2006 09:43:42 -0400 Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsgW5-0000dh-BP for syslog@ietf.org; Tue, 20 Jun 2006 09:43:42 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 24A939C00C for ; Tue, 20 Jun 2006 16:10:16 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24443-10 for ; Tue, 20 Jun 2006 16:10:05 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id AD21A9C00B for ; Tue, 20 Jun 2006 16:10:05 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jun 2006 15:43:30 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174976@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG secure transport requirement can be quickly solved... Thread-Index: AcaUb4P6Rv2ZkqYHRMe0gajYe6M8Fg== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Subject: [Syslog] IESG secure transport requirement can be quickly solved... X-BeenThere: syslog@lists.ietf.org X-Mailman-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 propose to update RFC 3195 in the spirit of syslog-protocol to satisfy the IESG secure transport requirement (I will call this derivative work RFC3195bis below). I sincerely believe that this option would enable us to submit syslog-protocol, -transport-UDP and RFC3195bis within a few weeks.=20 My reasoning for this proposal is as follows: We all know that 3195 has limited acceptance in the community and very few implementations. However, it satisfies all IESG criteria we have in our charter. Also, it *is* something that can be used in practice and implementing it becomes easier as support libraries become visible. I know it is not an optimal choice. On the other hand, we have syslog-transport-tls, which has been encrumbered by a patent claim. As it looks, this will need months to solve. RFC3195bis can not be taken hostage by any patent claims, because there is well-defined prior art in RFC 3195. Focussing on RFC 3195bis would enable us to complete our mission and finsh work that is in the queue for many years now. I think this is urgently needed. We might even put the netconf WG with their syslog gateway on hold (because syslog-protocol can not be published without resolving the secure transport). Or netconf might choose to drop syslog-protocol in order to publish. And the good news is that 3195bis can definitely very quickly be done. I am saying this on the assumption that we do not revisit the basics of 3195 but just adopt it to syslog-protocol. I've gone through 3195 today and the changes are absolutely minimal: Section 2: Most of it simply needs to be removed because the entity roles are defined in syslog-protocol. Section 3: - the message samples must be upgraded to -protocol-format - syslog-framing in section 3.3 must be changed (could be octet-counting or disallow of multiple messages per ANS, what I recommend) Section 4: 4.4.2=20 - needs to be updated with the new HEADER fields and STRUCTURED-DATA=20 - some work on "deviceFQDN" and "deviceIP" needed - some transformation rules (page 15) need to be removed - handling of invalid message formatting must be removed (no longer a concern) - samples must be adjusted 4.4.3 - sample on page 24 (top) must be checked and/or adjusted Section 7: - DTD needs to be adjusted Section 9: - new URIs for 3195bis (also in some other places) [we can reuse well-known port 601 for -protocol] Overall References to 3164 must be changed to -syslog-protocol. This seems quite trivial, because the references are easy to spot and do not touch any substance (except outlined above). Other than these minor things, there are *NO* other changes necessary. I'd expect that an initial version of 3195bis can be created within a single working day. Add some quick review and a very limited number of edits to change discovered nits - and we have something to publish by summer. I find this extremely tempting. It breaks the deadlock situation we are currently in. Especially as we have planned to do 3195bis some time later anyhow. I don't know if the authors of 3195 would volunteer to do the edit. But I hope so. I would appreciate if the chairs could try to reach consensus on my proposal. Comments are appreciated. Thanks, Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 20 10:05:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsgr3-0000vt-8o; Tue, 20 Jun 2006 10:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsgr2-0000vo-Ll for syslog@ietf.org; Tue, 20 Jun 2006 10:05:20 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsgr1-0003Wt-DY for syslog@ietf.org; Tue, 20 Jun 2006 10:05:20 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 20 Jun 2006 07:05:11 -0700 X-IronPort-AV: i="4.06,155,1149490800"; d="scan'208"; a="1829071729:sNHT3041101880" 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 k5KE5Aop008736; Tue, 20 Jun 2006 07:05:10 -0700 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 k5KE5A9t018975; Tue, 20 Jun 2006 07:05:10 -0700 (PDT) Date: Tue, 20 Jun 2006 07:05:10 -0700 (PDT) From: Chris Lonvick To: Rainer Gerhards Subject: Re: [Syslog] IESG secure transport requirement can be quickly solved... In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174976@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA174976@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=484; t=1150812310; x=1151676310; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Re=3A=20[Syslog]=20IESG=20secure=20transport=20requirement=20can=20be=20 quickly=0A=20solved...; X=v=3Dcisco.com=3B=20h=3DGQCbAS6MxfhZsGZB/hnf6JAg1TE=3D; b=FVppkkyoDoz7KA0fZXeMDmotc0lyo3ZqB6al3/Y/UwJ59pojuqrhQeFCa2m+DNscdjdWVPfq Fu0z9MrbPerpg5qhbWWJAT9WsIo7h7VXSZWill4K9GcQflno1PFcZ3Vx; Authentication-Results: sj-dkim-1.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Everyone, On Tue, 20 Jun 2006, Rainer Gerhards wrote: > > I would appreciate if the chairs could try to reach consensus on my > proposal. > > Comments are appreciated. > Thanks, > Rainer I'll apologize up front for not paricipating in some recent dicussions. I'm on a business trip and rather busy with the day job right now. I am willing to listen to a discussion of this proposal. As Rainer says, please provide some input and comments. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 20 12:39:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsjFv-0001J4-6X; Tue, 20 Jun 2006 12:39:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsj7W-0003wp-Nc for syslog@ietf.org; Tue, 20 Jun 2006 12:30:30 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsj7V-0003ed-AT for syslog@ietf.org; Tue, 20 Jun 2006 12:30:30 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5KGUPX97644; Tue, 20 Jun 2006 09:30:25 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5KGUK539436; Tue, 20 Jun 2006 09:30:20 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id k5KGUJwn034065; Tue, 20 Jun 2006 12:30:19 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200606201630.k5KGUJwn034065@idle.juniper.net> To: "Rainer Gerhards" In-Reply-To: Your message of "Tue, 20 Jun 2006 14:39:15 +0200." <577465F99B41C842AAFBE9ED71E70ABA174973@grfint2.intern.adiscon.com> Date: Tue, 20 Jun 2006 12:30:19 -0400 From: Phil Shafer X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-Mailman-Approved-At: Tue, 20 Jun 2006 12:39:10 -0400 Cc: syslog@ietf.org, netconf Subject: [Syslog] Re: draft-shafer-netconf-syslog-00.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 "Rainer Gerhards" writes: >as promised, I have gone through the netconf-syslog draft from the >syslog guy's perspective. I think netconf-syslog is a very useful >addition to the syslog community, too. I am cross-posting my message to >the syslog WG. Truly appreciate your comments, especially the terminology ones. I'll update the draft with these next week. >RFC 3164 and syslog-protocol both list names (e.g. "authorization" and >"emergency") as well as integer numbers for PRI contents. However, only >the integers are normative (see ABNF in syslog-protocol, PRI description >in RFC 3164). It has also been observed in practice that the names are >not without ambiguity. So I strongly suggest to use the integer values >only in netconf-syslog filters. If there is no consensus on this, I >propose to support both the names as well as the numbers. I strongly dislike using numbers, but if there's consensus to use them, I'll survive. >Remotly Received Events >From my understanding of netconf-syslog, a netconf-syslog server >supports forwarding via netconf both locally generated syslog messages >as well remotely received ones. I think the ability to process remotely >received messages is a vital asset. It enables a netconf-syslog server >to act as a hub/gateway to a number of netconf-unaware syslog clients. The target audience for NETCONF (network service providers) don't configure their boxes to forward syslog messages. These devices are the source of events and operators dislike having open ports on their boxes that aren't strictly required. But I can see the utility of this for other environments and the cost is minimal, so I'd consider rolling it in, except.... >When multiple host message may be present in a single netconf-syslog >stream, it might also be that different VERSIONS of the syslog protocol >be present in a single stream. ... this sounds like it will be an issue. Can we avoid mixing VERSIONs in a single stream? >"The SYSLOG protocol lacks security and reliability." >This is not true. There is RFC 3195 (syslog over BEEP) which supports >security and reliability. 3195 is currently only weakly accepted, but >there as some implementations of it. I suggest a reference is made to >3195 to clarify on that issue (and so that a casual reader will become >aware that there is more to look at then 3164 and syslog-protocol). The target of this comment was 3164, since 3195 doesn't seem to have been picked up by the operator community, but I'll add a reference to 3195 and clarify my comment. Thanks, Phil _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 20 13:30:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsk3E-0007hk-Pr; Tue, 20 Jun 2006 13:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsk3E-0007hf-8L for syslog@ietf.org; Tue, 20 Jun 2006 13:30:08 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsk3C-0003n6-V2 for syslog@ietf.org; Tue, 20 Jun 2006 13:30:08 -0400 Received: from pc6 (1Cust86.tnt24.lnd4.gbr.da.uu.net [62.188.151.86]) by ranger.systems.pipex.net (Postfix) with SMTP id 74C7AE000373; Tue, 20 Jun 2006 18:29:57 +0100 (BST) Message-ID: <000201c69486$3a6a2080$0601a8c0@pc6> From: "Tom Petch" To: References: <019001c67374$8d1a27e0$0400a8c0@china.huawei.com> Subject: Re: [Syslog] delineated datagrams was draft-ietf-syslog-transport-tls-01.txt Date: Tue, 20 Jun 2006 14:43:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I wonder if others share my concern about the lack of robustness in the way in which datagrams are delineated in the stream protocol (a TCP rather than a TLS issue). The system works as long as - the frame length is encoded perfectly - the frame length is decoded perfectly - no bytes are inserted or removed in error which is doubtless true in some networks, but I would prefer not to rely on it. So, when an error occurs, can the Collector/Relay detect it? Can the Collector/Relay recover synch? If not, what does the Collector/Relay do? There is very little redundancy in the definition of frame length, and syslog messages have very little structure to help the application, so I think that this is an issue we should address. Tom Petch ----- Original Message ----- From: "David B Harrington" To: Sent: Tuesday, May 09, 2006 4:26 PM Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt Hi, A new revision of the syslog/TLS draft is available. http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 .txt We need reviewers. Can we get 1) a person to check the grammar? 2) a person to check the syslog technical parts? 3) a person to check compatibility with the other WG documents? 4) a person to check the TLS technical parts? We also need general reviews of the document by multiple people. Thanks, David Harrington co-chair, Syslog WG ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 20 14:18:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskoF-0003m0-LP; Tue, 20 Jun 2006 14:18:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskoD-0003lv-Sk for syslog@ietf.org; Tue, 20 Jun 2006 14:18:41 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FskoC-0001mh-HH for syslog@ietf.org; Tue, 20 Jun 2006 14:18:41 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-1.cisco.com with ESMTP; 20 Jun 2006 11:18:40 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5KIIdBC007477; Tue, 20 Jun 2006 11:18:39 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5KIIPJ2020901; Tue, 20 Jun 2006 11:18:39 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 14:18:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] delineated datagrams Date: Tue, 20 Jun 2006 14:18:34 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731220196A27B@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] delineated datagrams Thread-Index: AcaUjzE3c6fnFZAGSLqMZ4/FsZTWYwAAqKBA From: "Anton Okmianski \(aokmians\)" To: "Tom Petch" , X-OriginalArrivalTime: 20 Jun 2006 18:18:34.0963 (UTC) FILETIME=[F183EA30:01C69495] DKIM-Signature: a=rsa-sha1; q=dns; l=2758; t=1150827519; x=1151691519; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20delineated=20datagrams; X=v=3Dcisco.com=3B=20h=3D8ErUHrKDOa8swdzWKUWUGDpLeiY=3D; b=XjdZ/hPkxfbfVadtE6OaQn6n3C6JNov08mVZJISnQW3dROM1EbEv10wR6FutNk3zbiS9/Hx2 5AwREvJZtP6slMuQkj2MhsMtTxYrm9tk+Y9IMWuyoJSkIn+zvyrhJVvR; Authentication-Results: sj-dkim-7.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Tom: I think these are valid concerns. They span different layers: 1. If we only care about network-layer reliability (as in byte = insert/remove examples): client/server can be recommended to reset = connection every so often. Decent corruption detection is already part = of TCP/IP and layer 2 protocols.=20 2. If we care about app-layer reliability (as in encode/decode error = examples): app-level ACK. As in RFC 3195, for example. This certainly = expands the scope quite a bit beyond just secure transport. =20 Anton.=20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Tuesday, June 20, 2006 8:43 AM > To: syslog@ietf.org > Subject: Re: [Syslog] delineated datagrams=20 > wasdraft-ietf-syslog-transport-tls-01.txt >=20 > I wonder if others share my concern about the lack of=20 > robustness in the way in > which datagrams are delineated in the stream protocol (a TCP=20 > rather than a TLS > issue). >=20 > The system works as long as > - the frame length is encoded perfectly > - the frame length is decoded perfectly > - no bytes are inserted or removed in error > which is doubtless true in some networks, but I would prefer=20 > not to rely on it. >=20 > So, when an error occurs, can the Collector/Relay detect it? Can the > Collector/Relay recover synch? If not, what does the=20 > Collector/Relay do? >=20 > There is very little redundancy in the definition of frame=20 > length, and syslog > messages have very little structure to help the application,=20 > so I think that > this is an issue we should address. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "David B Harrington" > To: > Sent: Tuesday, May 09, 2006 4:26 PM > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt >=20 >=20 > Hi, >=20 > A new revision of the syslog/TLS draft is available. > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > .txt >=20 > We need reviewers. > Can we get > 1) a person to check the grammar? > 2) a person to check the syslog technical parts? > 3) a person to check compatibility with the other WG documents? > 4) a person to check the TLS technical parts? >=20 > We also need general reviews of the document by multiple people. >=20 > Thanks, > David Harrington > co-chair, Syslog WG > ietfdbh@comcast.net >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 21 04:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsyOs-0006P8-9B; Wed, 21 Jun 2006 04:49:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsyOq-0006P3-AJ for syslog@ietf.org; Wed, 21 Jun 2006 04:49:24 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsyOo-0000u7-PT for syslog@ietf.org; Wed, 21 Jun 2006 04:49:24 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 46D9127C065; Wed, 21 Jun 2006 10:45:55 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22015-08; Wed, 21 Jun 2006 10:45:55 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D46CD27C061; Wed, 21 Jun 2006 10:45:54 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 10:49:16 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jun 2006 10:49:17 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174987@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <200606201630.k5KGUJwn034065@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-shafer-netconf-syslog-00.txt Thread-Index: AcaUhtsvgzEWDxbDQ12g0BSsYvJQTQAho3zQ From: "Rainer Gerhards" To: "Phil Shafer" X-OriginalArrivalTime: 21 Jun 2006 08:49:16.0891 (UTC) FILETIME=[942182B0:01C6950F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: syslog@ietf.org, netconf Subject: [Syslog] RE: draft-shafer-netconf-syslog-00.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 Phil, > >RFC 3164 and syslog-protocol both list names (e.g.=20 > "authorization" and > >"emergency") as well as integer numbers for PRI contents.=20 > However, only > >the integers are normative (see ABNF in syslog-protocol, PRI=20 > description > >in RFC 3164). It has also been observed in practice that the=20 > names are > >not without ambiguity. So I strongly suggest to use the=20 > integer values > >only in netconf-syslog filters. If there is no consensus on this, I > >propose to support both the names as well as the numbers. >=20 > I strongly dislike using numbers, but if there's consensus > to use them, I'll survive. I understand your position. At a minimum, I strongly suggest that you allow either numbers or names. I think most of the filter data is operator-entered, so it is left to the operators decisions what to use. This is especially important when different syslog message sources use different names (though this could be handled by the gateway exclusively). >=20 > >Remotly Received Events=20 > >From my understanding of netconf-syslog, a netconf-syslog server > >supports forwarding via netconf both locally generated=20 > syslog messages > >as well remotely received ones. I think the ability to=20 > process remotely > >received messages is a vital asset. It enables a=20 > netconf-syslog server > >to act as a hub/gateway to a number of netconf-unaware=20 > syslog clients. >=20 > The target audience for NETCONF (network service providers) don't > configure their boxes to forward syslog messages. These devices > are the source of events and operators dislike having open ports > on their boxes that aren't strictly required. >=20 > But I can see the utility of this for other environments and > the cost is minimal, so I'd consider rolling it in, except.... >=20 > >When multiple host message may be present in a single netconf-syslog > >stream, it might also be that different VERSIONS of the=20 > syslog protocol > >be present in a single stream. >=20 > ... this sounds like it will be an issue. Can we avoid mixing > VERSIONs in a single stream? Let me ask where you see an issue with multiple versions. For me it seems fairly easy to support them. I've also thought a little more about the local environment. I think there is no way you can guarantee that even a single machine will provide consistently one message format version or the other. Reasoning: The diagram in 2.1 of netconf-syslog precisely describes how the syslog subsystem works in many environments, namely Unix and Linux based systems. The syslog daemon is not the actual message generator. In fact, it is more like a relay. From the on-the-wire point of view, it is the initial sender. But if you think about local API, it is just a receiver forwarding (and potentially transforming) messages. The actual message generators are system components (called c1, c2, .... cn in your diagram). These components generate messages via API calls. The API covers only very limited syslog header fields. Most of the header is generated by the *system component*. So you are actually not dealing with a single syslogd and its format but with a potential myriad of different components on the box. This has been identified as a major issue moving legacy (rfc 3164) syslog to a standard (syslog-protocol). This is also one reason why there are so many different formats. In order to guarantee a consistent data model, you would need to change the (POSIX) logging API. As this change can not be done evolutionary (it would break existing apps), the old API would still needed to be supported. It is thought in the syslog WG that that API change should happen some time. But we are definitely some years away from that. Not to mention how long the old API will be utilized... So my firm believe is that it will be the absolutely common case for syslog implementations to have to deal with different message formats. Much of the evil in that can be avoided, if a syslog data model is defined. This, together with transformation rules, would make it very easy to handle different versions. As I have written in another mail this morning, syslog-protocol has such a data model "on its mind" but can not spell it out because the syslog WG is not chartered to do that. But it is fairly easy. I have also a working proof-of-concept implementation of the most important transformations in actual software (www.rsyslog.com). Its fairly easy to extend that to a full data model transformation. >=20 > >"The SYSLOG protocol lacks security and reliability." > >This is not true. There is RFC 3195 (syslog over BEEP) which supports > >security and reliability. 3195 is currently only weakly accepted, but > >there as some implementations of it. I suggest a reference is made to > >3195 to clarify on that issue (and so that a casual reader=20 > will become > >aware that there is more to look at then 3164 and syslog-protocol). >=20 > The target of this comment was 3164, since 3195 doesn't seem to > have been picked up by the operator community, but I'll add a > reference to 3195 and clarify my comment. I agree that 3195 is not overly successful ;) However, you never know what the future has in stock. As there is no additional effort to supporting 3195 in netconf-syslog, I think it would be useful to mention it and to also mention that it can be used together with netconf-syslog (it is VERSION 0 format, just like 3164). Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 21 13:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6Ao-0003HQ-Cl; Wed, 21 Jun 2006 13:07:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6An-0003HI-Nt for syslog@ietf.org; Wed, 21 Jun 2006 13:07:25 -0400 Received: from [216.148.227.155] (helo=rwcrmhc15.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6Am-0002nO-EY for syslog@ietf.org; Wed, 21 Jun 2006 13:07:25 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc15) with SMTP id <20060621170723m15003gskee>; Wed, 21 Jun 2006 17:07:23 +0000 From: "David Harrington" To: Subject: RE: [Syslog] IESG secure transport requirement can be quicklysolved... Date: Wed, 21 Jun 2006 13:06:11 -0400 Message-ID: <146801c69554$ff4aee10$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaUcpJmDDSNpEjjSR6sDkho19gobQA3ojBQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, As a co-chair looking for a way forward, I was considering asking for volunteers to write a syslog-over-SSH draft as the likely alternative to TLS as a security solution. I welcome the discussion of a 3195bis alternative rorposal as a way to move forward. Thanks Rainer. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Tuesday, June 20, 2006 10:05 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] IESG secure transport requirement can > be quicklysolved... > > Hi Everyone, > > > On Tue, 20 Jun 2006, Rainer Gerhards wrote: > > > > I would appreciate if the chairs could try to reach consensus on my > > proposal. > > > > Comments are appreciated. > > Thanks, > > Rainer > > I'll apologize up front for not paricipating in some recent > dicussions. > I'm on a business trip and rather busy with the day job right now. > > I am willing to listen to a discussion of this proposal. As > Rainer says, > please provide some input and comments. > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 21 13:54:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6tz-0000mT-99; Wed, 21 Jun 2006 13:54:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6ty-0000mO-C4 for syslog@ietf.org; Wed, 21 Jun 2006 13:54:06 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6tw-0007Wk-Ri for syslog@ietf.org; Wed, 21 Jun 2006 13:54:06 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc12) with SMTP id <20060621175403m12008v7dpe>; Wed, 21 Jun 2006 17:54:03 +0000 From: "David Harrington" To: Date: Wed, 21 Jun 2006 13:52:51 -0400 Message-ID: <146f01c6955b$842d1f30$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA17496E@grfint2.intern.adiscon.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaRJsvDvqeDRu+GRBiGp7K0XeJxhwC5c/cQABJdi8AAQOr+8A== X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: Subject: [Syslog] stream transport X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [Posting as a contributor] Let me tell you that in ISMS we have written an equivalent abstraction layer. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-isms-tmsm -02.txt discusses how to handle generic session-based security rather than datagram-based security, transport connection reuse, and other issues that came up because we now use a streaming protocol. Then we wrote a protocol-specific proposal in ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-isms-secs hell-03.txt. This separation into an abstract and protocol-specific layers has been a large task, partly because it is difficult to eliminate unnecessary repetition between documents, it is difficult to keep the two documents in sync on terminology, and so on (and I'm the author for both drafts). Having also authored RFC3411 which defines an abstracted modular architecture for SNMP frameworks, I can also tell you that going in that direction can end up constraining future development a great deal. The SMIng WG and the EOS WG suffered a great deal from having to try to remain compatible with the RFC3411 abstractions. I am a believer in specifying architectures or frameworks to guide modular development, but they also need to be taken with a grain of salt. That is much easier to do in a product development environment than it is in a standards development environment, so caveat emptor (and whatever latin phrase suits this best). I worked for years at Cabletron helping to develop internal standards for software OS-portability. There was a wonderful quote from somebody who led the industry effort to standardize some portion of X-Windows or Xmake. I don't remember the quote, the technology, or who said it, but I remember the gist of it - Do not try to abstract the concepts from one instance or implementation of a technology; there should always be at least two to draw from, and preferably more. I think that trying to develop an abstraction layer at this point would be a distraction. I think that this WG has a history of being easily distracted. As a contributor, I think we should not deal with an abstraction layer at this time. If the goal is to make it easy to develop an alternative proposal to TLS, I suggest that using cut-and-paste techniques to take text from the current syslog/tls draft (for the threat model discussions) and the current netconf/ssh draft (for layering over ssh) would be far more efficient than starting a new document and abstracting the concepts. My $.02 as a contributor, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Tuesday, June 20, 2006 6:48 AM > To: Miao Fuyou; Tom Petch > Cc: syslog@ietf.org > Subject: RE: [Syslog] stream > transportwasdraft-ietf-syslog-transport-tls-01.txt > > Miao, > > the idea of describing syslog over tcp is not to use this as an actual > transport, but to provide this as an interim for other stream > transport, > e.g. for use by ssh. The more I think about it, the more logical it > sounds to define how syslog framing works over a stream (not > necessarily > tcp). Then, other transports can build on this. As a software > engineer, > this is also like I would use layers in my application. So it sounds > quite natural and extensibel. > > A current practical good reason for this is the patent claim. An > interim-layer enables us to drop TLS with relative ease if we > decide to > do so. > > I've begun to put together some thoughts on stream framing. > > Rainer > > > -----Original Message----- > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > Sent: Tuesday, June 20, 2006 4:23 AM > > To: 'Tom Petch' > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] stream > > transportwasdraft-ietf-syslog-transport-tls-01.txt > > > > > Yes, maybe it is favorable to have Syslog over TCP and Syslog > > over DTLS for > > Syslog working group. But, there will be several transport > > documents for the > > working group: > > 1, Syslog over UDP, already there and favorable for implementers > > 2, Syslog over TCP, what is the benefit? > > 3, Syslog over TLS > > 4, Syslog over DTLS, I reckon implementer would like it, > but does IESG > > satisfy to this transport? > > With so many transport, implementer will be puzzled. Which is > > recommended by > > the working group? The current ones are option 1 and 3. > > > > > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > Sent: Friday, June 16, 2006 4:13 PM > > > To: syslog@ietf.org > > > Subject: Re: [Syslog] stream transport > > > wasdraft-ietf-syslog-transport-tls-01.txt > > > > > > I think that this document has some way to go. It has > > > introduced, and woven together, both TLS and TCP transport, > > > which I think wrong. Ideally, I think that we should have > > > two separate documents, one dealing with TLS, the other with > > > TCP issues; given that both would be short, it is probably > > > sensible to have only the one, but I still see the need for > > > separation within the document. After all, DTLS exists: an > > > outsider could, should, think that syslog is UDP-based, DTLS > > > provides UDP security so DTLS is the obvious choice, what on > > > earth is this document talking about? We need a section on > > > DTLS (if only justifying why it is not for further > > > consideration). And, for me, that alone justifies teasing > > > out the TLS issues from the TCP issues; is FRAME-LEN needed > > > over DTLS?. > > > > > > That said, I do not think that this document adequately > > > covers the TCP issues, ones that have surfaced on the list before. > > > > > > TLSoTCP can deliver one syslog message, many syslog messages, > > > part of a syslog message or a combination thereof - it is in > > > the nature of a stream protocol. > > > This needs spelling out. > > > > > > A TCP connection takes time to set up, TLSoTCP longer. This > > > needs spelling out; if timely delivery is a concern, then the > > > connection should be established in advance. > > > > > > The section on TCP termination is too weak. If we are > > > recommending a timeout, then we should recommend a value, > > > even specifying that it should be configurable over a range. > > > And if we cannot agree on such values, I do not think we > > > should be specifying a timeout. > > > > > > TCP perforce introduces flow control. This will slow down > > > and rate limit messages; what is the impact of this on the > > > application? > > > > > > TCP failures can terminate the connection! Again, this has > > > an impact on the application with the time taken to become > > > aware that the connection has failed. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "David B Harrington" > > > To: > > > Sent: Tuesday, May 09, 2006 4:26 PM > > > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > > > > > > > Hi, > > > > > > A new revision of the syslog/TLS draft is available. > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > > > .txt > > > > > > We need reviewers. > > > Can we get > > > 1) a person to check the grammar? > > > 2) a person to check the syslog technical parts? > > > 3) a person to check compatibility with the other WG documents? > > > 4) a person to check the TLS technical parts? > > > > > > We also need general reviews of the document by multiple people. > > > > > > Thanks, > > > David Harrington > > > co-chair, Syslog WG > > > ietfdbh@comcast.net > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 21 14:45:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7hj-0000Dz-7S; Wed, 21 Jun 2006 14:45:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7hh-00006c-Mw for syslog@ietf.org; Wed, 21 Jun 2006 14:45:29 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7hg-0003n0-DN for syslog@ietf.org; Wed, 21 Jun 2006 14:45:29 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc11) with SMTP id <20060621184527m1100b59f2e>; Wed, 21 Jun 2006 18:45:27 +0000 From: "David Harrington" To: "'Chris Lonvick'" , "'Rainer Gerhards'" Subject: RE: [Syslog] IESG secure transport requirement can be quicklysolved... Date: Wed, 21 Jun 2006 14:44:15 -0400 Message-ID: <147101c69562$b2457d70$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaUcpJmDDSNpEjjSR6sDkho19gobQA6XFyg X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [speaking as co-chair] I also am willing to listen to discussion of alternative proposals. As mentioned in my contributor posting, I can see a number of alternatives to syslog/TLS that I think might be viable. It is important that we make progress and not just discuss the alternatives, ad infinitum, however. We need volunteers who are willing to put in the work to write viable internet-drafts and drive them to completion, or the discussions are largely useless. So, I will make these requests to help focus the discussions: 1) please indicate which secure transports you consider to be feasible, 2) please indicate which secure transports address which syslog threats (they're listed in syslog/tls), 3) please indicate which secure transport you volunteer to write a draft for, and 4) please indicate which secure transport you would commit to implement in your products (and do you have the decision-making authority to commit what gets implemented in shipping products?). Disclaimer: products do not need to be commercial products; they can be freely available implementations, such as open source libraries. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Tuesday, June 20, 2006 10:05 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] IESG secure transport requirement can > be quicklysolved... > > Hi Everyone, > > > On Tue, 20 Jun 2006, Rainer Gerhards wrote: > > > > I would appreciate if the chairs could try to reach consensus on my > > proposal. > > > > Comments are appreciated. > > Thanks, > > Rainer > > I'll apologize up front for not paricipating in some recent > dicussions. > I'm on a business trip and rather busy with the day job right now. > > I am willing to listen to a discussion of this proposal. As > Rainer says, > please provide some input and comments. > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 21 14:47:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7jT-0001v4-2l; Wed, 21 Jun 2006 14:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7jR-0001uz-KG for syslog@ietf.org; Wed, 21 Jun 2006 14:47:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7FC-0001G6-EH for syslog@ietf.org; Wed, 21 Jun 2006 14:16:02 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ft6z3-0000dV-81 for syslog@ietf.org; Wed, 21 Jun 2006 13:59:23 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc11) with SMTP id <20060621175919m1100b0i3ee>; Wed, 21 Jun 2006 17:59:20 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , Date: Wed, 21 Jun 2006 13:58:07 -0400 Message-ID: <147001c6955c$40c4d890$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA174976@grfint2.intern.adiscon.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaUb4P6Rv2ZkqYHRMe0gajYe6M8FgA5HFhg X-Spam-Score: -2.6 (--) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: Subject: [Syslog] Secure transport alternatives X-BeenThere: syslog@lists.ietf.org X-Mailman-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, [Posting as a contributor] I am involved in a number of NM and Security WGs, and I can make these observations: Running an NM protocol over SSH has been done in both netconf and ISMS. I suspect it would be fairly easy to adapt the netconf-over-SSH draft to work for syslog-over-SSH. I suspect it would take a week or so to write a syslog-over-SSH draft since most could be cut-and-paste from the netconf-over-SSH draft. I am the author of the ISMS drafts, and I adapted the netconf/SSH draft for ISMS purposes. Syslog and netconf seem to be closer in their requirements than syslog and ISMS. ISMS has this whole model of access control to deal with that is not part of the threat model for syslog or for netconf at this time. There is a parallel discussion of running syslog messages over netconf. As Rainer has pointed out to Phil, having a consistent terminology would be very helpful. I think having a consistent security solution would probably be helpful in that situation as well. I have concerns about 3195bis as the only alternative we consider, because I have not seen much interest in RFC3195 yet, nor has there been much expresseed interest in netconf over BEEP. Since there may be delay involved in this WG no matter what, would somebody be willing to volunteer to write a syslog-over-SSH draft, so the WG can compare the three approaches? There are other possibilities as well (and I am being serious here, not "let's make this absurd by proposing a whole slew of alteratives documents"). 1) Tom mentioned DTLS, which might be a viable alternative given syslog's UDP roots. Tom would you, or somebody else, be willing to write a proposal for syslog/DTLS? 2) Andy Bierman observed that if syslog messages are going to be transported over netconf, then why not simply use syslog/netconf and let netconf deal with the security issues. That could be an alternative proposal. Is anybody willing to write a draft proposing that as a syslog secure transport solution? My $.02 as a contributor, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Tuesday, June 20, 2006 9:44 AM > To: syslog@ietf.org > Subject: [Syslog] IESG secure transport requirement can be > quickly solved... > > Hi all, > > I propose to update RFC 3195 in the spirit of syslog-protocol > to satisfy > the IESG secure transport requirement (I will call this > derivative work > RFC3195bis below). I sincerely believe that this option would > enable us > to submit syslog-protocol, -transport-UDP and RFC3195bis within a few > weeks. > > My reasoning for this proposal is as follows: > > We all know that 3195 has limited acceptance in the community and very > few implementations. However, it satisfies all IESG criteria > we have in > our charter. Also, it *is* something that can be used in practice and > implementing it becomes easier as support libraries become visible. I > know it is not an optimal choice. On the other hand, we have > syslog-transport-tls, which has been encrumbered by a patent claim. As > it looks, this will need months to solve. RFC3195bis can not be taken > hostage by any patent claims, because there is well-defined > prior art in > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > mission and finsh work that is in the queue for many years > now. I think > this is urgently needed. We might even put the netconf WG with their > syslog gateway on hold (because syslog-protocol can not be published > without resolving the secure transport). Or netconf might > choose to drop > syslog-protocol in order to publish. > > And the good news is that 3195bis can definitely very quickly > be done. I > am saying this on the assumption that we do not revisit the basics of > 3195 but just adopt it to syslog-protocol. I've gone through > 3195 today > and the changes are absolutely minimal: > > Section 2: > Most of it simply needs to be removed because the entity roles are > defined in syslog-protocol. > > Section 3: > - the message samples must be upgraded to -protocol-format > - syslog-framing in section 3.3 must be changed (could be > octet-counting > or disallow of multiple messages per ANS, what I recommend) > > Section 4: > 4.4.2 > - needs to be updated with the new HEADER fields and STRUCTURED-DATA > - some work on "deviceFQDN" and "deviceIP" needed > - some transformation rules (page 15) need to be removed > - handling of invalid message formatting must be removed (no longer a > concern) > - samples must be adjusted > > 4.4.3 > - sample on page 24 (top) must be checked and/or adjusted > > Section 7: > - DTD needs to be adjusted > > Section 9: > - new URIs for 3195bis (also in some other places) > [we can reuse well-known port 601 for -protocol] > > Overall > References to 3164 must be changed to -syslog-protocol. This > seems quite > trivial, because the references are easy to spot and do not touch any > substance (except outlined above). > > Other than these minor things, there are *NO* other changes necessary. > I'd expect that an initial version of 3195bis can be created within a > single working day. Add some quick review and a very limited number of > edits to change discovered nits - and we have something to publish by > summer. > > I find this extremely tempting. It breaks the deadlock > situation we are > currently in. Especially as we have planned to do 3195bis some time > later anyhow. I don't know if the authors of 3195 would > volunteer to do > the edit. But I hope so. > > I would appreciate if the chairs could try to reach consensus on my > proposal. > > Comments are appreciated. > Thanks, > Rainer > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 21 22:48:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFFD-0003G7-0S; Wed, 21 Jun 2006 22:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFFB-0003G2-Pj for syslog@ietf.org; Wed, 21 Jun 2006 22:48:33 -0400 Received: from dsl-202-45-110-141-static.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtFF9-0004w4-UA for syslog@ietf.org; Wed, 21 Jun 2006 22:48:33 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k5M2lram023212; Thu, 22 Jun 2006 12:47:53 +1000 (EST) From: Darren Reed Message-Id: <200606220247.k5M2leg2012997@firewall.reed.wattle.id.au> Subject: Re: [Syslog] IESG secure transport requirement can be quicklysolved... In-Reply-To: <147101c69562$b2457d70$0400a8c0@china.huawei.com> To: David Harrington Date: Thu, 22 Jun 2006 12:47:40 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > Hi, > > [speaking as co-chair] Please resign as co-chair. Your company is involed with IPR action regarding the work of this group and until your company gives up this path, we cannot accept any direction or input from you as co-chair. I ask all those in this working group to ignore any email from David Harrington in his role as co-chair as it compromises the abililty of this working group to produce free, open standards. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 21 22:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFGk-0005iS-HJ; Wed, 21 Jun 2006 22:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFGi-0005iH-QD for syslog@ietf.org; Wed, 21 Jun 2006 22:50:08 -0400 Received: from dsl-202-45-110-141-static.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtFGg-0005DM-T6 for syslog@ietf.org; Wed, 21 Jun 2006 22:50:08 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k5M2o1uh020476; Thu, 22 Jun 2006 12:50:01 +1000 (EST) From: Darren Reed Message-Id: <200606220249.k5M2niJ7004056@firewall.reed.wattle.id.au> Subject: Re: [Syslog] IESG secure transport requirement can be quicklysolved... In-Reply-To: <146801c69554$ff4aee10$0400a8c0@china.huawei.com> To: David Harrington Date: Thu, 22 Jun 2006 12:49:44 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > Hi, > > As a co-chair looking for a way forward, I was considering asking for .. Please resign as co-chair. Your company is involed with IPR action regarding the work of this group and until your company gives up this path, we cannot accept any direction or input from you as co-chair. I ask all those in this working group to ignore any email from David Harrington in his role as co-chair as it compromises the abililty of this working group to produce free, open standards. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 01:51:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtI5t-0007GC-TW; Thu, 22 Jun 2006 01:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtI5r-0007Fz-S5 for syslog@ietf.org; Thu, 22 Jun 2006 01:51:07 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtI5m-00032n-IG for syslog@ietf.org; Thu, 22 Jun 2006 01:51:07 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1800G2HZL6N4@szxga02-in.huawei.com> for syslog@ietf.org; Thu, 22 Jun 2006 14:05:31 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1800688ZL6P3@szxga02-in.huawei.com> for syslog@ietf.org; Thu, 22 Jun 2006 14:05:30 +0800 (CST) Received: from m19684 ([10.110.114.232]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1800MABYX1C4@szxml03-in.huawei.com> for syslog@ietf.org; Thu, 22 Jun 2006 13:51:05 +0800 (CST) Date: Thu, 22 Jun 2006 13:49:24 +0800 From: Miao Fuyou Subject: RE: [Syslog] Secure transport alternatives In-reply-to: <147001c6955c$40c4d890$0400a8c0@china.huawei.com> To: 'David Harrington' , 'Rainer Gerhards' , syslog@ietf.org Message-id: <022901c695bf$9e3121b0$e8726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaUb4P6Rv2ZkqYHRMe0gajYe6M8FgA5HFhgABk3X2A= X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, IMO, most current security protocols(TLS, DTLS, SSH, IPsec) provide similiar security service for application, such as confidentiality, integrity, anti-replay and peer identity authentication. In the same time, most of the applications share similiar security threats, such as hijacking, MITM, falsification, eveasdropping etc. So, it may does make much sense to invest too much effort on evaluating/matching security threats and service. In the same time, most current security protocols come from security mechanisms specific to some applications. For example, SSL was designed to secure HTTP, SSH is an application protocol for interactive shell command. They are not real "general" security mechanisms(except IPsec, but it is not application-friendly). So, IMHO the primary criteria for selection is: is it convenient for the application to invoke the security service provided by the security protocol? Taking convenience in mind: the order may be: DTLS -> TLS -> SSH -> BEEP(?) -> IPsec >From an implementer's perspective, I think DTLS costs the least effort to implement, TLS second. I have not much idea on how much SSH and BEEP take, but I believe it cost more than DTLS/TLS. There is few RFC3195 implementation, it sounds bad to revive an market-abandoned solution to just satisfy IESG. IPsec? It costs the specifcation and program developer nothing, but it costs too much to provision, never a good solution for Syslog. My 1 cent! Miao > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, June 22, 2006 1:58 AM > To: 'Rainer Gerhards'; syslog@ietf.org > Subject: [Syslog] Secure transport alternatives > > Hi, > > [Posting as a contributor] > > I am involved in a number of NM and Security WGs, and I can make these > observations: > > Running an NM protocol over SSH has been done in both netconf > and ISMS. I suspect it would be fairly easy to adapt the > netconf-over-SSH draft to work for syslog-over-SSH. I suspect > it would take a week or so to write a syslog-over-SSH draft > since most could be cut-and-paste from the netconf-over-SSH draft. > > I am the author of the ISMS drafts, and I adapted the > netconf/SSH draft for ISMS purposes. Syslog and netconf seem > to be closer in their requirements than syslog and ISMS. ISMS > has this whole model of access control to deal with that is > not part of the threat model for syslog or for netconf at this time. > > There is a parallel discussion of running syslog messages > over netconf. As Rainer has pointed out to Phil, having a > consistent terminology would be very helpful. I think having > a consistent security solution would probably be helpful in > that situation as well. > > I have concerns about 3195bis as the only alternative we > consider, because I have not seen much interest in RFC3195 > yet, nor has there been much expresseed interest in netconf over BEEP. > > Since there may be delay involved in this WG no matter what, > would somebody be willing to volunteer to write a > syslog-over-SSH draft, so the WG can compare the three approaches? > > There are other possibilities as well (and I am being serious > here, not "let's make this absurd by proposing a whole slew > of alteratives documents"). > 1) Tom mentioned DTLS, which might be a viable alternative > given syslog's UDP roots. Tom would you, or somebody else, be > willing to write a proposal for syslog/DTLS? > 2) Andy Bierman observed that if syslog messages are going to > be transported over netconf, then why not simply use > syslog/netconf and let netconf deal with the security issues. > That could be an alternative proposal. Is anybody willing to > write a draft proposing that as a syslog secure transport solution? > > My $.02 as a contributor, > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Tuesday, June 20, 2006 9:44 AM > > To: syslog@ietf.org > > Subject: [Syslog] IESG secure transport requirement can be > > quickly solved... > > > > Hi all, > > > > I propose to update RFC 3195 in the spirit of syslog-protocol > > to satisfy > > the IESG secure transport requirement (I will call this > > derivative work > > RFC3195bis below). I sincerely believe that this option would > > enable us > > to submit syslog-protocol, -transport-UDP and RFC3195bis within a > few > > weeks. > > > > My reasoning for this proposal is as follows: > > > > We all know that 3195 has limited acceptance in the community and > very > > few implementations. However, it satisfies all IESG criteria > > we have in > > our charter. Also, it *is* something that can be used in practice > and > > implementing it becomes easier as support libraries become visible. > I > > know it is not an optimal choice. On the other hand, we have > > syslog-transport-tls, which has been encrumbered by a patent claim. > As > > it looks, this will need months to solve. RFC3195bis can not be > taken > > hostage by any patent claims, because there is well-defined > > prior art in > > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > > mission and finsh work that is in the queue for many years > > now. I think > > this is urgently needed. We might even put the netconf WG with their > > syslog gateway on hold (because syslog-protocol can not be published > > without resolving the secure transport). Or netconf might > > choose to drop > > syslog-protocol in order to publish. > > > > And the good news is that 3195bis can definitely very quickly > > be done. I > > am saying this on the assumption that we do not revisit the basics > of > > 3195 but just adopt it to syslog-protocol. I've gone through > > 3195 today > > and the changes are absolutely minimal: > > > > Section 2: > > Most of it simply needs to be removed because the entity roles are > > defined in syslog-protocol. > > > > Section 3: > > - the message samples must be upgraded to -protocol-format > > - syslog-framing in section 3.3 must be changed (could be > > octet-counting > > or disallow of multiple messages per ANS, what I recommend) > > > > Section 4: > > 4.4.2 > > - needs to be updated with the new HEADER fields and > STRUCTURED-DATA > > - some work on "deviceFQDN" and "deviceIP" needed > > - some transformation rules (page 15) need to be removed > > - handling of invalid message formatting must be removed (no longer > a > > concern) > > - samples must be adjusted > > > > 4.4.3 > > - sample on page 24 (top) must be checked and/or adjusted > > > > Section 7: > > - DTD needs to be adjusted > > > > Section 9: > > - new URIs for 3195bis (also in some other places) > > [we can reuse well-known port 601 for -protocol] > > > > Overall > > References to 3164 must be changed to -syslog-protocol. This > > seems quite > > trivial, because the references are easy to spot and do not touch > any > > substance (except outlined above). > > > > Other than these minor things, there are *NO* other changes > necessary. > > I'd expect that an initial version of 3195bis can be created within > a > > single working day. Add some quick review and a very limited number > of > > edits to change discovered nits - and we have something to publish > by > > summer. > > > > I find this extremely tempting. It breaks the deadlock > > situation we are > > currently in. Especially as we have planned to do 3195bis some time > > later anyhow. I don't know if the authors of 3195 would > > volunteer to do > > the edit. But I hope so. > > > > I would appreciate if the chairs could try to reach consensus on my > > proposal. > > > > Comments are appreciated. > > Thanks, > > Rainer > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 03:43:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJqf-0001Ip-8c; Thu, 22 Jun 2006 03:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJqd-0001Ik-Uj for syslog@ietf.org; Thu, 22 Jun 2006 03:43:31 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtJqc-0000Sm-A7 for syslog@ietf.org; Thu, 22 Jun 2006 03:43:31 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 0BD0727C065; Thu, 22 Jun 2006 09:40:03 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30659-09; Thu, 22 Jun 2006 09:40:02 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id C030127C061; Thu, 22 Jun 2006 09:40:02 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 09:43:27 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] IESG secure transport requirement can be quicklysolved... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2006 09:43:22 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749A9@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <200606220247.k5M2leg2012997@firewall.reed.wattle.id.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] IESG secure transport requirement can be quicklysolved... Thread-Index: AcaVplpV6ZZj52kCQoW9zigLt5LW/AAJ35Eg From: "Rainer Gerhards" To: "Darren Reed" , "David Harrington" X-OriginalArrivalTime: 22 Jun 2006 07:43:27.0839 (UTC) FILETIME=[8CB9BEF0:01C695CF] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Darren, I think we have been through this. I see your point and I agree that the IPR action is, well, unfortunate ;) [I had some stronger words in previous posts and still fully support them] I also understand and to some extent support the position that there is some personal liability of a high-rank person with the companie's actions. HOWEVER, I do not find it productive to try to force David out of this. Yes, there is a problem. We are aware of it. I think we can handle it. But David's advise is very well thought-out, he has lots of IETF experience and he is still willing to help. I also can only spekulate on his personal involvement in the IPR issue. I do not know what he has advised. Also, I think we *need* his help if we intend to reach our goal. I still very much welcome him in the co-chair position. If for all upcoming next drafts similar IPR issues from Huawei arise, I would very probably be fully on your side. So far, I consider it as a single case and hope that the lessions are already learned. Actually, I am not ready to sacrifice a syslog standard for the sake of penalizing Huawei. That wouldn't help anything ... and it wouldn't even be smart ;) Huawei (and the probably just unfortunate I-D editors) is already penalized by the growind dis-acceptance of the TLS draft. I personally would also object any further I-D author from Huawei right at this stage. This is not because I distrust the author but Huawei's legal department. We have put so much work into this syslog effort, we shouldn't give up just because of a single incident. And IMHO we give up on it if we try to fight out this issue right at that time. I suggest we cool down a little and let things evolve. That will also provide better picture of who does what. Just my 2cts, but I hope I find support for it. Rainer > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Thursday, June 22, 2006 4:48 AM > To: David Harrington > Cc: 'Chris Lonvick'; Rainer Gerhards; syslog@ietf.org > Subject: Re: [Syslog] IESG secure transport requirement can=20 > be quicklysolved... >=20 > > Hi, > >=20 > > [speaking as co-chair] >=20 > Please resign as co-chair. >=20 > Your company is involed with IPR action regarding the work of this > group and until your company gives up this path, we cannot accept > any direction or input from you as co-chair. >=20 > I ask all those in this working group to ignore any email from David > Harrington in his role as co-chair as it compromises the abililty > of this working group to produce free, open standards. >=20 > Darren=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 03:59:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtK5W-0007cY-Sk; Thu, 22 Jun 2006 03:58:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtK5V-0007cT-N6 for syslog@ietf.org; Thu, 22 Jun 2006 03:58:53 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtK5S-0001eM-Ro for syslog@ietf.org; Thu, 22 Jun 2006 03:58:53 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 7E5F827C066; Thu, 22 Jun 2006 09:55:24 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00542-05; Thu, 22 Jun 2006 09:55:24 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 0B1A627C061; Thu, 22 Jun 2006 09:55:23 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 09:58:44 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Secure transport alternatives MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2006 09:58:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749AA@grfint2.intern.adiscon.com> In-Reply-To: <022901c695bf$9e3121b0$e8726e0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Secure transport alternatives Thread-Index: AcaUb4P6Rv2ZkqYHRMe0gajYe6M8FgA5HFhgABk3X2AABb7XIA== From: "Rainer Gerhards" To: "Miao Fuyou" , "David Harrington" , X-OriginalArrivalTime: 22 Jun 2006 07:58:44.0184 (UTC) FILETIME=[AEE8E580:01C695D1] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 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 Miao, technically, I agree with you. HOWEVER, I need to point out that your company is the root cause of the problem. The IPR rights claimed on your transport-tls document have taken it hostage. Even though the licensing terms seem reasonable (which needs to be prooven in undisclosed detail), there honestly is nothing novel in the draft. Your legal department is not even telling us which section is claimed to have been invented by Huawei. The simplest and most productive way to solve the current issue is make your legal department drop the patent claim. My understanding is that it can be easily challenged (for those with big legal departments...) so it will probably be without substance, too. You should also talk to your legal department and superiors that Huawei's peformance in this WG is costing Huawei a lot of its goodwill in the community and probably even in the end-user space. For example, the largest German IT-Site (Heise press[1]) has carried a story about Huawei's move and Huawei has not made a good picture in the user feedback. I also promise that I personally will try to get more press coverage of this move.=20 It is one thing to secure one's intellectual property. It is another thing to be a patent troll. And it is yet another thing to be a patent troll who steals other people's work. I have to admit that I consider Huawei (as far as the syslog WG is concerned) to be part of the third camp. Get *that IPR issue* solved and the technical issue is solved, too. In the mean time, we try to provide an open standard. RFC 3195bis seems to be the most appropriate choice here, because it can't be taken hostage by another abusive patent claim as it bases on well-defined prior art (RFC 3195). Far more important standardization efforts have been brought to a hold by IPR claims (think: SPAM). Claiming IPR where there are none is of no utility. Huawei needs to learn this. [1] http://www.heise.de/newsticker/meldung/74342 (in German) Rainer=20 > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Thursday, June 22, 2006 7:49 AM > To: 'David Harrington'; Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Secure transport alternatives >=20 >=20 > Hi,=20 >=20 > IMO, most current security protocols(TLS, DTLS, SSH, IPsec)=20 > provide similiar > security service for application, such as confidentiality, integrity, > anti-replay and peer identity authentication. In the same=20 > time, most of the > applications share similiar security threats, such as hijacking, MITM, > falsification, eveasdropping etc. So, it may does make much=20 > sense to invest > too much effort on evaluating/matching security threats and=20 > service. In the > same time, most current security protocols come from security=20 > mechanisms > specific to some applications. For example, SSL was designed=20 > to secure HTTP, > SSH is an application protocol for interactive shell command.=20 > They are not > real "general" security mechanisms(except IPsec, but it is not > application-friendly). So, IMHO the primary criteria for=20 > selection is: is it > convenient for the application to invoke the security service=20 > provided by > the security protocol?=20 >=20 > Taking convenience in mind: the order may be: DTLS -> TLS ->=20 > SSH -> BEEP(?) > -> IPsec >=20 > From an implementer's perspective, I think DTLS costs the=20 > least effort to > implement, TLS second. I have not much idea on how much SSH=20 > and BEEP take, > but I believe it cost more than DTLS/TLS. There is few RFC3195 > implementation, it sounds bad to revive an market-abandoned=20 > solution to just > satisfy IESG. IPsec? It costs the specifcation and program developer > nothing, but it costs too much to provision, never a good solution for > Syslog. >=20 > My 1 cent! >=20 > Miao > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > > Sent: Thursday, June 22, 2006 1:58 AM > > To: 'Rainer Gerhards'; syslog@ietf.org > > Subject: [Syslog] Secure transport alternatives > >=20 > > Hi, > >=20 > > [Posting as a contributor] > >=20 > > I am involved in a number of NM and Security WGs, and I can=20 > make these > > observations: > >=20 > > Running an NM protocol over SSH has been done in both netconf=20 > > and ISMS. I suspect it would be fairly easy to adapt the=20 > > netconf-over-SSH draft to work for syslog-over-SSH. I suspect=20 > > it would take a week or so to write a syslog-over-SSH draft=20 > > since most could be cut-and-paste from the netconf-over-SSH draft.=20 > >=20 > > I am the author of the ISMS drafts, and I adapted the=20 > > netconf/SSH draft for ISMS purposes. Syslog and netconf seem=20 > > to be closer in their requirements than syslog and ISMS. ISMS=20 > > has this whole model of access control to deal with that is=20 > > not part of the threat model for syslog or for netconf at=20 > this time.=20 > >=20 > > There is a parallel discussion of running syslog messages=20 > > over netconf. As Rainer has pointed out to Phil, having a=20 > > consistent terminology would be very helpful. I think having=20 > > a consistent security solution would probably be helpful in=20 > > that situation as well. > >=20 > > I have concerns about 3195bis as the only alternative we=20 > > consider, because I have not seen much interest in RFC3195=20 > > yet, nor has there been much expresseed interest in netconf=20 > over BEEP. > >=20 > > Since there may be delay involved in this WG no matter what,=20 > > would somebody be willing to volunteer to write a=20 > > syslog-over-SSH draft, so the WG can compare the three approaches?=20 > >=20 > > There are other possibilities as well (and I am being serious=20 > > here, not "let's make this absurd by proposing a whole slew=20 > > of alteratives documents"). > > 1) Tom mentioned DTLS, which might be a viable alternative=20 > > given syslog's UDP roots. Tom would you, or somebody else, be=20 > > willing to write a proposal for syslog/DTLS? > > 2) Andy Bierman observed that if syslog messages are going to=20 > > be transported over netconf, then why not simply use=20 > > syslog/netconf and let netconf deal with the security issues.=20 > > That could be an alternative proposal. Is anybody willing to=20 > > write a draft proposing that as a syslog secure transport solution? > >=20 > > My $.02 as a contributor, > >=20 > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > =20 > >=20 > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > > Sent: Tuesday, June 20, 2006 9:44 AM > > > To: syslog@ietf.org > > > Subject: [Syslog] IESG secure transport requirement can be=20 > > > quickly solved... > > >=20 > > > Hi all, > > >=20 > > > I propose to update RFC 3195 in the spirit of syslog-protocol=20 > > > to satisfy > > > the IESG secure transport requirement (I will call this=20 > > > derivative work > > > RFC3195bis below). I sincerely believe that this option would=20 > > > enable us > > > to submit syslog-protocol, -transport-UDP and RFC3195bis within a > > few > > > weeks.=20 > > >=20 > > > My reasoning for this proposal is as follows: > > >=20 > > > We all know that 3195 has limited acceptance in the community and > > very > > > few implementations. However, it satisfies all IESG criteria=20 > > > we have in > > > our charter. Also, it *is* something that can be used in practice > > and > > > implementing it becomes easier as support libraries=20 > become visible. > > I > > > know it is not an optimal choice. On the other hand, we have > > > syslog-transport-tls, which has been encrumbered by a=20 > patent claim. > > As > > > it looks, this will need months to solve. RFC3195bis can not be > > taken > > > hostage by any patent claims, because there is well-defined=20 > > > prior art in > > > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > > > mission and finsh work that is in the queue for many years=20 > > > now. I think > > > this is urgently needed. We might even put the netconf WG=20 > with their > > > syslog gateway on hold (because syslog-protocol can not=20 > be published > > > without resolving the secure transport). Or netconf might=20 > > > choose to drop > > > syslog-protocol in order to publish. > > >=20 > > > And the good news is that 3195bis can definitely very quickly=20 > > > be done. I > > > am saying this on the assumption that we do not revisit the basics > > of > > > 3195 but just adopt it to syslog-protocol. I've gone through=20 > > > 3195 today > > > and the changes are absolutely minimal: > > >=20 > > > Section 2: > > > Most of it simply needs to be removed because the entity roles are > > > defined in syslog-protocol. > > >=20 > > > Section 3: > > > - the message samples must be upgraded to -protocol-format > > > - syslog-framing in section 3.3 must be changed (could be=20 > > > octet-counting > > > or disallow of multiple messages per ANS, what I recommend) > > >=20 > > > Section 4: > > > 4.4.2=20 > > > - needs to be updated with the new HEADER fields and > > STRUCTURED-DATA=20 > > > - some work on "deviceFQDN" and "deviceIP" needed > > > - some transformation rules (page 15) need to be removed > > > - handling of invalid message formatting must be removed=20 > (no longer > > a > > > concern) > > > - samples must be adjusted > > >=20 > > > 4.4.3 > > > - sample on page 24 (top) must be checked and/or adjusted > > >=20 > > > Section 7: > > > - DTD needs to be adjusted > > >=20 > > > Section 9: > > > - new URIs for 3195bis (also in some other places) > > > [we can reuse well-known port 601 for -protocol] > > >=20 > > > Overall > > > References to 3164 must be changed to -syslog-protocol. This=20 > > > seems quite > > > trivial, because the references are easy to spot and do not touch > > any > > > substance (except outlined above). > > >=20 > > > Other than these minor things, there are *NO* other changes > > necessary. > > > I'd expect that an initial version of 3195bis can be=20 > created within > > a > > > single working day. Add some quick review and a very=20 > limited number > > of > > > edits to change discovered nits - and we have something to publish > > by > > > summer. > > >=20 > > > I find this extremely tempting. It breaks the deadlock=20 > > > situation we are > > > currently in. Especially as we have planned to do 3195bis=20 > some time > > > later anyhow. I don't know if the authors of 3195 would=20 > > > volunteer to do > > > the edit. But I hope so. > > >=20 > > > I would appreciate if the chairs could try to reach=20 > consensus on my > > > proposal. > > >=20 > > > Comments are appreciated. > > > Thanks, > > > Rainer > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 04:41:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtKkS-0006ak-8z; Thu, 22 Jun 2006 04:41:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtKkQ-0006af-DB for syslog@ietf.org; Thu, 22 Jun 2006 04:41:10 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtKkM-0005IG-P1 for syslog@ietf.org; Thu, 22 Jun 2006 04:41:10 -0400 Received: from pc6 (1Cust25.tnt102.lnd4.gbr.da.uu.net [213.116.52.25]) by astro.systems.pipex.net (Postfix) with SMTP id D00F6E00012C; Thu, 22 Jun 2006 09:41:02 +0100 (BST) Message-ID: <02bb01c695ce$aa5a8b20$0601a8c0@pc6> From: "Tom Petch" To: "David Harrington" , References: <147001c6955c$40c4d890$0400a8c0@china.huawei.com> Subject: Re: [Syslog] Secure transport alternatives Date: Thu, 22 Jun 2006 09:35:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 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 David You will know, and the archives show, that I spent much time in 2005 arguing for SSH as the transport for isms and, happily, the WG agreed. The archives also show that my efforts in syslog were to no avail and the WG overwhelmingly chose TLS. The argument in favour was the marketing one - syslogoTLS is already out there, just feel all those 220,000 hits in Google. And it was on that basis, that WG member's would commit to producing such products, that the WG was rechartered, as opposed to being wound up. (I now see that I should have threatened the syslog WG with an IPR claim on TLS and then we would not be having this discussion :-) But, in all seriousness, changing from TLS to anything is a charter change that I think needs the approval of the IESG, and should require commitment, similar to that given at the turn of the year, to produce conformant products. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'Rainer Gerhards'" ; Sent: Wednesday, June 21, 2006 7:58 PM Subject: [Syslog] Secure transport alternatives > Hi, > > [Posting as a contributor] > > I am involved in a number of NM and Security WGs, and I can make these > observations: > > Running an NM protocol over SSH has been done in both netconf and > ISMS. I suspect it would be fairly easy to adapt the netconf-over-SSH > draft to work for syslog-over-SSH. I suspect it would take a week or > so to write a syslog-over-SSH draft since most could be cut-and-paste > from the netconf-over-SSH draft. > > I am the author of the ISMS drafts, and I adapted the netconf/SSH > draft for ISMS purposes. Syslog and netconf seem to be closer in their > requirements than syslog and ISMS. ISMS has this whole model of access > control to deal with that is not part of the threat model for syslog > or for netconf at this time. > > There is a parallel discussion of running syslog messages over > netconf. As Rainer has pointed out to Phil, having a consistent > terminology would be very helpful. I think having a consistent > security solution would probably be helpful in that situation as well. > > I have concerns about 3195bis as the only alternative we consider, > because I have not seen much interest in RFC3195 yet, nor has there > been much expresseed interest in netconf over BEEP. > > Since there may be delay involved in this WG no matter what, would > somebody be willing to volunteer to write a syslog-over-SSH draft, so > the WG can compare the three approaches? > > There are other possibilities as well (and I am being serious here, > not "let's make this absurd by proposing a whole slew of alteratives > documents"). > 1) Tom mentioned DTLS, which might be a viable alternative given > syslog's UDP roots. Tom would you, or somebody else, be willing to > write a proposal for syslog/DTLS? > 2) Andy Bierman observed that if syslog messages are going to be > transported over netconf, then why not simply use syslog/netconf and > let netconf deal with the security issues. That could be an > alternative proposal. Is anybody willing to write a draft proposing > that as a syslog secure transport solution? > > My $.02 as a contributor, > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Tuesday, June 20, 2006 9:44 AM > > To: syslog@ietf.org > > Subject: [Syslog] IESG secure transport requirement can be > > quickly solved... > > > > Hi all, > > > > I propose to update RFC 3195 in the spirit of syslog-protocol > > to satisfy > > the IESG secure transport requirement (I will call this > > derivative work > > RFC3195bis below). I sincerely believe that this option would > > enable us > > to submit syslog-protocol, -transport-UDP and RFC3195bis within a > few > > weeks. > > > > My reasoning for this proposal is as follows: > > > > We all know that 3195 has limited acceptance in the community and > very > > few implementations. However, it satisfies all IESG criteria > > we have in > > our charter. Also, it *is* something that can be used in practice > and > > implementing it becomes easier as support libraries become visible. > I > > know it is not an optimal choice. On the other hand, we have > > syslog-transport-tls, which has been encrumbered by a patent claim. > As > > it looks, this will need months to solve. RFC3195bis can not be > taken > > hostage by any patent claims, because there is well-defined > > prior art in > > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > > mission and finsh work that is in the queue for many years > > now. I think > > this is urgently needed. We might even put the netconf WG with their > > syslog gateway on hold (because syslog-protocol can not be published > > without resolving the secure transport). Or netconf might > > choose to drop > > syslog-protocol in order to publish. > > > > And the good news is that 3195bis can definitely very quickly > > be done. I > > am saying this on the assumption that we do not revisit the basics > of > > 3195 but just adopt it to syslog-protocol. I've gone through > > 3195 today > > and the changes are absolutely minimal: > > > > Section 2: > > Most of it simply needs to be removed because the entity roles are > > defined in syslog-protocol. > > > > Section 3: > > - the message samples must be upgraded to -protocol-format > > - syslog-framing in section 3.3 must be changed (could be > > octet-counting > > or disallow of multiple messages per ANS, what I recommend) > > > > Section 4: > > 4.4.2 > > - needs to be updated with the new HEADER fields and > STRUCTURED-DATA > > - some work on "deviceFQDN" and "deviceIP" needed > > - some transformation rules (page 15) need to be removed > > - handling of invalid message formatting must be removed (no longer > a > > concern) > > - samples must be adjusted > > > > 4.4.3 > > - sample on page 24 (top) must be checked and/or adjusted > > > > Section 7: > > - DTD needs to be adjusted > > > > Section 9: > > - new URIs for 3195bis (also in some other places) > > [we can reuse well-known port 601 for -protocol] > > > > Overall > > References to 3164 must be changed to -syslog-protocol. This > > seems quite > > trivial, because the references are easy to spot and do not touch > any > > substance (except outlined above). > > > > Other than these minor things, there are *NO* other changes > necessary. > > I'd expect that an initial version of 3195bis can be created within > a > > single working day. Add some quick review and a very limited number > of > > edits to change discovered nits - and we have something to publish > by > > summer. > > > > I find this extremely tempting. It breaks the deadlock > > situation we are > > currently in. Especially as we have planned to do 3195bis some time > > later anyhow. I don't know if the authors of 3195 would > > volunteer to do > > the edit. But I hope so. > > > > I would appreciate if the chairs could try to reach consensus on my > > proposal. > > > > Comments are appreciated. > > Thanks, > > Rainer > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 04:48:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtKrT-0003CB-85; Thu, 22 Jun 2006 04:48:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtKrS-0003Bi-32 for syslog@ietf.org; Thu, 22 Jun 2006 04:48:26 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtKrR-0005dS-DP for syslog@ietf.org; Thu, 22 Jun 2006 04:48:26 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3C3EE27C065; Thu, 22 Jun 2006 10:44:55 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01776-04; Thu, 22 Jun 2006 10:44:55 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id BDA7327C061; Thu, 22 Jun 2006 10:44:54 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 10:48:16 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Secure transport alternatives MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2006 10:48:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749B2@grfint2.intern.adiscon.com> In-Reply-To: <02bb01c695ce$aa5a8b20$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Secure transport alternatives Thread-Index: AcaV16/DG7Z1XDEURSijSjAtNiWsiwAAFNGQ From: "Rainer Gerhards" To: "Tom Petch" , "David Harrington" , X-OriginalArrivalTime: 22 Jun 2006 08:48:16.0201 (UTC) FILETIME=[9A5EB390:01C695D8] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Tom, > But, in all seriousness, changing from TLS to anything is a=20 > charter change that > I think needs the approval of the IESG, and should require=20 > commitment, similar > to that given at the turn of the year, to produce conformant products. I do not agree here. We have deliberately not used the term "TLS" in the charter. The relevant excerpts are: ### The threats that this WG will primarily address are modification, disclosure, and masquerading. A secondary threat is message stream modification. Threats that will not be addressed by this WG are DoS and traffic analysis. The primary attacks may be thwarted by a secure transport. However, it must be remembered that a great deal of the success of syslog has been attributed to its ease of implementation and relatively low maintenance level. The Working Group will consider those factors, as well as current implementations, when deciding upon a secure transport. ### ### - A document will be produced that requires a secure transport for the delivery of syslog messages. ### As far as I remember (not looked up the archive yet), we did this intentionally so that we could change transports if need arises. At least for now, I think this need has arisen. The really bad thing about the IPR claim is that we do not even know what actually has been claimed. But I do not intend to invest any of my work into something that somebody else claims exclusive rights on. So -tls is a dead end for me as long as the claim is not dropped. I foresee similar harsh reaction at least of the open source commuity (*the* major driving factor behind syslog implementation) when we standardize something encrumbered by a patent. Rainer >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "David Harrington" > To: "'Rainer Gerhards'" ; > Sent: Wednesday, June 21, 2006 7:58 PM > Subject: [Syslog] Secure transport alternatives >=20 >=20 > > Hi, > > > > [Posting as a contributor] > > > > I am involved in a number of NM and Security WGs, and I can=20 > make these > > observations: > > > > Running an NM protocol over SSH has been done in both netconf and > > ISMS. I suspect it would be fairly easy to adapt the=20 > netconf-over-SSH > > draft to work for syslog-over-SSH. I suspect it would take a week or > > so to write a syslog-over-SSH draft since most could be=20 > cut-and-paste > > from the netconf-over-SSH draft. > > > > I am the author of the ISMS drafts, and I adapted the netconf/SSH > > draft for ISMS purposes. Syslog and netconf seem to be=20 > closer in their > > requirements than syslog and ISMS. ISMS has this whole=20 > model of access > > control to deal with that is not part of the threat model for syslog > > or for netconf at this time. > > > > There is a parallel discussion of running syslog messages over > > netconf. As Rainer has pointed out to Phil, having a consistent > > terminology would be very helpful. I think having a consistent > > security solution would probably be helpful in that=20 > situation as well. > > > > I have concerns about 3195bis as the only alternative we consider, > > because I have not seen much interest in RFC3195 yet, nor has there > > been much expresseed interest in netconf over BEEP. > > > > Since there may be delay involved in this WG no matter what, would > > somebody be willing to volunteer to write a syslog-over-SSH=20 > draft, so > > the WG can compare the three approaches? > > > > There are other possibilities as well (and I am being serious here, > > not "let's make this absurd by proposing a whole slew of alteratives > > documents"). > > 1) Tom mentioned DTLS, which might be a viable alternative given > > syslog's UDP roots. Tom would you, or somebody else, be willing to > > write a proposal for syslog/DTLS? > > 2) Andy Bierman observed that if syslog messages are going to be > > transported over netconf, then why not simply use syslog/netconf and > > let netconf deal with the security issues. That could be an > > alternative proposal. Is anybody willing to write a draft proposing > > that as a syslog secure transport solution? > > > > My $.02 as a contributor, > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Tuesday, June 20, 2006 9:44 AM > > > To: syslog@ietf.org > > > Subject: [Syslog] IESG secure transport requirement can be > > > quickly solved... > > > > > > Hi all, > > > > > > I propose to update RFC 3195 in the spirit of syslog-protocol > > > to satisfy > > > the IESG secure transport requirement (I will call this > > > derivative work > > > RFC3195bis below). I sincerely believe that this option would > > > enable us > > > to submit syslog-protocol, -transport-UDP and RFC3195bis within a > > few > > > weeks. > > > > > > My reasoning for this proposal is as follows: > > > > > > We all know that 3195 has limited acceptance in the community and > > very > > > few implementations. However, it satisfies all IESG criteria > > > we have in > > > our charter. Also, it *is* something that can be used in practice > > and > > > implementing it becomes easier as support libraries=20 > become visible. > > I > > > know it is not an optimal choice. On the other hand, we have > > > syslog-transport-tls, which has been encrumbered by a=20 > patent claim. > > As > > > it looks, this will need months to solve. RFC3195bis can not be > > taken > > > hostage by any patent claims, because there is well-defined > > > prior art in > > > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > > > mission and finsh work that is in the queue for many years > > > now. I think > > > this is urgently needed. We might even put the netconf WG=20 > with their > > > syslog gateway on hold (because syslog-protocol can not=20 > be published > > > without resolving the secure transport). Or netconf might > > > choose to drop > > > syslog-protocol in order to publish. > > > > > > And the good news is that 3195bis can definitely very quickly > > > be done. I > > > am saying this on the assumption that we do not revisit the basics > > of > > > 3195 but just adopt it to syslog-protocol. I've gone through > > > 3195 today > > > and the changes are absolutely minimal: > > > > > > Section 2: > > > Most of it simply needs to be removed because the entity roles are > > > defined in syslog-protocol. > > > > > > Section 3: > > > - the message samples must be upgraded to -protocol-format > > > - syslog-framing in section 3.3 must be changed (could be > > > octet-counting > > > or disallow of multiple messages per ANS, what I recommend) > > > > > > Section 4: > > > 4.4.2 > > > - needs to be updated with the new HEADER fields and > > STRUCTURED-DATA > > > - some work on "deviceFQDN" and "deviceIP" needed > > > - some transformation rules (page 15) need to be removed > > > - handling of invalid message formatting must be removed=20 > (no longer > > a > > > concern) > > > - samples must be adjusted > > > > > > 4.4.3 > > > - sample on page 24 (top) must be checked and/or adjusted > > > > > > Section 7: > > > - DTD needs to be adjusted > > > > > > Section 9: > > > - new URIs for 3195bis (also in some other places) > > > [we can reuse well-known port 601 for -protocol] > > > > > > Overall > > > References to 3164 must be changed to -syslog-protocol. This > > > seems quite > > > trivial, because the references are easy to spot and do not touch > > any > > > substance (except outlined above). > > > > > > Other than these minor things, there are *NO* other changes > > necessary. > > > I'd expect that an initial version of 3195bis can be=20 > created within > > a > > > single working day. Add some quick review and a very=20 > limited number > > of > > > edits to change discovered nits - and we have something to publish > > by > > > summer. > > > > > > I find this extremely tempting. It breaks the deadlock > > > situation we are > > > currently in. Especially as we have planned to do 3195bis=20 > some time > > > later anyhow. I don't know if the authors of 3195 would > > > volunteer to do > > > the edit. But I hope so. > > > > > > I would appreciate if the chairs could try to reach=20 > consensus on my > > > proposal. > > > > > > Comments are appreciated. > > > Thanks, > > > Rainer > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 06:32:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtMTc-0008N5-Gv; Thu, 22 Jun 2006 06:31:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtMSD-0006Wb-0f for syslog@ietf.org; Thu, 22 Jun 2006 06:30:29 -0400 Received: from gmpea-pix-1.sun.com ([192.18.1.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtMDt-0001V4-KQ for syslog@ietf.org; Thu, 22 Jun 2006 06:15:43 -0400 Received: from d1-emea-02.sun.com (d1-emea-02.sun.com [192.18.2.112] (may be forged)) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5MAFc0D002129 for ; Thu, 22 Jun 2006 11:15:40 +0100 (BST) Received: from conversion-daemon.d1-emea-02.sun.com by d1-emea-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1900601AVXTO00@d1-emea-02.sun.com> (original mail from Darren.Moffat@Sun.COM) for syslog@ietf.org; Thu, 22 Jun 2006 11:15:38 +0100 (BST) Received: from [129.150.120.103] by d1-emea-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1900FD5B5ZCU30@d1-emea-02.sun.com>; Thu, 22 Jun 2006 11:15:38 +0100 (BST) Date: Thu, 22 Jun 2006 11:14:08 +0100 From: Darren J Moffat Subject: Re: [Syslog] Secure transport alternatives In-reply-to: <022901c695bf$9e3121b0$e8726e0a@china.huawei.com> To: Miao Fuyou Message-id: <449A6D70.3080501@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <022901c695bf$9e3121b0$e8726e0a@china.huawei.com> User-Agent: Mail/News 1.5.0.2 (X11/20060515) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Miao Fuyou wrote: > real "general" security mechanisms(except IPsec, but it is not > application-friendly). So, IMHO the primary criteria for selection is: is it > convenient for the application to invoke the security service provided by > the security protocol? That to me sounds like GSSAPI or SASL. Any reason these aren't being considered ? -- Darren J Moffat _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 06:52:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtMn7-00066J-Qw; Thu, 22 Jun 2006 06:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtMn6-00061u-DK for syslog@ietf.org; Thu, 22 Jun 2006 06:52:04 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtMn4-00037s-Uv for syslog@ietf.org; Thu, 22 Jun 2006 06:52:04 -0400 Received: from pc6 (1Cust206.tnt109.lnd4.gbr.da.uu.net [62.188.172.206]) by astro.systems.pipex.net (Postfix) with SMTP id 4E146E000326; Thu, 22 Jun 2006 11:52:00 +0100 (BST) Message-ID: <064a01c695e0$f52e4120$0601a8c0@pc6> From: "Tom Petch" To: "Anton Okmianski \(aokmians\)" , References: <98AE08B66FAD1742BED6CB9522B731220196A27B@xmb-rtp-20d.amer.cisco.com> Subject: Re: [Syslog] delineated datagrams Date: Thu, 22 Jun 2006 11:47:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Anton Okmianski (aokmians)" To: "Tom Petch" ; Sent: Tuesday, June 20, 2006 8:18 PM Subject: RE: [Syslog] delineated datagrams Tom: I think these are valid concerns. They span different layers: 1. If we only care about network-layer reliability (as in byte insert/remove examples): client/server can be recommended to reset connection every so often. Decent corruption detection is already part of TCP/IP and layer 2 protocols. 2. If we care about app-layer reliability (as in encode/decode error examples): app-level ACK. As in RFC 3195, for example. This certainly expands the scope quite a bit beyond just secure transport. Anton My concern was in between, the shim between TCP and syslog that is TLS. With UDP transport, a Relay receives a datagram and sends it on its way, no processing required; probability of corruption small enough to ignore, consequences when it does, one corrupted packet. With TLS, the packet must be decrypted, unpadded, decompressed split into 'datagrams' on the basis of a string of decimal digits and then re-packaged to send on its way. If a byte is lost here, chances are the string of decimal digits will point into the middle of a valid string of decimal digits, which will give a truncated second 'datagram' and point into who knows what. Eventually, the pointer will not point to a string of decimal digits and the Relay will realise it is lost. By then, it may have forwarded several corrupted or truncated 'datagrams'. And the chance of recovering sync is, IMO, nil; tear down the connection and set it up again. By contrast, there are protocols which rely on detecting sync, use it initially, error detect and error recover with it. Of course, they have more to go on than a string of decimal digits, they have structures which are distinctive in the context of the datastream (I would for example expect to recover sync with BER.1 encoding of SNMP, although I don't know anyone who does that). So my thinking is should we have more than a string of decimal digits, like or something else that is obviously invalid so that errors are likely to be detected immediately and the Relay has a chance of scanning the stream to recover sync. You may recall we have had discussions of length v end of record marker before (and yes, I do like end of record markers:-) Tom Petch Anton. > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Tuesday, June 20, 2006 8:43 AM > To: syslog@ietf.org > Subject: Re: [Syslog] delineated datagrams > wasdraft-ietf-syslog-transport-tls-01.txt > > I wonder if others share my concern about the lack of > robustness in the way in > which datagrams are delineated in the stream protocol (a TCP > rather than a TLS > issue). > > The system works as long as > - the frame length is encoded perfectly > - the frame length is decoded perfectly > - no bytes are inserted or removed in error > which is doubtless true in some networks, but I would prefer > not to rely on it. > > So, when an error occurs, can the Collector/Relay detect it? Can the > Collector/Relay recover synch? If not, what does the > Collector/Relay do? > > There is very little redundancy in the definition of frame > length, and syslog > messages have very little structure to help the application, > so I think that > this is an issue we should address. > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" > To: > Sent: Tuesday, May 09, 2006 4:26 PM > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > Hi, > > A new revision of the syslog/TLS draft is available. > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > .txt > > We need reviewers. > Can we get > 1) a person to check the grammar? > 2) a person to check the syslog technical parts? > 3) a person to check compatibility with the other WG documents? > 4) a person to check the TLS technical parts? > > We also need general reviews of the document by multiple people. > > Thanks, > David Harrington > co-chair, Syslog WG > ietfdbh@comcast.net > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 06:52:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtMnS-0006YC-25; Thu, 22 Jun 2006 06:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtMnQ-0006Y4-V4 for syslog@ietf.org; Thu, 22 Jun 2006 06:52:24 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtMnP-0003Ci-LF for syslog@ietf.org; Thu, 22 Jun 2006 06:52:24 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 5180627C065 for ; Thu, 22 Jun 2006 12:48:56 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05223-06 for ; Thu, 22 Jun 2006 12:48:56 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 185DA27C061 for ; Thu, 22 Jun 2006 12:48:56 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 12:52:22 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2006 12:52:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749BC@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Huawei IPR claim Thread-Index: AcaV6e5o7kb4KUptTie4VMRZhtr3cg== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 22 Jun 2006 10:52:22.0321 (UTC) FILETIME=[F09A7210:01C695E9] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Syslog] Huawei IPR claim X-BeenThere: syslog@lists.ietf.org X-Mailman-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 think I have some good news. Huawei has updated its IPR disclosure. Please see https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D724 The license has dramatically been changed: ************** If technology in this document is included in a standard adopted by IETF and anyclaims of any Huawei patents are necessary for practicing the standard, Huawei will not assert any patents against any party that implements the standard, however that Huawei retains the right to assert its patents against any party that asserts any rights against Huawei; and Huawei retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard. ************** I am a bit stunned that Huawei updated the disclosure silently (on the 20th). I am a bit puzzled if another update might again impose more stringent terms. I still think the patent itself is theft of other person's work. Unfortunately, the disclosure still does not mention which section of the I-D is threatened by the patent. But the change is a very welcome one and I wanted to make you aware of it. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 07:07:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtN1d-0000Vw-BX; Thu, 22 Jun 2006 07:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtN1c-0000Vm-MZ for syslog@ietf.org; Thu, 22 Jun 2006 07:07:04 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtN1c-00044z-1G for syslog@ietf.org; Thu, 22 Jun 2006 07:07:04 -0400 Received: from pc6 (1Cust144.tnt106.lnd4.gbr.da.uu.net [213.116.60.144]) by astro.systems.pipex.net (Postfix) with SMTP id 533B7E000373; Thu, 22 Jun 2006 12:06:58 +0100 (BST) Message-ID: <06c201c695e3$0e2728c0$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , "David Harrington" , References: <577465F99B41C842AAFBE9ED71E70ABA1749B2@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Secure transport alternatives Date: Thu, 22 Jun 2006 12:02:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e 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 Rainer Looking at the outstanding milestones, I see Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Nov 2006 Submit Syslog Protocol to the IESG for consideration as a PROPOSED STANDARD Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Nov 2006 Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD Nov 2006 Submit a document that defines a message signing and ordering mechanism to the IESG for consideration as a PROPOSED STANDARD which is why I see TLS as embedded in the charter (as well as, more obscurely, in the discussions that led up to the charter change). Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Tom Petch" ; "David Harrington" ; Sent: Thursday, June 22, 2006 10:48 AM Subject: RE: [Syslog] Secure transport alternatives Tom, > But, in all seriousness, changing from TLS to anything is a > charter change that > I think needs the approval of the IESG, and should require > commitment, similar > to that given at the turn of the year, to produce conformant products. I do not agree here. We have deliberately not used the term "TLS" in the charter. The relevant excerpts are: ### The threats that this WG will primarily address are modification, disclosure, and masquerading. A secondary threat is message stream modification. Threats that will not be addressed by this WG are DoS and traffic analysis. The primary attacks may be thwarted by a secure transport. However, it must be remembered that a great deal of the success of syslog has been attributed to its ease of implementation and relatively low maintenance level. The Working Group will consider those factors, as well as current implementations, when deciding upon a secure transport. ### ### - A document will be produced that requires a secure transport for the delivery of syslog messages. ### As far as I remember (not looked up the archive yet), we did this intentionally so that we could change transports if need arises. At least for now, I think this need has arisen. The really bad thing about the IPR claim is that we do not even know what actually has been claimed. But I do not intend to invest any of my work into something that somebody else claims exclusive rights on. So -tls is a dead end for me as long as the claim is not dropped. I foresee similar harsh reaction at least of the open source commuity (*the* major driving factor behind syslog implementation) when we standardize something encrumbered by a patent. Rainer > > Tom Petch > > > ----- Original Message ----- > From: "David Harrington" > To: "'Rainer Gerhards'" ; > Sent: Wednesday, June 21, 2006 7:58 PM > Subject: [Syslog] Secure transport alternatives > > > > Hi, > > > > [Posting as a contributor] > > > > I am involved in a number of NM and Security WGs, and I can > make these > > observations: > > > > Running an NM protocol over SSH has been done in both netconf and > > ISMS. I suspect it would be fairly easy to adapt the > netconf-over-SSH > > draft to work for syslog-over-SSH. I suspect it would take a week or > > so to write a syslog-over-SSH draft since most could be > cut-and-paste > > from the netconf-over-SSH draft. > > > > I am the author of the ISMS drafts, and I adapted the netconf/SSH > > draft for ISMS purposes. Syslog and netconf seem to be > closer in their > > requirements than syslog and ISMS. ISMS has this whole > model of access > > control to deal with that is not part of the threat model for syslog > > or for netconf at this time. > > > > There is a parallel discussion of running syslog messages over > > netconf. As Rainer has pointed out to Phil, having a consistent > > terminology would be very helpful. I think having a consistent > > security solution would probably be helpful in that > situation as well. > > > > I have concerns about 3195bis as the only alternative we consider, > > because I have not seen much interest in RFC3195 yet, nor has there > > been much expresseed interest in netconf over BEEP. > > > > Since there may be delay involved in this WG no matter what, would > > somebody be willing to volunteer to write a syslog-over-SSH > draft, so > > the WG can compare the three approaches? > > > > There are other possibilities as well (and I am being serious here, > > not "let's make this absurd by proposing a whole slew of alteratives > > documents"). > > 1) Tom mentioned DTLS, which might be a viable alternative given > > syslog's UDP roots. Tom would you, or somebody else, be willing to > > write a proposal for syslog/DTLS? > > 2) Andy Bierman observed that if syslog messages are going to be > > transported over netconf, then why not simply use syslog/netconf and > > let netconf deal with the security issues. That could be an > > alternative proposal. Is anybody willing to write a draft proposing > > that as a syslog secure transport solution? > > > > My $.02 as a contributor, > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Tuesday, June 20, 2006 9:44 AM > > > To: syslog@ietf.org > > > Subject: [Syslog] IESG secure transport requirement can be > > > quickly solved... > > > > > > Hi all, > > > > > > I propose to update RFC 3195 in the spirit of syslog-protocol > > > to satisfy > > > the IESG secure transport requirement (I will call this > > > derivative work > > > RFC3195bis below). I sincerely believe that this option would > > > enable us > > > to submit syslog-protocol, -transport-UDP and RFC3195bis within a > > few > > > weeks. > > > > > > My reasoning for this proposal is as follows: > > > > > > We all know that 3195 has limited acceptance in the community and > > very > > > few implementations. However, it satisfies all IESG criteria > > > we have in > > > our charter. Also, it *is* something that can be used in practice > > and > > > implementing it becomes easier as support libraries > become visible. > > I > > > know it is not an optimal choice. On the other hand, we have > > > syslog-transport-tls, which has been encrumbered by a > patent claim. > > As > > > it looks, this will need months to solve. RFC3195bis can not be > > taken > > > hostage by any patent claims, because there is well-defined > > > prior art in > > > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > > > mission and finsh work that is in the queue for many years > > > now. I think > > > this is urgently needed. We might even put the netconf WG > with their > > > syslog gateway on hold (because syslog-protocol can not > be published > > > without resolving the secure transport). Or netconf might > > > choose to drop > > > syslog-protocol in order to publish. > > > > > > And the good news is that 3195bis can definitely very quickly > > > be done. I > > > am saying this on the assumption that we do not revisit the basics > > of > > > 3195 but just adopt it to syslog-protocol. I've gone through > > > 3195 today > > > and the changes are absolutely minimal: > > > > > > Section 2: > > > Most of it simply needs to be removed because the entity roles are > > > defined in syslog-protocol. > > > > > > Section 3: > > > - the message samples must be upgraded to -protocol-format > > > - syslog-framing in section 3.3 must be changed (could be > > > octet-counting > > > or disallow of multiple messages per ANS, what I recommend) > > > > > > Section 4: > > > 4.4.2 > > > - needs to be updated with the new HEADER fields and > > STRUCTURED-DATA > > > - some work on "deviceFQDN" and "deviceIP" needed > > > - some transformation rules (page 15) need to be removed > > > - handling of invalid message formatting must be removed > (no longer > > a > > > concern) > > > - samples must be adjusted > > > > > > 4.4.3 > > > - sample on page 24 (top) must be checked and/or adjusted > > > > > > Section 7: > > > - DTD needs to be adjusted > > > > > > Section 9: > > > - new URIs for 3195bis (also in some other places) > > > [we can reuse well-known port 601 for -protocol] > > > > > > Overall > > > References to 3164 must be changed to -syslog-protocol. This > > > seems quite > > > trivial, because the references are easy to spot and do not touch > > any > > > substance (except outlined above). > > > > > > Other than these minor things, there are *NO* other changes > > necessary. > > > I'd expect that an initial version of 3195bis can be > created within > > a > > > single working day. Add some quick review and a very > limited number > > of > > > edits to change discovered nits - and we have something to publish > > by > > > summer. > > > > > > I find this extremely tempting. It breaks the deadlock > > > situation we are > > > currently in. Especially as we have planned to do 3195bis > some time > > > later anyhow. I don't know if the authors of 3195 would > > > volunteer to do > > > the edit. But I hope so. > > > > > > I would appreciate if the chairs could try to reach > consensus on my > > > proposal. > > > > > > Comments are appreciated. > > > Thanks, > > > Rainer > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 08:10:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtO1O-0000Gh-3W; Thu, 22 Jun 2006 08:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtO1N-0000D8-9o for syslog@ietf.org; Thu, 22 Jun 2006 08:10:53 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtO1L-0007U1-RE for syslog@ietf.org; Thu, 22 Jun 2006 08:10:53 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6A27427C065 for ; Thu, 22 Jun 2006 14:07:24 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07719-07 for ; Thu, 22 Jun 2006 14:07:24 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 1834027C061 for ; Thu, 22 Jun 2006 14:07:24 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 14:10:49 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Huawei IPR claim MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2006 14:10:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749BE@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1749BC@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Huawei IPR claim Thread-Index: AcaV6e5o7kb4KUptTie4VMRZhtr3cgAChqbw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 22 Jun 2006 12:10:49.0262 (UTC) FILETIME=[E628A4E0:01C695F4] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi all, once again some news. I have contacted the ffii.org, which nobody can claim to be patent-friendly. This is the essential part of their reply: _______________________________________________________________________ On the one hand this is indeed a very good example of how software =20 patents obstruct standardisation, but on the other hand the license =20 offered by Huawei for the patent is very good: [snip - license from new IPR disclosure] [snip...] people may =20 merely see this as a responsible move by Huaewei to protect the =20 standard from a patent ambush by other companies (by means of the =20 "mutually assured destruction" clause in their license). Of course, the problem remains that a) there is no guarantee the patent will always be owned by Huaewei =20 (e.g. the JPEG patent was originally also owned by a company which =20 gave a similar license for it, but then they went broke, Forgent =20 bought them out and the rest is history as they say) b) the license does not state it is non-revokable c) lots of time is being wasted moving forward because of the dangers =20 of the previous points. _______________________________________________________________________ I also have to admit that these were the guys that acutally found the update IPR disclosure. I had not indicated this in my previous mail because I asked them for permission to use their name and had not yet received it at the time of my posting. Rainer=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Thursday, June 22, 2006 12:52 PM > To: syslog@ietf.org > Subject: [Syslog] Huawei IPR claim >=20 > Hi all, >=20 > I think I have some good news. Huawei has updated its IPR disclosure. > Please see >=20 > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D724 >=20 > The license has dramatically been changed: >=20 > ************** > If technology in this document is included in a standard=20 > adopted by IETF > and anyclaims of any Huawei patents are necessary for practicing the > standard, Huawei > will not assert any patents against any party that implements the > standard, > however that Huawei retains the right to assert its patents=20 > against any > party > that asserts any rights against Huawei; and Huawei retains=20 > the right to > assert > its patents against any product or portion thereof that is=20 > not necessary > for > compliance with the standard. > ************** >=20 > I am a bit stunned that Huawei updated the disclosure silently (on the > 20th). I am a bit puzzled if another update might again impose more > stringent terms. I still think the patent itself is theft of other > person's work. Unfortunately, the disclosure still does not mention > which section of the I-D is threatened by the patent. >=20 > But the change is a very welcome one and I wanted to make you aware of > it. >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 08:13:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtO3u-0002ms-V7; Thu, 22 Jun 2006 08:13:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtO3u-0002mf-1F for syslog@ietf.org; Thu, 22 Jun 2006 08:13:30 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtO3t-0007a4-62 for syslog@ietf.org; Thu, 22 Jun 2006 08:13:30 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 4400027C065; Thu, 22 Jun 2006 14:10:02 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07719-08; Thu, 22 Jun 2006 14:10:02 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id C301327C061; Thu, 22 Jun 2006 14:10:01 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 14:13:26 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Secure transport alternatives MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2006 14:13:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749BF@grfint2.intern.adiscon.com> In-Reply-To: <06c201c695e3$0e2728c0$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Secure transport alternatives Thread-Index: AcaV7rJ3EwUYLq6ZQ+qEONKIDMivlgABjNyw From: "Rainer Gerhards" To: "Tom Petch" , "David Harrington" , X-OriginalArrivalTime: 22 Jun 2006 12:13:26.0559 (UTC) FILETIME=[43EA42F0:01C695F5] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Tom, I have to admit I have overlooked this item. I agree that we (especially me) were very TLS-minded. My memories tell me we intentionally left the door open for other transports, but I may be wrong. As it looks, I need to re-visit the mailing list archive. I hope I will be able to do so soon. I also have on my mind that we intended to do 3195bis after tls was finshed, so we did not plan to totally abandon it. Again, all of this out of my memory... Rainer=20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Thursday, June 22, 2006 12:03 PM > To: Rainer Gerhards; David Harrington; syslog@ietf.org > Subject: Re: [Syslog] Secure transport alternatives >=20 > Rainer >=20 > Looking at the outstanding milestones, I see >=20 > Nov 2006 Submit Syslog UDP Transport Mapping to the IESG=20 > for consideration as > a PROPOSED STANDARD > Nov 2006 Submit Syslog Protocol to the IESG for=20 > consideration as a PROPOSED > STANDARD > Nov 2006 Submit Syslog TLS Transport Mapping to the IESG=20 > for consideration as > a PROPOSED STANDARD > Nov 2006 Submit Syslog Device MIB to IESG for=20 > consideration as a PROPOSED > STANDARD > Nov 2006 Submit a document that defines a message signing=20 > and ordering > mechanism to the IESG for consideration as a PROPOSED STANDARD >=20 > which is why I see TLS as embedded in the charter (as well=20 > as, more obscurely, > in the discussions that led up to the charter change). >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Rainer Gerhards" > To: "Tom Petch" ; "David Harrington" > ; > Sent: Thursday, June 22, 2006 10:48 AM > Subject: RE: [Syslog] Secure transport alternatives >=20 >=20 > Tom, > > But, in all seriousness, changing from TLS to anything is a > > charter change that > > I think needs the approval of the IESG, and should require > > commitment, similar > > to that given at the turn of the year, to produce=20 > conformant products. >=20 > I do not agree here. We have deliberately not used the term=20 > "TLS" in the > charter. The relevant excerpts are: >=20 > ### > The threats that this WG will primarily address are modification, > disclosure, and masquerading. A secondary threat is message stream > modification. Threats that will not be addressed by this WG=20 > are DoS and > traffic analysis. The primary attacks may be thwarted by a secure > transport. However, it must be remembered that a great deal of the > success of syslog has been attributed to its ease of=20 > implementation and > relatively low maintenance level. The Working Group will=20 > consider those > factors, as well as current implementations, when deciding upon a > secure transport. > ### >=20 > ### > - A document will be produced that requires a secure transport for the > delivery of syslog messages. > ### >=20 > As far as I remember (not looked up the archive yet), we did this > intentionally so that we could change transports if need arises. At > least for now, I think this need has arisen. >=20 > The really bad thing about the IPR claim is that we do not even know > what actually has been claimed. But I do not intend to invest=20 > any of my > work into something that somebody else claims exclusive rights on. So > -tls is a dead end for me as long as the claim is not=20 > dropped. I foresee > similar harsh reaction at least of the open source commuity=20 > (*the* major > driving factor behind syslog implementation) when we standardize > something encrumbered by a patent. >=20 > Rainer >=20 > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "David Harrington" > > To: "'Rainer Gerhards'" ;=20 > > > Sent: Wednesday, June 21, 2006 7:58 PM > > Subject: [Syslog] Secure transport alternatives > > > > > > > Hi, > > > > > > [Posting as a contributor] > > > > > > I am involved in a number of NM and Security WGs, and I can > > make these > > > observations: > > > > > > Running an NM protocol over SSH has been done in both netconf and > > > ISMS. I suspect it would be fairly easy to adapt the > > netconf-over-SSH > > > draft to work for syslog-over-SSH. I suspect it would=20 > take a week or > > > so to write a syslog-over-SSH draft since most could be > > cut-and-paste > > > from the netconf-over-SSH draft. > > > > > > I am the author of the ISMS drafts, and I adapted the netconf/SSH > > > draft for ISMS purposes. Syslog and netconf seem to be > > closer in their > > > requirements than syslog and ISMS. ISMS has this whole > > model of access > > > control to deal with that is not part of the threat model=20 > for syslog > > > or for netconf at this time. > > > > > > There is a parallel discussion of running syslog messages over > > > netconf. As Rainer has pointed out to Phil, having a consistent > > > terminology would be very helpful. I think having a consistent > > > security solution would probably be helpful in that > > situation as well. > > > > > > I have concerns about 3195bis as the only alternative we consider, > > > because I have not seen much interest in RFC3195 yet, nor=20 > has there > > > been much expresseed interest in netconf over BEEP. > > > > > > Since there may be delay involved in this WG no matter what, would > > > somebody be willing to volunteer to write a syslog-over-SSH > > draft, so > > > the WG can compare the three approaches? > > > > > > There are other possibilities as well (and I am being=20 > serious here, > > > not "let's make this absurd by proposing a whole slew of=20 > alteratives > > > documents"). > > > 1) Tom mentioned DTLS, which might be a viable alternative given > > > syslog's UDP roots. Tom would you, or somebody else, be willing to > > > write a proposal for syslog/DTLS? > > > 2) Andy Bierman observed that if syslog messages are going to be > > > transported over netconf, then why not simply use=20 > syslog/netconf and > > > let netconf deal with the security issues. That could be an > > > alternative proposal. Is anybody willing to write a draft=20 > proposing > > > that as a syslog secure transport solution? > > > > > > My $.02 as a contributor, > > > > > > David Harrington > > > dharrington@huawei.com > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > > > > > > > > -----Original Message----- > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > > Sent: Tuesday, June 20, 2006 9:44 AM > > > > To: syslog@ietf.org > > > > Subject: [Syslog] IESG secure transport requirement can be > > > > quickly solved... > > > > > > > > Hi all, > > > > > > > > I propose to update RFC 3195 in the spirit of syslog-protocol > > > > to satisfy > > > > the IESG secure transport requirement (I will call this > > > > derivative work > > > > RFC3195bis below). I sincerely believe that this option would > > > > enable us > > > > to submit syslog-protocol, -transport-UDP and=20 > RFC3195bis within a > > > few > > > > weeks. > > > > > > > > My reasoning for this proposal is as follows: > > > > > > > > We all know that 3195 has limited acceptance in the=20 > community and > > > very > > > > few implementations. However, it satisfies all IESG criteria > > > > we have in > > > > our charter. Also, it *is* something that can be used=20 > in practice > > > and > > > > implementing it becomes easier as support libraries > > become visible. > > > I > > > > know it is not an optimal choice. On the other hand, we have > > > > syslog-transport-tls, which has been encrumbered by a > > patent claim. > > > As > > > > it looks, this will need months to solve. RFC3195bis can not be > > > taken > > > > hostage by any patent claims, because there is well-defined > > > > prior art in > > > > RFC 3195. Focussing on RFC 3195bis would enable us to=20 > complete our > > > > mission and finsh work that is in the queue for many years > > > > now. I think > > > > this is urgently needed. We might even put the netconf WG > > with their > > > > syslog gateway on hold (because syslog-protocol can not > > be published > > > > without resolving the secure transport). Or netconf might > > > > choose to drop > > > > syslog-protocol in order to publish. > > > > > > > > And the good news is that 3195bis can definitely very quickly > > > > be done. I > > > > am saying this on the assumption that we do not revisit=20 > the basics > > > of > > > > 3195 but just adopt it to syslog-protocol. I've gone through > > > > 3195 today > > > > and the changes are absolutely minimal: > > > > > > > > Section 2: > > > > Most of it simply needs to be removed because the=20 > entity roles are > > > > defined in syslog-protocol. > > > > > > > > Section 3: > > > > - the message samples must be upgraded to -protocol-format > > > > - syslog-framing in section 3.3 must be changed (could be > > > > octet-counting > > > > or disallow of multiple messages per ANS, what I recommend) > > > > > > > > Section 4: > > > > 4.4.2 > > > > - needs to be updated with the new HEADER fields and > > > STRUCTURED-DATA > > > > - some work on "deviceFQDN" and "deviceIP" needed > > > > - some transformation rules (page 15) need to be removed > > > > - handling of invalid message formatting must be removed > > (no longer > > > a > > > > concern) > > > > - samples must be adjusted > > > > > > > > 4.4.3 > > > > - sample on page 24 (top) must be checked and/or adjusted > > > > > > > > Section 7: > > > > - DTD needs to be adjusted > > > > > > > > Section 9: > > > > - new URIs for 3195bis (also in some other places) > > > > [we can reuse well-known port 601 for -protocol] > > > > > > > > Overall > > > > References to 3164 must be changed to -syslog-protocol. This > > > > seems quite > > > > trivial, because the references are easy to spot and=20 > do not touch > > > any > > > > substance (except outlined above). > > > > > > > > Other than these minor things, there are *NO* other changes > > > necessary. > > > > I'd expect that an initial version of 3195bis can be > > created within > > > a > > > > single working day. Add some quick review and a very > > limited number > > > of > > > > edits to change discovered nits - and we have something=20 > to publish > > > by > > > > summer. > > > > > > > > I find this extremely tempting. It breaks the deadlock > > > > situation we are > > > > currently in. Especially as we have planned to do 3195bis > > some time > > > > later anyhow. I don't know if the authors of 3195 would > > > > volunteer to do > > > > the edit. But I hope so. > > > > > > > > I would appreciate if the chairs could try to reach > > consensus on my > > > > proposal. > > > > > > > > Comments are appreciated. > > > > Thanks, > > > > Rainer > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 08:21:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOBL-0006mz-4E; Thu, 22 Jun 2006 08:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOBK-0006kW-2M for syslog@ietf.org; Thu, 22 Jun 2006 08:21:10 -0400 Received: from ext-ch1gw-1.online-age.net ([216.34.191.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOBH-00088Y-90 for syslog@ietf.org; Thu, 22 Jun 2006 08:21:10 -0400 Received: from int-ch1gw-3.online-age.net (int-ch1gw-3 [3.159.232.67]) by ext-ch1gw-1.online-age.net (8.13.6/8.13.6/20051111-SVVS-TLS-DNSBL) with ESMTP id k5MCL4f2010826 for ; Thu, 22 Jun 2006 08:21:04 -0400 (EDT) Received: from cinmlef09.e2k.ad.ge.com (localhost [127.0.0.1]) by int-ch1gw-3.online-age.net (8.12.9/8.12.3/990426-RLH) with ESMTP id k5MCKq4h017526 for ; Thu, 22 Jun 2006 08:20:53 -0400 (EDT) Received: from ALPMLVEM07.e2k.ad.ge.com ([3.159.17.65]) by cinmlef09.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 22 Jun 2006 08:20:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Secure transport alternatives Date: Thu, 22 Jun 2006 08:20:51 -0400 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1749BF@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Secure transport alternatives Thread-Index: AcaV7rJ3EwUYLq6ZQ+qEONKIDMivlgABjNywAAAz1rA= From: "Moehrke, John \(GE Healthcare\)" To: "Rainer Gerhards" , "Tom Petch" , "David Harrington" , X-OriginalArrivalTime: 22 Jun 2006 12:20:53.0077 (UTC) FILETIME=[4E0F8050:01C695F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 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 An advantage of TLS over SSH that is not technical in nature is that TLS/SSL is already found in very low end devices as it is used for other purposes. Utilizing it is far better than requiring that these devices now take on the additional SSH (or other) protocols. SSH tends not to be as widely deployed in embedded systems as most of it's general purpose uses are in interactive-remote-control type applications. John > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Thursday, June 22, 2006 7:13 AM > To: Tom Petch; David Harrington; syslog@ietf.org > Subject: RE: [Syslog] Secure transport alternatives >=20 > Tom, >=20 > I have to admit I have overlooked this item. I agree that we=20 > (especially > me) were very TLS-minded. My memories tell me we=20 > intentionally left the > door open for other transports, but I may be wrong. As it=20 > looks, I need > to re-visit the mailing list archive. I hope I will be able to do so > soon. >=20 > I also have on my mind that we intended to do 3195bis after tls was > finshed, so we did not plan to totally abandon it. Again, all of this > out of my memory... >=20 > Rainer=20 >=20 > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > Sent: Thursday, June 22, 2006 12:03 PM > > To: Rainer Gerhards; David Harrington; syslog@ietf.org > > Subject: Re: [Syslog] Secure transport alternatives > >=20 > > Rainer > >=20 > > Looking at the outstanding milestones, I see > >=20 > > Nov 2006 Submit Syslog UDP Transport Mapping to the IESG=20 > > for consideration as > > a PROPOSED STANDARD > > Nov 2006 Submit Syslog Protocol to the IESG for=20 > > consideration as a PROPOSED > > STANDARD > > Nov 2006 Submit Syslog TLS Transport Mapping to the IESG=20 > > for consideration as > > a PROPOSED STANDARD > > Nov 2006 Submit Syslog Device MIB to IESG for=20 > > consideration as a PROPOSED > > STANDARD > > Nov 2006 Submit a document that defines a message signing=20 > > and ordering > > mechanism to the IESG for consideration as a PROPOSED STANDARD > >=20 > > which is why I see TLS as embedded in the charter (as well=20 > > as, more obscurely, > > in the discussions that led up to the charter change). > >=20 > > Tom Petch > >=20 > >=20 > > ----- Original Message ----- > > From: "Rainer Gerhards" > > To: "Tom Petch" ; "David Harrington" > > ; > > Sent: Thursday, June 22, 2006 10:48 AM > > Subject: RE: [Syslog] Secure transport alternatives > >=20 > >=20 > > Tom, > > > But, in all seriousness, changing from TLS to anything is a > > > charter change that > > > I think needs the approval of the IESG, and should require > > > commitment, similar > > > to that given at the turn of the year, to produce=20 > > conformant products. > >=20 > > I do not agree here. We have deliberately not used the term=20 > > "TLS" in the > > charter. The relevant excerpts are: > >=20 > > ### > > The threats that this WG will primarily address are modification, > > disclosure, and masquerading. A secondary threat is message stream > > modification. Threats that will not be addressed by this WG=20 > > are DoS and > > traffic analysis. The primary attacks may be thwarted by a secure > > transport. However, it must be remembered that a great deal of the > > success of syslog has been attributed to its ease of=20 > > implementation and > > relatively low maintenance level. The Working Group will=20 > > consider those > > factors, as well as current implementations, when deciding upon a > > secure transport. > > ### > >=20 > > ### > > - A document will be produced that requires a secure=20 > transport for the > > delivery of syslog messages. > > ### > >=20 > > As far as I remember (not looked up the archive yet), we did this > > intentionally so that we could change transports if need arises. At > > least for now, I think this need has arisen. > >=20 > > The really bad thing about the IPR claim is that we do not even know > > what actually has been claimed. But I do not intend to invest=20 > > any of my > > work into something that somebody else claims exclusive=20 > rights on. So > > -tls is a dead end for me as long as the claim is not=20 > > dropped. I foresee > > similar harsh reaction at least of the open source commuity=20 > > (*the* major > > driving factor behind syslog implementation) when we standardize > > something encrumbered by a patent. > >=20 > > Rainer > >=20 > > > > > > Tom Petch > > > > > > > > > ----- Original Message ----- > > > From: "David Harrington" > > > To: "'Rainer Gerhards'" ;=20 > > > > > Sent: Wednesday, June 21, 2006 7:58 PM > > > Subject: [Syslog] Secure transport alternatives > > > > > > > > > > Hi, > > > > > > > > [Posting as a contributor] > > > > > > > > I am involved in a number of NM and Security WGs, and I can > > > make these > > > > observations: > > > > > > > > Running an NM protocol over SSH has been done in both=20 > netconf and > > > > ISMS. I suspect it would be fairly easy to adapt the > > > netconf-over-SSH > > > > draft to work for syslog-over-SSH. I suspect it would=20 > > take a week or > > > > so to write a syslog-over-SSH draft since most could be > > > cut-and-paste > > > > from the netconf-over-SSH draft. > > > > > > > > I am the author of the ISMS drafts, and I adapted the=20 > netconf/SSH > > > > draft for ISMS purposes. Syslog and netconf seem to be > > > closer in their > > > > requirements than syslog and ISMS. ISMS has this whole > > > model of access > > > > control to deal with that is not part of the threat model=20 > > for syslog > > > > or for netconf at this time. > > > > > > > > There is a parallel discussion of running syslog messages over > > > > netconf. As Rainer has pointed out to Phil, having a consistent > > > > terminology would be very helpful. I think having a consistent > > > > security solution would probably be helpful in that > > > situation as well. > > > > > > > > I have concerns about 3195bis as the only alternative=20 > we consider, > > > > because I have not seen much interest in RFC3195 yet, nor=20 > > has there > > > > been much expresseed interest in netconf over BEEP. > > > > > > > > Since there may be delay involved in this WG no matter=20 > what, would > > > > somebody be willing to volunteer to write a syslog-over-SSH > > > draft, so > > > > the WG can compare the three approaches? > > > > > > > > There are other possibilities as well (and I am being=20 > > serious here, > > > > not "let's make this absurd by proposing a whole slew of=20 > > alteratives > > > > documents"). > > > > 1) Tom mentioned DTLS, which might be a viable alternative given > > > > syslog's UDP roots. Tom would you, or somebody else, be=20 > willing to > > > > write a proposal for syslog/DTLS? > > > > 2) Andy Bierman observed that if syslog messages are going to be > > > > transported over netconf, then why not simply use=20 > > syslog/netconf and > > > > let netconf deal with the security issues. That could be an > > > > alternative proposal. Is anybody willing to write a draft=20 > > proposing > > > > that as a syslog secure transport solution? > > > > > > > > My $.02 as a contributor, > > > > > > > > David Harrington > > > > dharrington@huawei.com > > > > dbharrington@comcast.net > > > > ietfdbh@comcast.net > > > > > > > > > > > > > -----Original Message----- > > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > > > Sent: Tuesday, June 20, 2006 9:44 AM > > > > > To: syslog@ietf.org > > > > > Subject: [Syslog] IESG secure transport requirement can be > > > > > quickly solved... > > > > > > > > > > Hi all, > > > > > > > > > > I propose to update RFC 3195 in the spirit of syslog-protocol > > > > > to satisfy > > > > > the IESG secure transport requirement (I will call this > > > > > derivative work > > > > > RFC3195bis below). I sincerely believe that this option would > > > > > enable us > > > > > to submit syslog-protocol, -transport-UDP and=20 > > RFC3195bis within a > > > > few > > > > > weeks. > > > > > > > > > > My reasoning for this proposal is as follows: > > > > > > > > > > We all know that 3195 has limited acceptance in the=20 > > community and > > > > very > > > > > few implementations. However, it satisfies all IESG criteria > > > > > we have in > > > > > our charter. Also, it *is* something that can be used=20 > > in practice > > > > and > > > > > implementing it becomes easier as support libraries > > > become visible. > > > > I > > > > > know it is not an optimal choice. On the other hand, we have > > > > > syslog-transport-tls, which has been encrumbered by a > > > patent claim. > > > > As > > > > > it looks, this will need months to solve. RFC3195bis=20 > can not be > > > > taken > > > > > hostage by any patent claims, because there is well-defined > > > > > prior art in > > > > > RFC 3195. Focussing on RFC 3195bis would enable us to=20 > > complete our > > > > > mission and finsh work that is in the queue for many years > > > > > now. I think > > > > > this is urgently needed. We might even put the netconf WG > > > with their > > > > > syslog gateway on hold (because syslog-protocol can not > > > be published > > > > > without resolving the secure transport). Or netconf might > > > > > choose to drop > > > > > syslog-protocol in order to publish. > > > > > > > > > > And the good news is that 3195bis can definitely very quickly > > > > > be done. I > > > > > am saying this on the assumption that we do not revisit=20 > > the basics > > > > of > > > > > 3195 but just adopt it to syslog-protocol. I've gone through > > > > > 3195 today > > > > > and the changes are absolutely minimal: > > > > > > > > > > Section 2: > > > > > Most of it simply needs to be removed because the=20 > > entity roles are > > > > > defined in syslog-protocol. > > > > > > > > > > Section 3: > > > > > - the message samples must be upgraded to -protocol-format > > > > > - syslog-framing in section 3.3 must be changed (could be > > > > > octet-counting > > > > > or disallow of multiple messages per ANS, what I recommend) > > > > > > > > > > Section 4: > > > > > 4.4.2 > > > > > - needs to be updated with the new HEADER fields and > > > > STRUCTURED-DATA > > > > > - some work on "deviceFQDN" and "deviceIP" needed > > > > > - some transformation rules (page 15) need to be removed > > > > > - handling of invalid message formatting must be removed > > > (no longer > > > > a > > > > > concern) > > > > > - samples must be adjusted > > > > > > > > > > 4.4.3 > > > > > - sample on page 24 (top) must be checked and/or adjusted > > > > > > > > > > Section 7: > > > > > - DTD needs to be adjusted > > > > > > > > > > Section 9: > > > > > - new URIs for 3195bis (also in some other places) > > > > > [we can reuse well-known port 601 for -protocol] > > > > > > > > > > Overall > > > > > References to 3164 must be changed to -syslog-protocol. This > > > > > seems quite > > > > > trivial, because the references are easy to spot and=20 > > do not touch > > > > any > > > > > substance (except outlined above). > > > > > > > > > > Other than these minor things, there are *NO* other changes > > > > necessary. > > > > > I'd expect that an initial version of 3195bis can be > > > created within > > > > a > > > > > single working day. Add some quick review and a very > > > limited number > > > > of > > > > > edits to change discovered nits - and we have something=20 > > to publish > > > > by > > > > > summer. > > > > > > > > > > I find this extremely tempting. It breaks the deadlock > > > > > situation we are > > > > > currently in. Especially as we have planned to do 3195bis > > > some time > > > > > later anyhow. I don't know if the authors of 3195 would > > > > > volunteer to do > > > > > the edit. But I hope so. > > > > > > > > > > I would appreciate if the chairs could try to reach > > > consensus on my > > > > > proposal. > > > > > > > > > > Comments are appreciated. > > > > > Thanks, > > > > > Rainer > > > > > > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > Syslog@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > >=20 > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 08:42:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVi-0007MZ-D2; Thu, 22 Jun 2006 08:42:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVd-0007Fd-Ff for syslog@ietf.org; Thu, 22 Jun 2006 08:42:09 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOR3-0000bb-AB for syslog@ietf.org; Thu, 22 Jun 2006 08:37:26 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc14) with SMTP id <20060622123723m14000gvgne>; Thu, 22 Jun 2006 12:37:23 +0000 From: "David Harrington" To: , "'Miao Fuyou'" Subject: RE: [Syslog] Secure transport alternatives Date: Thu, 22 Jun 2006 08:36:10 -0400 Message-ID: <166301c695f8$71cf0ae0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <449A6D70.3080501@Sun.COM> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaV5M9SaWy6Em2gRWGQlP5+8wl15QAEwa6Q X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Darren, I don't know them well enough to comment. Are you willing to write one or two drafts proposing these as possible solutions so the WG can evaluate them as alternatives? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Darren.Moffat@Sun.COM [mailto:Darren.Moffat@Sun.COM] > Sent: Thursday, June 22, 2006 6:14 AM > To: Miao Fuyou > Cc: 'David Harrington'; 'Rainer Gerhards'; syslog@ietf.org > Subject: Re: [Syslog] Secure transport alternatives > > Miao Fuyou wrote: > > real "general" security mechanisms(except IPsec, but it is not > > application-friendly). So, IMHO the primary criteria for > selection is: is it > > convenient for the application to invoke the security > service provided by > > the security protocol? > > That to me sounds like GSSAPI or SASL. > > Any reason these aren't being considered ? > > -- > Darren J Moffat > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 08:42:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVn-0007WI-Bj; Thu, 22 Jun 2006 08:42:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVh-0007Ll-Uv for syslog@ietf.org; Thu, 22 Jun 2006 08:42:13 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOMr-0000Dp-6G for syslog@ietf.org; Thu, 22 Jun 2006 08:33:06 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 1968127C065; Thu, 22 Jun 2006 14:29:33 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09198-02; Thu, 22 Jun 2006 14:29:33 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D33BF27C061; Thu, 22 Jun 2006 14:29:32 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 14:32:50 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] delineated datagrams MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2006 14:32:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749C2@grfint2.intern.adiscon.com> In-Reply-To: <064a01c695e0$f52e4120$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] delineated datagrams Thread-Index: AcaV6e6Aboeoksq9RbKHqx01CjgHWwADXZfg From: "Rainer Gerhards" To: "Tom Petch" , "Anton Okmianski (aokmians)" , X-OriginalArrivalTime: 22 Jun 2006 12:32:50.0985 (UTC) FILETIME=[F9F79190:01C695F7] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Tom:=20 [big snip] > You may recall we have had discussions of length v end of=20 > record marker before > (and yes, I do like end of record markers:-) I see your concerns and think they are valid. I have argued for using a length in the header instead of an end of record marker. But this is different from what you are discussing now. We discussed it in the context that there were no header and we would exlusively rely on the end of record marker. As any valid character sequence is allowed in the MSG part, this is not a valid option (how do you know it is an EOR and not just a usual sequence in the middle of the message?). However, we can add a trailer, which is much like a cookie. For the same reason as the EOR, it is not fault-prooven by itself, but the likelyhood that is is mistakenly interpreted if you use it togehter with a byte counting header is small. Again, the only other alternative would be to disallow an EOR sequence inside MSG or require it to be escaped their. That sounds like a crappy little rule to me... Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 09:03:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOpq-0005k6-2G; Thu, 22 Jun 2006 09:03:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOpp-0005k1-H6 for syslog@ietf.org; Thu, 22 Jun 2006 09:03:01 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOpo-0002Ui-TB for syslog@ietf.org; Thu, 22 Jun 2006 09:03:01 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 55F9027C065; Thu, 22 Jun 2006 14:59:33 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09109-08; Thu, 22 Jun 2006 14:59:33 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id E703D27C061; Thu, 22 Jun 2006 14:59:32 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 15:02:58 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2006 15:02:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749C5@grfint2.intern.adiscon.com> In-Reply-To: <147001c6955c$40c4d890$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secure transport alternatives Thread-Index: AcaUb4P6Rv2ZkqYHRMe0gajYe6M8FgA5HFhgACnbitA= From: "Rainer Gerhards" To: "David Harrington" , X-OriginalArrivalTime: 22 Jun 2006 13:02:58.0603 (UTC) FILETIME=[2F642FB0:01C695FC] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: Subject: [Syslog] RE: Secure transport alternatives X-BeenThere: syslog@lists.ietf.org X-Mailman-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, > Hi, >=20 > [Posting as a contributor] >=20 > I am involved in a number of NM and Security WGs, and I can make these > observations: >=20 > Running an NM protocol over SSH has been done in both netconf and > ISMS. I suspect it would be fairly easy to adapt the netconf-over-SSH > draft to work for syslog-over-SSH. I suspect it would take a week or > so to write a syslog-over-SSH draft since most could be cut-and-paste > from the netconf-over-SSH draft.=20 I have gone throught the netconf-over-ssh draft with syslog on my mind. I agree, it should be fairly easy to adapt. >=20 > I am the author of the ISMS drafts, and I adapted the netconf/SSH > draft for ISMS purposes. Syslog and netconf seem to be closer in their > requirements than syslog and ISMS. ISMS has this whole model of access > control to deal with that is not part of the threat model for syslog > or for netconf at this time.=20 >=20 > There is a parallel discussion of running syslog messages over > netconf. As Rainer has pointed out to Phil, having a consistent > terminology would be very helpful. I think having a consistent > security solution would probably be helpful in that situation as well. >=20 > I have concerns about 3195bis as the only alternative we consider, > because I have not seen much interest in RFC3195 yet, nor has there > been much expresseed interest in netconf over BEEP. I agree it is questionable if RFC 3195 will succeed. I have seen some companies (also at least one of the big guys) make investment in 3195. I am not sure if it simply is too early to abandon it. If we do not want to abandon it, we need to create a 3195bis, because 3195 will not be usable together with syslog-protocol (because it mandates a different format). >=20 > Since there may be delay involved in this WG no matter what, would > somebody be willing to volunteer to write a syslog-over-SSH draft, so > the WG can compare the three approaches?=20 After my review, I think I am able to do that. So I volunteer. >=20 > There are other possibilities as well (and I am being serious here, > not "let's make this absurd by proposing a whole slew of alteratives > documents"). > 1) Tom mentioned DTLS, which might be a viable alternative given > syslog's UDP roots. Tom would you, or somebody else, be willing to > write a proposal for syslog/DTLS? > 2) Andy Bierman observed that if syslog messages are going to be > transported over netconf, then why not simply use syslog/netconf and > let netconf deal with the security issues. That could be an > alternative proposal. Is anybody willing to write a draft proposing > that as a syslog secure transport solution? I, too, think this is an option. Wouldn't it be sufficient to adopt draft-shafer-netconf-syslog-00.txt as a WG document? (Provided Phil would be happy with that...). I guess that would obviously involve some coordination between the syslog and netconf WG, which I hope is not a big problem. Rainer >=20 > My $.02 as a contributor, >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net > =20 >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Tuesday, June 20, 2006 9:44 AM > > To: syslog@ietf.org > > Subject: [Syslog] IESG secure transport requirement can be=20 > > quickly solved... > >=20 > > Hi all, > >=20 > > I propose to update RFC 3195 in the spirit of syslog-protocol=20 > > to satisfy > > the IESG secure transport requirement (I will call this=20 > > derivative work > > RFC3195bis below). I sincerely believe that this option would=20 > > enable us > > to submit syslog-protocol, -transport-UDP and RFC3195bis within a > few > > weeks.=20 > >=20 > > My reasoning for this proposal is as follows: > >=20 > > We all know that 3195 has limited acceptance in the community and > very > > few implementations. However, it satisfies all IESG criteria=20 > > we have in > > our charter. Also, it *is* something that can be used in practice > and > > implementing it becomes easier as support libraries become visible. > I > > know it is not an optimal choice. On the other hand, we have > > syslog-transport-tls, which has been encrumbered by a patent claim. > As > > it looks, this will need months to solve. RFC3195bis can not be > taken > > hostage by any patent claims, because there is well-defined=20 > > prior art in > > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > > mission and finsh work that is in the queue for many years=20 > > now. I think > > this is urgently needed. We might even put the netconf WG with their > > syslog gateway on hold (because syslog-protocol can not be published > > without resolving the secure transport). Or netconf might=20 > > choose to drop > > syslog-protocol in order to publish. > >=20 > > And the good news is that 3195bis can definitely very quickly=20 > > be done. I > > am saying this on the assumption that we do not revisit the basics > of > > 3195 but just adopt it to syslog-protocol. I've gone through=20 > > 3195 today > > and the changes are absolutely minimal: > >=20 > > Section 2: > > Most of it simply needs to be removed because the entity roles are > > defined in syslog-protocol. > >=20 > > Section 3: > > - the message samples must be upgraded to -protocol-format > > - syslog-framing in section 3.3 must be changed (could be=20 > > octet-counting > > or disallow of multiple messages per ANS, what I recommend) > >=20 > > Section 4: > > 4.4.2=20 > > - needs to be updated with the new HEADER fields and > STRUCTURED-DATA=20 > > - some work on "deviceFQDN" and "deviceIP" needed > > - some transformation rules (page 15) need to be removed > > - handling of invalid message formatting must be removed (no longer > a > > concern) > > - samples must be adjusted > >=20 > > 4.4.3 > > - sample on page 24 (top) must be checked and/or adjusted > >=20 > > Section 7: > > - DTD needs to be adjusted > >=20 > > Section 9: > > - new URIs for 3195bis (also in some other places) > > [we can reuse well-known port 601 for -protocol] > >=20 > > Overall > > References to 3164 must be changed to -syslog-protocol. This=20 > > seems quite > > trivial, because the references are easy to spot and do not touch > any > > substance (except outlined above). > >=20 > > Other than these minor things, there are *NO* other changes > necessary. > > I'd expect that an initial version of 3195bis can be created within > a > > single working day. Add some quick review and a very limited number > of > > edits to change discovered nits - and we have something to publish > by > > summer. > >=20 > > I find this extremely tempting. It breaks the deadlock=20 > > situation we are > > currently in. Especially as we have planned to do 3195bis some time > > later anyhow. I don't know if the authors of 3195 would=20 > > volunteer to do > > the edit. But I hope so. > >=20 > > I would appreciate if the chairs could try to reach consensus on my > > proposal. > >=20 > > Comments are appreciated. > > Thanks, > > Rainer > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 11:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQoJ-0004Mu-1c; Thu, 22 Jun 2006 11:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQoI-0004Mp-09 for syslog@ietf.org; Thu, 22 Jun 2006 11:09:34 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtQoG-0007us-GW for syslog@ietf.org; Thu, 22 Jun 2006 11:09:33 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3DF4C27C065; Thu, 22 Jun 2006 17:06:04 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13894-01; Thu, 22 Jun 2006 17:06:04 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id B850F27C061; Thu, 22 Jun 2006 17:06:03 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 17:09:23 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] IESG secure transport requirement can be quicklysolved... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2006 17:09:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749C8@grfint2.intern.adiscon.com> In-Reply-To: <147101c69562$b2457d70$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] IESG secure transport requirement can be quicklysolved... Thread-Index: AcaUcpJmDDSNpEjjSR6sDkho19gobQA6XFygACv5TjA= From: "Rainer Gerhards" To: "David Harrington" , "Chris Lonvick" X-OriginalArrivalTime: 22 Jun 2006 15:09:23.0964 (UTC) FILETIME=[D89E6BC0:01C6960D] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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, WG, > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 [snip] > It is important that we make progress and not just discuss the > alternatives, ad infinitum, however. We need volunteers who are > willing to put in the work to write viable internet-drafts and drive > them to completion, or the discussions are largely useless.=20 >=20 > So, I will make these requests to help focus the discussions: > 1) please indicate which secure transports you consider to be > feasible, -transport-ssh, rfc3195bis, [-transport-tls] > 2) please indicate which secure transports address which syslog > threats (they're listed in syslog/tls), section 2 of -transport-tls, IMHO, applies to all three > 3) please indicate which secure transport you volunteer to write a > draft for, and I have acutally "written" (copy&paste plus a few sentences) something that could be a starting point for -transport-ssh: http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-transport-ssh-00pre.t xt If it is WG consensus, I can submit this as an WG document. The current version describes the overall picture plus a weak idea of framing and transmission (sections 4, 5, and 6). This idea was taken from the current discussion on -transport-tls. However, I consider it to be very insufficient and have made no attempt to specify it in depth. If we adopt this document, I would further investigate how a proper framing would look like. I have on my mind to borrough some ideas from netconf, but use them in the simple spirit of syslog (e.g. we might use the same opening with a syslog-reserved URI, if the netconf-WG does not object against this, but it is too early to discuss such issues). I would also volunteer to update 3195 to 3195bis, if their original authors are not available for that. I expect to need some help on the XML schema when doing so. As I have already written, I expect this to be an extremely easy and quick task. My summary in the other mail was concluding. There is no need for any additional edits. > 4) please indicate which secure transport you would commit to > implement in your products (and do you have the decision-making > authority to commit what gets implemented in shipping products?). With a very high probability, we would implement -transport-ssh and with a somewhat lower probability we would change our rfc 3195 implementation to support 3195bis. I would expect this to happen in our products as well as in liblogging/rsyslog (open source projects). I have sufficent decision-making authority to make this commitment (not thinking about major market or overall company policy changes). I would deeply appreciate feedback if I should submit the -transport-ssh draft as a WG document. Rainer >=20 > Disclaimer: products do not need to be commercial products; they can > be freely available implementations, such as open source libraries.=20 >=20 > Thanks, > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG=20 >=20 >=20 > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > > Sent: Tuesday, June 20, 2006 10:05 AM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] IESG secure transport requirement can=20 > > be quicklysolved... > >=20 > > Hi Everyone, > >=20 > >=20 > > On Tue, 20 Jun 2006, Rainer Gerhards wrote: > > > > > > I would appreciate if the chairs could try to reach consensus on > my > > > proposal. > > > > > > Comments are appreciated. > > > Thanks, > > > Rainer > >=20 > > I'll apologize up front for not paricipating in some recent=20 > > dicussions.=20 > > I'm on a business trip and rather busy with the day job right now. > >=20 > > I am willing to listen to a discussion of this proposal. As=20 > > Rainer says,=20 > > please provide some input and comments. > >=20 > > Thanks, > > Chris > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 11:19:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQxj-0007Yn-1H; Thu, 22 Jun 2006 11:19:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQxh-0007JY-5O for syslog@ietf.org; Thu, 22 Jun 2006 11:19:17 -0400 Received: from dsl-202-45-110-141-static.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtQxd-0000qE-Rz for syslog@ietf.org; Thu, 22 Jun 2006 11:19:17 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k5MFIc0D017937; Fri, 23 Jun 2006 01:18:38 +1000 (EST) From: Darren Reed Message-Id: <200606221518.k5MFIbW7004434@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Secure transport alternatives In-Reply-To: <166301c695f8$71cf0ae0$0400a8c0@china.huawei.com> To: David Harrington Date: Fri, 23 Jun 2006 01:18:37 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: syslog@ietf.org, Darren.Moffat@Sun.COM X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David, Your actions as co-chair of this group represent a conflict of interest for so long as Huawei maintains it has an intellectual property claim with respect to its work. I would request that you either step down as co-chair of the group, cease employment with Huawei or convince Huawei to cease the IPR action. Of course the latter two of these are not what I would call reasonable demands to make of anyone given that there are financial issues (and more) involved, but I would request that you step down as co-chair of this group. I would also ask Darren Moffat (and others within this IETF group) to ignore this request and others coming from you, regardless of their relevance to the IPR, because your involvement with Huawei makes you unfit for this role within the syslog IETF group. If you do not wish to step down then the best we can do is to ignore your attempts to continue to function in this role and continue to apply pressure for it to be resolved. This group needs to develop open standards, not IP for Huawei. Your involvement as co-chair and Huawei's IPR claim cast that shadow over this group. I'm sure we all would welcome your continued involvement with the group, just not as co-chair. If Chris is having difficulties with managing the IETF side of things by himself then I'm sure we can find someone else to fill in for you. In no way am I implying you are doing a bad role now or in the past, just that your current association makes you ineligable for being co-chair. Cheers, Darren > Hi Darren, > > I don't know them well enough to comment. > Are you willing to write one or two drafts proposing these as possible > solutions so the WG can evaluate them as alternatives? > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > -----Original Message----- > > From: Darren.Moffat@Sun.COM [mailto:Darren.Moffat@Sun.COM] > > Sent: Thursday, June 22, 2006 6:14 AM > > To: Miao Fuyou > > Cc: 'David Harrington'; 'Rainer Gerhards'; syslog@ietf.org > > Subject: Re: [Syslog] Secure transport alternatives > > > > Miao Fuyou wrote: > > > real "general" security mechanisms(except IPsec, but it is not > > > application-friendly). So, IMHO the primary criteria for > > selection is: is it > > > convenient for the application to invoke the security > > service provided by > > > the security protocol? > > > > That to me sounds like GSSAPI or SASL. > > > > Any reason these aren't being considered ? > > > > -- > > Darren J Moffat > > > > > _______________________________________________ > 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 Jun 22 11:47:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRP9-0000YK-BF; Thu, 22 Jun 2006 11:47:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRP8-0000YA-7D for syslog@ietf.org; Thu, 22 Jun 2006 11:47:38 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRP6-00048h-Oz for syslog@ietf.org; Thu, 22 Jun 2006 11:47:38 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 22 Jun 2006 08:47:36 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5MFlaQB003213 for ; Thu, 22 Jun 2006 08:47:36 -0700 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 k5MFla9t011719 for ; Thu, 22 Jun 2006 08:47:36 -0700 (PDT) Date: Thu, 22 Jun 2006 08:47:35 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1032; t=1150991256; x=1151855256; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Posting=20of=20IPR=20Disclosure=20(fwd); X=v=3Dcisco.com=3B=20h=3Dikc6AXt53bhLzvk1hpAb9CuuCoU=3D; b=kN6pWeUQTMZq3C82AoAtUGLEeSznV3Ad2vxLZeGoeU8G0o+dmUW+whOf8nQdEMyc+cHPUeJ1 Fx7lhh3Dw7lzS/mqsjWjUJOLtdXa8Kp0tRBn8bK8LiYt7YvsnP4cAu8P; Authentication-Results: sj-dkim-3.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Syslog] Posting of IPR Disclosure (fwd) X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, I've got lots in my inbox that I can't catch up to this week but this caught my eye. I have not received anything back from Huawei about the specific claim, but according to RFC 3979 they don't have to. Thanks, Chris ---------- Forwarded message ---------- Date: Wed, 21 Jun 2006 11:04:17 -0400 From: IETF Secretariat To: myz@huawei.com, miaofy@huawei.com Cc: hartmans-ietf@mit.edu, dharrington@huawei.com, clonvick@cisco.com Subject: Posting of IPR Disclosure Dear Ma Yuzhi, Fuyou Miao: An IPR disclosure that pertains to your Internet-Draft entitled "TLS Transport Mapping for SYSLOG" (draft-ietf-syslog-transport-tls) was submitted to the IETF Secretariat on 2006-06-20 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "HUAWEI TECHNOLOGIES CO.,LTD's statement about IPR claimed in draft-ietf-syslog-transport-tls-02.txt." The IETF Secretariat _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 12:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRsG-0005Tf-8z; Thu, 22 Jun 2006 12:17:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRsE-0005S8-TZ for syslog@ietf.org; Thu, 22 Jun 2006 12:17:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRsC-0007Hw-5w for syslog@ietf.org; Thu, 22 Jun 2006 12:17:42 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2006 09:17:39 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="30260477:sNHT27857732" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5MGHbYL017225; Thu, 22 Jun 2006 12:17:37 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 12:17:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Secure transport alternatives Date: Thu, 22 Jun 2006 12:17:36 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731220196AA5B@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Secure transport alternatives Thread-Index: AcaUb4P6Rv2ZkqYHRMe0gajYe6M8FgA5HFhgABk3X2AAFUpdoA== From: "Anton Okmianski \(aokmians\)" To: "Miao Fuyou" , "David Harrington" , "Rainer Gerhards" , X-OriginalArrivalTime: 22 Jun 2006 16:17:37.0546 (UTC) FILETIME=[609576A0:01C69617] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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 am not sure RFC 3195 is completely market-abandoned. Cisco has some = interest in it. Although I cannot comment on any product roadmaps.=20 Anton.=20 > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Thursday, June 22, 2006 1:49 AM > To: 'David Harrington'; 'Rainer Gerhards'; syslog@ietf.org > Subject: RE: [Syslog] Secure transport alternatives >=20 >=20 > Hi,=20 >=20 > IMO, most current security protocols(TLS, DTLS, SSH, IPsec)=20 > provide similiar > security service for application, such as confidentiality, integrity, > anti-replay and peer identity authentication. In the same=20 > time, most of the > applications share similiar security threats, such as hijacking, MITM, > falsification, eveasdropping etc. So, it may does make much=20 > sense to invest > too much effort on evaluating/matching security threats and=20 > service. In the > same time, most current security protocols come from security=20 > mechanisms > specific to some applications. For example, SSL was designed=20 > to secure HTTP, > SSH is an application protocol for interactive shell command.=20 > They are not > real "general" security mechanisms(except IPsec, but it is not > application-friendly). So, IMHO the primary criteria for=20 > selection is: is it > convenient for the application to invoke the security service=20 > provided by > the security protocol?=20 >=20 > Taking convenience in mind: the order may be: DTLS -> TLS ->=20 > SSH -> BEEP(?) > -> IPsec >=20 > >From an implementer's perspective, I think DTLS costs the=20 > least effort to > implement, TLS second. I have not much idea on how much SSH=20 > and BEEP take, > but I believe it cost more than DTLS/TLS. There is few RFC3195 > implementation, it sounds bad to revive an market-abandoned=20 > solution to just > satisfy IESG. IPsec? It costs the specifcation and program developer > nothing, but it costs too much to provision, never a good solution for > Syslog. >=20 > My 1 cent! >=20 > Miao > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > > Sent: Thursday, June 22, 2006 1:58 AM > > To: 'Rainer Gerhards'; syslog@ietf.org > > Subject: [Syslog] Secure transport alternatives > >=20 > > Hi, > >=20 > > [Posting as a contributor] > >=20 > > I am involved in a number of NM and Security WGs, and I can=20 > make these > > observations: > >=20 > > Running an NM protocol over SSH has been done in both netconf=20 > > and ISMS. I suspect it would be fairly easy to adapt the=20 > > netconf-over-SSH draft to work for syslog-over-SSH. I suspect=20 > > it would take a week or so to write a syslog-over-SSH draft=20 > > since most could be cut-and-paste from the netconf-over-SSH draft.=20 > >=20 > > I am the author of the ISMS drafts, and I adapted the=20 > > netconf/SSH draft for ISMS purposes. Syslog and netconf seem=20 > > to be closer in their requirements than syslog and ISMS. ISMS=20 > > has this whole model of access control to deal with that is=20 > > not part of the threat model for syslog or for netconf at=20 > this time.=20 > >=20 > > There is a parallel discussion of running syslog messages=20 > > over netconf. As Rainer has pointed out to Phil, having a=20 > > consistent terminology would be very helpful. I think having=20 > > a consistent security solution would probably be helpful in=20 > > that situation as well. > >=20 > > I have concerns about 3195bis as the only alternative we=20 > > consider, because I have not seen much interest in RFC3195=20 > > yet, nor has there been much expresseed interest in netconf=20 > over BEEP. > >=20 > > Since there may be delay involved in this WG no matter what,=20 > > would somebody be willing to volunteer to write a=20 > > syslog-over-SSH draft, so the WG can compare the three approaches?=20 > >=20 > > There are other possibilities as well (and I am being serious=20 > > here, not "let's make this absurd by proposing a whole slew=20 > > of alteratives documents"). > > 1) Tom mentioned DTLS, which might be a viable alternative=20 > > given syslog's UDP roots. Tom would you, or somebody else, be=20 > > willing to write a proposal for syslog/DTLS? > > 2) Andy Bierman observed that if syslog messages are going to=20 > > be transported over netconf, then why not simply use=20 > > syslog/netconf and let netconf deal with the security issues.=20 > > That could be an alternative proposal. Is anybody willing to=20 > > write a draft proposing that as a syslog secure transport solution? > >=20 > > My $.02 as a contributor, > >=20 > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > =20 > >=20 >=20 > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > > Sent: Tuesday, June 20, 2006 9:44 AM > > > To: syslog@ietf.org > > > Subject: [Syslog] IESG secure transport requirement can be=20 > > > quickly solved... > > >=20 > > > Hi all, > > >=20 > > > I propose to update RFC 3195 in the spirit of syslog-protocol=20 > > > to satisfy > > > the IESG secure transport requirement (I will call this=20 > > > derivative work > > > RFC3195bis below). I sincerely believe that this option would=20 > > > enable us > > > to submit syslog-protocol, -transport-UDP and RFC3195bis within a > > few > > > weeks.=20 > > >=20 > > > My reasoning for this proposal is as follows: > > >=20 > > > We all know that 3195 has limited acceptance in the community and > > very > > > few implementations. However, it satisfies all IESG criteria=20 > > > we have in > > > our charter. Also, it *is* something that can be used in practice > > and > > > implementing it becomes easier as support libraries=20 > become visible. > > I > > > know it is not an optimal choice. On the other hand, we have > > > syslog-transport-tls, which has been encrumbered by a=20 > patent claim. > > As > > > it looks, this will need months to solve. RFC3195bis can not be > > taken > > > hostage by any patent claims, because there is well-defined=20 > > > prior art in > > > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > > > mission and finsh work that is in the queue for many years=20 > > > now. I think > > > this is urgently needed. We might even put the netconf WG=20 > with their > > > syslog gateway on hold (because syslog-protocol can not=20 > be published > > > without resolving the secure transport). Or netconf might=20 > > > choose to drop > > > syslog-protocol in order to publish. > > >=20 > > > And the good news is that 3195bis can definitely very quickly=20 > > > be done. I > > > am saying this on the assumption that we do not revisit the basics > > of > > > 3195 but just adopt it to syslog-protocol. I've gone through=20 > > > 3195 today > > > and the changes are absolutely minimal: > > >=20 > > > Section 2: > > > Most of it simply needs to be removed because the entity roles are > > > defined in syslog-protocol. > > >=20 > > > Section 3: > > > - the message samples must be upgraded to -protocol-format > > > - syslog-framing in section 3.3 must be changed (could be=20 > > > octet-counting > > > or disallow of multiple messages per ANS, what I recommend) > > >=20 > > > Section 4: > > > 4.4.2=20 > > > - needs to be updated with the new HEADER fields and > > STRUCTURED-DATA=20 > > > - some work on "deviceFQDN" and "deviceIP" needed > > > - some transformation rules (page 15) need to be removed > > > - handling of invalid message formatting must be removed=20 > (no longer > > a > > > concern) > > > - samples must be adjusted > > >=20 > > > 4.4.3 > > > - sample on page 24 (top) must be checked and/or adjusted > > >=20 > > > Section 7: > > > - DTD needs to be adjusted > > >=20 > > > Section 9: > > > - new URIs for 3195bis (also in some other places) > > > [we can reuse well-known port 601 for -protocol] > > >=20 > > > Overall > > > References to 3164 must be changed to -syslog-protocol. This=20 > > > seems quite > > > trivial, because the references are easy to spot and do not touch > > any > > > substance (except outlined above). > > >=20 > > > Other than these minor things, there are *NO* other changes > > necessary. > > > I'd expect that an initial version of 3195bis can be=20 > created within > > a > > > single working day. Add some quick review and a very=20 > limited number > > of > > > edits to change discovered nits - and we have something to publish > > by > > > summer. > > >=20 > > > I find this extremely tempting. It breaks the deadlock=20 > > > situation we are > > > currently in. Especially as we have planned to do 3195bis=20 > some time > > > later anyhow. I don't know if the authors of 3195 would=20 > > > volunteer to do > > > the edit. But I hope so. > > >=20 > > > I would appreciate if the chairs could try to reach=20 > consensus on my > > > proposal. > > >=20 > > > Comments are appreciated. > > > Thanks, > > > Rainer > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 12:23:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRxc-0001aO-5M; Thu, 22 Jun 2006 12:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRxb-0001aJ-Is for syslog@ietf.org; Thu, 22 Jun 2006 12:23:15 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRxa-0007Y3-4b for syslog@ietf.org; Thu, 22 Jun 2006 12:23:15 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc13) with SMTP id <20060622162312m1300g56lme>; Thu, 22 Jun 2006 16:23:13 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , "'Chris Lonvick'" Subject: RE: [Syslog] IESG secure transport requirement can be quicklysolved... Date: Thu, 22 Jun 2006 12:22:00 -0400 Message-ID: <16ae01c69617$fddd97d0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA1749C8@grfint2.intern.adiscon.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaUcpJmDDSNpEjjSR6sDkho19gobQA6XFygACv5TjAAAsrPUA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, The deadline for a -00- draft has just passed, so you won't be able to publish officially until after Montreal. I recommend posting the draft to the mailing list for discussion, as a non-WG draft. By the time the I-D publication process re-opens after montreal, the WG can decide whether to have you publish as an individual or WG draft. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Thursday, June 22, 2006 11:09 AM > To: David Harrington; Chris Lonvick > Cc: syslog@ietf.org > Subject: RE: [Syslog] IESG secure transport requirement can > be quicklysolved... > > David, WG, > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > [snip] > > > It is important that we make progress and not just discuss the > > alternatives, ad infinitum, however. We need volunteers who are > > willing to put in the work to write viable internet-drafts and drive > > them to completion, or the discussions are largely useless. > > > > So, I will make these requests to help focus the discussions: > > 1) please indicate which secure transports you consider to be > > feasible, > > -transport-ssh, rfc3195bis, [-transport-tls] > > > 2) please indicate which secure transports address which syslog > > threats (they're listed in syslog/tls), > > section 2 of -transport-tls, IMHO, applies to all three > > > 3) please indicate which secure transport you volunteer to write a > > draft for, and > > I have acutally "written" (copy&paste plus a few sentences) something > that could be a starting point for -transport-ssh: > > http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-transport-s sh-00pre.t > xt > > If it is WG consensus, I can submit this as an WG document. > The current > version describes the overall picture plus a weak idea of framing and > transmission (sections 4, 5, and 6). This idea was taken from the > current discussion on -transport-tls. However, I consider it > to be very > insufficient and have made no attempt to specify it in depth. If we > adopt this document, I would further investigate how a proper framing > would look like. I have on my mind to borrough some ideas > from netconf, > but use them in the simple spirit of syslog (e.g. we might > use the same > opening with a syslog-reserved URI, if the netconf-WG does not object > against this, but it is too early to discuss such issues). > > I would also volunteer to update 3195 to 3195bis, if their original > authors are not available for that. I expect to need some help on the > XML schema when doing so. As I have already written, I expect > this to be > an extremely easy and quick task. My summary in the other mail was > concluding. There is no need for any additional edits. > > > 4) please indicate which secure transport you would commit to > > implement in your products (and do you have the decision-making > > authority to commit what gets implemented in shipping products?). > > With a very high probability, we would implement > -transport-ssh and with > a somewhat lower probability we would change our rfc 3195 > implementation > to support 3195bis. I would expect this to happen in our products as > well as in liblogging/rsyslog (open source projects). I have sufficent > decision-making authority to make this commitment (not thinking about > major market or overall company policy changes). > > I would deeply appreciate feedback if I should submit the > -transport-ssh > draft as a WG document. > > Rainer > > > > > Disclaimer: products do not need to be commercial products; they can > > be freely available implementations, such as open source libraries. > > > > Thanks, > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > co-chair, Syslog WG > > > > > > > -----Original Message----- > > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > > Sent: Tuesday, June 20, 2006 10:05 AM > > > To: Rainer Gerhards > > > Cc: syslog@ietf.org > > > Subject: Re: [Syslog] IESG secure transport requirement can > > > be quicklysolved... > > > > > > Hi Everyone, > > > > > > > > > On Tue, 20 Jun 2006, Rainer Gerhards wrote: > > > > > > > > I would appreciate if the chairs could try to reach consensus on > > my > > > > proposal. > > > > > > > > Comments are appreciated. > > > > Thanks, > > > > Rainer > > > > > > I'll apologize up front for not paricipating in some recent > > > dicussions. > > > I'm on a business trip and rather busy with the day job right now. > > > > > > I am willing to listen to a discussion of this proposal. As > > > Rainer says, > > > please provide some input and comments. > > > > > > Thanks, > > > Chris > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 12:38:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSCR-0000GO-VI; Thu, 22 Jun 2006 12:38:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSCQ-0000DE-E7 for syslog@ietf.org; Thu, 22 Jun 2006 12:38:34 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSCP-0008Lh-61 for syslog@ietf.org; Thu, 22 Jun 2006 12:38:34 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc11) with SMTP id <20060622163831m1100b05oce>; Thu, 22 Jun 2006 16:38:32 +0000 From: "David Harrington" To: , "'Miao Fuyou'" Subject: RE: [Syslog] Secure transport alternatives Date: Thu, 22 Jun 2006 12:37:19 -0400 Message-ID: <16af01c6961a$21adeb40$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <449A6D70.3080501@Sun.COM> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaV5M9SaWy6Em2gRWGQlP5+8wl15QANRyGg X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Darren, [posting as a contributor] I don't know GSSAPI or SASL well enough to evaluate their approriateness for securing syslog. Are you willing to write one or two drafts proposing these as possible solutions so the WG can evaluate them as alternatives? [posting as a contributor] David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Darren.Moffat@Sun.COM [mailto:Darren.Moffat@Sun.COM] > Sent: Thursday, June 22, 2006 6:14 AM > To: Miao Fuyou > Cc: 'David Harrington'; 'Rainer Gerhards'; syslog@ietf.org > Subject: Re: [Syslog] Secure transport alternatives > > Miao Fuyou wrote: > > real "general" security mechanisms(except IPsec, but it is not > > application-friendly). So, IMHO the primary criteria for > selection is: is it > > convenient for the application to invoke the security > service provided by > > the security protocol? > > That to me sounds like GSSAPI or SASL. > > Any reason these aren't being considered ? > > -- > Darren J Moffat > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 22 14:10:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTdb-0000Fb-1H; Thu, 22 Jun 2006 14:10:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTda-0000FU-CE for syslog@ietf.org; Thu, 22 Jun 2006 14:10:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTdX-0004kX-Qy for syslog@ietf.org; Thu, 22 Jun 2006 14:10:42 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2006 11:10:37 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="30271067:sNHT288597808" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5MIAanu026722; Thu, 22 Jun 2006 14:10:36 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 14:09:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] IESG secure transport requirement can be quicklysolved... Date: Thu, 22 Jun 2006 14:09:36 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731220196AAFC@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] IESG secure transport requirement can be quicklysolved... Thread-Index: AcaUcpJmDDSNpEjjSR6sDkho19gobQA6XFygADKeFNA= From: "Anton Okmianski \(aokmians\)" To: "David Harrington" , "Chris Lonvick \(clonvick\)" , "Rainer Gerhards" X-OriginalArrivalTime: 22 Jun 2006 18:09:37.0340 (UTC) FILETIME=[05E4A7C0:01C69627] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Wednesday, June 21, 2006 2:44 PM > To: Chris Lonvick (clonvick); 'Rainer Gerhards' > Cc: syslog@ietf.org > Subject: RE: [Syslog] IESG secure transport requirement can=20 > be quicklysolved... >=20 > Hi, >=20 > [speaking as co-chair] >=20 > I also am willing to listen to discussion of alternative proposals. As > mentioned in my contributor posting, I can see a number of > alternatives to syslog/TLS that I think might be viable. >=20 > It is important that we make progress and not just discuss the > alternatives, ad infinitum, however. We need volunteers who are > willing to put in the work to write viable internet-drafts and drive > them to completion, or the discussions are largely useless.=20 >=20 > So, I will make these requests to help focus the discussions: > 1) please indicate which secure transports you consider to be > feasible, syslog-ssh, syslog-beep (RFC 3195v2) Syslog-tls if not for IPR issues. =20 > 2) please indicate which secure transports address which syslog > threats (they're listed in syslog/tls), Same > 3) please indicate which secure transport you volunteer to write a > draft for, and None at this time. > 4) please indicate which secure transport you would commit to > implement in your products (and do you have the decision-making > authority to commit what gets implemented in shipping products?). Cisco has a genereal interest in secure transport. SSH or RFC 3195 = based transport would do. I'd be violating company policy if I were to = comment on any commitments to implement anything or any non-public = product road maps.=20 I don't think it is a reasonable request to ask for implementation = commitment at IETF. We are here as inidividuals, not companies. Any = large company will have similar policy.=20 Anton.=20 >=20 > Disclaimer: products do not need to be commercial products; they can > be freely available implementations, such as open source libraries.=20 >=20 > Thanks, > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG=20 >=20 >=20 > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > > Sent: Tuesday, June 20, 2006 10:05 AM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] IESG secure transport requirement can=20 > > be quicklysolved... > >=20 > > Hi Everyone, > >=20 > >=20 > > On Tue, 20 Jun 2006, Rainer Gerhards wrote: > > > > > > I would appreciate if the chairs could try to reach consensus on > my > > > proposal. > > > > > > Comments are appreciated. > > > Thanks, > > > Rainer > >=20 > > I'll apologize up front for not paricipating in some recent=20 > > dicussions.=20 > > I'm on a business trip and rather busy with the day job right now. > >=20 > > I am willing to listen to a discussion of this proposal. As=20 > > Rainer says,=20 > > please provide some input and comments. > >=20 > > Thanks, > > Chris > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 23 04:09:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftgiy-0007II-Rd; Fri, 23 Jun 2006 04:09:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftgiy-0007Fi-2d for syslog@ietf.org; Fri, 23 Jun 2006 04:09:08 -0400 Received: from gmpea-pix-1.sun.com ([192.18.1.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftgiw-0008H3-L5 for syslog@ietf.org; Fri, 23 Jun 2006 04:09:08 -0400 Received: from d1-emea-01.sun.com ([192.18.2.111]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5N895qX006306 for ; Fri, 23 Jun 2006 09:09:05 +0100 (BST) Received: from conversion-daemon.d1-emea-01.sun.com by d1-emea-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1A00L01ZDC2W00@d1-emea-01.sun.com> (original mail from Darren.Moffat@Sun.COM) for syslog@ietf.org; Fri, 23 Jun 2006 09:09:05 +0100 (BST) Received: from [129.150.120.103] by d1-emea-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1A0079IZZ4P760@d1-emea-01.sun.com>; Fri, 23 Jun 2006 09:09:05 +0100 (BST) Date: Fri, 23 Jun 2006 09:07:35 +0100 From: Darren J Moffat Subject: Re: [Syslog] Secure transport alternatives In-reply-to: <16af01c6961a$21adeb40$0400a8c0@china.huawei.com> To: David Harrington Message-id: <449BA147.1040001@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <16af01c6961a$21adeb40$0400a8c0@china.huawei.com> User-Agent: Mail/News 1.5.0.2 (X11/20060515) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David Harrington wrote: > Hi Darren, > > [posting as a contributor] > > I don't know GSSAPI or SASL well enough to evaluate their > approriateness for securing syslog. > Are you willing to write one or two drafts proposing these as possible > solutions so the WG can evaluate them as alternatives? > > [posting as a contributor] I'll see what I can do but I'm not sure if I have the time available in the next couple of months. -- Darren J Moffat _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 23 06:05:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtiXg-0005fW-VJ; Fri, 23 Jun 2006 06:05:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtiXf-0005fR-Qs for syslog@ietf.org; Fri, 23 Jun 2006 06:05:35 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtiXc-0008M6-8B for syslog@ietf.org; Fri, 23 Jun 2006 06:05:35 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1B00J135E6SH@szxga01-in.huawei.com> for syslog@ietf.org; Fri, 23 Jun 2006 18:06:06 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1B004ZL5E5AV@szxga01-in.huawei.com> for syslog@ietf.org; Fri, 23 Jun 2006 18:06:06 +0800 (CST) Received: from m19684 ([10.110.114.232]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1B00HEI5T6T8@szxml04-in.huawei.com> for syslog@ietf.org; Fri, 23 Jun 2006 18:15:10 +0800 (CST) Date: Fri, 23 Jun 2006 18:04:19 +0800 From: Miao Fuyou Subject: RE: [Syslog] IESG secure transport requirement can be quicklysolved... In-reply-to: <147101c69562$b2457d70$0400a8c0@china.huawei.com> To: 'David Harrington' , 'Chris Lonvick' , 'Rainer Gerhards' Message-id: <037d01c696ac$64daa5b0$e8726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaUcpJmDDSNpEjjSR6sDkho19gobQA6XFygAFP0raA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > So, I will make these requests to help focus the discussions: > 1) please indicate which secure transports you consider to be > feasible, TLS/DTLS/SSH/BEEP/GSSAPI > 2) please indicate which secure transports address which > syslog threats (they're listed in syslog/tls), Similiar > 3) please indicate which secure transport you volunteer to > write a draft for, and > 4) please indicate which secure transport you would commit to > implement in your products (and do you have the > decision-making authority to commit what gets implemented in > shipping products?).> TLS/DTLS -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, June 22, 2006 2:44 AM > To: 'Chris Lonvick'; 'Rainer Gerhards' > Cc: syslog@ietf.org > Subject: RE: [Syslog] IESG secure transport requirement can > be quicklysolved... > > Hi, > > [speaking as co-chair] > > I also am willing to listen to discussion of alternative > proposals. As mentioned in my contributor posting, I can see > a number of alternatives to syslog/TLS that I think might be viable. > > It is important that we make progress and not just discuss > the alternatives, ad infinitum, however. We need volunteers > who are willing to put in the work to write viable > internet-drafts and drive them to completion, or the > discussions are largely useless. > > So, I will make these requests to help focus the discussions: > 1) please indicate which secure transports you consider to be > feasible, TLS/DTLS > 2) please indicate which secure transports address which > syslog threats (they're listed in syslog/tls), > 3) please indicate which secure transport you volunteer to > write a draft for, and > 4) please indicate which secure transport you would commit to > implement in your products (and do you have the > decision-making authority to commit what gets implemented in > shipping products?). > > Disclaimer: products do not need to be commercial products; > they can be freely available implementations, such as open > source libraries. > > Thanks, > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > > > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Tuesday, June 20, 2006 10:05 AM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] IESG secure transport requirement can > > be quicklysolved... > > > > Hi Everyone, > > > > > > On Tue, 20 Jun 2006, Rainer Gerhards wrote: > > > > > > I would appreciate if the chairs could try to reach consensus on > my > > > proposal. > > > > > > Comments are appreciated. > > > Thanks, > > > Rainer > > > > I'll apologize up front for not paricipating in some recent > > dicussions. > > I'm on a business trip and rather busy with the day job right now. > > > > I am willing to listen to a discussion of this proposal. As > > Rainer says, > > please provide some input and comments. > > > > Thanks, > > Chris > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 23 08:25:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftkib-0000Uv-Bb; Fri, 23 Jun 2006 08:25:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtkiZ-0000Uo-NB for syslog@ietf.org; Fri, 23 Jun 2006 08:24:59 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtkiY-0006a9-6C for syslog@ietf.org; Fri, 23 Jun 2006 08:24:59 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 4746127C065; Fri, 23 Jun 2006 14:21:27 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15486-05; Fri, 23 Jun 2006 14:21:27 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id DD06627C061; Fri, 23 Jun 2006 14:21:26 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 14:24:50 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] IESG secure transport requirement can be quicklysolved... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jun 2006 14:24:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1749DE@grfint2.intern.adiscon.com> In-Reply-To: <16ae01c69617$fddd97d0$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] IESG secure transport requirement can be quicklysolved... Thread-Index: AcaUcpJmDDSNpEjjSR6sDkho19gobQA6XFygACv5TjAAAsrPUAAqK0ag From: "Rainer Gerhards" To: "David Harrington" X-OriginalArrivalTime: 23 Jun 2006 12:24:50.0395 (UTC) FILETIME=[05ED1AB0:01C696C0] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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 David, thanks for the advise, I will do as suggested. I am currently thinking about the framing used inside the session. Once ready, I will publish it on my website and send a link to the WG. I would appreciate, though, some feedback on the overall picture based on what I currently have: http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-transport-ssh-00pre.t xt=20 Thanks, Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, June 22, 2006 6:22 PM > To: Rainer Gerhards; 'Chris Lonvick' > Cc: syslog@ietf.org > Subject: RE: [Syslog] IESG secure transport requirement can=20 > be quicklysolved... >=20 > Hi Rainer, >=20 > The deadline for a -00- draft has just passed, so you won't be able to > publish officially until after Montreal. I recommend posting the draft > to the mailing list for discussion, as a non-WG draft.=20 >=20 > By the time the I-D publication process re-opens after montreal, the > WG can decide whether to have you publish as an individual or WG > draft. >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net > =20 >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Thursday, June 22, 2006 11:09 AM > > To: David Harrington; Chris Lonvick > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] IESG secure transport requirement can=20 > > be quicklysolved... > >=20 > > David, WG, > >=20 > > > -----Original Message----- > > > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > >=20 > > [snip] > >=20 > > > It is important that we make progress and not just discuss the > > > alternatives, ad infinitum, however. We need volunteers who are > > > willing to put in the work to write viable internet-drafts and > drive > > > them to completion, or the discussions are largely useless.=20 > > >=20 > > > So, I will make these requests to help focus the discussions: > > > 1) please indicate which secure transports you consider to be > > > feasible, > >=20 > > -transport-ssh, rfc3195bis, [-transport-tls] > >=20 > > > 2) please indicate which secure transports address which syslog > > > threats (they're listed in syslog/tls), > >=20 > > section 2 of -transport-tls, IMHO, applies to all three > >=20 > > > 3) please indicate which secure transport you volunteer to write a > > > draft for, and > >=20 > > I have acutally "written" (copy&paste plus a few sentences) > something > > that could be a starting point for -transport-ssh: > >=20 > > http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-transport-s > sh-00pre.t > > xt > >=20 > > If it is WG consensus, I can submit this as an WG document.=20 > > The current > > version describes the overall picture plus a weak idea of framing > and > > transmission (sections 4, 5, and 6). This idea was taken from the > > current discussion on -transport-tls. However, I consider it=20 > > to be very > > insufficient and have made no attempt to specify it in depth. If we > > adopt this document, I would further investigate how a proper > framing > > would look like. I have on my mind to borrough some ideas=20 > > from netconf, > > but use them in the simple spirit of syslog (e.g. we might=20 > > use the same > > opening with a syslog-reserved URI, if the netconf-WG does not > object > > against this, but it is too early to discuss such issues). > >=20 > > I would also volunteer to update 3195 to 3195bis, if their original > > authors are not available for that. I expect to need some help on > the > > XML schema when doing so. As I have already written, I expect=20 > > this to be > > an extremely easy and quick task. My summary in the other mail was > > concluding. There is no need for any additional edits. > >=20 > > > 4) please indicate which secure transport you would commit to > > > implement in your products (and do you have the decision-making > > > authority to commit what gets implemented in shipping products?). > >=20 > > With a very high probability, we would implement=20 > > -transport-ssh and with > > a somewhat lower probability we would change our rfc 3195=20 > > implementation > > to support 3195bis. I would expect this to happen in our products as > > well as in liblogging/rsyslog (open source projects). I have > sufficent > > decision-making authority to make this commitment (not thinking > about > > major market or overall company policy changes). > >=20 > > I would deeply appreciate feedback if I should submit the=20 > > -transport-ssh > > draft as a WG document. > >=20 > > Rainer > >=20 > > >=20 > > > Disclaimer: products do not need to be commercial products; they > can > > > be freely available implementations, such as open source > libraries.=20 > > >=20 > > > Thanks, > > > David Harrington > > > dharrington@huawei.com=20 > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > co-chair, Syslog WG=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > > > > Sent: Tuesday, June 20, 2006 10:05 AM > > > > To: Rainer Gerhards > > > > Cc: syslog@ietf.org > > > > Subject: Re: [Syslog] IESG secure transport requirement can=20 > > > > be quicklysolved... > > > >=20 > > > > Hi Everyone, > > > >=20 > > > >=20 > > > > On Tue, 20 Jun 2006, Rainer Gerhards wrote: > > > > > > > > > > I would appreciate if the chairs could try to reach consensus > on > > > my > > > > > proposal. > > > > > > > > > > Comments are appreciated. > > > > > Thanks, > > > > > Rainer > > > >=20 > > > > I'll apologize up front for not paricipating in some recent=20 > > > > dicussions.=20 > > > > I'm on a business trip and rather busy with the day job right > now. > > > >=20 > > > > I am willing to listen to a discussion of this proposal. As=20 > > > > Rainer says,=20 > > > > please provide some input and comments. > > > >=20 > > > > Thanks, > > > > Chris > > > >=20 > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 26 17:50:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuyy6-0001lC-M1; Mon, 26 Jun 2006 17:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuyy5-0001gk-NE for syslog@ietf.org; Mon, 26 Jun 2006 17:50:05 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuyy4-0002qd-01 for syslog@ietf.org; Mon, 26 Jun 2006 17:50:05 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2006 14:49:46 -0700 X-IronPort-AV: i="4.06,178,1149490800"; d="scan'208,217"; a="1832952144:sNHT1992854720" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k5QLnkI2014727; Mon, 26 Jun 2006 14:49:46 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5QLnXJC002595; Mon, 26 Jun 2006 14:49:45 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 17:49:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] IESG secure transport requirement can be quickly solved... Date: Mon, 26 Jun 2006 17:49:41 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122019C12C0@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] IESG secure transport requirement can be quickly solved... Thread-Index: AcaUb4P6Rv2ZkqYHRMe0gajYe6M8FgE9SeTA From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" X-OriginalArrivalTime: 26 Jun 2006 21:49:43.0002 (UTC) FILETIME=[6EBBC3A0:01C6996A] DKIM-Signature: a=rsa-sha1; q=dns; l=6841; t=1151358586; x=1152222586; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20IESG=20secure=20transport=20requirement=20can=20be=20 quickly=20solved...; X=v=3Dcisco.com=3B=20h=3D4n76BoXEtkA/a3PZAooWjRdBDX8=3D; b=ayz8T/iw6KryicEiBVAge10h4T3X61ZBALiXrIm0jHuGROmKdVyCLjsRnvh8lRqhHjikB1MR FrEQ5iW9z/QF0UOWCjaZouqEFnwF8A1rq31IvQFsKiy66nMUuXOFigqC; Authentication-Results: sj-dkim-6.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Rainer: A few thoughts on 3195bis. Generally, I like the idea of app-layer ACKs. = =20 1. I think the format would need to be changed a bit more than you = suggested. If you do XML, you should do it all the way -- not mix it = with special delimiters. Structured data, for example, should be = encoded as normal XML using separate tags instead of text separators as = in syslog protocol. This means it can't go as an attribute in entry = tag. It needs separate tags. Possibly something like:
... ... ... aaa bbb
... Basically, you will need a new XSD. BTW, I can't find XSD for 3195. 2. XSD needs to be defined in a way that allows extensions in headers = and body. For example, XSD could support Body as anyType allowing the = use of simple strings or inserting XML there without escaping it. I am = not clear if currently XML in tag has to be escaped in 3195bis. = =20 3. If you allow custom XML payload, people could use this as a transport = for events defined elsewhere, enabling syslog to become really more = about transport. For example, IBM contributed their extensive XML schema = for events to OASIS. See CBE format announcement: = http://xml.coverpages.org/xmlPapers200308.html#IBM-CBEvent=20 4. If one defined XSD and all, should we consider defining a standard = WSDL (same XSD as above) and switch to standard SOAP over HTTP mapping = instead of BEEP. You just need to define 4 messages: ClientIdentity(ClientIdentity) - "iam" equivalent ClientIdentityResponse(Status) ReportEvent(Message) - "entry" ReportEventResponse(Status) (Client identity could be included in Message for simplicity - reduces = this to two RPCs.) I think this would have greater chance of being adopted than XML over = BEEP. WS-I.org has developed a lot of interoperability and security = profiles (TLS) for SOAP already and a bunch of tools to validate it. As = a result, you can use any number of free high-quality interoperable = libraries off the shelf.=20 I can generate sample WSDL if it helps people think about this. WSDL = being a formal specification of protocol messaging and with abundance of = good quality WS-I specs to reference the draft could be pretty = streamlined. Given sufficient interest in WG, I could throw some rough = draft together pretty quickly. =20 Basically, I think if we do XML-based RPC mechanism, doing something = other than SOAP over HTTP is really not aiding interop. Sorry to stir = the pot with further alternatives. :( Thoughts? Thanks, Anton.=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Tuesday, June 20, 2006 9:44 AM > To: syslog@ietf.org > Subject: [Syslog] IESG secure transport requirement can be=20 > quickly solved... >=20 > Hi all, >=20 > I propose to update RFC 3195 in the spirit of syslog-protocol=20 > to satisfy > the IESG secure transport requirement (I will call this=20 > derivative work > RFC3195bis below). I sincerely believe that this option would=20 > enable us > to submit syslog-protocol, -transport-UDP and RFC3195bis within a few > weeks.=20 >=20 > My reasoning for this proposal is as follows: >=20 > We all know that 3195 has limited acceptance in the community and very > few implementations. However, it satisfies all IESG criteria=20 > we have in > our charter. Also, it *is* something that can be used in practice and > implementing it becomes easier as support libraries become visible. I > know it is not an optimal choice. On the other hand, we have > syslog-transport-tls, which has been encrumbered by a patent claim. As > it looks, this will need months to solve. RFC3195bis can not be taken > hostage by any patent claims, because there is well-defined=20 > prior art in > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > mission and finsh work that is in the queue for many years=20 > now. I think > this is urgently needed. We might even put the netconf WG with their > syslog gateway on hold (because syslog-protocol can not be published > without resolving the secure transport). Or netconf might=20 > choose to drop > syslog-protocol in order to publish. >=20 > And the good news is that 3195bis can definitely very quickly=20 > be done. I > am saying this on the assumption that we do not revisit the basics of > 3195 but just adopt it to syslog-protocol. I've gone through=20 > 3195 today > and the changes are absolutely minimal: >=20 > Section 2: > Most of it simply needs to be removed because the entity roles are > defined in syslog-protocol. >=20 > Section 3: > - the message samples must be upgraded to -protocol-format > - syslog-framing in section 3.3 must be changed (could be=20 > octet-counting > or disallow of multiple messages per ANS, what I recommend) >=20 > Section 4: > 4.4.2=20 > - needs to be updated with the new HEADER fields and STRUCTURED-DATA=20 > - some work on "deviceFQDN" and "deviceIP" needed > - some transformation rules (page 15) need to be removed > - handling of invalid message formatting must be removed (no longer a > concern) > - samples must be adjusted >=20 > 4.4.3 > - sample on page 24 (top) must be checked and/or adjusted >=20 > Section 7: > - DTD needs to be adjusted >=20 > Section 9: > - new URIs for 3195bis (also in some other places) > [we can reuse well-known port 601 for -protocol] >=20 > Overall > References to 3164 must be changed to -syslog-protocol. This=20 > seems quite > trivial, because the references are easy to spot and do not touch any > substance (except outlined above). >=20 > Other than these minor things, there are *NO* other changes necessary. > I'd expect that an initial version of 3195bis can be created within a > single working day. Add some quick review and a very limited number of > edits to change discovered nits - and we have something to publish by > summer. >=20 > I find this extremely tempting. It breaks the deadlock=20 > situation we are > currently in. Especially as we have planned to do 3195bis some time > later anyhow. I don't know if the authors of 3195 would=20 > volunteer to do > the edit. But I hope so. >=20 > I would appreciate if the chairs could try to reach consensus on my > proposal. >=20 > Comments are appreciated. > Thanks, > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 27 05:01:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv9Rg-0000cf-0Y; Tue, 27 Jun 2006 05:01:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv9Re-0000ca-EH for syslog@ietf.org; Tue, 27 Jun 2006 05:01:18 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv9Rb-0007tB-GU for syslog@ietf.org; Tue, 27 Jun 2006 05:01:18 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 8450427C065; Tue, 27 Jun 2006 10:57:32 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28978-04; Tue, 27 Jun 2006 10:57:32 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 08DAB27C061; Tue, 27 Jun 2006 10:57:31 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 11:01:05 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] IESG secure transport requirement can be quickly solved... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jun 2006 11:01:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174A22@grfint2.intern.adiscon.com> In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122019C12C0@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] IESG secure transport requirement can be quickly solved... Thread-Index: AcaUb4P6Rv2ZkqYHRMe0gajYe6M8FgE9SeTAABcJ77A= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" X-OriginalArrivalTime: 27 Jun 2006 09:01:05.0701 (UTC) FILETIME=[3917D550:01C699C8] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd 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 Anton, many thanks for your well thought-out mail. My apologies that I provide a more general answer. I see a lot of truth in your thoughts. I support some of them, on some I have a slightly different opinion. But I think the big question is *when* to do all that. The last thing this WG published was RFC 3195, in November 2001. Since then, we have done - 18 revisions of syslog-sign - 7 revisions of syslog-mib - 17 revisions of syslog-protocol - 7 revisions of syslog-transport udp - 2 revisions of syslog-transport tls We have had big discussions, we also have been re-iterating some issues ever and ever again. We have missed charter milestones repeatedly. We are are also (rightfully, IMHO) threatend by the IESG announcement that the WG will be concluded if we will miss our current milestones again. So while I agree there is lot that could be changed, I also think we are in the deperate need to finally publish. The current approach documented in -protocol and -udp might not be perfect, but I think it is a good-enough compromise. What I suggest is that we do not touch any essentials of these documents, at least not now. Let's look at finishing a secure transport, so that we actually can publish. RFC 3195bis with the few alterations I described still looks like a good candidate to me. One reason for this is that some companies have made investment into RFC 3195. If we now do not do 3195bis, we will actually render their investment useless(because unmodified 3195 will not be able to be used with -protocol). It is minimal effort to update 3195. I suspect this helps preserve some considerable investment. So we should do it - but without touching the basics, just adopting it. Much of the same reasoning applies to syslog-tls, except that existing investment (in terms of effort required) is much lower. -transport-ssh might also be a good alternative. But I have some concerns to create it with a too simplistic framing, just to get it finished. If it is something being done from scratch, it would pay to do it right in the first place. I have also begun to very seriously look at the netconf documents and watch the discussion that's going on there. NETCONF is talking much about event notifications these days. I begin to like the NETCONF way of doing things and think we can at least adopt some things from there. I highly suggest people from this WG to watch what NETCONF is doing. My proposed course of action is as follows: We should do NOW: 1. minor edits to -protocol and -transport-udp as need arises 2.1 update 3195 to 3195bis [I volunteer to do that if the original authors are not available] 2.2 (finish -transport-tls) [interest in this might be affected by IPR claim) =20 PUBLISH As soon as 2.1 or 2.2 is finshed, we should publish this work. Do not wait for the non-finished 2.x part. My preferrence is to focus on updating 3195 because there is existing investment to be preserved. We should do THEN: 1. More transports - think about a generic stream framing=20 [after thoughtful consideration, I am again=20 of the opinion that a -transport-stream is useful] I volunteer to write this and already have some ideas. - define syslog-transport-ssh via transport-stream I already have written a rough proposal which I consider to be a starting point. - define/update syslog-transport-tls via transport-stream - eventually update RFC 3195bis to support -transport-stream semantics and the data model=20 in 2. below 2. think about a data model for syslog messages [probably best done in the OPS and not the SEC area of the IETF] 3. eventually update -protocol to cover XML STRUCTURED-DATA [may be a side-effect of 2. above] If you follow my proposal, you see that some work is done twice. For example, I accept to publish -protocol as it is today but revisit it some time in the not so distant future. One can argue that this leads to implementation effort that would not necessarily be needed if we wait for the "final" version. HOWEVER, experience tells me that there is never something like a "final version". You even always can do things better. But if you always wait for the best solution, you will never have any solution in the first place. This is where I think this WG is heading to. I suggest that we accept our faith and publish the imperfect (but well-discussed) drafts we currently have. We should try to do this ASAP. I have a strong argument on my side: if we do not do that by the end of the year (which quickly approaches), we will not publish anything - of course that avoids publishing imperfect draft but at the price of never publishing "perfect" ones. The current state of non-standardization is by far worse than publishing what we have. We are also beginning to hinder other standardization efforts (namely NETCONF) because they are refering to I-Ds which we discuss eternally ;) I hope this clarifies my position on the big picture. I would really appreciate if we could concentrate on publishing. Again, I strongly suggest to create 3195bis, satisfy the IETF secure transport criteria with that, PUBLISH and then carry on with all the well thought-out ideas we have. Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Monday, June 26, 2006 11:50 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] IESG secure transport requirement can=20 > be quickly solved... >=20 > Rainer: >=20 > A few thoughts on 3195bis. Generally, I like the idea of=20 > app-layer ACKs. =20 >=20 > 1. I think the format would need to be changed a bit more=20 > than you suggested. If you do XML, you should do it all the=20 > way -- not mix it with special delimiters. Structured data,=20 > for example, should be encoded as normal XML using separate=20 > tags instead of text separators as in syslog protocol. This=20 > means it can't go as an attribute in entry tag. It needs=20 > separate tags. Possibly something like: >=20 > >
> ... > ... > > ... > > > > aaa > bbb > > >
> > ... > > >=20 > Basically, you will need a new XSD. BTW, I can't find XSD for 3195. >=20 > 2. XSD needs to be defined in a way that allows extensions in=20 > headers and body. For example, XSD could support Body as=20 > anyType allowing the use of simple strings or inserting XML=20 > there without escaping it. I am not clear if currently XML in=20 > tag has to be escaped in 3195bis. =20 >=20 > 3. If you allow custom XML payload, people could use this as=20 > a transport for events defined elsewhere, enabling syslog to=20 > become really more about transport. For example, IBM=20 > contributed their extensive XML schema for events to OASIS.=20 > See CBE format announcement:=20 > http://xml.coverpages.org/xmlPapers200308.html#IBM-CBEvent=20 >=20 > 4. If one defined XSD and all, should we consider defining a=20 > standard WSDL (same XSD as above) and switch to standard SOAP=20 > over HTTP mapping instead of BEEP. You just need to define 4=20 > messages: >=20 > ClientIdentity(ClientIdentity) - "iam" equivalent > ClientIdentityResponse(Status) > ReportEvent(Message) - "entry" > ReportEventResponse(Status) >=20 > (Client identity could be included in Message for simplicity=20 > - reduces this to two RPCs.) >=20 > I think this would have greater chance of being adopted than=20 > XML over BEEP. WS-I.org has developed a lot of=20 > interoperability and security profiles (TLS) for SOAP already=20 > and a bunch of tools to validate it. As a result, you can=20 > use any number of free high-quality interoperable libraries=20 > off the shelf.=20 >=20 > I can generate sample WSDL if it helps people think about=20 > this. WSDL being a formal specification of protocol messaging=20 > and with abundance of good quality WS-I specs to reference=20 > the draft could be pretty streamlined. Given sufficient=20 > interest in WG, I could throw some rough draft together=20 > pretty quickly. =20 >=20 > Basically, I think if we do XML-based RPC mechanism, doing=20 > something other than SOAP over HTTP is really not aiding=20 > interop. Sorry to stir the pot with further alternatives. :( >=20 > Thoughts? >=20 > Thanks, > Anton.=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Tuesday, June 20, 2006 9:44 AM > > To: syslog@ietf.org > > Subject: [Syslog] IESG secure transport requirement can be=20 > > quickly solved... > >=20 > > Hi all, > >=20 > > I propose to update RFC 3195 in the spirit of syslog-protocol=20 > > to satisfy > > the IESG secure transport requirement (I will call this=20 > > derivative work > > RFC3195bis below). I sincerely believe that this option would=20 > > enable us > > to submit syslog-protocol, -transport-UDP and RFC3195bis=20 > within a few > > weeks.=20 > >=20 > > My reasoning for this proposal is as follows: > >=20 > > We all know that 3195 has limited acceptance in the=20 > community and very > > few implementations. However, it satisfies all IESG criteria=20 > > we have in > > our charter. Also, it *is* something that can be used in=20 > practice and > > implementing it becomes easier as support libraries become=20 > visible. I > > know it is not an optimal choice. On the other hand, we have > > syslog-transport-tls, which has been encrumbered by a=20 > patent claim. As > > it looks, this will need months to solve. RFC3195bis can=20 > not be taken > > hostage by any patent claims, because there is well-defined=20 > > prior art in > > RFC 3195. Focussing on RFC 3195bis would enable us to complete our > > mission and finsh work that is in the queue for many years=20 > > now. I think > > this is urgently needed. We might even put the netconf WG with their > > syslog gateway on hold (because syslog-protocol can not be published > > without resolving the secure transport). Or netconf might=20 > > choose to drop > > syslog-protocol in order to publish. > >=20 > > And the good news is that 3195bis can definitely very quickly=20 > > be done. I > > am saying this on the assumption that we do not revisit the=20 > basics of > > 3195 but just adopt it to syslog-protocol. I've gone through=20 > > 3195 today > > and the changes are absolutely minimal: > >=20 > > Section 2: > > Most of it simply needs to be removed because the entity roles are > > defined in syslog-protocol. > >=20 > > Section 3: > > - the message samples must be upgraded to -protocol-format > > - syslog-framing in section 3.3 must be changed (could be=20 > > octet-counting > > or disallow of multiple messages per ANS, what I recommend) > >=20 > > Section 4: > > 4.4.2=20 > > - needs to be updated with the new HEADER fields and=20 > STRUCTURED-DATA=20 > > - some work on "deviceFQDN" and "deviceIP" needed > > - some transformation rules (page 15) need to be removed > > - handling of invalid message formatting must be removed=20 > (no longer a > > concern) > > - samples must be adjusted > >=20 > > 4.4.3 > > - sample on page 24 (top) must be checked and/or adjusted > >=20 > > Section 7: > > - DTD needs to be adjusted > >=20 > > Section 9: > > - new URIs for 3195bis (also in some other places) > > [we can reuse well-known port 601 for -protocol] > >=20 > > Overall > > References to 3164 must be changed to -syslog-protocol. This=20 > > seems quite > > trivial, because the references are easy to spot and do=20 > not touch any > > substance (except outlined above). > >=20 > > Other than these minor things, there are *NO* other changes=20 > necessary. > > I'd expect that an initial version of 3195bis can be=20 > created within a > > single working day. Add some quick review and a very=20 > limited number of > > edits to change discovered nits - and we have something to=20 > publish by > > summer. > >=20 > > I find this extremely tempting. It breaks the deadlock=20 > > situation we are > > currently in. Especially as we have planned to do 3195bis some time > > later anyhow. I don't know if the authors of 3195 would=20 > > volunteer to do > > the edit. But I hope so. > >=20 > > I would appreciate if the chairs could try to reach consensus on my > > proposal. > >=20 > > Comments are appreciated. > > Thanks, > > Rainer > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 28 13:56:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FveGi-00061B-Rk; Wed, 28 Jun 2006 13:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FveGh-000611-DE for syslog@ietf.org; Wed, 28 Jun 2006 13:56:03 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FveGe-00028C-UY for syslog@ietf.org; Wed, 28 Jun 2006 13:56:03 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 28 Jun 2006 10:56:00 -0700 X-IronPort-AV: i="4.06,189,1149490800"; d="scan'208"; a="1834123745:sNHT75371320" 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 k5SHtxMA029704 for ; Wed, 28 Jun 2006 10:55:59 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5SHtxCV014832 for ; Wed, 28 Jun 2006 10:55:59 -0700 (PDT) Date: Wed, 28 Jun 2006 10:55:59 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=5235; t=1151517359; x=1152381359; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Decisions=20to=20make=20about=20the=20Huawei=20IPR=20claim; X=v=3Dcisco.com=3B=20h=3DAMxeMJXSLShclZqgQ6VUlmFFu4s=3D; b=cO8NawBWWBbrwua7mPH2VlHuYR7H3wqi2xDNksf6vTd4PLbSW1ag/HsQZHbGqXGZGxMzIdVA fuSUHcHnZIm5XxAWwpk7eoKGog3qAwYGgWgcJX7U31M/U1WJYUuDkK1h; Authentication-Results: sj-dkim-2.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [Syslog] Decisions to make about the Huawei IPR claim X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, It's looking like we have a primary decision to make about the IPR claim that Huawei has made on syslog-transport-tls. First and foremost, I want everyone to be informed of the IETF stand on IPR claims and on the IETF process that we will follow. This is the position of the IETF on IPR claims: ------------------------------------------------------------------------- Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. ------------------------------------------------------------------------- This is at the bottom of all RFCs. It's pretty clear that we (our Working Group) has no place to appeal claims of IPR to. Also, the more detailed explanation of the IETF position is in BCP 79: http://www.ietf.org/rfc/rfc3979.txt I will ask that everyone read through this before expressing their opinion. One additional source of information for our process is RFC 3669: http://www.ietf.org/rfc/rfc3669.txt "Guidelines for Working Groups on Intellectual Property Issues" ------------------------------------------------------------------------- 1. Introduction This memo lays out a conceptual framework and rules of thumb to assist working groups dealing with IPR issues. The goal is to achieve a balance between the needs of IPR claimants and the implementers of IETF standards which is appropriate to current times. As part of trying to distill out principles for dealing with IPR in IETF working groups, it provides case studies of working group IPR treatment. In other words, it documents the running code of the IETF process. This memo does not describe IPR procedures for document authors or IPR claimants. Those are covered in two other memos, on submission rights [5] and IPR in the IETF [6]. Rather, this memo is for working groups that are trying to decide what to do about technology contributions which have associated IPR claims. ------------------------------------------------------------------------- [5] and [6] are BCP78 and BCP79 respecively. This document contains a lot of really good advice that we should be aware of while we make our decision. One part of RFC 3669 is a recommendation to take a critical look at the terms of the claim - Section 5.6. Essentially, if we can get consensus that the terms are acceptable for implementation, then the IPR claim may not be an issue - we can continue to progress syslog-transport-tls. On the other hand, if the terms are not acceptable then we can't expect any implementations. I'm going to ask that everyone please start considering these inputs and openly discuss your thoughts about the IETF process and the options available to our Working Group on the mailing list. +++ +++ +++ +++ +++ +++ +++ +++ +++ Do not declare your opinion yet. +++ +++ +++ +++ +++ +++ +++ +++ +++ In a week or so I will ask the group to decide how we should process. I want everyone to take the time now to get acquainted with the process and the information that we have available to us. I believe that ultimately, we will need to decide on whether to continue to progress syslog-transport-tls, or if we will want to accept a different path. If we start down a new path, then we will still need to make sure that we are meeting the security objectives that we feel are important. This discussion has already been started, which is good in that it can bringing to light some of the issues that need to be discussed around the secure transport of syslog. Once we get this primary issue resolved then we can decide upon that. Also, the Milestone about delivering a TLS solution can be easily changed. I did submit it that way to the IESG and Tom Petch noted that the Charter just said "security" protocol while the Goal specified a specific solution. Sam didn't want to change it after it had gone in but I'm certain that it's not going to be a problem if we do want to change it. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 29 05:11:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvsYa-0005x8-N0; Thu, 29 Jun 2006 05:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvsYZ-0005qx-Hj for syslog@ietf.org; Thu, 29 Jun 2006 05:11:27 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvsYU-0000Sv-QU for syslog@ietf.org; Thu, 29 Jun 2006 05:11:27 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 0886727C065; Thu, 29 Jun 2006 11:07:33 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02797-05; Thu, 29 Jun 2006 11:07:32 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 5E04927C061; Thu, 29 Jun 2006 11:07:32 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 11:11:20 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jun 2006 11:11:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174A88@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Decisions to make about the Huawei IPR claim Thread-Index: Acaa3EiOng4KrbaFSXKf9aYL7q19aQAfVmew From: "Rainer Gerhards" To: "Chris Lonvick" , X-OriginalArrivalTime: 29 Jun 2006 09:11:20.0026 (UTC) FILETIME=[FC15E3A0:01C69B5B] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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 Besides the somewhat political issue, I think there is also technical issue that affects the question. I think we should consider that question in parallel to the IPR question. This question is if this WG intends to do a revision of 3195. And, if so, I think the very close next question is if we "just" update it to support syslog-protocol or if we intend to make any substantial changes. I see a relationship between the IPR and the 3195bis issue because 3195bis modifies the "cost" of finding alternate solutions. Coming to this point, it would probably be helpful if we could actually weigh cost vs. utlity of the different approaches. IPR, IMHO, is just a cost, obviously one whose weight we need to decide on. But I think it is not the only cost. If the WG finds such a "cost vs. utility" discussion useful, I could document my point of view as a starting point. I volunteer to create a summary document (a public web page, not a I-D) where I track all contributions to this discussion (for an example of what I have in mind see Juergen Schoenwaelder's page on netconf notification requirements: http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications). I would find such a page very helpful. It documents the decision process and the decision criteria. In doing that, it helps us come to a better decison because we than have all facts at a single place. Thus, it also provides good argument when dealing with the IESG (in the case we need to justify the decision).=20 Thanks, Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Wednesday, June 28, 2006 7:56 PM > To: syslog@ietf.org > Subject: [Syslog] Decisions to make about the Huawei IPR claim >=20 > Hi Folks, >=20 > It's looking like we have a primary decision to make about=20 > the IPR claim=20 > that Huawei has made on syslog-transport-tls. First and=20 > foremost, I want=20 > everyone to be informed of the IETF stand on IPR claims and=20 > on the IETF=20 > process that we will follow. >=20 > This is the position of the IETF on IPR claims: > -------------------------------------------------------------- > ----------- > Intellectual Property >=20 > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might=20 > be claimed to > pertain to the implementation or use of the technology=20 > described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. =20 > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. >=20 > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission=20 > for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR=20 > repository at > http://www.ietf.org/ipr. >=20 > The IETF invites any interested party to bring to its=20 > attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > -------------------------------------------------------------- > ----------- > This is at the bottom of all RFCs. It's pretty clear that we=20 > (our Working=20 > Group) has no place to appeal claims of IPR to. >=20 > Also, the more detailed explanation of the IETF position is in BCP 79: > http://www.ietf.org/rfc/rfc3979.txt > I will ask that everyone read through this before expressing their=20 > opinion. >=20 > One additional source of information for our process is RFC 3669: > http://www.ietf.org/rfc/rfc3669.txt > "Guidelines for Working Groups on Intellectual Property Issues" > -------------------------------------------------------------- > ----------- > 1. Introduction >=20 > This memo lays out a conceptual framework and rules of thumb to > assist working groups dealing with IPR issues. The goal is to > achieve a balance between the needs of IPR claimants and the > implementers of IETF standards which is appropriate to=20 > current times. > As part of trying to distill out principles for dealing=20 > with IPR in > IETF working groups, it provides case studies of working group IPR > treatment. In other words, it documents the running code=20 > of the IETF > process. >=20 > This memo does not describe IPR procedures for document authors or > IPR claimants. Those are covered in two other memos, on=20 > submission > rights [5] and IPR in the IETF [6]. Rather, this memo is=20 > for working > groups that are trying to decide what to do about technology > contributions which have associated IPR claims. > -------------------------------------------------------------- > ----------- > [5] and [6] are BCP78 and BCP79 respecively. > This document contains a lot of really good advice that we=20 > should be aware=20 > of while we make our decision. >=20 > One part of RFC 3669 is a recommendation to take a critical=20 > look at the=20 > terms of the claim - Section 5.6. Essentially, if we can get=20 > consensus=20 > that the terms are acceptable for implementation, then the=20 > IPR claim may=20 > not be an issue - we can continue to progress=20 > syslog-transport-tls. On=20 > the other hand, if the terms are not acceptable then we can't=20 > expect any=20 > implementations. >=20 > I'm going to ask that everyone please start considering these=20 > inputs and=20 > openly discuss your thoughts about the IETF process and the options=20 > available to our Working Group on the mailing list. > +++ +++ +++ +++ +++ +++ +++ +++ +++ > Do not declare your opinion yet. > +++ +++ +++ +++ +++ +++ +++ +++ +++ > In a week or so I will ask the group to decide how we should=20 > process. I=20 > want everyone to take the time now to get acquainted with the=20 > process and=20 > the information that we have available to us. >=20 > I believe that ultimately, we will need to decide on whether=20 > to continue=20 > to progress syslog-transport-tls, or if we will want to=20 > accept a different=20 > path. If we start down a new path, then we will still need=20 > to make sure=20 > that we are meeting the security objectives that we feel are=20 > important.=20 > This discussion has already been started, which is good in that it can > bringing to light some of the issues that need to be=20 > discussed around the=20 > secure transport of syslog. Once we get this primary issue=20 > resolved then=20 > we can decide upon that. >=20 > Also, the Milestone about delivering a TLS solution can be=20 > easily changed.=20 > I did submit it that way to the IESG and Tom Petch noted that=20 > the Charter=20 > just said "security" protocol while the Goal specified a specific=20 > solution. Sam didn't want to change it after it had gone in but I'm=20 > certain that it's not going to be a problem if we do want to=20 > change it. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 29 14:33:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw1Kf-0002Bj-4c; Thu, 29 Jun 2006 14:33:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw1Kd-00025z-Px for syslog@ietf.org; Thu, 29 Jun 2006 14:33:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw1Kd-00007C-KQ for syslog@ietf.org; Thu, 29 Jun 2006 14:33:39 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fw1KZ-00010H-Tg for syslog@ietf.org; Thu, 29 Jun 2006 14:33:39 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc13) with SMTP id <2006062918333201300b2orce>; Thu, 29 Jun 2006 18:33:32 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , "'Chris Lonvick'" , Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim Date: Thu, 29 Jun 2006 14:32:19 -0400 Message-ID: <0aae01c69baa$5ad82c60$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acaa3EiOng4KrbaFSXKf9aYL7q19aQAfVmewABM/w6A= In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174A88@grfint2.intern.adiscon.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, [speaking as a contributor] This WG needs to deliver documents soon or the WG could be closed. We need to deliver a secure transport solution. If the WG decides to do a 3195bis as the secure transport solution, I recommend the short-term deliverable be "good enough" to work with syslog-protocol. That way we can get 3195bis AND the other documents (-protocol- and -udp-) published and onto the standards track, so the industry can begin to implement, and the WG can stay open to do additional work. Then we can address whether the 3195 design should be modified in other ways. There have been suggestions to modify 3195 to "harmonize" with the work of other Standards Development Organizations such as OASIS and W3C. Doing that work would likely not be quick or easy. I fear it would be a real rathole that would prevent us getting 3195bis published at all, and if 3195bis is the WG's choice as the secure transport protocol, then that rathole would also prevent the publication of -protocol- and -udp- on a timely basis. As a 14-year veteran of IETF WG efforts, I think it would be a bad WG decision to put 3195bis on the critical path and to open it up to a rathole discussion. If 3195bis is on the critical path, we need to avoid the rathole discussion for now; it can be considered for a future "release". If the WG feels the rathole discussion is really necessary, and 3195bis should not be done without having had such a possible-rathole discussion, then 3195bis should not be put on the critical path. My $.02 David Harrington ietfdbh@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Thursday, June 29, 2006 5:11 AM > To: Chris Lonvick; syslog@ietf.org > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > Besides the somewhat political issue, I think there is also technical > issue that affects the question. I think we should consider that > question in parallel to the IPR question. > > This question is if this WG intends to do a revision of 3195. And, if > so, I think the very close next question is if we "just" update it to > support syslog-protocol or if we intend to make any > substantial changes. > > I see a relationship between the IPR and the 3195bis issue because > 3195bis modifies the "cost" of finding alternate solutions. Coming to > this point, it would probably be helpful if we could actually > weigh cost > vs. utlity of the different approaches. IPR, IMHO, is just a cost, > obviously one whose weight we need to decide on. But I think it is not > the only cost. If the WG finds such a "cost vs. utility" discussion > useful, I could document my point of view as a starting point. I > volunteer to create a summary document (a public web page, not a I-D) > where I track all contributions to this discussion (for an example of > what I have in mind see Juergen Schoenwaelder's page on netconf > notification requirements: > http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications). > > I would find such a page very helpful. It documents the > decision process > and the decision criteria. In doing that, it helps us come to a better > decison because we than have all facts at a single place. > Thus, it also > provides good argument when dealing with the IESG (in the case we need > to justify the decision). > > Thanks, > Rainer > > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Wednesday, June 28, 2006 7:56 PM > > To: syslog@ietf.org > > Subject: [Syslog] Decisions to make about the Huawei IPR claim > > > > Hi Folks, > > > > It's looking like we have a primary decision to make about > > the IPR claim > > that Huawei has made on syslog-transport-tls. First and > > foremost, I want > > everyone to be informed of the IETF stand on IPR claims and > > on the IETF > > process that we will follow. > > > > This is the position of the IETF on IPR claims: > > -------------------------------------------------------------- > > ----------- > > Intellectual Property > > > > The IETF takes no position regarding the validity or > scope of any > > Intellectual Property Rights or other rights that might > > be claimed to > > pertain to the implementation or use of the technology > > described in > > this document or the extent to which any license under > such rights > > might or might not be available; nor does it represent > that it has > > made any independent effort to identify any such rights. > > Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > > > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission > > for the use of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR > > repository at > > http://www.ietf.org/ipr. > > > > The IETF invites any interested party to bring to its > > attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required > to implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > > -------------------------------------------------------------- > > ----------- > > This is at the bottom of all RFCs. It's pretty clear that we > > (our Working > > Group) has no place to appeal claims of IPR to. > > > > Also, the more detailed explanation of the IETF position is > in BCP 79: > > http://www.ietf.org/rfc/rfc3979.txt > > I will ask that everyone read through this before expressing their > > opinion. > > > > One additional source of information for our process is RFC 3669: > > http://www.ietf.org/rfc/rfc3669.txt > > "Guidelines for Working Groups on Intellectual Property Issues" > > -------------------------------------------------------------- > > ----------- > > 1. Introduction > > > > This memo lays out a conceptual framework and rules of thumb to > > assist working groups dealing with IPR issues. The goal is to > > achieve a balance between the needs of IPR claimants and the > > implementers of IETF standards which is appropriate to > > current times. > > As part of trying to distill out principles for dealing > > with IPR in > > IETF working groups, it provides case studies of > working group IPR > > treatment. In other words, it documents the running code > > of the IETF > > process. > > > > This memo does not describe IPR procedures for document > authors or > > IPR claimants. Those are covered in two other memos, on > > submission > > rights [5] and IPR in the IETF [6]. Rather, this memo is > > for working > > groups that are trying to decide what to do about technology > > contributions which have associated IPR claims. > > -------------------------------------------------------------- > > ----------- > > [5] and [6] are BCP78 and BCP79 respecively. > > This document contains a lot of really good advice that we > > should be aware > > of while we make our decision. > > > > One part of RFC 3669 is a recommendation to take a critical > > look at the > > terms of the claim - Section 5.6. Essentially, if we can get > > consensus > > that the terms are acceptable for implementation, then the > > IPR claim may > > not be an issue - we can continue to progress > > syslog-transport-tls. On > > the other hand, if the terms are not acceptable then we can't > > expect any > > implementations. > > > > I'm going to ask that everyone please start considering these > > inputs and > > openly discuss your thoughts about the IETF process and the options > > available to our Working Group on the mailing list. > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > Do not declare your opinion yet. > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > In a week or so I will ask the group to decide how we should > > process. I > > want everyone to take the time now to get acquainted with the > > process and > > the information that we have available to us. > > > > I believe that ultimately, we will need to decide on whether > > to continue > > to progress syslog-transport-tls, or if we will want to > > accept a different > > path. If we start down a new path, then we will still need > > to make sure > > that we are meeting the security objectives that we feel are > > important. > > This discussion has already been started, which is good in > that it can > > bringing to light some of the issues that need to be > > discussed around the > > secure transport of syslog. Once we get this primary issue > > resolved then > > we can decide upon that. > > > > Also, the Milestone about delivering a TLS solution can be > > easily changed. > > I did submit it that way to the IESG and Tom Petch noted that > > the Charter > > just said "security" protocol while the Goal specified a specific > > solution. Sam didn't want to change it after it had gone > in but I'm > > certain that it's not going to be a problem if we do want to > > change it. > > > > Thanks, > > Chris > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 30 06:18:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwG51-00013m-0O; Fri, 30 Jun 2006 06:18:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwG4D-0000VI-T8 for syslog@ietf.org; Fri, 30 Jun 2006 06:17:41 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwFyK-00078w-2O for syslog@ietf.org; Fri, 30 Jun 2006 06:11:38 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 959AA27C065; Fri, 30 Jun 2006 12:07:42 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04948-04; Fri, 30 Jun 2006 12:07:42 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 0941927C061; Fri, 30 Jun 2006 12:07:41 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 12:11:30 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Jun 2006 12:11:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174ABF@grfint2.intern.adiscon.com> In-Reply-To: <0aae01c69baa$5ad82c60$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Decisions to make about the Huawei IPR claim Thread-Index: Acaa3EiOng4KrbaFSXKf9aYL7q19aQAfVmewABM/w6AAIN0g0A== From: "Rainer Gerhards" To: "David Harrington" , "Chris Lonvick" , X-OriginalArrivalTime: 30 Jun 2006 10:11:30.0334 (UTC) FILETIME=[8E68EBE0:01C69C2D] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David, I fully agree with your thought. I, too, think we must put emphasis on the delivery of documents. In my personal opinion, this leaves only two realistic options: a) rfc 3195bis as you have described it (without the "rathole discussion") b) -transport-tls more or less as it is now I think there are enough comments on a) already in the list archive. I will not repeat them. Comments on b) currently tend to focus on the IPR issue. Let's ignore that for a moment and look at other arguments. We have intially opted in favor of -transport-tls because it already is in widespread use. What is done currently can not be standardized literally, but we can standardize something that is quite close to it. It was our opinion that -transport-tls should by fairly easy to implement, thus bringing some immediate value to the community. Now some technical issues have come up on the list, things like app-layer ACKs, opening and closeing conversations. I have brought up some of them. I am also of the view that we could craft a better framing, probably borrowing from NETCONF (and thus easing conversion - the "big picture"). This is still sufficiently easy, but it is a big departure from the "let's standardize what is used in practice" approach. I fear that discussing a better framing/session management again takes up a lot of time and includes a high risk of missing our milestones again. BTW: we are scheduled to deliver by November 2006, and I do not expect that we will be granted an extension this time again. November will be very soon, especially looking at the summer break. So I propose that we do NOT enter any new discussion. We should deliver either a) or b) (above), without introducing any new features or ideas. That means that the result will be sub-optimal. But delivering something usable is much better than aiming for the perfect one that will never appear. Once we have delivered, we should discuss what to do next (but only AFTER delivery). I have to admit that I now see some good points in a -transport-ssh and consider it implementable with reasonable effort. However, -transport-ssh should be done after we have reconsidered the framing. Given the track record of this WG, I would suspect this can not be done in less than 12 to 24 month. There are also the issues that Anton brought up and the general question on configuration and event data models for syslog. A lot of useful work lying ahead (but depending on our ability to finish the base stuff first). I think this work can never be done if this WG fails. So I am desperately trying to get us to publish. I think what we have is useful and well-enough. If we do not publish soon, we will never be able to publish at all. IMHO, we have already received our third chance and there will be no fourth... Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, June 29, 2006 8:32 PM > To: Rainer Gerhards; 'Chris Lonvick'; syslog@ietf.org > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim >=20 > Hi Rainer, >=20 > [speaking as a contributor] >=20 > This WG needs to deliver documents soon or the WG could be closed.=20 > We need to deliver a secure transport solution. > If the WG decides to do a 3195bis as the secure transport solution, I > recommend the short-term deliverable be "good enough" to work with > syslog-protocol. That way we can get 3195bis AND the other documents > (-protocol- and -udp-) published and onto the standards track, so the > industry can begin to implement, and the WG can stay open to do > additional work. >=20 > Then we can address whether the 3195 design should be modified in > other ways. There have been suggestions to modify 3195 to "harmonize" > with the work of other Standards Development Organizations such as > OASIS and W3C. Doing that work would likely not be quick or easy. I > fear it would be a real rathole that would prevent us getting 3195bis > published at all, and if 3195bis is the WG's choice as the secure > transport protocol, then that rathole would also prevent the > publication of -protocol- and -udp- on a timely basis. >=20 > As a 14-year veteran of IETF WG efforts, I think it would be a bad WG > decision to put 3195bis on the critical path and to open it up to a > rathole discussion. If 3195bis is on the critical path, we need to > avoid the rathole discussion for now; it can be considered for a > future "release". If the WG feels the rathole discussion is really > necessary, and 3195bis should not be done without having had such a > possible-rathole discussion, then 3195bis should not be put on the > critical path. >=20 > My $.02 > David Harrington > ietfdbh@comcast.net >=20 >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Thursday, June 29, 2006 5:11 AM > > To: Chris Lonvick; syslog@ietf.org > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > >=20 > > Besides the somewhat political issue, I think there is also > technical > > issue that affects the question. I think we should consider that > > question in parallel to the IPR question. > >=20 > > This question is if this WG intends to do a revision of 3195. And, > if > > so, I think the very close next question is if we "just" update it > to > > support syslog-protocol or if we intend to make any=20 > > substantial changes. > >=20 > > I see a relationship between the IPR and the 3195bis issue because > > 3195bis modifies the "cost" of finding alternate solutions. Coming > to > > this point, it would probably be helpful if we could actually=20 > > weigh cost > > vs. utlity of the different approaches. IPR, IMHO, is just a cost, > > obviously one whose weight we need to decide on. But I think it is > not > > the only cost. If the WG finds such a "cost vs. utility" discussion > > useful, I could document my point of view as a starting point. I > > volunteer to create a summary document (a public web page, not a > I-D) > > where I track all contributions to this discussion (for an example > of > > what I have in mind see Juergen Schoenwaelder's page on netconf > > notification requirements: > > http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications). > >=20 > > I would find such a page very helpful. It documents the=20 > > decision process > > and the decision criteria. In doing that, it helps us come to a > better > > decison because we than have all facts at a single place.=20 > > Thus, it also > > provides good argument when dealing with the IESG (in the case we > need > > to justify the decision).=20 > >=20 > > Thanks, > > Rainer > >=20 > > > -----Original Message----- > > > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > > > Sent: Wednesday, June 28, 2006 7:56 PM > > > To: syslog@ietf.org > > > Subject: [Syslog] Decisions to make about the Huawei IPR claim > > >=20 > > > Hi Folks, > > >=20 > > > It's looking like we have a primary decision to make about=20 > > > the IPR claim=20 > > > that Huawei has made on syslog-transport-tls. First and=20 > > > foremost, I want=20 > > > everyone to be informed of the IETF stand on IPR claims and=20 > > > on the IETF=20 > > > process that we will follow. > > >=20 > > > This is the position of the IETF on IPR claims: > > > -------------------------------------------------------------- > > > ----------- > > > Intellectual Property > > >=20 > > > The IETF takes no position regarding the validity or=20 > > scope of any > > > Intellectual Property Rights or other rights that might=20 > > > be claimed to > > > pertain to the implementation or use of the technology=20 > > > described in > > > this document or the extent to which any license under=20 > > such rights > > > might or might not be available; nor does it represent=20 > > that it has > > > made any independent effort to identify any such rights. =20 > > > Information > > > on the procedures with respect to rights in RFC documents can > be > > > found in BCP 78 and BCP 79. > > >=20 > > > Copies of IPR disclosures made to the IETF Secretariat and any > > > assurances of licenses to be made available, or the result of > an > > > attempt made to obtain a general license or permission=20 > > > for the use of > > > such proprietary rights by implementers or users of this > > > specification can be obtained from the IETF on-line IPR=20 > > > repository at > > > http://www.ietf.org/ipr. > > >=20 > > > The IETF invites any interested party to bring to its=20 > > > attention any > > > copyrights, patents or patent applications, or other > proprietary > > > rights that may cover technology that may be required=20 > > to implement > > > this standard. Please address the information to the IETF at > > > ietf-ipr@ietf.org. > > > -------------------------------------------------------------- > > > ----------- > > > This is at the bottom of all RFCs. It's pretty clear that we=20 > > > (our Working=20 > > > Group) has no place to appeal claims of IPR to. > > >=20 > > > Also, the more detailed explanation of the IETF position is=20 > > in BCP 79: > > > http://www.ietf.org/rfc/rfc3979.txt > > > I will ask that everyone read through this before expressing their >=20 > > > opinion. > > >=20 > > > One additional source of information for our process is RFC 3669: > > > http://www.ietf.org/rfc/rfc3669.txt > > > "Guidelines for Working Groups on Intellectual Property Issues" > > > -------------------------------------------------------------- > > > ----------- > > > 1. Introduction > > >=20 > > > This memo lays out a conceptual framework and rules of thumb > to > > > assist working groups dealing with IPR issues. The goal is to > > > achieve a balance between the needs of IPR claimants and the > > > implementers of IETF standards which is appropriate to=20 > > > current times. > > > As part of trying to distill out principles for dealing=20 > > > with IPR in > > > IETF working groups, it provides case studies of=20 > > working group IPR > > > treatment. In other words, it documents the running code=20 > > > of the IETF > > > process. > > >=20 > > > This memo does not describe IPR procedures for document=20 > > authors or > > > IPR claimants. Those are covered in two other memos, on=20 > > > submission > > > rights [5] and IPR in the IETF [6]. Rather, this memo is=20 > > > for working > > > groups that are trying to decide what to do about technology > > > contributions which have associated IPR claims. > > > -------------------------------------------------------------- > > > ----------- > > > [5] and [6] are BCP78 and BCP79 respecively. > > > This document contains a lot of really good advice that we=20 > > > should be aware=20 > > > of while we make our decision. > > >=20 > > > One part of RFC 3669 is a recommendation to take a critical=20 > > > look at the=20 > > > terms of the claim - Section 5.6. Essentially, if we can get=20 > > > consensus=20 > > > that the terms are acceptable for implementation, then the=20 > > > IPR claim may=20 > > > not be an issue - we can continue to progress=20 > > > syslog-transport-tls. On=20 > > > the other hand, if the terms are not acceptable then we can't=20 > > > expect any=20 > > > implementations. > > >=20 > > > I'm going to ask that everyone please start considering these=20 > > > inputs and=20 > > > openly discuss your thoughts about the IETF process and the > options=20 > > > available to our Working Group on the mailing list. > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > Do not declare your opinion yet. > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > In a week or so I will ask the group to decide how we should=20 > > > process. I=20 > > > want everyone to take the time now to get acquainted with the=20 > > > process and=20 > > > the information that we have available to us. > > >=20 > > > I believe that ultimately, we will need to decide on whether=20 > > > to continue=20 > > > to progress syslog-transport-tls, or if we will want to=20 > > > accept a different=20 > > > path. If we start down a new path, then we will still need=20 > > > to make sure=20 > > > that we are meeting the security objectives that we feel are=20 > > > important.=20 > > > This discussion has already been started, which is good in=20 > > that it can > > > bringing to light some of the issues that need to be=20 > > > discussed around the=20 > > > secure transport of syslog. Once we get this primary issue=20 > > > resolved then=20 > > > we can decide upon that. > > >=20 > > > Also, the Milestone about delivering a TLS solution can be=20 > > > easily changed.=20 > > > I did submit it that way to the IESG and Tom Petch noted that=20 > > > the Charter=20 > > > just said "security" protocol while the Goal specified a specific=20 > > > solution. Sam didn't want to change it after it had gone=20 > > in but I'm=20 > > > certain that it's not going to be a problem if we do want to=20 > > > change it. > > >=20 > > > Thanks, > > > Chris > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 30 11:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLOP-0002Iq-3Y; Fri, 30 Jun 2006 11:58:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLON-0002Il-KF for syslog@ietf.org; Fri, 30 Jun 2006 11:58:51 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwLOM-0001oj-0f for syslog@ietf.org; Fri, 30 Jun 2006 11:58:51 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc15) with SMTP id <2006063015584801500r5ooge>; Fri, 30 Jun 2006 15:58:49 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , "'Chris Lonvick'" , Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim Date: Fri, 30 Jun 2006 11:57:35 -0400 Message-ID: <0d5601c69c5d$e78ff260$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acaa3EiOng4KrbaFSXKf9aYL7q19aQAfVmewABM/w6AAIN0g0AAL14Ww In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174ABF@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2f46977da373544777a750d5247d6ccc Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [posting as a contributor] I recommend this WG make a clear separation (as much as is possible) between issues of security and issues of network management. Issues such as harmonization with the work of other SDOs, integration with netconf, message formatting, content standardization, and so on, are about syslog as a network management protocol. I strongly beleve this work should **not** be done by the syslog-sec WG, but in a WG chartered in the OPS area or the Application area, not the Security area. There are many contributors who have worked on, and are currently working on, other network management protocols and have addressed issues similar to those facing syslog. In addition, there is an effort by the new OPS Management AD to address the current isolated decision making (silos) that is occurring regarding the management plane throughout the IETF. The contributors to this WG should be involved in that discussion, which is likely to be centered in the OPS area. This WG is about security for syslog, and we should focus our efforts on solving the security problems, whether with tls or ssh or beep, and publish. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Friday, June 30, 2006 6:11 AM > To: David Harrington; Chris Lonvick; syslog@ietf.org > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > David, > > I fully agree with your thought. I, too, think we must put emphasis on > the delivery of documents. In my personal opinion, this > leaves only two > realistic options: > > a) rfc 3195bis as you have described it (without the "rathole > discussion") > b) -transport-tls more or less as it is now > > I think there are enough comments on a) already in the list archive. I > will not repeat them. > > Comments on b) currently tend to focus on the IPR issue. Let's ignore > that for a moment and look at other arguments. We have > intially opted in > favor of -transport-tls because it already is in widespread > use. What is > done currently can not be standardized literally, but we can > standardize > something that is quite close to it. It was our opinion that > -transport-tls should by fairly easy to implement, thus bringing some > immediate value to the community. > > Now some technical issues have come up on the list, things like > app-layer ACKs, opening and closeing conversations. I have brought up > some of them. I am also of the view that we could craft a better > framing, probably borrowing from NETCONF (and thus easing conversion - > the "big picture"). This is still sufficiently easy, but it is a big > departure from the "let's standardize what is used in practice" > approach. I fear that discussing a better framing/session management > again takes up a lot of time and includes a high risk of missing our > milestones again. BTW: we are scheduled to deliver by > November 2006, and > I do not expect that we will be granted an extension this time again. > November will be very soon, especially looking at the summer break. > > So I propose that we do NOT enter any new discussion. We > should deliver > either a) or b) (above), without introducing any new features > or ideas. > That means that the result will be sub-optimal. But > delivering something > usable is much better than aiming for the perfect one that will never > appear. > > Once we have delivered, we should discuss what to do next (but only > AFTER delivery). I have to admit that I now see some good points in a > -transport-ssh and consider it implementable with reasonable effort. > However, -transport-ssh should be done after we have reconsidered the > framing. Given the track record of this WG, I would suspect > this can not > be done in less than 12 to 24 month. There are also the issues that > Anton brought up and the general question on configuration and event > data models for syslog. A lot of useful work lying ahead (but > depending > on our ability to finish the base stuff first). > > I think this work can never be done if this WG fails. So I am > desperately trying to get us to publish. I think what we have > is useful > and well-enough. If we do not publish soon, we will never be able to > publish at all. IMHO, we have already received our third chance and > there will be no fourth... > > Rainer > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Thursday, June 29, 2006 8:32 PM > > To: Rainer Gerhards; 'Chris Lonvick'; syslog@ietf.org > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > Hi Rainer, > > > > [speaking as a contributor] > > > > This WG needs to deliver documents soon or the WG could be closed. > > We need to deliver a secure transport solution. > > If the WG decides to do a 3195bis as the secure transport > solution, I > > recommend the short-term deliverable be "good enough" to work with > > syslog-protocol. That way we can get 3195bis AND the other documents > > (-protocol- and -udp-) published and onto the standards > track, so the > > industry can begin to implement, and the WG can stay open to do > > additional work. > > > > Then we can address whether the 3195 design should be modified in > > other ways. There have been suggestions to modify 3195 to > "harmonize" > > with the work of other Standards Development Organizations such as > > OASIS and W3C. Doing that work would likely not be quick or easy. I > > fear it would be a real rathole that would prevent us > getting 3195bis > > published at all, and if 3195bis is the WG's choice as the secure > > transport protocol, then that rathole would also prevent the > > publication of -protocol- and -udp- on a timely basis. > > > > As a 14-year veteran of IETF WG efforts, I think it would > be a bad WG > > decision to put 3195bis on the critical path and to open it up to a > > rathole discussion. If 3195bis is on the critical path, we need to > > avoid the rathole discussion for now; it can be considered for a > > future "release". If the WG feels the rathole discussion is really > > necessary, and 3195bis should not be done without having had such a > > possible-rathole discussion, then 3195bis should not be put on the > > critical path. > > > > My $.02 > > David Harrington > > ietfdbh@comcast.net > > > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Thursday, June 29, 2006 5:11 AM > > > To: Chris Lonvick; syslog@ietf.org > > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > > > Besides the somewhat political issue, I think there is also > > technical > > > issue that affects the question. I think we should consider that > > > question in parallel to the IPR question. > > > > > > This question is if this WG intends to do a revision of 3195. And, > > if > > > so, I think the very close next question is if we "just" update it > > to > > > support syslog-protocol or if we intend to make any > > > substantial changes. > > > > > > I see a relationship between the IPR and the 3195bis issue because > > > 3195bis modifies the "cost" of finding alternate solutions. Coming > > to > > > this point, it would probably be helpful if we could actually > > > weigh cost > > > vs. utlity of the different approaches. IPR, IMHO, is just a cost, > > > obviously one whose weight we need to decide on. But I think it is > > not > > > the only cost. If the WG finds such a "cost vs. utility" > discussion > > > useful, I could document my point of view as a starting point. I > > > volunteer to create a summary document (a public web page, not a > > I-D) > > > where I track all contributions to this discussion (for an example > > of > > > what I have in mind see Juergen Schoenwaelder's page on netconf > > > notification requirements: > > > > http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications). > > > > > > I would find such a page very helpful. It documents the > > > decision process > > > and the decision criteria. In doing that, it helps us come to a > > better > > > decison because we than have all facts at a single place. > > > Thus, it also > > > provides good argument when dealing with the IESG (in the case we > > need > > > to justify the decision). > > > > > > Thanks, > > > Rainer > > > > > > > -----Original Message----- > > > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > > > Sent: Wednesday, June 28, 2006 7:56 PM > > > > To: syslog@ietf.org > > > > Subject: [Syslog] Decisions to make about the Huawei IPR claim > > > > > > > > Hi Folks, > > > > > > > > It's looking like we have a primary decision to make about > > > > the IPR claim > > > > that Huawei has made on syslog-transport-tls. First and > > > > foremost, I want > > > > everyone to be informed of the IETF stand on IPR claims and > > > > on the IETF > > > > process that we will follow. > > > > > > > > This is the position of the IETF on IPR claims: > > > > -------------------------------------------------------------- > > > > ----------- > > > > Intellectual Property > > > > > > > > The IETF takes no position regarding the validity or > > > scope of any > > > > Intellectual Property Rights or other rights that might > > > > be claimed to > > > > pertain to the implementation or use of the technology > > > > described in > > > > this document or the extent to which any license under > > > such rights > > > > might or might not be available; nor does it represent > > > that it has > > > > made any independent effort to identify any such rights. > > > > Information > > > > on the procedures with respect to rights in RFC > documents can > > be > > > > found in BCP 78 and BCP 79. > > > > > > > > Copies of IPR disclosures made to the IETF > Secretariat and any > > > > assurances of licenses to be made available, or the > result of > > an > > > > attempt made to obtain a general license or permission > > > > for the use of > > > > such proprietary rights by implementers or users of this > > > > specification can be obtained from the IETF on-line IPR > > > > repository at > > > > http://www.ietf.org/ipr. > > > > > > > > The IETF invites any interested party to bring to its > > > > attention any > > > > copyrights, patents or patent applications, or other > > proprietary > > > > rights that may cover technology that may be required > > > to implement > > > > this standard. Please address the information to > the IETF at > > > > ietf-ipr@ietf.org. > > > > -------------------------------------------------------------- > > > > ----------- > > > > This is at the bottom of all RFCs. It's pretty clear that we > > > > (our Working > > > > Group) has no place to appeal claims of IPR to. > > > > > > > > Also, the more detailed explanation of the IETF position is > > > in BCP 79: > > > > http://www.ietf.org/rfc/rfc3979.txt > > > > I will ask that everyone read through this before > expressing their > > > > > > opinion. > > > > > > > > One additional source of information for our process is > RFC 3669: > > > > http://www.ietf.org/rfc/rfc3669.txt > > > > "Guidelines for Working Groups on Intellectual Property Issues" > > > > -------------------------------------------------------------- > > > > ----------- > > > > 1. Introduction > > > > > > > > This memo lays out a conceptual framework and rules of thumb > > to > > > > assist working groups dealing with IPR issues. The > goal is to > > > > achieve a balance between the needs of IPR claimants and the > > > > implementers of IETF standards which is appropriate to > > > > current times. > > > > As part of trying to distill out principles for dealing > > > > with IPR in > > > > IETF working groups, it provides case studies of > > > working group IPR > > > > treatment. In other words, it documents the running code > > > > of the IETF > > > > process. > > > > > > > > This memo does not describe IPR procedures for document > > > authors or > > > > IPR claimants. Those are covered in two other memos, on > > > > submission > > > > rights [5] and IPR in the IETF [6]. Rather, this memo is > > > > for working > > > > groups that are trying to decide what to do about technology > > > > contributions which have associated IPR claims. > > > > -------------------------------------------------------------- > > > > ----------- > > > > [5] and [6] are BCP78 and BCP79 respecively. > > > > This document contains a lot of really good advice that we > > > > should be aware > > > > of while we make our decision. > > > > > > > > One part of RFC 3669 is a recommendation to take a critical > > > > look at the > > > > terms of the claim - Section 5.6. Essentially, if we can get > > > > consensus > > > > that the terms are acceptable for implementation, then the > > > > IPR claim may > > > > not be an issue - we can continue to progress > > > > syslog-transport-tls. On > > > > the other hand, if the terms are not acceptable then we can't > > > > expect any > > > > implementations. > > > > > > > > I'm going to ask that everyone please start considering these > > > > inputs and > > > > openly discuss your thoughts about the IETF process and the > > options > > > > available to our Working Group on the mailing list. > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > Do not declare your opinion yet. > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > In a week or so I will ask the group to decide how we should > > > > process. I > > > > want everyone to take the time now to get acquainted with the > > > > process and > > > > the information that we have available to us. > > > > > > > > I believe that ultimately, we will need to decide on whether > > > > to continue > > > > to progress syslog-transport-tls, or if we will want to > > > > accept a different > > > > path. If we start down a new path, then we will still need > > > > to make sure > > > > that we are meeting the security objectives that we feel are > > > > important. > > > > This discussion has already been started, which is good in > > > that it can > > > > bringing to light some of the issues that need to be > > > > discussed around the > > > > secure transport of syslog. Once we get this primary issue > > > > resolved then > > > > we can decide upon that. > > > > > > > > Also, the Milestone about delivering a TLS solution can be > > > > easily changed. > > > > I did submit it that way to the IESG and Tom Petch noted that > > > > the Charter > > > > just said "security" protocol while the Goal specified > a specific > > > > solution. Sam didn't want to change it after it had gone > > > in but I'm > > > > certain that it's not going to be a problem if we do want to > > > > change it. > > > > > > > > Thanks, > > > > Chris > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 30 14:23:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwNeH-0006RP-GO; Fri, 30 Jun 2006 14:23:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwNeF-0006RK-N5 for syslog@ietf.org; Fri, 30 Jun 2006 14:23:23 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwNeC-0003YT-8o for syslog@ietf.org; Fri, 30 Jun 2006 14:23:23 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 30 Jun 2006 12:23:12 -0600 Message-Id: <44A517A9.37FF.0081.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Fri, 30 Jun 2006 12:23:05 -0600 From: "John Calcote" To: "'Chris Lonvick'" , "David Harrington" , "'Rainer Gerhards'" , Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim References: <577465F99B41C842AAFBE9ED71E70ABA174ABF@grfint2.intern.adiscon.com> <0d5601c69c5d$e78ff260$0400a8c0@china.huawei.com> In-Reply-To: <0d5601c69c5d$e78ff260$0400a8c0@china.huawei.com> Mime-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0849990480==" Errors-To: syslog-bounces@lists.ietf.org --===============0849990480== Content-Type: multipart/alternative; boundary="=__PartFCD91019.3__=" --=__PartFCD91019.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jumping in to add my two cents... I quite agree with David on this point. If the syslog WG chose to begin work on network management issues, it would be stepping into a realm already well covered by other standards efforts. However - what the world does need is a standardized and widely understood and deployed _secure_transport_ for management events. One that will guarantee deliver and sequencing, as well as privacy based on administrative policy. I work for Novell on the Audit Record Framework (ARF) - a part of the Bandit Project (http://www.bandit-project.org). ARF is chartered to provide an open source, portable, application audit instrumentation library based on existing standards work. We've chosen to use the OASIS WSDM Event Format - a W3C XML Schema-based approach. The ARF library will send management events over a secure protocol - hopefully syslog - to back-end event collection servers. Novell's eSecurity-acquired Sentinel product already listens on syslog (3195) channels for such event information. ARF will provide rich structured content from instrumented applications on this channel. My suggestion would be for the syslog-sec WG to simply define the payload of syslog messages to be extensible and flexible, and not spend much time on defining the management content itself. With efforts like OASIS WSDM, DMTF CIM-XML (WBEM), and others already well underway, it makes no sense to go farther down this road with syslog - an event protocol whose charter makes it infeasible to try to cover the same amount of network management ground as these other standards efforts will. John Calcote (jcalcote@novell.com) Software Engineer/Architect Novell, Inc. >>> "David Harrington" 6/30/2006 9:57 AM >>> Hi, [posting as a contributor] I recommend this WG make a clear separation (as much as is possible) between issues of security and issues of network management. Issues such as harmonization with the work of other SDOs, integration with netconf, message formatting, content standardization, and so on, are about syslog as a network management protocol. I strongly beleve this work should **not** be done by the syslog-sec WG, but in a WG chartered in the OPS area or the Application area, not the Security area. There are many contributors who have worked on, and are currently working on, other network management protocols and have addressed issues similar to those facing syslog. In addition, there is an effort by the new OPS Management AD to address the current isolated decision making (silos) that is occurring regarding the management plane throughout the IETF. The contributors to this WG should be involved in that discussion, which is likely to be centered in the OPS area. This WG is about security for syslog, and we should focus our efforts on solving the security problems, whether with tls or ssh or beep, and publish. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Friday, June 30, 2006 6:11 AM > To: David Harrington; Chris Lonvick; syslog@ietf.org > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > David, > > I fully agree with your thought. I, too, think we must put emphasis on > the delivery of documents. In my personal opinion, this > leaves only two > realistic options: > > a) rfc 3195bis as you have described it (without the "rathole > discussion") > b) -transport-tls more or less as it is now > > I think there are enough comments on a) already in the list archive. I > will not repeat them. > > Comments on b) currently tend to focus on the IPR issue. Let's ignore > that for a moment and look at other arguments. We have > intially opted in > favor of -transport-tls because it already is in widespread > use. What is > done currently can not be standardized literally, but we can > standardize > something that is quite close to it. It was our opinion that > -transport-tls should by fairly easy to implement, thus bringing some > immediate value to the community. > > Now some technical issues have come up on the list, things like > app-layer ACKs, opening and closeing conversations. I have brought up > some of them. I am also of the view that we could craft a better > framing, probably borrowing from NETCONF (and thus easing conversion - > the "big picture"). This is still sufficiently easy, but it is a big > departure from the "let's standardize what is used in practice" > approach. I fear that discussing a better framing/session management > again takes up a lot of time and includes a high risk of missing our > milestones again. BTW: we are scheduled to deliver by > November 2006, and > I do not expect that we will be granted an extension this time again. > November will be very soon, especially looking at the summer break. > > So I propose that we do NOT enter any new discussion. We > should deliver > either a) or b) (above), without introducing any new features > or ideas. > That means that the result will be sub-optimal. But > delivering something > usable is much better than aiming for the perfect one that will never > appear. > > Once we have delivered, we should discuss what to do next (but only > AFTER delivery). I have to admit that I now see some good points in a > -transport-ssh and consider it implementable with reasonable effort. > However, -transport-ssh should be done after we have reconsidered the > framing. Given the track record of this WG, I would suspect > this can not > be done in less than 12 to 24 month. There are also the issues that > Anton brought up and the general question on configuration and event > data models for syslog. A lot of useful work lying ahead (but > depending > on our ability to finish the base stuff first). > > I think this work can never be done if this WG fails. So I am > desperately trying to get us to publish. I think what we have > is useful > and well-enough. If we do not publish soon, we will never be able to > publish at all. IMHO, we have already received our third chance and > there will be no fourth... > > Rainer > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Thursday, June 29, 2006 8:32 PM > > To: Rainer Gerhards; 'Chris Lonvick'; syslog@ietf.org > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > Hi Rainer, > > > > [speaking as a contributor] > > > > This WG needs to deliver documents soon or the WG could be closed. > > We need to deliver a secure transport solution. > > If the WG decides to do a 3195bis as the secure transport > solution, I > > recommend the short-term deliverable be "good enough" to work with > > syslog-protocol. That way we can get 3195bis AND the other documents > > (-protocol- and -udp-) published and onto the standards > track, so the > > industry can begin to implement, and the WG can stay open to do > > additional work. > > > > Then we can address whether the 3195 design should be modified in > > other ways. There have been suggestions to modify 3195 to > "harmonize" > > with the work of other Standards Development Organizations such as > > OASIS and W3C. Doing that work would likely not be quick or easy. I > > fear it would be a real rathole that would prevent us > getting 3195bis > > published at all, and if 3195bis is the WG's choice as the secure > > transport protocol, then that rathole would also prevent the > > publication of -protocol- and -udp- on a timely basis. > > > > As a 14-year veteran of IETF WG efforts, I think it would > be a bad WG > > decision to put 3195bis on the critical path and to open it up to a > > rathole discussion. If 3195bis is on the critical path, we need to > > avoid the rathole discussion for now; it can be considered for a > > future "release". If the WG feels the rathole discussion is really > > necessary, and 3195bis should not be done without having had such a > > possible-rathole discussion, then 3195bis should not be put on the > > critical path. > > > > My $.02 > > David Harrington > > ietfdbh@comcast.net > > > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Thursday, June 29, 2006 5:11 AM > > > To: Chris Lonvick; syslog@ietf.org > > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > > > Besides the somewhat political issue, I think there is also > > technical > > > issue that affects the question. I think we should consider that > > > question in parallel to the IPR question. > > > > > > This question is if this WG intends to do a revision of 3195. And, > > if > > > so, I think the very close next question is if we "just" update it > > to > > > support syslog-protocol or if we intend to make any > > > substantial changes. > > > > > > I see a relationship between the IPR and the 3195bis issue because > > > 3195bis modifies the "cost" of finding alternate solutions. Coming > > to > > > this point, it would probably be helpful if we could actually > > > weigh cost > > > vs. utlity of the different approaches. IPR, IMHO, is just a cost, > > > obviously one whose weight we need to decide on. But I think it is > > not > > > the only cost. If the WG finds such a "cost vs. utility" > discussion > > > useful, I could document my point of view as a starting point. I > > > volunteer to create a summary document (a public web page, not a > > I-D) > > > where I track all contributions to this discussion (for an example > > of > > > what I have in mind see Juergen Schoenwaelder's page on netconf > > > notification requirements: > > > > http://www.eecs.iu ( http://www.eecs.iu/ )-bremen.de/wiki/index.php/Netconf_notifications). > > > > > > I would find such a page very helpful. It documents the > > > decision process > > > and the decision criteria. In doing that, it helps us come to a > > better > > > decison because we than have all facts at a single place. > > > Thus, it also > > > provides good argument when dealing with the IESG (in the case we > > need > > > to justify the decision). > > > > > > Thanks, > > > Rainer > > > > > > > -----Original Message----- > > > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > > > Sent: Wednesday, June 28, 2006 7:56 PM > > > > To: syslog@ietf.org > > > > Subject: [Syslog] Decisions to make about the Huawei IPR claim > > > > > > > > Hi Folks, > > > > > > > > It's looking like we have a primary decision to make about > > > > the IPR claim > > > > that Huawei has made on syslog-transport-tls. First and > > > > foremost, I want > > > > everyone to be informed of the IETF stand on IPR claims and > > > > on the IETF > > > > process that we will follow. > > > > > > > > This is the position of the IETF on IPR claims: > > > > -------------------------------------------------------------- > > > > ----------- > > > > Intellectual Property > > > > > > > > The IETF takes no position regarding the validity or > > > scope of any > > > > Intellectual Property Rights or other rights that might > > > > be claimed to > > > > pertain to the implementation or use of the technology > > > > described in > > > > this document or the extent to which any license under > > > such rights > > > > might or might not be available; nor does it represent > > > that it has > > > > made any independent effort to identify any such rights. > > > > Information > > > > on the procedures with respect to rights in RFC > documents can > > be > > > > found in BCP 78 and BCP 79. > > > > > > > > Copies of IPR disclosures made to the IETF > Secretariat and any > > > > assurances of licenses to be made available, or the > result of > > an > > > > attempt made to obtain a general license or permission > > > > for the use of > > > > such proprietary rights by implementers or users of this > > > > specification can be obtained from the IETF on-line IPR > > > > repository at > > > > http://www.ietf.org/ipr. > > > > > > > > The IETF invites any interested party to bring to its > > > > attention any > > > > copyrights, patents or patent applications, or other > > proprietary > > > > rights that may cover technology that may be required > > > to implement > > > > this standard. Please address the information to > the IETF at > > > > ietf-ipr@ietf.org. > > > > -------------------------------------------------------------- > > > > ----------- > > > > This is at the bottom of all RFCs. It's pretty clear that we > > > > (our Working > > > > Group) has no place to appeal claims of IPR to. > > > > > > > > Also, the more detailed explanation of the IETF position is > > > in BCP 79: > > > > http://www.ietf.org/rfc/rfc3979.txt > > > > I will ask that everyone read through this before > expressing their > > > > > > opinion. > > > > > > > > One additional source of information for our process is > RFC 3669: > > > > http://www.ietf.org/rfc/rfc3669.txt > > > > "Guidelines for Working Groups on Intellectual Property Issues" > > > > -------------------------------------------------------------- > > > > ----------- > > > > 1. Introduction > > > > > > > > This memo lays out a conceptual framework and rules of thumb > > to > > > > assist working groups dealing with IPR issues. The > goal is to > > > > achieve a balance between the needs of IPR claimants and the > > > > implementers of IETF standards which is appropriate to > > > > current times. > > > > As part of trying to distill out principles for dealing > > > > with IPR in > > > > IETF working groups, it provides case studies of > > > working group IPR > > > > treatment. In other words, it documents the running code > > > > of the IETF > > > > process. > > > > > > > > This memo does not describe IPR procedures for document > > > authors or > > > > IPR claimants. Those are covered in two other memos, on > > > > submission > > > > rights [5] and IPR in the IETF [6]. Rather, this memo is > > > > for working > > > > groups that are trying to decide what to do about technology > > > > contributions which have associated IPR claims. > > > > -------------------------------------------------------------- > > > > ----------- > > > > [5] and [6] are BCP78 and BCP79 respecively. > > > > This document contains a lot of really good advice that we > > > > should be aware > > > > of while we make our decision. > > > > > > > > One part of RFC 3669 is a recommendation to take a critical > > > > look at the > > > > terms of the claim - Section 5.6. Essentially, if we can get > > > > consensus > > > > that the terms are acceptable for implementation, then the > > > > IPR claim may > > > > not be an issue - we can continue to progress > > > > syslog-transport-tls. On > > > > the other hand, if the terms are not acceptable then we can't > > > > expect any > > > > implementations. > > > > > > > > I'm going to ask that everyone please start considering these > > > > inputs and > > > > openly discuss your thoughts about the IETF process and the > > options > > > > available to our Working Group on the mailing list. > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > Do not declare your opinion yet. > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > In a week or so I will ask the group to decide how we should > > > > process. I > > > > want everyone to take the time now to get acquainted with the > > > > process and > > > > the information that we have available to us. > > > > > > > > I believe that ultimately, we will need to decide on whether > > > > to continue > > > > to progress syslog-transport-tls, or if we will want to > > > > accept a different > > > > path. If we start down a new path, then we will still need > > > > to make sure > > > > that we are meeting the security objectives that we feel are > > > > important. > > > > This discussion has already been started, which is good in > > > that it can > > > > bringing to light some of the issues that need to be > > > > discussed around the > > > > secure transport of syslog. Once we get this primary issue > > > > resolved then > > > > we can decide upon that. > > > > > > > > Also, the Milestone about delivering a TLS solution can be > > > > easily changed. > > > > I did submit it that way to the IESG and Tom Petch noted that > > > > the Charter > > > > just said "security" protocol while the Goal specified > a specific > > > > solution. Sam didn't want to change it after it had gone > > > in but I'm > > > > certain that it's not going to be a problem if we do want to > > > > change it. > > > > > > > > Thanks, > > > > Chris > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --=__PartFCD91019.3__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: HTML
Jumping in to add my two cents...
 
I quite agree with David on this point. If the syslog WG chose to begin work on network management issues, it would be stepping into a realm already well covered by other standards efforts. However - what the world does need is a standardized and widely understood and deployed _secure_transport_ for management events. One that will guarantee deliver and sequencing, as well as privacy based on administrative policy.
 
I work for Novell on the Audit Record Framework (ARF) - a part of the Bandit Project (http://www.bandit-project.org). ARF is chartered to provide an open source, portable, application audit instrumentation library based on existing standards work. We've chosen to use the OASIS WSDM Event Format - a W3C XML Schema-based approach. The ARF library will send management events over a secure protocol - hopefully syslog - to back-end event collection servers. Novell's eSecurity-acquired Sentinel product already listens on syslog (3195) channels for such event information. ARF will provide rich structured content from instrumented applications on this channel.
 
My suggestion would be for the syslog-sec WG to simply define the payload of syslog messages to be extensible and flexible, and not spend much time on defining the management content itself. With efforts like OASIS WSDM, DMTF CIM-XML (WBEM), and others already well underway, it makes no sense to go farther down this road with syslog - an event protocol whose charter makes it infeasible to try to cover the same amount of network management ground as these other standards efforts will.
 
John Calcote (jcalcote@novell.com)
Software Engineer/Architect
Novell, Inc.

>>> "David Harrington" <ietfdbh@comcast.net> 6/30/2006 9:57 AM >>>
Hi,

[posting as a contributor]

I recommend this WG make a clear separation (as much as is possible)
between issues of security and issues of network management.

Issues such as harmonization with the work of other SDOs, integration
with netconf, message formatting, content standardization, and so on,
are about syslog as a network management protocol. I strongly beleve
this work should **not** be done by the syslog-sec WG, but in a WG
chartered in the OPS area or the Application area, not the Security
area. There are many contributors who have worked on, and are
currently working on, other network management protocols and have
addressed issues similar to those facing syslog.

In addition, there is an effort by the new OPS Management AD to
address the current isolated decision making (silos) that is occurring
regarding the management plane throughout the IETF. The contributors
to this WG should be involved in that discussion, which is likely to
be centered in the OPS area.

This WG is about security for syslog, and we should focus our efforts
on solving the security problems, whether with tls or ssh or beep, and
publish.

David Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net


> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> Sent: Friday, June 30, 2006 6:11 AM
> To: David Harrington; Chris Lonvick; syslog@ietf.org
> Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim
>
> David,
>
> I fully agree with your thought. I, too, think we must put emphasis
on
> the delivery of documents. In my personal opinion, this
> leaves only two
> realistic options:
>
> a) rfc 3195bis as you have described it (without the "rathole
> discussion")
> b) -transport-tls more or less as it is now
>
> I think there are enough comments on a) already in the list archive.
I
> will not repeat them.
>
> Comments on b) currently tend to focus on the IPR issue. Let's
ignore
> that for a moment and look at other arguments. We have
> intially opted in
> favor of -transport-tls because it already is in widespread
> use. What is
> done currently can not be standardized literally, but we can
> standardize
> something that is quite close to it. It was our opinion that
> -transport-tls should by fairly easy to implement, thus bringing
some
> immediate value to the community.
>
> Now some technical issues have come up on the list, things like
> app-layer ACKs, opening and closeing conversations. I have brought
up
> some of them. I am also of the view that we could craft a better
> framing, probably borrowing from NETCONF (and thus easing conversion
-
> the "big picture"). This is still sufficiently easy, but it is a big
> departure from the "let's standardize what is used in practice"
> approach. I fear that discussing a better framing/session management
> again takes up a lot of time and includes a high risk of missing our
> milestones again. BTW: we are scheduled to deliver by
> November 2006, and
> I do not expect that we will be granted an extension this time
again.
> November will be very soon, especially looking at the summer break.
>
> So I propose that we do NOT enter any new discussion. We
> should deliver
> either a) or b) (above), without introducing any new features
> or ideas.
> That means that the result will be sub-optimal. But
> delivering something
> usable is much better than aiming for the perfect one that will
never
> appear.
>
> Once we have delivered, we should discuss what to do next (but only
> AFTER delivery). I have to admit that I now see some good points in
a
> -transport-ssh and consider it implementable with reasonable effort.
> However, -transport-ssh should be done after we have reconsidered
the
> framing. Given the track record of this WG, I would suspect
> this can not
> be done in less than 12 to 24 month. There are also the issues that
> Anton brought up and the general question on configuration and event
> data models for syslog. A lot of useful work lying ahead (but
> depending
> on our ability to finish the base stuff first).
>
> I think this work can never be done if this WG fails. So I am
> desperately trying to get us to publish. I think what we have
> is useful
> and well-enough. If we do not publish soon, we will never be able to
> publish at all. IMHO, we have already received our third chance and
> there will be no fourth...
>
> Rainer
>
> > -----Original Message-----
> > From: David Harrington [mailto:ietfdbh@comcast.net]
> > Sent: Thursday, June 29, 2006 8:32 PM
> > To: Rainer Gerhards; 'Chris Lonvick'; syslog@ietf.org
> > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim
> >
> > Hi Rainer,
> >
> > [speaking as a contributor]
> >
> > This WG needs to deliver documents soon or the WG could be closed.

> > We need to deliver a secure transport solution.
> > If the WG decides to do a 3195bis as the secure transport
> solution, I
> > recommend the short-term deliverable be "good enough" to work with
> > syslog-protocol. That way we can get 3195bis AND the other
documents
> > (-protocol- and -udp-) published and onto the standards
> track, so the
> > industry can begin to implement, and the WG can stay open to do
> > additional work.
> >
> > Then we can address whether the 3195 design should be modified in
> > other ways. There have been suggestions to modify 3195 to
> "harmonize"
> > with the work of other Standards Development Organizations such as
> > OASIS and W3C. Doing that work would likely not be quick or easy.
I
> > fear it would be a real rathole that would prevent us
> getting 3195bis
> > published at all, and if 3195bis is the WG's choice as the secure
> > transport protocol, then that rathole would also prevent the
> > publication of -protocol- and -udp- on a timely basis.
> >
> > As a 14-year veteran of IETF WG efforts, I think it would
> be a bad WG
> > decision to put 3195bis on the critical path and to open it up to
a
> > rathole discussion. If 3195bis is on the critical path, we need to
> > avoid the rathole discussion for now; it can be considered for a
> > future "release". If the WG feels the rathole discussion is really
> > necessary, and 3195bis should not be done without having had such
a
> > possible-rathole discussion, then 3195bis should not be put on the
> > critical path.
> >
> > My $.02
> > David Harrington
> > ietfdbh@comcast.net
> >
> >
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> > > Sent: Thursday, June 29, 2006 5:11 AM
> > > To: Chris Lonvick; syslog@ietf.org
> > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR
claim
> > >
> > > Besides the somewhat political issue, I think there is also
> > technical
> > > issue that affects the question. I think we should consider that
> > > question in parallel to the IPR question.
> > >
> > > This question is if this WG intends to do a revision of 3195.
And,
> > if
> > > so, I think the very close next question is if we "just" update
it
> > to
> > > support syslog-protocol or if we intend to make any
> > > substantial changes.
> > >
> > > I see a relationship between the IPR and the 3195bis issue
because
> > > 3195bis modifies the "cost" of finding alternate solutions.
Coming
> > to
> > > this point, it would probably be helpful if we could actually
> > > weigh cost
> > > vs. utlity of the different approaches. IPR, IMHO, is just a
cost,
> > > obviously one whose weight we need to decide on. But I think it
is
> > not
> > > the only cost. If the WG finds such a "cost vs. utility"
> discussion
> > > useful, I could document my point of view as a starting point. I
> > > volunteer to create a summary document (a public web page, not a
> > I-D)
> > > where I track all contributions to this discussion (for an
example
> > of
> > > what I have in mind see Juergen Schoenwaelder's page on netconf
> > > notification requirements:
> > >
> http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications).
> > >
> > > I would find such a page very helpful. It documents the
> > > decision process
> > > and the decision criteria. In doing that, it helps us come to a
> > better
> > > decison because we than have all facts at a single place.
> > > Thus, it also
> > > provides good argument when dealing with the IESG (in the case
we
> > need
> > > to justify the decision).
> > >
> > > Thanks,
> > > Rainer
> > >
> > > > -----Original Message-----
> > > > From: Chris Lonvick [mailto:clonvick@cisco.com]
> > > > Sent: Wednesday, June 28, 2006 7:56 PM
> > > > To: syslog@ietf.org
> > > > Subject: [Syslog] Decisions to make about the Huawei IPR claim
> > > >
> > > > Hi Folks,
> > > >
> > > > It's looking like we have a primary decision to make about
> > > > the IPR claim
> > > > that Huawei has made on syslog-transport-tls.  First and
> > > > foremost, I want
> > > > everyone to be informed of the IETF stand on IPR claims and
> > > > on the IETF
> > > > process that we will follow.
> > > >
> > > > This is the position of the IETF on IPR claims:
> > > > --------------------------------------------------------------
> > > > -----------
> > > > Intellectual Property
> > > >
> > > >     The IETF takes no position regarding the validity or
> > > scope of any
> > > >     Intellectual Property Rights or other rights that might
> > > > be claimed to
> > > >     pertain to the implementation or use of the technology
> > > > described in
> > > >     this document or the extent to which any license under
> > > such rights
> > > >     might or might not be available; nor does it represent
> > > that it has
> > > >     made any independent effort to identify any such rights. 
> > > > Information
> > > >     on the procedures with respect to rights in RFC
> documents can
> > be
> > > >     found in BCP 78 and BCP 79.
> > > >
> > > >     Copies of IPR disclosures made to the IETF
> Secretariat and any
> > > >     assurances of licenses to be made available, or the
> result of
> > an
> > > >     attempt made to obtain a general license or permission
> > > > for the use of
> > > >     such proprietary rights by implementers or users of this
> > > >     specification can be obtained from the IETF on-line IPR
> > > > repository at
> > > >     http://www.ietf.org/ipr.
> > > >
> > > >     The IETF invites any interested party to bring to its
> > > > attention any
> > > >     copyrights, patents or patent applications, or other
> > proprietary
> > > >     rights that may cover technology that may be required
> > > to implement
> > > >     this standard.  Please address the information to
> the IETF at
> > > >     ietf-ipr@ietf.org.
> > > > --------------------------------------------------------------
> > > > -----------
> > > > This is at the bottom of all RFCs.  It's pretty clear that we
> > > > (our Working
> > > > Group) has no place to appeal claims of IPR to.
> > > >
> > > > Also, the more detailed explanation of the IETF position is
> > > in BCP 79:
> > > >    http://www.ietf.org/rfc/rfc3979.txt
> > > > I will ask that everyone read through this before
> expressing their
> >
> > > > opinion.
> > > >
> > > > One additional source of information for our process is
> RFC 3669:
> > > >    http://www.ietf.org/rfc/rfc3669.txt
> > > > "Guidelines for Working Groups on Intellectual Property
Issues"
> > > > --------------------------------------------------------------
> > > > -----------
> > > > 1.  Introduction
> > > >
> > > >     This memo lays out a conceptual framework and rules of
thumb
> > to
> > > >     assist working groups dealing with IPR issues.  The
> goal is to
> > > >     achieve a balance between the needs of IPR claimants and
the
> > > >     implementers of IETF standards which is appropriate to
> > > > current times.
> > > >     As part of trying to distill out principles for dealing
> > > > with IPR in
> > > >     IETF working groups, it provides case studies of
> > > working group IPR
> > > >     treatment.  In other words, it documents the running code
> > > > of the IETF
> > > >     process.
> > > >
> > > >     This memo does not describe IPR procedures for document
> > > authors or
> > > >     IPR claimants.  Those are covered in two other memos, on
> > > > submission
> > > >     rights [5] and IPR in the IETF [6].  Rather, this memo is
> > > > for working
> > > >     groups that are trying to decide what to do about
technology
> > > >     contributions which have associated IPR claims.
> > > > --------------------------------------------------------------
> > > > -----------
> > > > [5] and [6] are BCP78 and BCP79 respecively.
> > > > This document contains a lot of really good advice that we
> > > > should be aware
> > > > of while we make our decision.
> > > >
> > > > One part of RFC 3669 is a recommendation to take a critical
> > > > look at the
> > > > terms of the claim - Section 5.6.  Essentially, if we can get
> > > > consensus
> > > > that the terms are acceptable for implementation, then the
> > > > IPR claim may
> > > > not be an issue - we can continue to progress
> > > > syslog-transport-tls.  On
> > > > the other hand, if the terms are not acceptable then we can't
> > > > expect any
> > > > implementations.
> > > >
> > > > I'm going to ask that everyone please start considering these
> > > > inputs and
> > > > openly discuss your thoughts about the IETF process and the
> > options
> > > > available to our Working Group on the mailing list.
> > > > +++ +++ +++ +++ +++ +++ +++ +++ +++
> > > >    Do not declare your opinion yet.
> > > > +++ +++ +++ +++ +++ +++ +++ +++ +++
> > > > In a week or so I will ask the group to decide how we should
> > > > process.  I
> > > > want everyone to take the time now to get acquainted with the
> > > > process and
> > > > the information that we have available to us.
> > > >
> > > > I believe that ultimately, we will need to decide on whether
> > > > to continue
> > > > to progress syslog-transport-tls, or if we will want to
> > > > accept a different
> > > > path.  If we start down a new path, then we will still need
> > > > to make sure
> > > > that we are meeting the security objectives that we feel are
> > > > important.
> > > > This discussion has already been started, which is good in
> > > that it can
> > > > bringing to light some of the issues that need to be
> > > > discussed around the
> > > > secure transport of syslog.  Once we get this primary issue
> > > > resolved then
> > > > we can decide upon that.
> > > >
> > > > Also, the Milestone about delivering a TLS solution can be
> > > > easily changed.
> > > > I did submit it that way to the IESG and Tom Petch noted that
> > > > the Charter
> > > > just said "security" protocol while the Goal specified
> a specific
> > > > solution.  Sam didn't want to change it after it had gone
> > > in but I'm
> > > > certain that it's not going to be a problem if we do want to
> > > > change it.
> > > >
> > > > Thanks,
> > > > Chris
> > > >
> > > > _______________________________________________
> > > > Syslog mailing list
> > > > Syslog@lists.ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/syslog
> > > >
> > >
> > > _______________________________________________
> > > Syslog mailing list
> > > Syslog@lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > >
> >
> >
>


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
--=__PartFCD91019.3__=-- --===============0849990480== 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 --===============0849990480==-- From syslog-bounces@lists.ietf.org Fri Jun 30 15:43:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOtU-0007BS-Li; Fri, 30 Jun 2006 15:43:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOtT-0007BI-Ib for syslog@ietf.org; Fri, 30 Jun 2006 15:43:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwOtR-0001d6-S9 for syslog@ietf.org; Fri, 30 Jun 2006 15:43:11 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 Jun 2006 15:43:10 -0400 X-IronPort-AV: i="4.06,197,1149480000"; d="scan'208"; a="91444123:sNHT36198096" 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 k5UJh9no022418; Fri, 30 Jun 2006 15:43:09 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Jun 2006 15:43:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim Date: Fri, 30 Jun 2006 15:43:08 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B7312201A1CDE9@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Decisions to make about the Huawei IPR claim Thread-Index: Acaa3EiOng4KrbaFSXKf9aYL7q19aQAfVmewABM/w6AAIN0g0AAL14WwAAiAfgA= From: "Anton Okmianski \(aokmians\)" To: "David Harrington" , "Rainer Gerhards" , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 30 Jun 2006 19:43:09.0052 (UTC) FILETIME=[6A09F3C0:01C69C7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David: Please clarify... Are you suggesting we drop syslog-protocol, which actually defines = message format, and just do a generic secure transport for events? = Something that just does framing, app-level ack and had generic payload? = And then we continue to live without syslog standard, waiting for others = to standardize payload? =20 Anton. =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, June 30, 2006 11:58 AM > To: 'Rainer Gerhards'; Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim >=20 > Hi, >=20 > [posting as a contributor] >=20 > I recommend this WG make a clear separation (as much as is possible) > between issues of security and issues of network management.=20 >=20 > Issues such as harmonization with the work of other SDOs, integration > with netconf, message formatting, content standardization, and so on, > are about syslog as a network management protocol. I strongly beleve > this work should **not** be done by the syslog-sec WG, but in a WG > chartered in the OPS area or the Application area, not the Security > area. There are many contributors who have worked on, and are > currently working on, other network management protocols and have > addressed issues similar to those facing syslog.=20 >=20 > In addition, there is an effort by the new OPS Management AD to > address the current isolated decision making (silos) that is occurring > regarding the management plane throughout the IETF. The contributors > to this WG should be involved in that discussion, which is likely to > be centered in the OPS area. >=20 > This WG is about security for syslog, and we should focus our efforts > on solving the security problems, whether with tls or ssh or beep, and > publish.=20 >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Friday, June 30, 2006 6:11 AM > > To: David Harrington; Chris Lonvick; syslog@ietf.org > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > >=20 > > David, > >=20 > > I fully agree with your thought. I, too, think we must put emphasis > on > > the delivery of documents. In my personal opinion, this=20 > > leaves only two > > realistic options: > >=20 > > a) rfc 3195bis as you have described it (without the "rathole > > discussion") > > b) -transport-tls more or less as it is now > >=20 > > I think there are enough comments on a) already in the list archive. > I > > will not repeat them. > >=20 > > Comments on b) currently tend to focus on the IPR issue. Let's > ignore > > that for a moment and look at other arguments. We have=20 > > intially opted in > > favor of -transport-tls because it already is in widespread=20 > > use. What is > > done currently can not be standardized literally, but we can=20 > > standardize > > something that is quite close to it. It was our opinion that > > -transport-tls should by fairly easy to implement, thus bringing > some > > immediate value to the community. > >=20 > > Now some technical issues have come up on the list, things like > > app-layer ACKs, opening and closeing conversations. I have brought > up > > some of them. I am also of the view that we could craft a better > > framing, probably borrowing from NETCONF (and thus easing conversion > - > > the "big picture"). This is still sufficiently easy, but it is a big > > departure from the "let's standardize what is used in practice" > > approach. I fear that discussing a better framing/session management > > again takes up a lot of time and includes a high risk of missing our > > milestones again. BTW: we are scheduled to deliver by=20 > > November 2006, and > > I do not expect that we will be granted an extension this time > again. > > November will be very soon, especially looking at the summer break. > >=20 > > So I propose that we do NOT enter any new discussion. We=20 > > should deliver > > either a) or b) (above), without introducing any new features=20 > > or ideas. > > That means that the result will be sub-optimal. But=20 > > delivering something > > usable is much better than aiming for the perfect one that will > never > > appear. > >=20 > > Once we have delivered, we should discuss what to do next (but only > > AFTER delivery). I have to admit that I now see some good points in > a > > -transport-ssh and consider it implementable with reasonable effort. > > However, -transport-ssh should be done after we have reconsidered > the > > framing. Given the track record of this WG, I would suspect=20 > > this can not > > be done in less than 12 to 24 month. There are also the issues that > > Anton brought up and the general question on configuration and event > > data models for syslog. A lot of useful work lying ahead (but=20 > > depending > > on our ability to finish the base stuff first). > >=20 > > I think this work can never be done if this WG fails. So I am > > desperately trying to get us to publish. I think what we have=20 > > is useful > > and well-enough. If we do not publish soon, we will never be able to > > publish at all. IMHO, we have already received our third chance and > > there will be no fourth... > >=20 > > Rainer > >=20 > > > -----Original Message----- > > > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > > > Sent: Thursday, June 29, 2006 8:32 PM > > > To: Rainer Gerhards; 'Chris Lonvick'; syslog@ietf.org > > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > >=20 > > > Hi Rainer, > > >=20 > > > [speaking as a contributor] > > >=20 > > > This WG needs to deliver documents soon or the WG could be closed. >=20 > > > We need to deliver a secure transport solution. > > > If the WG decides to do a 3195bis as the secure transport=20 > > solution, I > > > recommend the short-term deliverable be "good enough" to work with > > > syslog-protocol. That way we can get 3195bis AND the other > documents > > > (-protocol- and -udp-) published and onto the standards=20 > > track, so the > > > industry can begin to implement, and the WG can stay open to do > > > additional work. > > >=20 > > > Then we can address whether the 3195 design should be modified in > > > other ways. There have been suggestions to modify 3195 to=20 > > "harmonize" > > > with the work of other Standards Development Organizations such as > > > OASIS and W3C. Doing that work would likely not be quick or easy. > I > > > fear it would be a real rathole that would prevent us=20 > > getting 3195bis > > > published at all, and if 3195bis is the WG's choice as the secure > > > transport protocol, then that rathole would also prevent the > > > publication of -protocol- and -udp- on a timely basis. > > >=20 > > > As a 14-year veteran of IETF WG efforts, I think it would=20 > > be a bad WG > > > decision to put 3195bis on the critical path and to open it up to > a > > > rathole discussion. If 3195bis is on the critical path, we need to > > > avoid the rathole discussion for now; it can be considered for a > > > future "release". If the WG feels the rathole discussion is really > > > necessary, and 3195bis should not be done without having had such > a > > > possible-rathole discussion, then 3195bis should not be put on the > > > critical path. > > >=20 > > > My $.02 > > > David Harrington > > > ietfdbh@comcast.net > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > > > Sent: Thursday, June 29, 2006 5:11 AM > > > > To: Chris Lonvick; syslog@ietf.org > > > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR > claim > > > >=20 > > > > Besides the somewhat political issue, I think there is also > > > technical > > > > issue that affects the question. I think we should consider that > > > > question in parallel to the IPR question. > > > >=20 > > > > This question is if this WG intends to do a revision of 3195. > And, > > > if > > > > so, I think the very close next question is if we "just" update > it > > > to > > > > support syslog-protocol or if we intend to make any=20 > > > > substantial changes. > > > >=20 > > > > I see a relationship between the IPR and the 3195bis issue > because > > > > 3195bis modifies the "cost" of finding alternate solutions. > Coming > > > to > > > > this point, it would probably be helpful if we could actually=20 > > > > weigh cost > > > > vs. utlity of the different approaches. IPR, IMHO, is just a > cost, > > > > obviously one whose weight we need to decide on. But I think it > is > > > not > > > > the only cost. If the WG finds such a "cost vs. utility"=20 > > discussion > > > > useful, I could document my point of view as a starting point. I > > > > volunteer to create a summary document (a public web page, not a > > > I-D) > > > > where I track all contributions to this discussion (for an > example > > > of > > > > what I have in mind see Juergen Schoenwaelder's page on netconf > > > > notification requirements: > > > >=20 > > http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications). > > > >=20 > > > > I would find such a page very helpful. It documents the=20 > > > > decision process > > > > and the decision criteria. In doing that, it helps us come to a > > > better > > > > decison because we than have all facts at a single place.=20 > > > > Thus, it also > > > > provides good argument when dealing with the IESG (in the case > we > > > need > > > > to justify the decision).=20 > > > >=20 > > > > Thanks, > > > > Rainer > > > >=20 > > > > > -----Original Message----- > > > > > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > > > > > Sent: Wednesday, June 28, 2006 7:56 PM > > > > > To: syslog@ietf.org > > > > > Subject: [Syslog] Decisions to make about the Huawei IPR claim > > > > >=20 > > > > > Hi Folks, > > > > >=20 > > > > > It's looking like we have a primary decision to make about=20 > > > > > the IPR claim=20 > > > > > that Huawei has made on syslog-transport-tls. First and=20 > > > > > foremost, I want=20 > > > > > everyone to be informed of the IETF stand on IPR claims and=20 > > > > > on the IETF=20 > > > > > process that we will follow. > > > > >=20 > > > > > This is the position of the IETF on IPR claims: > > > > > -------------------------------------------------------------- > > > > > ----------- > > > > > Intellectual Property > > > > >=20 > > > > > The IETF takes no position regarding the validity or=20 > > > > scope of any > > > > > Intellectual Property Rights or other rights that might=20 > > > > > be claimed to > > > > > pertain to the implementation or use of the technology=20 > > > > > described in > > > > > this document or the extent to which any license under=20 > > > > such rights > > > > > might or might not be available; nor does it represent=20 > > > > that it has > > > > > made any independent effort to identify any such rights. =20 > > > > > Information > > > > > on the procedures with respect to rights in RFC=20 > > documents can > > > be > > > > > found in BCP 78 and BCP 79. > > > > >=20 > > > > > Copies of IPR disclosures made to the IETF=20 > > Secretariat and any > > > > > assurances of licenses to be made available, or the=20 > > result of > > > an > > > > > attempt made to obtain a general license or permission=20 > > > > > for the use of > > > > > such proprietary rights by implementers or users of this > > > > > specification can be obtained from the IETF on-line IPR=20 > > > > > repository at > > > > > http://www.ietf.org/ipr. > > > > >=20 > > > > > The IETF invites any interested party to bring to its=20 > > > > > attention any > > > > > copyrights, patents or patent applications, or other > > > proprietary > > > > > rights that may cover technology that may be required=20 > > > > to implement > > > > > this standard. Please address the information to=20 > > the IETF at > > > > > ietf-ipr@ietf.org. > > > > > -------------------------------------------------------------- > > > > > ----------- > > > > > This is at the bottom of all RFCs. It's pretty clear that we=20 > > > > > (our Working=20 > > > > > Group) has no place to appeal claims of IPR to. > > > > >=20 > > > > > Also, the more detailed explanation of the IETF position is=20 > > > > in BCP 79: > > > > > http://www.ietf.org/rfc/rfc3979.txt > > > > > I will ask that everyone read through this before=20 > > expressing their > > >=20 > > > > > opinion. > > > > >=20 > > > > > One additional source of information for our process is=20 > > RFC 3669: > > > > > http://www.ietf.org/rfc/rfc3669.txt > > > > > "Guidelines for Working Groups on Intellectual Property > Issues" > > > > > -------------------------------------------------------------- > > > > > ----------- > > > > > 1. Introduction > > > > >=20 > > > > > This memo lays out a conceptual framework and rules of > thumb > > > to > > > > > assist working groups dealing with IPR issues. The=20 > > goal is to > > > > > achieve a balance between the needs of IPR claimants and > the > > > > > implementers of IETF standards which is appropriate to=20 > > > > > current times. > > > > > As part of trying to distill out principles for dealing=20 > > > > > with IPR in > > > > > IETF working groups, it provides case studies of=20 > > > > working group IPR > > > > > treatment. In other words, it documents the running code=20 > > > > > of the IETF > > > > > process. > > > > >=20 > > > > > This memo does not describe IPR procedures for document=20 > > > > authors or > > > > > IPR claimants. Those are covered in two other memos, on=20 > > > > > submission > > > > > rights [5] and IPR in the IETF [6]. Rather, this memo is=20 > > > > > for working > > > > > groups that are trying to decide what to do about > technology > > > > > contributions which have associated IPR claims. > > > > > -------------------------------------------------------------- > > > > > ----------- > > > > > [5] and [6] are BCP78 and BCP79 respecively. > > > > > This document contains a lot of really good advice that we=20 > > > > > should be aware=20 > > > > > of while we make our decision. > > > > >=20 > > > > > One part of RFC 3669 is a recommendation to take a critical=20 > > > > > look at the=20 > > > > > terms of the claim - Section 5.6. Essentially, if we can get=20 > > > > > consensus=20 > > > > > that the terms are acceptable for implementation, then the=20 > > > > > IPR claim may=20 > > > > > not be an issue - we can continue to progress=20 > > > > > syslog-transport-tls. On=20 > > > > > the other hand, if the terms are not acceptable then we can't=20 > > > > > expect any=20 > > > > > implementations. > > > > >=20 > > > > > I'm going to ask that everyone please start considering these=20 > > > > > inputs and=20 > > > > > openly discuss your thoughts about the IETF process and the > > > options=20 > > > > > available to our Working Group on the mailing list. > > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > > Do not declare your opinion yet. > > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > > In a week or so I will ask the group to decide how we should=20 > > > > > process. I=20 > > > > > want everyone to take the time now to get acquainted with the=20 > > > > > process and=20 > > > > > the information that we have available to us. > > > > >=20 > > > > > I believe that ultimately, we will need to decide on whether=20 > > > > > to continue=20 > > > > > to progress syslog-transport-tls, or if we will want to=20 > > > > > accept a different=20 > > > > > path. If we start down a new path, then we will still need=20 > > > > > to make sure=20 > > > > > that we are meeting the security objectives that we feel are=20 > > > > > important.=20 > > > > > This discussion has already been started, which is good in=20 > > > > that it can > > > > > bringing to light some of the issues that need to be=20 > > > > > discussed around the=20 > > > > > secure transport of syslog. Once we get this primary issue=20 > > > > > resolved then=20 > > > > > we can decide upon that. > > > > >=20 > > > > > Also, the Milestone about delivering a TLS solution can be=20 > > > > > easily changed.=20 > > > > > I did submit it that way to the IESG and Tom Petch noted that=20 > > > > > the Charter=20 > > > > > just said "security" protocol while the Goal specified=20 > > a specific=20 > > > > > solution. Sam didn't want to change it after it had gone=20 > > > > in but I'm=20 > > > > > certain that it's not going to be a problem if we do want to=20 > > > > > change it. > > > > >=20 > > > > > Thanks, > > > > > Chris > > > > >=20 > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > Syslog@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 30 16:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwPmj-0003cs-95; Fri, 30 Jun 2006 16:40:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwPBM-00060D-Jl for syslog@ietf.org; Fri, 30 Jun 2006 16:01:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwPBH-0003Hg-Mh for syslog@ietf.org; Fri, 30 Jun 2006 16:01:40 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 30 Jun 2006 13:01:35 -0700 X-IronPort-AV: i="4.06,197,1149490800"; d="scan'208,217"; a="432390888:sNHT72629028" 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 k5UK1YQ9023897; Fri, 30 Jun 2006 13:01:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5UK1UCW024785; Fri, 30 Jun 2006 13:01:34 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Jun 2006 16:01:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim Date: Fri, 30 Jun 2006 16:01:32 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B7312201A1CDF6@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Decisions to make about the Huawei IPR claim Thread-Index: AcacclvS5BtsWtgUQZWjAVlCpZo6nwAC1T3w From: "Anton Okmianski \(aokmians\)" To: "John Calcote" , "Chris Lonvick \(clonvick\)" , "David Harrington" , "Rainer Gerhards" , X-OriginalArrivalTime: 30 Jun 2006 20:01:33.0690 (UTC) FILETIME=[FC7455A0:01C69C7F] DKIM-Signature: a=rsa-sha1; q=dns; l=50677; t=1151697694; x=1152561694; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20Decisions=20to=20make=20about=20the=20Huawei=20IPR=20 claim; X=v=3Dcisco.com=3B=20h=3DpZ6MAsKD/W/l8cNIU26foLgLZQM=3D; b=TMALw/j+E2QJEHvnTa4+qIz9eb9R4BXbwDEB+N7A1iaQVfMr7ozHr1XvWrq6yZ5pHg/LcI0v C/6EJQoX1H5mvfc+aJsS9v4UzS/ewC5OPX5K4JRia6hXfQfewi3O9RS6; Authentication-Results: sj-dkim-2.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ff540dacb4d3b4985fe0123ade9f3d7 X-Mailman-Approved-At: Fri, 30 Jun 2006 16:40:16 -0400 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1602045984==" Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1602045984== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69C7F.FC07BFEE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69C7F.FC07BFEE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John: =20 The standards you listed define not just payload, but also the whole = messaging. WSDM uses SOAP over HTTP. CIM-CX / WBEM - non-SOAP XML over = HTTP. =20 =20 I am not sure what we can add to help the above other than to say use = TLS. =20 =20 Or do you want syslog WG to provide an alternative messaging system, so = you could do SOAP or CIM XML over syslog instead of HTTP? SOAP = Envelopes within syslog messages sounds a bit of a stretch. =20 =20 Could you give a rough, but specific example of what you have in mind = for what syslog WG could produce to satisfy your goals? =20 Frankly, there will always be frameworks which will want to do eventing = using their own protocol. For example, DSL Forum's TR-069 obsoletes all = of SNMP and they are not relying on syslog. They uses their own = SOAP-based framework for everything. Even if we provided a separate = messaging system for syslog, why would they use it and deal with another = protocol, more authentication, etc? So, I am am not sure how we can = accommodate such frameworks. =20 =20 Something that define pure payload, like IBM's CBE (XML messages), which = they contributed to WSDM could be accommodated. Syslog-protocol supports = any UTF-8 payload already.=20 =20 Thanks, Anton. =20 ________________________________ From: John Calcote [mailto:jcalcote@novell.com]=20 Sent: Friday, June 30, 2006 2:23 PM To: Chris Lonvick (clonvick); David Harrington; 'Rainer Gerhards'; = syslog@ietf.org Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim =09 =09 Jumping in to add my two cents... =20 I quite agree with David on this point. If the syslog WG chose to begin = work on network management issues, it would be stepping into a realm = already well covered by other standards efforts. However - what the = world does need is a standardized and widely understood and deployed = _secure_transport_ for management events. One that will guarantee = deliver and sequencing, as well as privacy based on administrative = policy. =20 I work for Novell on the Audit Record Framework (ARF) - a part of the = Bandit Project (http://www.bandit-project.org). ARF is chartered to = provide an open source, portable, application audit instrumentation = library based on existing standards work. We've chosen to use the OASIS = WSDM Event Format - a W3C XML Schema-based approach. The ARF library = will send management events over a secure protocol - hopefully syslog - = to back-end event collection servers. Novell's eSecurity-acquired = Sentinel product already listens on syslog (3195) channels for such = event information. ARF will provide rich structured content from = instrumented applications on this channel. =20 My suggestion would be for the syslog-sec WG to simply define the = payload of syslog messages to be extensible and flexible, and not spend = much time on defining the management content itself. With efforts like = OASIS WSDM, DMTF CIM-XML (WBEM), and others already well underway, it = makes no sense to go farther down this road with syslog - an event = protocol whose charter makes it infeasible to try to cover the same = amount of network management ground as these other standards efforts = will. =20 John Calcote (jcalcote@novell.com) Software Engineer/Architect Novell, Inc. =09 >>> "David Harrington" 6/30/2006 9:57 AM >>> Hi, =09 [posting as a contributor] =09 I recommend this WG make a clear separation (as much as is possible) between issues of security and issues of network management.=20 =09 Issues such as harmonization with the work of other SDOs, integration with netconf, message formatting, content standardization, and so on, are about syslog as a network management protocol. I strongly beleve this work should **not** be done by the syslog-sec WG, but in a WG chartered in the OPS area or the Application area, not the Security area. There are many contributors who have worked on, and are currently working on, other network management protocols and have addressed issues similar to those facing syslog.=20 =09 In addition, there is an effort by the new OPS Management AD to address the current isolated decision making (silos) that is occurring regarding the management plane throughout the IETF. The contributors to this WG should be involved in that discussion, which is likely to be centered in the OPS area. =09 This WG is about security for syslog, and we should focus our efforts on solving the security problems, whether with tls or ssh or beep, and publish.=20 =09 David Harrington dharrington@huawei.com=20 dbharrington@comcast.net ietfdbh@comcast.net =09 =09 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Friday, June 30, 2006 6:11 AM > To: David Harrington; Chris Lonvick; syslog@ietf.org > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim >=20 > David, >=20 > I fully agree with your thought. I, too, think we must put emphasis on > the delivery of documents. In my personal opinion, this=20 > leaves only two > realistic options: >=20 > a) rfc 3195bis as you have described it (without the "rathole > discussion")> b ) -transport-tls more or less as it is now >=20 > I think there are enough comments on a) already in the list archive. I > will not repeat them. >=20 > Comments on b) currently tend to focus on the IPR issue. Let's ignore > that for a moment and look at other arguments. We have=20 > intially opted in > favor of -transport-tls because it already is in widespread=20 > use. What is > done currently can not be standardized literally, but we can=20 > standardize > something that is quite close to it. It was our opinion that > -transport-tls should by fairly easy to implement, thus bringing some > immediate value to the community. >=20 > Now some technical issues have come up on the list, things like > app-layer ACKs, opening and closeing conversations. I have brought up > some of them. I am also of the view that we could craft a better > framing, probably borrowing from NETCONF (and thus easing conversion - > the "big picture"). This is still sufficiently easy, but it is a big > departure from the "let's standardize what is used in practice" > approach. I fear that discussing a better framing/session management > again takes up a lot of time and includes a high risk of missing our > milestones again. BTW: we are scheduled to deliver by=20 > November 2006, and > I do not expect that we will be granted an extension this time again. > November will be very soon, especially looking at the summer break. >=20 > So I propose that we do NOT enter any new discussion. We=20 > should deliver > either a) or b) (above), without introducing any new features=20 > or ideas. > That means that the result will be sub-optimal. But=20 > delivering something > usable is much better than aiming for the perfect one that will never > appear. >=20 > Once we have delivered, we should discuss what to do next (but on! ly &g t; AFTER delivery). I have to admit that I now see some good points = in a > -transport-ssh and consider it implementable with reasonable effort. > However, -transport-ssh should be done after we have reconsidered the > framing. Given the track record of this WG, I would suspect=20 > this can not > be done in less than 12 to 24 month. There are also the issues that > Anton brought up and the general question on configuration and event > data models for syslog. A lot of useful work lying ahead (but=20 > depending > on our ability to finish the base stuff first). >=20 > I think this work can never be done if this WG fails. So I am > desperately trying to get us to publish. I think what we have=20 > is useful > and well-enough. If we do not publish soon, we will never be able to > publish at all. IMHO, we have already received our third chance and > there will be no fourth... >=20 > Rainer >=20 > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > > Sent: Thursday, June 29, 2006 8:32 PM > > To: Rainer Gerhards; 'Chris Lonvick'; syslog@ietf.org > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > >=20 > > Hi Rainer, > >=20 > > [speaking as a contributor] > >=20 > > This WG needs to deliver documents soon or the WG could be closed. =09 > > We need to deliver a secure transport solution. > > If the WG decides to do a 3195bis as the secure transport=20 > solution, I > > recommend the short-term deliverable be "good enough" to work with > > syslog-protocol. That way we can get 3195bis AND the other documents > > (-protocol- and -udp-) published and onto the standards=20 > track, so the > > industry can begin to implement, and the WG can stay open to do > > additional work. > > > &g t; Then we can address whether the 3195 design should be = modified in > > other ways. There have been suggestions to modify 3195 to=20 > "harmonize" > > with the work of other Standards Development Organizations such as > > OASIS and W3C. Doing that work would likely not be quick or easy. I > > fear it would be a real rathole that would prevent us=20 > getting 3195bis > > published at all, and if 3195bis is the WG's choice as the secure > > transport protocol, then that rathole would also prevent the > > publication of -protocol- and -udp- on a timely basis. > >=20 > > As a 14-year veteran of IETF WG efforts, I think it would=20 > be a bad WG > > decision to put 3195bis on the critical path and to open it up to a > > rathole discussion. If 3195bis is on the critical path, we need to > > avoid the rathole discussion for now; it can be considered for a > > future "release". If the WG feels the rathole discussion is really > > necessary, and 3195bis should not be done without having had such a > > possible-rathole discussion, then 3195bis should not be put on the > > critical path. > >=20 > > My $.02 > > David Harrington > > ietfdbh@comcast.net > >=20 > >=20 > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > > Sent: Thursday, June 29, 2006 5:11 AM > > > To: Chris Lonvick; syslog@ietf.org > > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > >=20 > > > Besides the somewhat political issue, I think there is also > > technical > > > issue that affects the question. I think we should consider that > > > question in parallel to the IPR question. > > >=20 > > > This question is if this WG intends to! do a re vision of 3195. And, > > if > > > so, I think the very close next question is if we "just" update it > > to > > > support syslog-protocol or if we intend to make any=20 > > > substantial changes. > > >=20 > > > I see a relationship between the IPR and the 3195bis issue because > > > 3195bis modifies the "cost" of finding alternate solutions. Coming > > to > > > this point, it would probably be helpful if we could actually=20 > > > weigh cost > > > vs. utlity of the different approaches. IPR, IMHO, is just a cost, > > > obviously one whose weight we need to decide on. But I think it is > > not > > > the only cost. If the WG finds such a "cost vs. utility"=20 > discussion > > > useful, I could document my point of view as a starting point. I > > > volunteer to create a summary document (a public web page, not a > > I-D) > > > where I track all contributions to this discussion (for an example > > of > > > what I have in mind see Juergen Schoenwaelder's page on netconf > > > notification requirements: > > >=20 > http://www.eecs.iu = -bremen.de/wiki/index.php/Netconf_notifications). > > >=20 > > > I would find such a page very helpful. It documents the=20 > > > decision process > > > and the decision criteria. In doing that, it helps us come to a > > better > > > decison because we than have all facts at a single place.=20 > > > Thus, it also > > > provides good argument when dealing with the IESG (in the case we > > need > > > to justify the decision).=20 > > >=20 > > > Thanks, > > > Rainer > > >=20 > > > > -----Original Message----- ! > > ; > > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > > > > Sent: Wednesday, June 28, 2006 7:56 PM > > > > To: syslog@ietf.org > > > > Subject: [Syslog] Decisions to make about the Huawei IPR claim > > > >=20 > > > > Hi Folks, > > > >=20 > > > > It's looking like we have a primary decision to make about=20 > > > > the IPR claim=20 > > > > that Huawei has made on syslog-transport-tls. First and=20 > > > > foremost, I want=20 > > > > everyone to be informed of the IETF stand on IPR claims and=20 > > > > on the IETF=20 > > > > process that we will follow. > > > >=20 > > > > This is the position of the IETF on IPR claims: > > > > -------------------------------------------------------------- > > > > ----------- > > > > Intellectual Property > > > >=20 > > > > The IETF takes no position regarding the validity or=20 > > > scope of any > > > > Intellectual Property Rights or other rights that might=20 > > > > be claimed to > > > > pertain to the implementation or use of the technology=20 > > > > described in > > > > this document or the extent to which any license under=20 > > > such rights > > > > might or might not be available; nor does it represent=20 > > > that it has > > > > made any independent effort to identify any such rights. =20 > > > > Information > > > > on the procedures with respect to rights in RFC=20 > documents can > > be > > > > &nb! sp; foun d in BCP 78 and BCP 79. > > > >=20 > > > > Copies of IPR disclosures made to the IETF=20 > Secretariat and any > > > > assurances of licenses to be made available, or the=20 > result of > > an > > > > attempt made to obtain a general license or permission=20 > > > > for the use of > > > > such proprietary rights by implementers or users of this > > > > specification can be obtained from the IETF on-line IPR=20 > > > > repository at > > > > http://www.ietf.org/ipr. > > > >=20 > > > > The IETF invites any interested party to bring to its=20 > > > > attention any > > > > copyrights, patents or patent applications, or other > > proprietary > > > > rights that may cover technology that may be required=20 > > > to implement > > > > this standard. Please address the information to=20 > the IETF at > > > > ietf-ipr@ietf.org. > > > > -------------------------------------------------------------- > > > > ----------- > > > > This is at the bottom of all RFCs. It's pretty clear that we=20 > > > > (our Working=20 > > > > Group) has no place to appeal claims of IPR to. > > > >=20 > > > > Also, the more detailed explanation of the IETF position is=20 > > > in BCP 79: > > > > http://www.ietf.org/rfc/rfc3979.txt > > > > I will ask that everyone! read th rough this before=20 > expressing their > >=20 > > > > opinion. > > > >=20 > > > > One additional source of information for our process is=20 > RFC 3669: > > > > http://www.ietf.org/rfc/rfc3669.txt > > > > "Guidelines for Working Groups on Intellectual Property Issues" > > > > -------------------------------------------------------------- > > > > ----------- > > > > 1. Introduction > > > >=20 > > > > This memo lays out a conceptual framework and rules of thumb > > to > > > > assist working groups dealing with IPR issues. The=20 > goal is to > > > > achieve a balance between the needs of IPR claimants and the > > > > implementers of IETF standards which is appropriate to=20 > > > > current times. > > > > As part of trying to distill out principles for dealing=20 > > > > with IPR in > > > > IETF working groups, it provides case studies of=20 > > > working group IPR > > > > treatment. In other words, it documents the running code=20 > > > > of the IETF > > > > process. > > > >=20 > > > > This memo does not describe IPR procedures for document=20 > > > authors or > > > > IPR claimants. Those are covered in two other memos, on=20 > > > > submission > > > > rights [5] and IPR in the IETF [6]. Rather, this memo is=20 > > > > for work! ing & gt; > > > groups that are trying to decide what to do about technology > > > > contributions which have associated IPR claims. > > > > -------------------------------------------------------------- > > > > ----------- > > > > [5] and [6] are BCP78 and BCP79 respecively. > > > > This document contains a lot of really good advice that we=20 > > > > should be aware=20 > > > > of while we make our decision. > > > >=20 > > > > One part of RFC 3669 is a recommendation to take a critical=20 > > > > look at the=20 > > > > terms of the claim - Section 5.6. Essentially, if we can get=20 > > > > consensus=20 > > > > that the terms are acceptable for implementation, then the=20 > > > > IPR claim may=20 > > > > not be an issue - we can continue to progress=20 > > > > syslog-transport-tls. On=20 > > > > the other hand, if the terms are not acceptable then we can't=20 > > > > expect any=20 > > > > implementations. > > > >=20 > > > > I'm going to ask that everyone please start considering these=20 > > > > inputs and=20 > > > > openly discuss your thoughts about the IETF process and the > > options=20 > > > > available to our Working Group on the mailing list. > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > Do not declare your opinion yet. > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > In a week or so I will ask the group to decide how we should=20 > > > > process. I=20 > > > > want everyone to take the time now to get acquainted with the=20 > > > > process and=20 > > > > the inf! ormation that we have available to us. > > > >=20 > > > > I believe that ultimately, we will need to decide on whether=20 > > > > to continue=20 > > > > to progress syslog-transport-tls, or if we will want to=20 > > > > accept a different=20 > > > > path. If we start down a new path, then we will still need=20 > > > > to make sure=20 > > > > that we are meeting the security objectives that we feel are=20 > > > > important.=20 > > > > This discussion has already been started, which is good in=20 > > > that it can > > > > bringing to light some of the issues that need to be=20 > > > > discussed around the=20 > > > > secure transport of syslog. Once we get this primary issue=20 > > > > resolved then=20 > > > > we can decide upon that. > > > >=20 > > > > Also, the Milestone about delivering a TLS solution can be=20 > > > > easily changed.=20 > > > > I did submit it that way to the IESG and Tom Petch noted that=20 > > > > the Charter=20 > > > > just said "security" protocol while the Goal specified=20 > a specific=20 > > > > solution. Sam didn't want to change it after it had gone=20 > > > in but I'm=20 > > > > certain that it's not going to be a problem if we do want to=20 > > > > change it. > > > >=20 > > > > Thanks, > > > > Chris > > > >=20 > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > >=20 > > >=20 > > > _______________________! ________ ________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 > >=20 >=20 =09 =09 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog =09 ------_=_NextPart_001_01C69C7F.FC07BFEE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
John:
 
The standards you listed define not just payload, but = also the=20 whole messaging.  WSDM uses SOAP over HTTP.  CIM-CX / WBEM - = non-SOAP=20 XML over HTTP. 
 
I am not sure what we can add to help the above other = than to say=20 use TLS. 
 
Or do you want syslog WG to provide an alternative = messaging=20 system, so you could do SOAP or CIM XML over syslog instead of = HTTP?  SOAP=20 Envelopes within syslog messages sounds a bit of a = stretch. =20
 
Could you give a rough, but specific example of = what you have=20 in mind for what syslog WG could produce to satisfy your=20 goals?
 
Frankly, there will always be frameworks which will want = to do=20 eventing using their own protocol.  For example, DSL Forum's TR-069 = obsoletes all of SNMP and they are not relying on = syslog.  They uses=20 their own SOAP-based framework for everything.  Even if we provided = a=20 separate messaging system for syslog, why would they use it and deal = with=20 another protocol, more authentication, etc?  So, I am am not sure = how we=20 can accommodate such frameworks.   
 
Something that define pure payload, like IBM's CBE (XML = messages),=20 which they contributed to WSDM could be accommodated. Syslog-protocol = supports=20 any UTF-8 payload already.
 
Thanks,
Anton.
 

From: John Calcote = [mailto:jcalcote@novell.com]=20
Sent: Friday, June 30, 2006 2:23 PM
To: Chris = Lonvick=20 (clonvick); David Harrington; 'Rainer Gerhards';=20 syslog@ietf.org
Subject: RE: [Syslog] Decisions to make = about the=20 Huawei IPR claim

Jumping in to add my two cents...
 
I quite agree with David on this point. If the syslog WG chose to = begin=20 work on network management issues, it would be stepping into a realm = already=20 well covered by other standards efforts. However - what the world does = need is=20 a standardized and widely understood and deployed _secure_transport_ = for=20 management events. One that will guarantee deliver and sequencing, as = well as=20 privacy based on administrative policy.
 
I work for Novell on the Audit Record Framework (ARF) - a part of = the=20 Bandit Project (http://www.bandit-project.org)= . ARF=20 is chartered to provide an open source, portable, application = audit=20 instrumentation library based on existing standards work. We've chosen = to use=20 the OASIS WSDM Event Format - a W3C XML Schema-based = approach. The ARF=20 library will send management events over a secure protocol - hopefully = syslog=20 - to back-end event collection servers. Novell's eSecurity-acquired = Sentinel=20 product already listens on syslog (3195) channels for such event = information.=20 ARF will provide rich structured content from instrumented = applications=20 on this channel.
 
My suggestion would be for the syslog-sec WG to simply define the = payload=20 of syslog messages to be extensible and flexible, and not spend much = time on=20 defining the management content itself. With efforts like OASIS WSDM, = DMTF=20 CIM-XML (WBEM), and others already well underway, it makes no sense to = go=20 farther down this road with syslog - an event protocol whose charter = makes it=20 infeasible to try to cover the same amount of network management = ground as=20 these other standards efforts will.
 
John Calcote (jcalcote@novell.com)
Software Engineer/Architect
Novell, Inc.

>>> "David = Harrington"=20 <ietfdbh@comcast.net> 6/30/2006 9:57 AM=20 >>>
Hi,

[posting as a contributor]

I = recommend this=20 WG make a clear separation (as much as is possible)
between issues = of=20 security and issues of network management.

Issues such as=20 harmonization with the work of other SDOs, integration
with = netconf,=20 message formatting, content standardization, and so on,
are about = syslog as=20 a network management protocol. I strongly beleve
this work should = **not**=20 be done by the syslog-sec WG, but in a WG
chartered in the OPS area = or the=20 Application area, not the Security
area. There are many = contributors who=20 have worked on, and are
currently working on, other network = management=20 protocols and have
addressed issues similar to those facing syslog. =

In addition, there is an effort by the new OPS Management AD=20 to
address the current isolated decision making (silos) that is=20 occurring
regarding the management plane throughout the IETF. The=20 contributors
to this WG should be involved in that discussion, = which is=20 likely to
be centered in the OPS area.

This WG is about = security for=20 syslog, and we should focus our efforts
on solving the security = problems,=20 whether with tls or ssh or beep, and
publish.

David=20 Harrington
dharrington@huawei.com=20
dbharrington@comcast.net
ietfdbh@comcast.net


>=20 -----Original Message-----
> From: Rainer Gerhards=20 [mailto:rgerhards@hq.adiscon.com]
> Sent: Friday, June 30, 2006 = 6:11=20 AM
> To: David Harrington; Chris Lonvick; = syslog@ietf.org
>=20 Subject: RE: [Syslog] Decisions to make about the Huawei IPR = claim
>=20
> David,
>
> I fully agree with your thought. I, = too,=20 think we must put emphasis
on
> the delivery of documents. In = my=20 personal opinion, this
> leaves only two
> realistic=20 options:
>
> a) rfc 3195bis as you have described it = (without the=20 "rathole
> discussion")> b ) -transport-tls more or = less as it=20 is now
>
> I think there are enough comments on a) = already in the=20 list archive.
I
> will not repeat them.
>
> = Comments on=20 b) currently tend to focus on the IPR issue. Let's
ignore
> = that for=20 a moment and look at other arguments. We have
> intially opted=20 in
> favor of -transport-tls because it already is in widespread =
> use. What is
> done currently can not be standardized=20 literally, but we can
> standardize
> something that is = quite=20 close to it. It was our opinion that
> -transport-tls should by = fairly=20 easy to implement, thus bringing
some
> immediate value to = the=20 community.
>
> Now some technical issues have come up on = the=20 list, things like
> app-layer ACKs, opening and closeing = conversations.=20 I have brought
up
> some of them. I am also of the view that = we could=20 craft a better
> framing, probably borrowing from NETCONF (and = thus=20 easing conversion
-
> the "big picture"). This is still = sufficiently=20 easy, but it is a big
> departure from the "let's standardize = what is=20 used in practice"
> approach. I fear that discussing a better=20 framing/session management
> again takes up a lot of time and = includes a=20 high risk of missing our
> milestones again. BTW: we are = scheduled to=20 deliver by
> November 2006, and
> I do not expect that we = will be=20 granted an extension this time
again.
> November will be very = soon,=20 especially looking at the summer break.
>
> So I propose = that we=20 do NOT enter any new discussion. We
> should deliver
> = either a)=20 or b) (above), without introducing any new features
> or = ideas.
>=20 That means that the result will be sub-optimal. But
> = delivering=20 something
> usable is much better than aiming for the perfect = one that=20 will
never
> appear.
>
> Once we have delivered, = we=20 should discuss what to do next (but on! ly
&g t; AFTER = delivery). I=20 have to admit that I now see some good points in
a
> = -transport-ssh=20 and consider it implementable with reasonable effort.
> However, = -transport-ssh should be done after we have = reconsidered
the
>=20 framing. Given the track record of this WG, I would suspect
> = this can=20 not
> be done in less than 12 to 24 month. There are also the = issues=20 that
> Anton brought up and the general question on = configuration and=20 event
> data models for syslog. A lot of useful work lying ahead = (but=20
> depending
> on our ability to finish the base stuff=20 first).
>
> I think this work can never be done if this = WG fails.=20 So I am
> desperately trying to get us to publish. I think what = we have=20
> is useful
> and well-enough. If we do not publish soon, = we will=20 never be able to
> publish at all. IMHO, we have already = received our=20 third chance and
> there will be no fourth...
>
>=20 Rainer
>
> > -----Original Message-----
> > = From:=20 David Harrington [mailto:ietfdbh@comcast.net]
> > Sent: = Thursday,=20 June 29, 2006 8:32 PM
> > To: Rainer Gerhards; 'Chris = Lonvick';=20 syslog@ietf.org
> > Subject: RE: [Syslog] Decisions to make = about the=20 Huawei IPR claim
> >
> > Hi Rainer,
> > =
>=20 > [speaking as a contributor]
> >
> > This WG = needs to=20 deliver documents soon or the WG could be closed.

> > We = need to=20 deliver a secure transport solution.
> > If the WG decides to = do a=20 3195bis as the secure transport
> solution, I
> > = recommend=20 the short-term deliverable be "good enough" to work with
> >=20 syslog-protocol. That way we can get 3195bis AND the=20 other
documents
> > (-protocol- and -udp-) published and = onto the=20 standards
> track, so the
> > industry can begin to = implement,=20 and the WG can stay open to do
> > additional work.
> = >=20 > &g t; Then we can address whether the 3195 design should = be=20 modified in
> > other ways. There have been suggestions to = modify=20 3195 to
> "harmonize"
> > with the work of other = Standards=20 Development Organizations such as
> > OASIS and W3C. Doing = that work=20 would likely not be quick or easy.
I
> > fear it would be = a real=20 rathole that would prevent us
> getting 3195bis
> > = published=20 at all, and if 3195bis is the WG's choice as the secure
> > = transport=20 protocol, then that rathole would also prevent the
> > = publication of=20 -protocol- and -udp- on a timely basis.
> >
> > As = a=20 14-year veteran of IETF WG efforts, I think it would
> be a bad = WG
> > decision to put 3195bis on the critical path and to = open it up=20 to
a
> > rathole discussion. If 3195bis is on the critical = path,=20 we need to
> > avoid the rathole discussion for now; it can = be=20 considered for a
> > future "release". If the WG feels the = rathole=20 discussion is really
> > necessary, and 3195bis should not be = done=20 without having had such
a
> > possible-rathole discussion, = then=20 3195bis should not be put on the
> > critical path.
> = >=20
> > My $.02
> > David Harrington
> >=20 ietfdbh@comcast.net
> >
> >
> > >=20 -----Original Message-----
> > > From: Rainer Gerhards=20 [mailto:rgerhards@hq.adiscon.com]
> > > Sent: Thursday, = June 29,=20 2006 5:11 AM
> > > To: Chris Lonvick; = syslog@ietf.org
> >=20 > Subject: RE: [Syslog] Decisions to make about the Huawei=20 IPR
claim
> > >
> > > Besides the somewhat = political issue, I think there is also
> > technical
> = >=20 > issue that affects the question. I think we should consider = that
>=20 > > question in parallel to the IPR question.
> > > =
>=20 > > This question is if this WG intends to! do a re vision of=20 3195.
And,
> > if
> > > so, I think the very = close=20 next question is if we "just" update
it
> > to
> = > >=20 support syslog-protocol or if we intend to make any
> > > = substantial changes.
> > >
> > > I see a = relationship=20 between the IPR and the 3195bis issue
because
> > > = 3195bis=20 modifies the "cost" of finding alternate solutions.
Coming
> = >=20 to
> > > this point, it would probably be helpful if we = could=20 actually
> > > weigh cost
> > > vs. utlity of = the=20 different approaches. IPR, IMHO, is just a
cost,
> > >=20 obviously one whose weight we need to decide on. But I think = it
is
>=20 > not
> > > the only cost. If the WG finds such a "cost = vs.=20 utility"
> discussion
> > > useful, I could = document my=20 point of view as a starting point. I
> > > volunteer to = create a=20 summary document (a public web page, not a
> > I-D)
> = > >=20 where I track all contributions to this discussion (for = an
example
>=20 > of
> > > what I have in mind see Juergen = Schoenwaelder's page=20 on netconf
> > > notification requirements:
> > = >=20
> http://www.eecs.iu-bremen.de/wiki/index.= php/Netconf_notifications).
>=20 > >
> > > I would find such a page very helpful. It = documents the
> > > decision process
> > > = and the=20 decision criteria. In doing that, it helps us come to a
> >=20 better
> > > decison because we than have all facts at a = single=20 place.
> > > Thus, it also
> > > provides = good=20 argument when dealing with the IESG (in the case
we
> >=20 need
> > > to justify the decision).
> > > =
>=20 > > Thanks,
> > > Rainer
> > >
> = >=20 > > -----Original Message-----
! > > ; > > From: = Chris=20 Lonvick [mailto:clonvick@cisco.com]
> > > > Sent: = Wednesday,=20 June 28, 2006 7:56 PM
> > > > To: = syslog@ietf.org
> >=20 > > Subject: [Syslog] Decisions to make about the Huawei IPR=20 claim
> > > >
> > > > Hi Folks,
> = >=20 > >
> > > > It's looking like we have a primary = decision=20 to make about
> > > > the IPR claim
> > > = >=20 that Huawei has made on syslog-transport-tls.  First and
> = >=20 > > foremost, I want
> > > > everyone to be = informed of=20 the IETF stand on IPR claims and
> > > > on the IETF =
>=20 > > > process that we will follow.
> > > > =
>=20 > > > This is the position of the IETF on IPR claims:
> = >=20 > >=20 --------------------------------------------------------------
> = >=20 > > -----------
> > > > Intellectual = Property
>=20 > > >
> > > >     The = IETF takes=20 no position regarding the validity or
> > > scope of = any
>=20 > > >     Intellectual Property Rights or = other=20 rights that might
> > > > be claimed to
> > = >=20 >     pertain to the implementation or use of = the=20 technology
> > > > described in
> > >=20 >     this document or the extent to which any = license=20 under
> > > such rights
> > >=20 >     might or might not be available; nor does = it=20 represent
> > > that it has
> > >=20 >     made any independent effort to identify = any such=20 rights. 
> > > > Information
> > >=20 >     on the procedures with respect to rights = in RFC=20
> documents can
> > be
> > >=20 >   &nb! sp; foun d in BCP 78 and BCP = 79.
> >=20 > >
> > > >     Copies of = IPR=20 disclosures made to the IETF
> Secretariat and any
> > = >=20 >     assurances of licenses to be made = available, or=20 the
> result of
> > an
> > >=20 >     attempt made to obtain a general license = or=20 permission
> > > > for the use of
> > >=20 >     such proprietary rights by implementers = or users=20 of this
> > > >     specification = can be=20 obtained from the IETF on-line IPR
> > > > repository=20 at
> > > >     http://www.ietf.org/ipr.
> = > >=20 >
> > > >     The IETF invites = any=20 interested party to bring to its
> > > > attention = any
>=20 > > >     copyrights, patents or patent=20 applications, or other
> > proprietary
> > >=20 >     rights that may cover technology that may = be=20 required
> > > to implement
> > >=20 >     this standard.  Please address the=20 information to
> the IETF at
> > >=20 >     ietf-ipr@ietf.org.
> > > > = --------------------------------------------------------------
> = >=20 > > -----------
> > > > This is at the bottom of = all=20 RFCs.  It's pretty clear that we
> > > > (our = Working=20
> > > > Group) has no place to appeal claims of IPR=20 to.
> > > >
> > > > Also, the more = detailed=20 explanation of the IETF position is
> > > in BCP = 79:
> >=20 > >    http://www.ietf.org/rfc/rfc3= 979.txt
>=20 > > > I will ask that everyone! read th rough this before =
>=20 expressing their
> >
> > > > opinion.
> = >=20 > >
> > > > One additional source of information = for our=20 process is
> RFC 3669:
> > > >    = http://www.ietf.org/rfc/rfc3= 669.txt
>=20 > > > "Guidelines for Working Groups on Intellectual=20 Property
Issues"
> > > >=20 --------------------------------------------------------------
> = >=20 > > -----------
> > > > 1.  = Introduction
>=20 > > >
> > > >     This = memo lays=20 out a conceptual framework and rules of
thumb
> > = to
> >=20 > >     assist working groups dealing with = IPR=20 issues.  The
> goal is to
> > >=20 >     achieve a balance between the needs of = IPR=20 claimants and
the
> > > >    =20 implementers of IETF standards which is appropriate to
> > = > >=20 current times.
> > > >     As part = of=20 trying to distill out principles for dealing
> > > > = with IPR=20 in
> > > >     IETF working groups, = it=20 provides case studies of
> > > working group IPR
> = >=20 > >     treatment.  In other words, it=20 documents the running code
> > > > of the IETF
> = >=20 > >     process.
> > > > =
>=20 > > >     This memo does not describe IPR = procedures for document
> > > authors or
> > = >=20 >     IPR claimants.  Those are covered in = two=20 other memos, on
> > > > submission
> > >=20 >     rights [5] and IPR in the IETF [6].  = Rather,=20 this memo is
> > > > for work! ing
& gt; > = >=20 >     groups that are trying to decide what to = do=20 about
technology
> > > >    =20 contributions which have associated IPR claims.
> > > > = --------------------------------------------------------------
> = >=20 > > -----------
> > > > [5] and [6] are BCP78 and = BCP79=20 respecively.
> > > > This document contains a lot of = really=20 good advice that we
> > > > should be aware
> = > >=20 > of while we make our decision.
> > > >
> = > >=20 > One part of RFC 3669 is a recommendation to take a critical =
> >=20 > > look at the
> > > > terms of the claim - = Section=20 5.6.  Essentially, if we can get
> > > > = consensus=20
> > > > that the terms are acceptable for = implementation, then=20 the
> > > > IPR claim may
> > > > not = be an=20 issue - we can continue to progress
> > > >=20 syslog-transport-tls.  On
> > > > the other hand, = if the=20 terms are not acceptable then we can't
> > > > expect = any=20
> > > > implementations.
> > > > =
> >=20 > > I'm going to ask that everyone please start considering = these=20
> > > > inputs and
> > > > openly = discuss your=20 thoughts about the IETF process and the
> > options
> = >=20 > > available to our Working Group on the mailing list.
> = >=20 > > +++ +++ +++ +++ +++ +++ +++ +++ +++
> > >=20 >    Do not declare your opinion yet.
> > = > >=20 +++ +++ +++ +++ +++ +++ +++ +++ +++
> > > > In a week = or so I=20 will ask the group to decide how we should
> > > >=20 process.  I
> > > > want everyone to take the = time now to=20 get acquainted with the
> > > > process and
> = > >=20 > the inf! ormation that we have available to us.
> > > = >=20
> > > > I believe that ultimately, we will need to = decide on=20 whether
> > > > to continue
> > > > to = progress syslog-transport-tls, or if we will want to
> > = > >=20 accept a different
> > > > path.  If we start = down a new=20 path, then we will still need
> > > > to make sure =
>=20 > > > that we are meeting the security objectives that we = feel are=20
> > > > important.
> > > > This = discussion has=20 already been started, which is good in
> > > that it = can
>=20 > > > bringing to light some of the issues that need to be =
>=20 > > > discussed around the
> > > > secure = transport=20 of syslog.  Once we get this primary issue
> > > = >=20 resolved then
> > > > we can decide upon that.
> = >=20 > >
> > > > Also, the Milestone about delivering = a TLS=20 solution can be
> > > > easily changed.
> > = >=20 > I did submit it that way to the IESG and Tom Petch noted that =
>=20 > > > the Charter
> > > > just said = "security"=20 protocol while the Goal specified
> a specific
> > = > >=20 solution.  Sam didn't want to change it after it had gone =
> >=20 > in but I'm
> > > > certain that it's not going to = be a=20 problem if we do want to
> > > > change it.
> = > >=20 >
> > > > Thanks,
> > > > = Chris
> >=20 > >
> > > >=20 _______________________________________________
> > > > = Syslog=20 mailing list
> > > > Syslog@lists.ietf.org
> > = >=20 > https://www1.ietf.= org/mailman/listinfo/syslog
>=20 > > >
> > >
> > > = _______________________!=20 ________ ________________
> > > Syslog mailing = list
> >=20 > Syslog@lists.ietf.org
> > > https://www1.ietf.= org/mailman/listinfo/syslog
>=20 > >
> >
> >
>=20


_______________________________________________
Syslog = mailing=20 list
Syslog@lists.ietf.org
https://www1.ietf.= org/mailman/listinfo/syslog
------_=_NextPart_001_01C69C7F.FC07BFEE-- --===============1602045984== 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 --===============1602045984==-- From syslog-bounces@lists.ietf.org Fri Jun 30 23:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwW8z-0006Zc-J0; Fri, 30 Jun 2006 23:27:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwVn2-0000SG-2l for syslog@ietf.org; Fri, 30 Jun 2006 23:05:00 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwVmy-00081O-GP for syslog@ietf.org; Fri, 30 Jun 2006 23:05:00 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 30 Jun 2006 21:04:48 -0600 Message-Id: <44A591E5.37FF.0081.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Fri, 30 Jun 2006 21:04:37 -0600 From: "John Calcote" To: "Anton Okmianski (aokmians)" , "Chris Lonvick (clonvick)" , "David Harrington" , "Rainer Gerhards" , Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim References: <98AE08B66FAD1742BED6CB9522B7312201A1CDF6@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <98AE08B66FAD1742BED6CB9522B7312201A1CDF6@xmb-rtp-20d.amer.cisco.com> Mime-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ca81a19b939ce054f98c8f830c2d7742 X-Mailman-Approved-At: Fri, 30 Jun 2006 23:27:40 -0400 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0528072658==" Errors-To: syslog-bounces@lists.ietf.org --===============0528072658== Content-Type: multipart/alternative; boundary="=__Part3A1FD655.3__=" --=__Part3A1FD655.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Anton, I could have been more clear on that point. These other standards describe publish/subscribe systems for event notification. I was referring to a standardized protocol for audit/log data. This data stream may be filtered by policy at various points in the stream, but it's not pub/sub. I was not considering soap - that's a request/response protocol. But I would like to see syslog allow xml in the payload, so that rich structured data can be sent. John >>> "Anton Okmianski (aokmians)" 6/30/2006 2:01 PM >>> John: The standards you listed define not just payload, but also the whole messaging. WSDM uses SOAP over HTTP. CIM-CX / WBEM - non-SOAP XML over HTTP. I am not sure what we can add to help the above other than to say use TLS. Or do you want syslog WG to provide an alternative messaging system, so you could do SOAP or CIM XML over syslog instead of HTTP? SOAP Envelopes within syslog messages sounds a bit of a stretch. Could you give a rough, but specific example of what you have in mind for what syslog WG could produce to satisfy your goals? Frankly, there will always be frameworks which will want to do eventing using their own protocol. For example, DSL Forum's TR-069 obsoletes all of SNMP and they are not relying on syslog. They uses their own SOAP-based framework for everything. Even if we provided a separate messaging system for syslog, why would they use it and deal with another protocol, more authentication, etc? So, I am am not sure how we can accommodate such frameworks. Something that define pure payload, like IBM's CBE (XML messages), which they contributed to WSDM could be accommodated. Syslog-protocol supports any UTF-8 payload already. Thanks, Anton. From: John Calcote [mailto:jcalcote@novell.com] Sent: Friday, June 30, 2006 2:23 PM To: Chris Lonvick (clonvick); David Harrington; 'Rainer Gerhards'; syslog@ietf.org Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim Jumping in to add my two cents... I quite agree with David on this point. If the syslog WG chose to begin work on network management issues, it would be stepping into a realm already well covered by other standards efforts. However - what the world does need is a standardized and widely understood and deployed _secure_transport_ for management events. One that will guarantee deliver and sequencing, as well as privacy based on administrative policy. I work for Novell on the Audit Record Framework (ARF) - a part of the Bandit Project (http://www.bandit-project.org ( http://www.bandit-project.org/ )). ARF is chartered to provide an open source, portable, application audit instrumentation library based on existing standards work. We've chosen to use the OASIS WSDM Event Format - a W3C XML Schema-based approach. The ARF library will send management events over a secure protocol - hopefully syslog - to back-end event collection servers. Novell's eSecurity-acquired Sentinel product already listens on syslog (3195) channels for such event information. ARF will provide rich structured content from instrumented applications on this channel. My suggestion would be for the syslog-sec WG to simply define the payload of syslog messages to be extensible and flexible, and not spend much time on defining the management content itself. With efforts like OASIS WSDM, DMTF CIM-XML (WBEM), and others already well underway, it makes no sense to go farther down this road with syslog - an event protocol whose charter makes it infeasible to try to cover the same amount of network management ground as these other standards efforts will. John Calcote (jcalcote@novell.com) Software Engineer/Architect Novell, Inc. >>> "David Harrington" 6/30/2006 9:57 AM >>> Hi, [posting as a contributor] I recommend this WG make a clear separation (as much as is possible) between issues of security and issues of network management. Issues such as harmonization with the work of other SDOs, integration with netconf, message formatting, content standardization, and so on, are about syslog as a network management protocol. I strongly beleve this work should **not** be done by the syslog-sec WG, but in a WG chartered in the OPS area or the Application area, not the Security area. There are many contributors who have worked on, and are currently working on, other network management protocols and have addressed issues similar to those facing syslog. In addition, there is an effort by the new OPS Management AD to address the current isolated decision making (silos) that is occurring regarding the management plane throughout the IETF. The contributors to this WG should be involved in that discussion, which is likely to be centered in the OPS area. This WG is about security for syslog, and we should focus our efforts on solving the security problems, whether with tls or ssh or beep, and publish. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Friday, June 30, 2006 6:11 AM > To: David Harrington; Chris Lonvick; syslog@ietf.org > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > David, > > I fully agree with your thought. I, too, think we must put emphasis on > the delivery of documents. In my personal opinion, this > leaves only two > realistic options: > > a) rfc 3195bis as you have described it (without the "rathole > discussion")> b ) -transport-tls more or less as it is now > > I think there are enough comments on a) already in the list archive. I > will not repeat them. > > Comments on b) currently tend to focus on the IPR issue. Let's ignore > that for a moment and look at other arguments. We have > intially opted in > favor of -transport-tls because it already is in widespread > use. What is > done currently can not be standardized literally, but we can > standardize > something that is quite close to it. It was our opinion that > -transport-tls should by fairly easy to implement, thus bringing some > immediate value to the community. > > Now some technical issues have come up on the list, things like > app-layer ACKs, opening and closeing conversations. I have brought up > some of them. I am also of the view that we could craft a better > framing, probably borrowing from NETCONF (and thus easing conversion - > the "big picture"). This is still sufficiently easy, but it is a big > departure from the "let's standardize what is used in practice" > approach. I fear that discussing a better framing/session management > again takes up a lot of time and includes a high risk of missing our > milestones again. BTW: we are scheduled to deliver by > November 2006, and > I do not expect that we will be granted an extension this time again. > November will be very soon, especially looking at the summer break. > > So I propose that we do NOT enter any new discussion. We > should deliver > either a) or b) (above), without introducing any new features > or ideas. > That means that the result will be sub-optimal. But > delivering something > usable is much better than aiming for the perfect one that will never > appear. > > Once we have delivered, we should discuss what to do next (but on! ly &g t; AFTER delivery). I have to admit that I now see some good points in a > -transport-ssh and consider it implementable with reasonable effort. > However, -transport-ssh should be done after we have reconsidered the > framing. Given the track record of this WG, I would suspect > this can not > be done in less than 12 to 24 month. There are also the issues that > Anton brought up and the general question on configuration and event > data models for syslog. A lot of useful work lying ahead (but > depending > on our ability to finish the base stuff first). > > I think this work can never be done if this WG fails. So I am > desperately trying to get us to publish. I think what we have > is useful > and well-enough. If we do not publish soon, we will never be able to > publish at all. IMHO, we have already received our third chance and > there will be no fourth... > > Rainer > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Thursday, June 29, 2006 8:32 PM > > To: Rainer Gerhards; 'Chris Lonvick'; syslog@ietf.org > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > Hi Rainer, > > > > [speaking as a contributor] > > > > This WG needs to deliver documents soon or the WG could be closed. > > We need to deliver a secure transport solution. > > If the WG decides to do a 3195bis as the secure transport > solution, I > > recommend the short-term deliverable be "good enough" to work with > > syslog-protocol. That way we can get 3195bis AND the other documents > > (-protocol- and -udp-) published and onto the standards > track, so the > > industry can begin to implement, and the WG can stay open to do > > additional work. > > > &g t; Then we can address whether the 3195 design should be modified in > > other ways. There have been suggestions to modify 3195 to > "harmonize" > > with the work of other Standards Development Organizations such as > > OASIS and W3C. Doing that work would likely not be quick or easy. I > > fear it would be a real rathole that would prevent us > getting 3195bis > > published at all, and if 3195bis is the WG's choice as the secure > > transport protocol, then that rathole would also prevent the > > publication of -protocol- and -udp- on a timely basis. > > > > As a 14-year veteran of IETF WG efforts, I think it would > be a bad WG > > decision to put 3195bis on the critical path and to open it up to a > > rathole discussion. If 3195bis is on the critical path, we need to > > avoid the rathole discussion for now; it can be considered for a > > future "release". If the WG feels the rathole discussion is really > > necessary, and 3195bis should not be done without having had such a > > possible-rathole discussion, then 3195bis should not be put on the > > critical path. > > > > My $.02 > > David Harrington > > ietfdbh@comcast.net > > > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Thursday, June 29, 2006 5:11 AM > > > To: Chris Lonvick; syslog@ietf.org > > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > > > Besides the somewhat political issue, I think there is also > > technical > > > issue that affects the question. I think we should consider that > > > question in parallel to the IPR question. > > > > > > This question is if this WG intends to! do a re vision of 3195. And, > > if > > > so, I think the very close next question is if we "just" update it > > to > > > support syslog-protocol or if we intend to make any > > > substantial changes. > > > > > > I see a relationship between the IPR and the 3195bis issue because > > > 3195bis modifies the "cost" of finding alternate solutions. Coming > > to > > > this point, it would probably be helpful if we could actually > > > weigh cost > > > vs. utlity of the different approaches. IPR, IMHO, is just a cost, > > > obviously one whose weight we need to decide on. But I think it is > > not > > > the only cost. If the WG finds such a "cost vs. utility" > discussion > > > useful, I could document my point of view as a starting point. I > > > volunteer to create a summary document (a public web page, not a > > I-D) > > > where I track all contributions to this discussion (for an example > > of > > > what I have in mind see Juergen Schoenwaelder's page on netconf > > > notification requirements: > > > > http://www.eecs.iu ( http://www.eecs.iu/ )-bremen.de/wiki/index.php/Netconf_notifications). > > > > > > I would find such a page very helpful. It documents the > > > decision process > > > and the decision criteria. In doing that, it helps us come to a > > better > > > decison because we than have all facts at a single place. > > > Thus, it also > > > provides good argument when dealing with the IESG (in the case we > > need > > > to justify the decision). > > > > > > Thanks, > > > Rainer > > > > > > > -----Original Message----- ! > > ; > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > > > Sent: Wednesday, June 28, 2006 7:56 PM > > > > To: syslog@ietf.org > > > > Subject: [Syslog] Decisions to make about the Huawei IPR claim > > > > > > > > Hi Folks, > > > > > > > > It's looking like we have a primary decision to make about > > > > the IPR claim > > > > that Huawei has made on syslog-transport-tls. First and > > > > foremost, I want > > > > everyone to be informed of the IETF stand on IPR claims and > > > > on the IETF > > > > process that we will follow. > > > > > > > > This is the position of the IETF on IPR claims: > > > > -------------------------------------------------------------- > > > > ----------- > > > > Intellectual Property > > > > > > > > The IETF takes no position regarding the validity or > > > scope of any > > > > Intellectual Property Rights or other rights that might > > > > be claimed to > > > > pertain to the implementation or use of the technology > > > > described in > > > > this document or the extent to which any license under > > > such rights > > > > might or might not be available; nor does it represent > > > that it has > > > > made any independent effort to identify any such rights. > > > > Information > > > > on the procedures with respect to rights in RFC > documents can > > be > > > > &nb! sp; foun d in BCP 78 and BCP 79. > > > > > > > > Copies of IPR disclosures made to the IETF > Secretariat and any > > > > assurances of licenses to be made available, or the > result of > > an > > > > attempt made to obtain a general license or permission > > > > for the use of > > > > such proprietary rights by implementers or users of this > > > > specification can be obtained from the IETF on-line IPR > > > > repository at > > > > http://www.ietf.org/ipr. > > > > > > > > The IETF invites any interested party to bring to its > > > > attention any > > > > copyrights, patents or patent applications, or other > > proprietary > > > > rights that may cover technology that may be required > > > to implement > > > > this standard. Please address the information to > the IETF at > > > > ietf-ipr@ietf.org. > > > > -------------------------------------------------------------- > > > > ----------- > > > > This is at the bottom of all RFCs. It's pretty clear that we > > > > (our Working > > > > Group) has no place to appeal claims of IPR to. > > > > > > > > Also, the more detailed explanation of the IETF position is > > > in BCP 79: > > > > http://www.ietf.org/rfc/rfc3979.txt > > > > I will ask that everyone! read th rough this before > expressing their > > > > > > opinion. > > > > > > > > One additional source of information for our process is > RFC 3669: > > > > http://www.ietf.org/rfc/rfc3669.txt > > > > "Guidelines for Working Groups on Intellectual Property Issues" > > > > -------------------------------------------------------------- > > > > ----------- > > > > 1. Introduction > > > > > > > > This memo lays out a conceptual framework and rules of thumb > > to > > > > assist working groups dealing with IPR issues. The > goal is to > > > > achieve a balance between the needs of IPR claimants and the > > > > implementers of IETF standards which is appropriate to > > > > current times. > > > > As part of trying to distill out principles for dealing > > > > with IPR in > > > > IETF working groups, it provides case studies of > > > working group IPR > > > > treatment. In other words, it documents the running code > > > > of the IETF > > > > process. > > > > > > > > This memo does not describe IPR procedures for document > > > authors or > > > > IPR claimants. Those are covered in two other memos, on > > > > submission > > > > rights [5] and IPR in the IETF [6]. Rather, this memo is > > > > for work! ing & gt; > > > groups that are trying to decide what to do about technology > > > > contributions which have associated IPR claims. > > > > -------------------------------------------------------------- > > > > ----------- > > > > [5] and [6] are BCP78 and BCP79 respecively. > > > > This document contains a lot of really good advice that we > > > > should be aware > > > > of while we make our decision. > > > > > > > > One part of RFC 3669 is a recommendation to take a critical > > > > look at the > > > > terms of the claim - Section 5.6. Essentially, if we can get > > > > consensus > > > > that the terms are acceptable for implementation, then the > > > > IPR claim may > > > > not be an issue - we can continue to progress > > > > syslog-transport-tls. On > > > > the other hand, if the terms are not acceptable then we can't > > > > expect any > > > > implementations. > > > > > > > > I'm going to ask that everyone please start considering these > > > > inputs and > > > > openly discuss your thoughts about the IETF process and the > > options > > > > available to our Working Group on the mailing list. > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > Do not declare your opinion yet. > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > In a week or so I will ask the group to decide how we should > > > > process. I > > > > want everyone to take the time now to get acquainted with the > > > > process and > > > > the inf! ormation that we have available to us. > > > > > > > > I believe that ultimately, we will need to decide on whether > > > > to continue > > > > to progress syslog-transport-tls, or if we will want to > > > > accept a different > > > > path. If we start down a new path, then we will still need > > > > to make sure > > > > that we are meeting the security objectives that we feel are > > > > important. > > > > This discussion has already been started, which is good in > > > that it can > > > > bringing to light some of the issues that need to be > > > > discussed around the > > > > secure transport of syslog. Once we get this primary issue > > > > resolved then > > > > we can decide upon that. > > > > > > > > Also, the Milestone about delivering a TLS solution can be > > > > easily changed. > > > > I did submit it that way to the IESG and Tom Petch noted that > > > > the Charter > > > > just said "security" protocol while the Goal specified > a specific > > > > solution. Sam didn't want to change it after it had gone > > > in but I'm > > > > certain that it's not going to be a problem if we do want to > > > > change it. > > > > > > > > Thanks, > > > > Chris > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > _______________________! ________ ________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --=__Part3A1FD655.3__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: HTML
Anton,
 
I could have been more clear on that point. These other standards describe publish/subscribe systems for event notification. I was referring to a standardized protocol for audit/log data. This data stream may be filtered by policy at various points in the stream, but it's not pub/sub.
 
I was not considering soap - that's a request/response protocol. But I would like to see syslog allow xml in the payload, so that rich structured data can be sent.
 
John

>>> "Anton Okmianski (aokmians)" <aokmians@cisco.com> 6/30/2006 2:01 PM >>>
John:
 
The standards you listed define not just payload, but also the whole messaging.  WSDM uses SOAP over HTTP.  CIM-CX / WBEM - non-SOAP XML over HTTP. 
 
I am not sure what we can add to help the above other than to say use TLS. 
 
Or do you want syslog WG to provide an alternative messaging system, so you could do SOAP or CIM XML over syslog instead of HTTP?  SOAP Envelopes within syslog messages sounds a bit of a stretch. 
 
Could you give a rough, but specific example of what you have in mind for what syslog WG could produce to satisfy your goals?
 
Frankly, there will always be frameworks which will want to do eventing using their own protocol.  For example, DSL Forum's TR-069 obsoletes all of SNMP and they are not relying on syslog.  They uses their own SOAP-based framework for everything.  Even if we provided a separate messaging system for syslog, why would they use it and deal with another protocol, more authentication, etc?  So, I am am not sure how we can accommodate such frameworks.   
 
Something that define pure payload, like IBM's CBE (XML messages), which they contributed to WSDM could be accommodated. Syslog-protocol supports any UTF-8 payload already.
 
Thanks,
Anton.
 

From: John Calcote [mailto:jcalcote@novell.com]
Sent: Friday, June 30, 2006 2:23 PM
To: Chris Lonvick (clonvick); David Harrington; 'Rainer Gerhards'; syslog@ietf.org
Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim

Jumping in to add my two cents...
 
I quite agree with David on this point. If the syslog WG chose to begin work on network management issues, it would be stepping into a realm already well covered by other standards efforts. However - what the world does need is a standardized and widely understood and deployed _secure_transport_ for management events. One that will guarantee deliver and sequencing, as well as privacy based on administrative policy.
 
I work for Novell on the Audit Record Framework (ARF) - a part of the Bandit Project (http://www.bandit-project.org). ARF is chartered to provide an open source, portable, application audit instrumentation library based on existing standards work. We've chosen to use the OASIS WSDM Event Format - a W3C XML Schema-based approach. The ARF library will send management events over a secure protocol - hopefully syslog - to back-end event collection servers. Novell's eSecurity-acquired Sentinel product already listens on syslog (3195) channels for such event information. ARF will provide rich structured content from instrumented applications on this channel.
 
My suggestion would be for the syslog-sec WG to simply define the payload of syslog messages to be extensible and flexible, and not spend much time on defining the management content itself. With efforts like OASIS WSDM, DMTF CIM-XML (WBEM), and others already well underway, it makes no sense to go farther down this road with syslog - an event protocol whose charter makes it infeasible to try to cover the same amount of network management ground as these other standards efforts will.
 
John Calcote (jcalcote@novell.com)
Software Engineer/Architect
Novell, Inc.

>>> "David Harrington" <ietfdbh@comcast.net> 6/30/2006 9:57 AM >>>
Hi,

[posting as a contributor]

I recommend this WG make a clear separation (as much as is possible)
between issues of security and issues of network management.

Issues such as harmonization with the work of other SDOs, integration
with netconf, message formatting, content standardization, and so on,
are about syslog as a network management protocol. I strongly beleve
this work should **not** be done by the syslog-sec WG, but in a WG
chartered in the OPS area or the Application area, not the Security
area. There are many contributors who have worked on, and are
currently working on, other network management protocols and have
addressed issues similar to those facing syslog.

In addition, there is an effort by the new OPS Management AD to
address the current isolated decision making (silos) that is occurring
regarding the management plane throughout the IETF. The contributors
to this WG should be involved in that discussion, which is likely to
be centered in the OPS area.

This WG is about security for syslog, and we should focus our efforts
on solving the security problems, whether with tls or ssh or beep, and
publish.

David Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net


> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> Sent: Friday, June 30, 2006 6:11 AM
> To: David Harrington; Chris Lonvick; syslog@ietf.org
> Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim
>
> David,
>
> I fully agree with your thought. I, too, think we must put emphasis
on
> the delivery of documents. In my personal opinion, this
> leaves only two
> realistic options:
>
> a) rfc 3195bis as you have described it (without the "rathole
> discussion")> b ) -transport-tls more or less as it is now
>
> I think there are enough comments on a) already in the list archive.
I
> will not repeat them.
>
> Comments on b) currently tend to focus on the IPR issue. Let's
ignore
> that for a moment and look at other arguments. We have
> intially opted in
> favor of -transport-tls because it already is in widespread
> use. What is
> done currently can not be standardized literally, but we can
> standardize
> something that is quite close to it. It was our opinion that
> -transport-tls should by fairly easy to implement, thus bringing
some
> immediate value to the community.
>
> Now some technical issues have come up on the list, things like
> app-layer ACKs, opening and closeing conversations. I have brought
up
> some of them. I am also of the view that we could craft a better
> framing, probably borrowing from NETCONF (and thus easing conversion
-
> the "big picture"). This is still sufficiently easy, but it is a big
> departure from the "let's standardize what is used in practice"
> approach. I fear that discussing a better framing/session management
> again takes up a lot of time and includes a high risk of missing our
> milestones again. BTW: we are scheduled to deliver by
> November 2006, and
> I do not expect that we will be granted an extension this time
again.
> November will be very soon, especially looking at the summer break.
>
> So I propose that we do NOT enter any new discussion. We
> should deliver
> either a) or b) (above), without introducing any new features
> or ideas.
> That means that the result will be sub-optimal. But
> delivering something
> usable is much better than aiming for the perfect one that will
never
> appear.
>
> Once we have delivered, we should discuss what to do next (but on! ly
&g t; AFTER delivery). I have to admit that I now see some good points in
a
> -transport-ssh and consider it implementable with reasonable effort.
> However, -transport-ssh should be done after we have reconsidered
the
> framing. Given the track record of this WG, I would suspect
> this can not
> be done in less than 12 to 24 month. There are also the issues that
> Anton brought up and the general question on configuration and event
> data models for syslog. A lot of useful work lying ahead (but
> depending
> on our ability to finish the base stuff first).
>
> I think this work can never be done if this WG fails. So I am
> desperately trying to get us to publish. I think what we have
> is useful
> and well-enough. If we do not publish soon, we will never be able to
> publish at all. IMHO, we have already received our third chance and
> there will be no fourth...
>
> Rainer
>
> > -----Original Message-----
> > From: David Harrington [mailto:ietfdbh@comcast.net]
> > Sent: Thursday, June 29, 2006 8:32 PM
> > To: Rainer Gerhards; 'Chris Lonvick'; syslog@ietf.org
> > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim
> >
> > Hi Rainer,
> >
> > [speaking as a contributor]
> >
> > This WG needs to deliver documents soon or the WG could be closed.

> > We need to deliver a secure transport solution.
> > If the WG decides to do a 3195bis as the secure transport
> solution, I
> > recommend the short-term deliverable be "good enough" to work with
> > syslog-protocol. That way we can get 3195bis AND the other
documents
> > (-protocol- and -udp-) published and onto the standards
> track, so the
> > industry can begin to implement, and the WG can stay open to do
> > additional work.
> > > &g t; Then we can address whether the 3195 design should be modified in
> > other ways. There have been suggestions to modify 3195 to
> "harmonize"
> > with the work of other Standards Development Organizations such as
> > OASIS and W3C. Doing that work would likely not be quick or easy.
I
> > fear it would be a real rathole that would prevent us
> getting 3195bis
> > published at all, and if 3195bis is the WG's choice as the secure
> > transport protocol, then that rathole would also prevent the
> > publication of -protocol- and -udp- on a timely basis.
> >
> > As a 14-year veteran of IETF WG efforts, I think it would
> be a bad WG
> > decision to put 3195bis on the critical path and to open it up to
a
> > rathole discussion. If 3195bis is on the critical path, we need to
> > avoid the rathole discussion for now; it can be considered for a
> > future "release". If the WG feels the rathole discussion is really
> > necessary, and 3195bis should not be done without having had such
a
> > possible-rathole discussion, then 3195bis should not be put on the
> > critical path.
> >
> > My $.02
> > David Harrington
> > ietfdbh@comcast.net
> >
> >
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> > > Sent: Thursday, June 29, 2006 5:11 AM
> > > To: Chris Lonvick; syslog@ietf.org
> > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR
claim
> > >
> > > Besides the somewhat political issue, I think there is also
> > technical
> > > issue that affects the question. I think we should consider that
> > > question in parallel to the IPR question.
> > >
> > > This question is if this WG intends to! do a re vision of 3195.
And,
> > if
> > > so, I think the very close next question is if we "just" update
it
> > to
> > > support syslog-protocol or if we intend to make any
> > > substantial changes.
> > >
> > > I see a relationship between the IPR and the 3195bis issue
because
> > > 3195bis modifies the "cost" of finding alternate solutions.
Coming
> > to
> > > this point, it would probably be helpful if we could actually
> > > weigh cost
> > > vs. utlity of the different approaches. IPR, IMHO, is just a
cost,
> > > obviously one whose weight we need to decide on. But I think it
is
> > not
> > > the only cost. If the WG finds such a "cost vs. utility"
> discussion
> > > useful, I could document my point of view as a starting point. I
> > > volunteer to create a summary document (a public web page, not a
> > I-D)
> > > where I track all contributions to this discussion (for an
example
> > of
> > > what I have in mind see Juergen Schoenwaelder's page on netconf
> > > notification requirements:
> > >
> http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications).
> > >
> > > I would find such a page very helpful. It documents the
> > > decision process
> > > and the decision criteria. In doing that, it helps us come to a
> > better
> > > decison because we than have all facts at a single place.
> > > Thus, it also
> > > provides good argument when dealing with the IESG (in the case
we
> > need
> > > to justify the decision).
> > >
> > > Thanks,
> > > Rainer
> > >
> > > > -----Original Message-----
! > > ; > > From: Chris Lonvick [mailto:clonvick@cisco.com]
> > > > Sent: Wednesday, June 28, 2006 7:56 PM
> > > > To: syslog@ietf.org
> > > > Subject: [Syslog] Decisions to make about the Huawei IPR claim
> > > >
> > > > Hi Folks,
> > > >
> > > > It's looking like we have a primary decision to make about
> > > > the IPR claim
> > > > that Huawei has made on syslog-transport-tls.  First and
> > > > foremost, I want
> > > > everyone to be informed of the IETF stand on IPR claims and
> > > > on the IETF
> > > > process that we will follow.
> > > >
> > > > This is the position of the IETF on IPR claims:
> > > > --------------------------------------------------------------
> > > > -----------
> > > > Intellectual Property
> > > >
> > > >     The IETF takes no position regarding the validity or
> > > scope of any
> > > >     Intellectual Property Rights or other rights that might
> > > > be claimed to
> > > >     pertain to the implementation or use of the technology
> > > > described in
> > > >     this document or the extent to which any license under
> > > such rights
> > > >     might or might not be available; nor does it represent
> > > that it has
> > > >     made any independent effort to identify any such rights. 
> > > > Information
> > > >     on the procedures with respect to rights in RFC
> documents can
> > be
> > > >   &nb! sp; foun d in BCP 78 and BCP 79.
> > > >
> > > >     Copies of IPR disclosures made to the IETF
> Secretariat and any
> > > >     assurances of licenses to be made available, or the
> result of
> > an
> > > >     attempt made to obtain a general license or permission
> > > > for the use of
> > > >     such proprietary rights by implementers or users of this
> > > >     specification can be obtained from the IETF on-line IPR
> > > > repository at
> > > >     http://www.ietf.org/ipr.
> > > >
> > > >     The IETF invites any interested party to bring to its
> > > > attention any
> > > >     copyrights, patents or patent applications, or other
> > proprietary
> > > >     rights that may cover technology that may be required
> > > to implement
> > > >     this standard.  Please address the information to
> the IETF at
> > > >     ietf-ipr@ietf.org.
> > > > --------------------------------------------------------------
> > > > -----------
> > > > This is at the bottom of all RFCs.  It's pretty clear that we
> > > > (our Working
> > > > Group) has no place to appeal claims of IPR to.
> > > >
> > > > Also, the more detailed explanation of the IETF position is
> > > in BCP 79:
> > > >    http://www.ietf.org/rfc/rfc3979.txt
> > > > I will ask that everyone! read th rough this before
> expressing their
> >
> > > > opinion.
> > > >
> > > > One additional source of information for our process is
> RFC 3669:
> > > >    http://www.ietf.org/rfc/rfc3669.txt
> > > > "Guidelines for Working Groups on Intellectual Property
Issues"
> > > > --------------------------------------------------------------
> > > > -----------
> > > > 1.  Introduction
> > > >
> > > >     This memo lays out a conceptual framework and rules of
thumb
> > to
> > > >     assist working groups dealing with IPR issues.  The
> goal is to
> > > >     achieve a balance between the needs of IPR claimants and
the
> > > >     implementers of IETF standards which is appropriate to
> > > > current times.
> > > >     As part of trying to distill out principles for dealing
> > > > with IPR in
> > > >     IETF working groups, it provides case studies of
> > > working group IPR
> > > >     treatment.  In other words, it documents the running code
> > > > of the IETF
> > > >     process.
> > > >
> > > >     This memo does not describe IPR procedures for document
> > > authors or
> > > >     IPR claimants.  Those are covered in two other memos, on
> > > > submission
> > > >     rights [5] and IPR in the IETF [6].  Rather, this memo is
> > > > for work! ing
& gt; > > >     groups that are trying to decide what to do about
technology
> > > >     contributions which have associated IPR claims.
> > > > --------------------------------------------------------------
> > > > -----------
> > > > [5] and [6] are BCP78 and BCP79 respecively.
> > > > This document contains a lot of really good advice that we
> > > > should be aware
> > > > of while we make our decision.
> > > >
> > > > One part of RFC 3669 is a recommendation to take a critical
> > > > look at the
> > > > terms of the claim - Section 5.6.  Essentially, if we can get
> > > > consensus
> > > > that the terms are acceptable for implementation, then the
> > > > IPR claim may
> > > > not be an issue - we can continue to progress
> > > > syslog-transport-tls.  On
> > > > the other hand, if the terms are not acceptable then we can't
> > > > expect any
> > > > implementations.
> > > >
> > > > I'm going to ask that everyone please start considering these
> > > > inputs and
> > > > openly discuss your thoughts about the IETF process and the
> > options
> > > > available to our Working Group on the mailing list.
> > > > +++ +++ +++ +++ +++ +++ +++ +++ +++
> > > >    Do not declare your opinion yet.
> > > > +++ +++ +++ +++ +++ +++ +++ +++ +++
> > > > In a week or so I will ask the group to decide how we should
> > > > process.  I
> > > > want everyone to take the time now to get acquainted with the
> > > > process and
> > > > the inf! ormation that we have available to us.
> > > >
> > > > I believe that ultimately, we will need to decide on whether
> > > > to continue
> > > > to progress syslog-transport-tls, or if we will want to
> > > > accept a different
> > > > path.  If we start down a new path, then we will still need
> > > > to make sure
> > > > that we are meeting the security objectives that we feel are
> > > > important.
> > > > This discussion has already been started, which is good in
> > > that it can
> > > > bringing to light some of the issues that need to be
> > > > discussed around the
> > > > secure transport of syslog.  Once we get this primary issue
> > > > resolved then
> > > > we can decide upon that.
> > > >
> > > > Also, the Milestone about delivering a TLS solution can be
> > > > easily changed.
> > > > I did submit it that way to the IESG and Tom Petch noted that
> > > > the Charter
> > > > just said "security" protocol while the Goal specified
> a specific
> > > > solution.  Sam didn't want to change it after it had gone
> > > in but I'm
> > > > certain that it's not going to be a problem if we do want to
> > > > change it.
> > > >
> > > > Thanks,
> > > > Chris
> > > >
> > > > _______________________________________________
> > > > Syslog mailing list
> > > > Syslog@lists.ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/syslog
> > > >
> > >
> > > _______________________! ________ ________________
> > > Syslog mailing list
> > > Syslog@lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > >
> >
> >
>


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
--=__Part3A1FD655.3__=-- --===============0528072658== 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 --===============0528072658==--