From syslog-bounces@lists.ietf.org Fri Nov 03 12:35:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2vO-0005nP-HI; Fri, 03 Nov 2006 12:33:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2vN-0005nG-KG for syslog@ietf.org; Fri, 03 Nov 2006 12:33:49 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg2vH-0008Dm-Qv for syslog@ietf.org; Fri, 03 Nov 2006 12:33:49 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2006 09:33:43 -0800 X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="85125688:sNHT148336443" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3HXhEo002946 for ; Fri, 3 Nov 2006 09:33:43 -0800 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 kA3HXhio020591 for ; Fri, 3 Nov 2006 09:33:43 -0800 (PST) Date: Fri, 3 Nov 2006 09:33:42 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=517; t=1162575223; x=1163439223; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Alarm=20MIB=20in=20syslog-protocol; X=v=3Dcisco.com=3B=20h=3DXxy7MuW7fBWVIh83w1e00lvZD0M=3D; b=QetFKJSMB5/90cJv1xB62OdT80Oh1cxET8iU2pGz7TUjd8CxUfKo69fOzOIUO8fb+2e75/q/ pSaNYm4v/lH0uV8NyV7I4iHy43ila0FsLb6/G3Hgpov/JixDh/N9MYU1; 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Syslog] Alarm MIB in 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, In David Harrington's review of syslog-protocol-17 http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877). We discussed this a while ago and it doesn't seem that there is a good fit between the historical syslog severities and the Alarm MIBs. I've asked Rainer to remove this. Anyone interested is hereby encouraged to write a document that specifies how to display the Alarm MIBs as Structured Data. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 03 12:44:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg352-0005ih-7u; Fri, 03 Nov 2006 12:43:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg351-0005ib-Kv for syslog@ietf.org; Fri, 03 Nov 2006 12:43:47 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg34v-0000oG-81 for syslog@ietf.org; Fri, 03 Nov 2006 12:43:47 -0500 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kA3HaPR21664 for ; Fri, 3 Nov 2006 12:36:25 -0500 (EST) 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] Alarm MIB in syslog-protocol Date: Fri, 3 Nov 2006 12:43:08 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40BC54CA9@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Alarm MIB in syslog-protocol Thread-Index: Acb/buZ/38/pLEKnSAmHiTpHgaqrDgAABoNQ From: "Sharon Chisholm" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi This is an important section (and no, I'm not just saying that because I co-authored RFC 3877). It provides the mapping between severities in alarms sent via SNMP and those logged in syslog. Removing it means that implementations will all have different mappings. Sharon -----Original Message----- From: Chris Lonvick [mailto:clonvick@cisco.com]=20 Sent: Friday, November 03, 2006 12:34 PM To: syslog@ietf.org Subject: [Syslog] Alarm MIB in syslog-protocol Hi, In David Harrington's review of syslog-protocol-17 http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877). We discussed this a while ago and it doesn't seem that there is a good fit between the historical syslog severities and the Alarm MIBs. I've asked Rainer to remove this. Anyone interested is hereby encouraged to write a document that specifies how to display the Alarm MIBs as Structured Data. 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 Fri Nov 03 13:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3jh-0003hv-F1; Fri, 03 Nov 2006 13:25:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg3jf-0003e9-NK for syslog@ietf.org; Fri, 03 Nov 2006 13:25:47 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg3jd-0004cL-C4 for syslog@ietf.org; Fri, 03 Nov 2006 13:25:47 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2006 10:25:38 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACgYS0WrR7PDh2dsb2JhbACMSgEBCQ4q X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="349916456:sNHT25111616" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3IPbv4020629; Fri, 3 Nov 2006 10:25:37 -0800 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 kA3IPbio002839; Fri, 3 Nov 2006 10:25:37 -0800 (PST) Date: Fri, 3 Nov 2006 10:25:36 -0800 (PST) From: Chris Lonvick To: Sharon Chisholm Subject: RE: [Syslog] Alarm MIB in syslog-protocol In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40BC54CA9@zcarhxm2.corp.nortel.com> Message-ID: References: <713043CE8B8E1348AF3C546DBE02C1B40BC54CA9@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1867; t=1162578337; x=1163442337; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:RE=3A=20[Syslog]=20Alarm=20MIB=20in=20syslog-protocol; X=v=3Dcisco.com=3B=20h=3DHT6uTyVuPNk/5HHZQOkjsv1U/c4=3D; b=Uyq7BQ9kkPxSFbnUl1SROJXPMKf7LihGCEA9E6LHssf2qbHmOBv0L/0in6AFGw7PBY6SLlKj p/jBjTpXefpIHNLFe+TN9DnIhXFTJ4tSp+O0orVRP6HWv5dn4K9g6jAN; 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: 7aafa0432175920a4b3e118e16c5cb64 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 Sharon, It's an important concept but I feel that it is underspecified and ambiguous in the current document. The recipent of a message with the Severity of Notice would not be able to tell if the sender intended for it to be the ITU alarm of Indeterminate or Cleared. I believe that this part was specified before the concept of Structured Data was included in syslog-protocol. Using Structured Data would disambiguate the intention. Thanks, Chris On Fri, 3 Nov 2006, Sharon Chisholm wrote: > Hi > > This is an important section (and no, I'm not just saying that because I > co-authored RFC 3877). It provides the mapping between severities in > alarms sent via SNMP and those logged in syslog. Removing it means that > implementations will all have different mappings. > > Sharon > > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, November 03, 2006 12:34 PM > To: syslog@ietf.org > Subject: [Syslog] Alarm MIB in syslog-protocol > > Hi, > > In David Harrington's review of syslog-protocol-17 > http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html > he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877). We > discussed this a while ago and it doesn't seem that there is a good fit > between the historical syslog severities and the Alarm MIBs. I've asked > Rainer to remove this. Anyone interested is hereby encouraged to write > a document that specifies how to display the Alarm MIBs as Structured > Data. > > 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 Nov 03 14:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4nM-00070j-E1; Fri, 03 Nov 2006 14:33:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4nK-00070d-Ir for syslog@ietf.org; Fri, 03 Nov 2006 14:33:38 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg4nH-0005Yz-5D for syslog@ietf.org; Fri, 03 Nov 2006 14:33:38 -0500 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA3JXFx09060 for ; Fri, 3 Nov 2006 14:33:15 -0500 (EST) 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] Alarm MIB in syslog-protocol Date: Fri, 3 Nov 2006 14:32:58 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40BC54F6E@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Alarm MIB in syslog-protocol Thread-Index: Acb/dXo+XSNVM+qLSROKAB/KsRGvIAACKeSw From: "Sharon Chisholm" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 Actually, no structured data was already in the draft when this was added.=20 At the time, the working group discussed the lossy nature of the mapping, determined it was inevitable, looked at the various ways the mapping could be constructed and settled on the one which lost the least important bit of information. Perhaps a note indicating that this mapping is lossy and that implementations that want to be able to do a fully reversible mapping should consider also sending the alarm/ITU severity within the syslog message. I don't believe we need to indicate how in this document. Just indicate that we recognize the issue and hint at how to solve it. Sort of like a security considerations section. Even if people have some extra field, they still need to know what to do with the severity field syslog. I view this as no different then the mapping to ifAdmin and ifOper status we did when we did the Entity State MIB. http://www.ietf.org/rfc/rfc4268.txt?number=3D4268 Sharon=20 -----Original Message----- From: Chris Lonvick [mailto:clonvick@cisco.com]=20 Sent: Friday, November 03, 2006 1:26 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: syslog@ietf.org Subject: RE: [Syslog] Alarm MIB in syslog-protocol Hi Sharon, It's an important concept but I feel that it is underspecified and ambiguous in the current document. The recipent of a message with the Severity of Notice would not be able to tell if the sender intended for it to be the ITU alarm of Indeterminate or Cleared. I believe that this part was specified before the concept of Structured Data was included in syslog-protocol. Using Structured Data would disambiguate the intention. Thanks, Chris On Fri, 3 Nov 2006, Sharon Chisholm wrote: > Hi > > This is an important section (and no, I'm not just saying that because > I co-authored RFC 3877). It provides the mapping between severities in > alarms sent via SNMP and those logged in syslog. Removing it means=20 > that implementations will all have different mappings. > > Sharon > > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, November 03, 2006 12:34 PM > To: syslog@ietf.org > Subject: [Syslog] Alarm MIB in syslog-protocol > > Hi, > > In David Harrington's review of syslog-protocol-17 > http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html > he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877). We=20 > discussed this a while ago and it doesn't seem that there is a good=20 > fit between the historical syslog severities and the Alarm MIBs. I've > asked Rainer to remove this. Anyone interested is hereby encouraged=20 > to write a document that specifies how to display the Alarm MIBs as=20 > Structured Data. > > 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 Nov 03 15:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg5nC-0006QZ-Pb; Fri, 03 Nov 2006 15:37:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg5nC-0006QU-1R for syslog@ietf.org; Fri, 03 Nov 2006 15:37:34 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg5nA-0008Ic-Kq for syslog@ietf.org; Fri, 03 Nov 2006 15:37:34 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2006 12:37:32 -0800 X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="85211479:sNHT59038137" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3KbWOV028124; Fri, 3 Nov 2006 12:37:32 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA3KbVW5028264; Fri, 3 Nov 2006 12:37:31 -0800 (PST) Date: Fri, 3 Nov 2006 12:37:31 -0800 (PST) From: Chris Lonvick To: Sharon Chisholm Subject: RE: [Syslog] Alarm MIB in syslog-protocol In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40BC54F6E@zcarhxm2.corp.nortel.com> Message-ID: References: <713043CE8B8E1348AF3C546DBE02C1B40BC54F6E@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=3954; t=1162586252; x=1163450252; c=relaxed/simple; s=sjdkim4002; 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]=20Alarm=20MIB=20in=20syslog-protocol; X=v=3Dcisco.com=3B=20h=3DHT6uTyVuPNk/5HHZQOkjsv1U/c4=3D; b=SOUxyRhMwQ2W8GU8nfrahjzOkBgOOmr+HanJXGHKvqzKW4pZTLqIYPtxC7/NiE+ejy1AxZvT jvCEe9+jam2Bc62i97kz9CFJGye43m8EYBG71AJ148olF5bYSpq0eG4d; 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: 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 Hi Sharon, On Fri, 3 Nov 2006, Sharon Chisholm wrote: > Hi > > Actually, no structured data was already in the draft when this was > added. > > At the time, the working group discussed the lossy nature of the > mapping, determined it was inevitable, looked at the various ways the > mapping could be constructed and settled on the one which lost the least > important bit of information. > > Perhaps a note indicating that this mapping is lossy and that > implementations that want to be able to do a fully reversible mapping > should consider also sending the alarm/ITU severity within the syslog > message. I don't believe we need to indicate how in this document. Just > indicate that we recognize the issue and hint at how to solve it. Sort > of like a security considerations section. We have a mechanism defined to address the issue properly. Why would we want to underspecify this standard (syslog-protocol) by just giving a hint of how to do it right? If it is going to be done, then it needs to be done properly and completely, which means fully specifying how to indicate the true ITU severity within structured data. However, I don't want to delay this document by doing it here at this time. What's wrong with putting this in a separate document? Thanks, Chris > > Even if people have some extra field, they still need to know what to do > with the severity field syslog. I view this as no different then the > mapping to ifAdmin and ifOper status we did when we did the Entity State > MIB. > http://www.ietf.org/rfc/rfc4268.txt?number=4268 > > Sharon > > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, November 03, 2006 1:26 PM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: syslog@ietf.org > Subject: RE: [Syslog] Alarm MIB in syslog-protocol > > Hi Sharon, > > It's an important concept but I feel that it is underspecified and > ambiguous in the current document. The recipent of a message with the > Severity of Notice would not be able to tell if the sender intended for > it to be the ITU alarm of Indeterminate or Cleared. I believe that this > part was specified before the concept of Structured Data was included in > syslog-protocol. Using Structured Data would disambiguate the > intention. > > Thanks, > Chris > > > On Fri, 3 Nov 2006, Sharon Chisholm wrote: > >> Hi >> >> This is an important section (and no, I'm not just saying that because > >> I co-authored RFC 3877). It provides the mapping between severities in > >> alarms sent via SNMP and those logged in syslog. Removing it means >> that implementations will all have different mappings. >> >> Sharon >> >> -----Original Message----- >> From: Chris Lonvick [mailto:clonvick@cisco.com] >> Sent: Friday, November 03, 2006 12:34 PM >> To: syslog@ietf.org >> Subject: [Syslog] Alarm MIB in syslog-protocol >> >> Hi, >> >> In David Harrington's review of syslog-protocol-17 >> http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html >> he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877). We >> discussed this a while ago and it doesn't seem that there is a good >> fit between the historical syslog severities and the Alarm MIBs. I've > >> asked Rainer to remove this. Anyone interested is hereby encouraged >> to write a document that specifies how to display the Alarm MIBs as >> Structured Data. >> >> 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 08 11:14:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghq1z-0003AI-1H; Wed, 08 Nov 2006 11:12:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghq1x-00036f-3J for syslog@ietf.org; Wed, 08 Nov 2006 11:12:01 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghq1v-00029o-Ir for syslog@ietf.org; Wed, 08 Nov 2006 11:12:01 -0500 Received: from pc6 (1Cust3.tnt21.lnd4.gbr.da.uu.net [62.188.150.3]) by ranger.systems.pipex.net (Postfix) with SMTP id BBE69E0000D6; Wed, 8 Nov 2006 16:11:43 +0000 (GMT) Message-ID: <032601c70348$4a7ec8a0$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , "Sharon Chisholm" References: <713043CE8B8E1348AF3C546DBE02C1B40BC54F6E@zcarhxm2.corp.nortel.com> Subject: Re: [Syslog] Alarm MIB in syslog-protocol Date: Wed, 8 Nov 2006 12:31:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Chris Lonvick" To: "Sharon Chisholm" Cc: Sent: Friday, November 03, 2006 9:37 PM Subject: RE: [Syslog] Alarm MIB in syslog-protocol > > On Fri, 3 Nov 2006, Sharon Chisholm wrote: > > > Actually, no structured data was already in the draft when this was > > added. > > > > At the time, the working group discussed the lossy nature of the > > mapping, determined it was inevitable, looked at the various ways the > > mapping could be constructed and settled on the one which lost the least > > important bit of information. > > > > Perhaps a note indicating that this mapping is lossy and that > > implementations that want to be able to do a fully reversible mapping > > should consider also sending the alarm/ITU severity within the syslog > > message. I don't believe we need to indicate how in this document. Just > > indicate that we recognize the issue and hint at how to solve it. Sort > > of like a security considerations section. > > We have a mechanism defined to address the issue properly. Why would we > want to underspecify this standard (syslog-protocol) by just giving a hint > of how to do it right? If it is going to be done, then it needs to be > done properly and completely, which means fully specifying how to indicate > the true ITU severity within structured data. However, I don't want to > delay this document by doing it here at this time. > > What's wrong with putting this in a separate document? > > Chris I am with Sharon with this. The information is not perfect but it is the best we can do and, for me, it is near enough right to be worth including, perhaps with a caveat that the nature of syslog and the nature of the ITU-T means that the mapping cannot be perfect. Tom Petch > > > > > Even if people have some extra field, they still need to know what to do > > with the severity field syslog. I view this as no different then the > > mapping to ifAdmin and ifOper status we did when we did the Entity State > > MIB. > > http://www.ietf.org/rfc/rfc4268.txt?number=4268 > > > > Sharon > > > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Friday, November 03, 2006 1:26 PM > > To: Chisholm, Sharon (CAR:ZZ00) > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] Alarm MIB in syslog-protocol > > > > Hi Sharon, > > > > It's an important concept but I feel that it is underspecified and > > ambiguous in the current document. The recipent of a message with the > > Severity of Notice would not be able to tell if the sender intended for > > it to be the ITU alarm of Indeterminate or Cleared. I believe that this > > part was specified before the concept of Structured Data was included in > > syslog-protocol. Using Structured Data would disambiguate the > > intention. > > > > Thanks, > > Chris > > > > > > On Fri, 3 Nov 2006, Sharon Chisholm wrote: > > > >> Hi > >> > >> This is an important section (and no, I'm not just saying that because > > > >> I co-authored RFC 3877). It provides the mapping between severities in > > > >> alarms sent via SNMP and those logged in syslog. Removing it means > >> that implementations will all have different mappings. > >> > >> Sharon > >> > >> -----Original Message----- > >> From: Chris Lonvick [mailto:clonvick@cisco.com] > >> Sent: Friday, November 03, 2006 12:34 PM > >> To: syslog@ietf.org > >> Subject: [Syslog] Alarm MIB in syslog-protocol > >> > >> Hi, > >> > >> In David Harrington's review of syslog-protocol-17 > >> http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html > >> he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877). We > >> discussed this a while ago and it doesn't seem that there is a good > >> fit between the historical syslog severities and the Alarm MIBs. I've > > > >> asked Rainer to remove this. Anyone interested is hereby encouraged > >> to write a document that specifies how to display the Alarm MIBs as > >> Structured Data. > >> > >> Thanks, > >> Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 08 17:56:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhwKf-0004Cb-Jt; Wed, 08 Nov 2006 17:55:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhwKe-0004CV-IN for syslog@ietf.org; Wed, 08 Nov 2006 17:55:44 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhwKc-0007j3-BB for syslog@ietf.org; Wed, 08 Nov 2006 17:55:44 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kA8MtfJW018144; Thu, 9 Nov 2006 07:55:41 +0900 (JST) Received: from [127.0.0.1] (kiras8.priv.cysol.co.jp [192.168.0.158]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kA8MtcsN003625; Thu, 9 Nov 2006 07:55:39 +0900 (JST) Message-ID: <45526069.1060409@cysols.com> Date: Thu, 09 Nov 2006 07:55:37 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Subject: Re: [Syslog] RE: Request for Reviewers - draft-ietf-syslog-device-mib-09.txt References: <7D5D48D2CAA3D84C813F5B154F43B1550AD316A3@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550AD316A3@nl0006exch001u.nl.lucent.com> Content-Type: multipart/mixed; boundary="------------020507020806060900040601" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f671485bda3f2f1be548f998883cfbd 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 This is a multi-part message in MIME format. --------------020507020806060900040601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bert, I have revised and submitted draft-ietf-syslog-device-mib-11.txt. The actions taken for each of the points raised are given in the attached document. Please let me know if any of the points have not been addressed adequately. Cheers Glenn Wijnen, Bert (Bert) wrote: > David Harrington (co-chair of the Syslog WG) specifically asked me > for a review of documents in WG Last Call. > > I am not subscribed to the SYSLOG WG mailing list, so pls copy > me explicitly on any reactions that you want me to see. > > Bert > > ----- draft-ietf-syslog-device-mib-09.txt > > First some SMICng error messages resulting from syntax checking: > > C:\bwijnen\smicng\work>smicng syslog.inc > W: f(syslog.mi2), (47,17) REVISION value "200609R04000Z" is not > a valid extended UTC time > E: f(syslog.mi2), (97,15) Name of "auth" duplicates an existing one > E: f(syslog.mi2), (102,15) Name of "cron" duplicates an existing one > E: f(syslog.mi2), (54,20) Sub-Id for item "syslogMIB" must be > "number" or "name(number)" format > W: f(syslog.mi2), (245,4) Sequence "SyslDevOpsEntry" and Row > "syslEntOpsEntry" should have related names > W: f(syslog.mi2), (418,4) Sequence "SyslDevCtlEntry" and Row > "syslEntCtlEntry" should have related names > E: f(syslog.mi2), (418,4) Row "syslEntCtlEntry" may not have > columns with MAX-ACCESS of read-write if any column is read-create > > *** 4 errors and 3 warnings in parsing > > > I see on page 3, sect 2: > > status or the occurence of events. These messages are handled by what > has come to be known as the syslog application[RFCPROT] or device > [RFC3164]. In this document we refer to a syslog application or > > Mmm RFCPROT and RFC3164 are both a protocol spec, not an "application" > or a "devie", are they? > > I see on page 5: > > The SyslogMIB module uses textual conventions defined in INET- > ADDRESS-MIB[RFC4001], TRANSPORT-ADDRESS-MIB[RFC4001] and SNMP- > FRAMEWORK-MIB[RFC3411]. > > I believe that the TRANSPORT-ADDRESS-MIB is described in RFC3419 > and not in RFC4001. > > Page 6: > > LAST-UPDATED "200511250000Z" -- 25th November, 2005 > > While in the DESCRIPTION clause you have a copyright of 2006!!?? > > Further it is in conflict with the latest revision clause > REVISION "200609R04000Z" -- 9th September, 2006 > AND... that one has an R in there that is not valid either. > > Page 6: > Copyright (C) The Internet Society (2006). The initial > version of this MIB module was published in RFC yyyy; > for full legal notices see the RFC itself. Supplementary > information may be available at: > http://www.ietf.org/copyrights/ianamib.html. > " > -- RFC Ed.: replace XXXX with the actual RFC number & remove this > -- note > > I think the "RFC yyyy" should read "RFC XXXX" in order to bein sync > with the RFCEd. note. > Further, I do NOT think that the copyrights for iana maintained MIB > modules is applicable here. I think you picked up the incorrect > template for MIB copyright. So probably you need to use: > > Copyright (C) The Internet Society (2006). This version of this > MIB module is part of RFC XXXX; see the RFC itself for full > legal notices." > > > The read-write objects under syslogSystem MUST add text to the > DESCRIPTION clauses that state the expected persistency behaviour. > > For > syslogDefaultTransport OBJECT-TYPE > SYNTAX TransportAddressType > I wonder how you represent syslog-transport over tls. > I guess you could use "unknown" but that seems not very satisfactory. > You could use one of the tcp transports I guess, but you would loose > the info about the fact that it is over tls, no? > > Same question of course for syslEntCtlTransport object. > >>From the DESCRIPTION clause of > syslEntOpsTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslDevOpsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table containing information about the syslog entities > serviced by an SNMP agent. > > I cannot see why the "Ops" string is in the name??? > It is OK if that is what the WG wants, but personally, I would > rather name it > syslogEntityTable > which seems a much more meaningfull name. > > For > syslEntCtlTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslDevCtlEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table containing static information about > the syslog entity. > " > ::= { syslogDevice 2 } > > I think that in the description clause I would state that this table > is to have control over the configuration of syslog Entities. > I think I would name it > > syslogEntityCtlTable or syslogEntityControlTable > > > I further note that I find it a naming inconsistency to use "sysl" > as the prefix here instead of "syslog". This happens in the above > 2 tables only. The rest of the MIB module nicely has syslog as > prefix. > > I see: > > syslEntOpsTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslDevOpsEntry > MAX-ACCESS not-accessible > > Normal practice is that the SEQUENCE OF would in tis case be: > syslEntOpsTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslEntOpsEntry > ^^^ > Same story for: > syslEntCtlTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslDevCtlEntry > > > For > syslEntCtlEntry OBJECT-TYPE > SYNTAX SyslDevCtlEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The parameters pertaining to a syslog process." > INDEX { syslEntOpsIndex } > ::= { syslEntCtlTable 1 } > > I wonder if this is a sparse augmentation (it seems so because > otherwise it might have been an AUGMENTs). > I wonder though if this is intentional or accidental. > I personally think I would have made this the base table > and maybe used an AUGMENTS for the read-only (syslEntOpsTable). > > The Counter32 object in the syslEntOpsTable MUST specify if/when > a discontinuity can occur and which timer indicates such discontinuity. > Probably the only discontinuity is when the SNMP agent restarts, > but I am not sure. If so it would be sysUptime that serves as the > discontinuity timer. > > For: > syslEntOpsLastMsgDeliveredTime OBJECT-TYPE > SYNTAX TimeStamp > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The local time when the last message was delivered > by the syslog process. > " > > I would think it is better to say "was relayed or sent"? > Because you do not actually know (in many cases) if the > message indeed does get delivered to the other end, do you? > > For: > syslEntOpsLastError OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A description of the last error that was encountered > by this process. > " > > I am not sure I understand what "this process" is? > Is it the agent (I guess not)? Is it the syslog entity? > Or is it something else? > > For: > syslEntOpsReference OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "If the Host resource MIB is serviced on the host then > this entry will have the value of the hrSWRunIndex > of the corresponding entry in the hrSWRunTable. > Otherwise this object will be inaccessible, > " > > First, I would change "is serviced" into "is instantiated" or "is supportted". > Further I see that hrSWRunIndex is defined as: > hrSWOSIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > So I would expect the SYNTAX for syslEntOpsReference to also be > SYNTAX Integer32 (1..2147483647) > But... The last sentence of the DESCRIPTION clause says: > Otherwise this object will be inaccessible, > (should have a period at the end instead of a comma by theway) > and that is also something that is VERY UNCLEAR. > Maybe a "nosuchInstance" exception would be better. > Maybe the best is to define the object as: > syslEntOpsReference OBJECT-TYPE > SYNTAX Integer32 (0..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "If the Host resource MIB is instantiated on the host then > this entry will have the value of the hrSWRunIndex > of the corresponding entry in the hrSWRunTable. > The special value of zero indicates that the Host resource > MIB is not instantiated. > " > > I see: > syslEntCtlTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslDevCtlEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table containing static information about > the syslog entity. > " > > First I am not sure it is really static, because it allows to change > the values. But in any event, I would describe that this table is > intended to configure syslogEntities. > > For syslEntCtlProcDescr I wonder if this value is/can be used > anywhere else. If yes, pls say something about it. > > For: > syslEntCtlBindAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The specific IP address or hostname the syslog process > will bind to. If a hostname is specified, the IPv4 or > IPv6 address corresponding to the hostname will be used. > " > ::= { syslEntCtlEntry 3 } > > I am not sure what "if a hostname is specified..." means. > If it is a FQDN, then the InetAddressType would be 'dns' > And yoiu MUST specify when that name is resolved into an IP address. > But probably you mean that if it is just some local hostname, that > in that case an IPv4 or IPv6 address shoudl be specified. That is not > 100% clear to me though. So pls clarify. > > You MUST also add some text that states that the format of this address > is controlled by the value of the corresponding syslEntCtlBindAddrType > object. > > For: > syslEntCtlConfFileName OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The fullpath name of the configuration file where the > syslog entity's message selection and corresponding > action rules will be read from. > Data is loaded from this file into the > syslogCtlSelectionTable and the syslogCtlLogActionTable. > If the objects loaded from the file specified by this > object have an access level of read-create, this file MUST > be writable so that modifications to the corresponding > objects, if any, will be effected in this file. > If the system does not support the specification of a > configuration file, this field will not be accessible. > " > DEFVAL { "/etc/syslog.conf" } > ::= { syslEntCtlEntry 7 } > > I wonder where is/are the syslogCtlSelectionTable and the > syslogCtlLogActionTable tables defined? I cannot find them > so I am not sure what this means. > I think that instead of > If the system does not support the specification of a > configuration file, this field will not be accessible. > I would make this object a zero-length string. Much cleaner > and much easier on both agent and NMS. > > For: > syslEntCtlStatus OBJECT-TYPE > SYNTAX INTEGER { > unknown (1), > started (2), > suspended(3), > stopped (4) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The status of the process. > " > DEFVAL { unknown } > > What is "the process" ?? > > I think I would add a DEFVAL for syslEntCtlStorageType > Any value that the WG feels appropriate is fine. > > For syslEntCtlRowStatus > - s/iff/if/ > - I am surprised to see that one needs to go to notInService > state in order to change any column in the row. There are > various that could very well be changed (maybe even all) > while in active state. And such is much easier on both > agent and manager. > > The two NOTIFICATIONs could easily be combined into a > syslogEntitySTatusChanged NOTIFICATION-TYPE > Just a minor optimization I guess > > I would think/hope that there is some relation between theobjects in the > syslogSystemGroup and those in the syslogDevCtlGroup. > For example, if no maxMessage size is specified in syslEntCtlMaxMessageSize, > then the maxmessagesize from syslogDefaultMaxMessageSize is used? > But the DESCRIPTION clauses of the OBJCTS say nothing about this, > so I am not sure how to determine which value to use when? > > I think I would change > syslogCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for SNMP entities > which implement the SYSLOG-MIB. > " > Into something like: > syslogFullCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for SNMP entities which implement > the SYSLOG-MIB with support for writable objects. Such an > implentation can be both monitored and configured via SNMP. > " > > I am not sure I completely understand the intent of > syslogNotificationCompliance. Is it the idea that an implementation > can claim compliance to just send notifications and nothing else? > If so, you may want to make that clear. > > Even then, I think I would include the syslogNotificationGroup in > both the other two MODULE-COMPLIANCE statements, so that if you > support it all, you only have to claim compliance with a single > MODULE-COMPLIANCE statement. > > On page 27 I see: > > Even if the network itself is secure (for example by using IPSec), > > I know that at least one of the SECURITY ADs will want you to > s/IPSec/IPsec/. > The latest MIB security template has the fix already in it. > > I see quite a few places where you use "MIB" while I think what you > mean is the/a "MIB Module". I know this is a nit. Nevertheless, > it seems you need to do a revision to at least fix the syntax errors, > so might as well addres this. > > Bert > > ----------- original review message: >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt >>>> Transmission of syslog messages over UDP >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 >>>> .txt >>>> >>>> TLS Transport Mapping for SYSLOG >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 >>>> .txt >>>> >>>> Syslog Management Information Base >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx >>>> t >>>> >>>> Signed syslog Messages >>>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt >>>> (We expect this document to be updated this week.) >>>> >>>> David Harrington >>>> dharrington@huawei.com >>>> dbharrington@comcast.net >>>> ietfdbh@comcast.net >>>> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog --------------020507020806060900040601 Content-Type: text/plain; name="BertComments-mib09Reply.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="BertComments-mib09Reply.txt" 1. First some SMICng error messages resulting from syntax checking: => => C:\bwijnen\smicng\work>smicng syslog.inc =>1a W: f(syslog.mi2), (47,17) REVISION value "200609R04000Z" is not => a valid extended UTC time =>1b E: f(syslog.mi2), (97,15) Name of "auth" duplicates an existing one =>1c E: f(syslog.mi2), (102,15) Name of "cron" duplicates an existing one =>1d E: f(syslog.mi2), (54,20) Sub-Id for item "syslogMIB" must be => "number" or "name(number)" format =>1e W: f(syslog.mi2), (245,4) Sequence "SyslDevOpsEntry" and Row => "syslEntOpsEntry" should have related names =>1f W: f(syslog.mi2), (418,4) Sequence "SyslDevCtlEntry" and Row => "syslEntCtlEntry" should have related names =>1g E: f(syslog.mi2), (418,4) Row "syslEntCtlEntry" may not have => columns with MAX-ACCESS of read-write if any column is read-create => => *** 4 errors and 3 warnings in parsing => Action. Fixed 1a-1f changed the duplicate instances of auth and cron to auth1, auth2, cron1, cron2 changed: SyslDevOpsEntry -> SyslogEntityOperationsEntry syslEntOpsEntry -> syslogEntityOperationsEntry SyslDevCtlEntry -> SyslogEntityControlEntry syslEntCtlEntry -> syslogEntityControlEntry +------------------------------------------------------------+ 2 I see on page 3, sect 2: => => status or the occurence of events. These messages are handled by what => has come to be known as the syslog application[RFCPROT] or device => [RFC3164]. In this document we refer to a syslog application or => => Mmm RFCPROT and RFC3164 are both a protocol spec, not an "application" => or a "devie", are they? Action. Response: The entity that handles syslog messages is called an "application" in [RFCPROT] and a device in [RFC3164]. That is what the text above intends to say. Looks OK to me. Let me know if you want to change the wordings. +------------------------------------------------------------+ 3 I see on page 5: => => The SyslogMIB module uses textual conventions defined in INET- => ADDRESS-MIB[RFC4001], TRANSPORT-ADDRESS-MIB[RFC4001] and SNMP- => FRAMEWORK-MIB[RFC3411]. => => I believe that the TRANSPORT-ADDRESS-MIB is described in RFC3419 => and not in RFC4001. => Action. Fixed. Added TRANSPORT-ADDRESS-MIB[RFC3419] to the text on section 3 (and 7.1 Normative References). +------------------------------------------------------------+ 4 Page 6: => => LAST-UPDATED "200511250000Z" -- 25th November, 2005 => =>4a While in the DESCRIPTION clause you have a copyright of 2006!!?? => =>4b Further it is in conflict with the latest revision clause => REVISION "200609R04000Z" -- 9th September, 2006 => AND... that one has an R in there that is not valid either. => Action. Fixed 4a-4b. +------------------------------------------------------------+ 5 Page 6: => Copyright (C) The Internet Society (2006). The initial => version of this MIB module was published in RFC yyyy; => for full legal notices see the RFC itself. Supplementary => information may be available at: => http://www.ietf.org/copyrights/ianamib.html. => " => -- RFC Ed.: replace XXXX with the actual RFC number & remove this => -- note => =>5a I think the "RFC yyyy" should read "RFC XXXX" in order to bein sync => with the RFCEd. note. =>5b Further, I do NOT think that the copyrights for iana maintained MIB => modules is applicable here. I think you picked up the incorrect => template for MIB copyright. So probably you need to use: => => Copyright (C) The Internet Society (2006). This version of this => MIB module is part of RFC XXXX; see the RFC itself for full => legal notices." => Action. Fixed 5a-5b. +------------------------------------------------------------+ 6 The read-write objects under syslogSystem MUST add text to the DESCRIPTION clauses that state the expected persistency behaviour. Action. Fixed. Added text "The value of this object SHOULD remain unchanged across reboots of the managed entity." to the DESCRIPTION clauses for all the read-write objects under syslogSystem. +------------------------------------------------------------+ 7 For syslogDefaultTransport OBJECT-TYPE SYNTAX TransportAddressType =>7a => I wonder how you represent syslog-transport over tls. => I guess you could use "unknown" but that seems not very satisfactory. => You could use one of the tcp transports I guess, but you would loose => the info about the fact that it is over tls, no? => =>7b => Same question of course for syslEntCtlTransport object. Action. Fixed 7a, 7b replaced syslogDefaultTransport OBJECT-TYPE SYNTAX TransportAddressType and syslEntCtlTransport OBJECT-TYPE SYNTAX TransportAddressType by syslogDefaultTransportDomain OBJECT-TYPE SYNTAX TransportDomain and syslogEntityControlTransportDomain OBJECT-TYPE SYNTAX TransportDomain +------------------------------------------------------------+ 8 >From the DESCRIPTION clause of => syslEntOpsTable OBJECT-TYPE => SYNTAX SEQUENCE OF SyslDevOpsEntry => MAX-ACCESS not-accessible => STATUS current => DESCRIPTION => "A table containing information about the syslog entities => serviced by an SNMP agent. => => I cannot see why the "Ops" string is in the name??? => It is OK if that is what the WG wants, but personally, I would => rather name it => syslogEntityTable => which seems a much more meaningfull name. Action. Fixed. Changed "Ops" to "Operations". The table name is changed to syslogEntityOperationsTable. There are two tables syslogEntityControlTable and syslogEntityOperationsTable one is for control and the other for operations statistics and information. +------------------------------------------------------------+ =>9 For => syslEntCtlTable OBJECT-TYPE => SYNTAX SEQUENCE OF SyslDevCtlEntry => MAX-ACCESS not-accessible => STATUS current => DESCRIPTION => "A table containing static information about => the syslog entity. => " => ::= { syslogDevice 2 } => =>9a I think that in the description clause I would state that this table => is to have control over the configuration of syslog Entities. => =>9b I think I would name it => => syslogEntityCtlTable or syslogEntityControlTable => => =>9c I further note that I find it a naming inconsistency to use "sysl" => as the prefix here instead of "syslog". This happens in the above => 2 tables only. The rest of the MIB module nicely has syslog as => prefix. => Action. Fixed 9a-9c revised DESCRIPTION of syslogEntityControlTable. changed syslEntCtlTable -> syslogEntityControlTable fixed SyslDevCtlEntry -> SyslogEntityControlEntry +------------------------------------------------------------+ 10 I see: => => syslEntOpsTable OBJECT-TYPE => SYNTAX SEQUENCE OF SyslDevOpsEntry => MAX-ACCESS not-accessible => => Normal practice is that the SEQUENCE OF would in tis case be: => syslEntOpsTable OBJECT-TYPE => SYNTAX SEQUENCE OF SyslEntOpsEntry =>Action. Fixed. => changed: SyslDevOpsEntry -> SyslogEntityOpsEntry => syslEntOpsEntry -> syslogEntityOpsEntry => ^^^ =>11 Same story for: => syslEntCtlTable OBJECT-TYPE => SYNTAX SEQUENCE OF SyslDevCtlEntry Action. Fixed. changed: SyslDevCtlEntry -> SyslogEntityControlEntry syslEntCtlEntry -> syslogEntityControlEntry +------------------------------------------------------------+ 12 For => syslEntCtlEntry OBJECT-TYPE => SYNTAX SyslDevCtlEntry => MAX-ACCESS not-accessible => STATUS current => DESCRIPTION => "The parameters pertaining to a syslog process." => INDEX { syslEntOpsIndex } => ::= { syslEntCtlTable 1 } => =>12a I wonder if this is a sparse augmentation (it seems so because => otherwise it might have been an AUGMENTs). => I wonder though if this is intentional or accidental. => I personally think I would have made this the base table => and maybe used an AUGMENTS for the read-only (syslEntOpsTable). => =>12b The Counter32 object in the syslEntOpsTable MUST specify if/when => a discontinuity can occur and which timer indicates such discontinuity. => Probably the only discontinuity is when the SNMP agent restarts, => but I am not sure. If so it would be sysUptime that serves as the => discontinuity timer. => Action. Fixed 12a, 12b a. syslogEntityOperationsTable AUGMENTS syslogEntityControlTable b. added syslogEntityOperationsCounterDiscontinuityTime object added text to the Counter32 objects about the discontinuities +------------------------------------------------------------+ 13 For: => syslEntOpsLastMsgDeliveredTime OBJECT-TYPE => SYNTAX TimeStamp => MAX-ACCESS read-only => STATUS current => DESCRIPTION => "The local time when the last message was delivered => by the syslog process. => " => => I would think it is better to say "was relayed or sent"? => Because you do not actually know (in many cases) if the => message indeed does get delivered to the other end, do you? Action. Fixed. renamed the object from syslEntOpsLastMsgDeliveredTime to syslogEntityOperationsLastMsgTransmittedTime. revised the DESCRIPTION of the object +------------------------------------------------------------+ 14 For: => syslEntOpsLastError OBJECT-TYPE => SYNTAX SnmpAdminString => MAX-ACCESS read-only => STATUS current => DESCRIPTION => "A description of the last error that was encountered => by this process. => " => => I am not sure I understand what "this process" is? => Is it the agent (I guess not)? Is it the syslog entity? => Or is it something else? => Action. Fixed. Revised the DESCRIPTION. process-> entity +------------------------------------------------------------+ =>15 For: => syslEntOpsReference OBJECT-TYPE => SYNTAX Integer32 => MAX-ACCESS read-only => STATUS current => DESCRIPTION => "If the Host resource MIB is serviced on the host then => this entry will have the value of the hrSWRunIndex => of the corresponding entry in the hrSWRunTable. => Otherwise this object will be inaccessible, => " => =>15a => First, I would change "is serviced" into "is instantiated" or "is supportted". =>15b => Further I see that hrSWRunIndex is defined as: => hrSWOSIndex OBJECT-TYPE => SYNTAX Integer32 (1..2147483647) => So I would expect the SYNTAX for syslEntOpsReference to also be => SYNTAX Integer32 (1..2147483647) => But... The last sentence of the DESCRIPTION clause says: => Otherwise this object will be inaccessible, => (should have a period at the end instead of a comma by theway) => and that is also something that is VERY UNCLEAR. => Maybe a "nosuchInstance" exception would be better. => Maybe the best is to define the object as: => syslEntOpsReference OBJECT-TYPE => SYNTAX Integer32 (0..2147483647) => MAX-ACCESS read-only => STATUS current => DESCRIPTION => "If the Host resource MIB is instantiated on the host then => this entry will have the value of the hrSWRunIndex => of the corresponding entry in the hrSWRunTable. => The special value of zero indicates that the Host resource => MIB is not instantiated. => " Action. Fixed. a. Revised the DESCRIPTION. b. Revised the SYNTAX to Integer32 (0..2147483647) +------------------------------------------------------------+ 16 I see: => syslEntCtlTable OBJECT-TYPE => SYNTAX SEQUENCE OF SyslDevCtlEntry => MAX-ACCESS not-accessible => STATUS current => DESCRIPTION => "A table containing static information about => the syslog entity. => " => =>16a => First I am not sure it is really static, because it allows to change => the values. But in any event, I would describe that this table is => intended to configure syslogEntities. => =>16b => For syslEntCtlProcDescr I wonder if this value is/can be used => anywhere else. If yes, pls say something about it. Action. Fixed. Revised the DESCRIPTION clause +------------------------------------------------------------+ 17 For: => syslEntCtlBindAddr OBJECT-TYPE => SYNTAX InetAddress => MAX-ACCESS read-create => STATUS current => DESCRIPTION => "The specific IP address or hostname the syslog process => will bind to. If a hostname is specified, the IPv4 or => IPv6 address corresponding to the hostname will be used. => " => ::= { syslEntCtlEntry 3 } => =>17a => I am not sure what "if a hostname is specified..." means. => If it is a FQDN, then the InetAddressType would be 'dns' =>17b => And yoiu MUST specify when that name is resolved into an IP address. => But probably you mean that if it is just some local hostname, that => in that case an IPv4 or IPv6 address shoudl be specified. That is not => 100% clear to me though. So pls clarify. => =>17c => You MUST also add some text that states that the format of this address => is controlled by the value of the corresponding syslEntCtlBindAddrType => object. Action. Fixed 17a, 17b, 17c. Revised the DESCRIPTION clause. +------------------------------------------------------------+ 18 For: => syslEntCtlConfFileName OBJECT-TYPE => SYNTAX SnmpAdminString => MAX-ACCESS read-create => STATUS current => DESCRIPTION => "The fullpath name of the configuration file where the => syslog entity's message selection and corresponding => action rules will be read from. => Data is loaded from this file into the => syslogCtlSelectionTable and the syslogCtlLogActionTable. => If the objects loaded from the file specified by this => object have an access level of read-create, this file MUST => be writable so that modifications to the corresponding => objects, if any, will be effected in this file. => If the system does not support the specification of a => configuration file, this field will not be accessible. => " => DEFVAL { "/etc/syslog.conf" } => ::= { syslEntCtlEntry 7 } => =>18a => I wonder where is/are the syslogCtlSelectionTable and the => syslogCtlLogActionTable tables defined? I cannot find them => so I am not sure what this means. =>18b => I think that instead of => If the system does not support the specification of a => configuration file, this field will not be accessible. => I would make this object a zero-length string. Much cleaner => and much easier on both agent and NMS. Action. Fixed 18a, 18b. Revised DESCRIPTION clause. Removed references to syslogCtlSelectionTable and syslogCtlLogActionTable. +------------------------------------------------------------+ 19 => For: => syslEntCtlStatus OBJECT-TYPE => SYNTAX INTEGER { => unknown (1), => started (2), => suspended(3), => stopped (4) => } => MAX-ACCESS read-only => STATUS current => DESCRIPTION => "The status of the process. => " => DEFVAL { unknown } => =>19a => What is "the process" ?? =>19b => I think I would add a DEFVAL for syslEntCtlStorageType => Any value that the WG feels appropriate is fine. => Action. Fixed. a. Changed process -> entity. b. added DEFVAL { nonVolatile } to syslEntCtlStorageType +------------------------------------------------------------+ 20 For syslEntCtlRowStatus =>20a => - s/iff/if/ =>20b => - I am surprised to see that one needs to go to notInService => state in order to change any column in the row. There are => various that could very well be changed (maybe even all) => while in active state. And such is much easier on both => agent and manager. Action. Fixed 20a, 20b. a. changed iff->if. b. added text in the DESCRIPTION about objects that be changed when this object is in state ''active'' or in ''notInService''. +------------------------------------------------------------+ 21 => The two NOTIFICATIONs could easily be combined into a => syslogEntitySTatusChanged NOTIFICATION-TYPE => Just a minor optimization I guess Action. Fixed. +------------------------------------------------------------+ 22 I would think/hope that there is some relation between theobjects in the => syslogSystemGroup and those in the syslogDevCtlGroup. => For example, if no maxMessage size is specified in syslEntCtlMaxMessageSize, => then the maxmessagesize from syslogDefaultMaxMessageSize is used? => But the DESCRIPTION clauses of the OBJCTS say nothing about this, => so I am not sure how to determine which value to use when? Action. Fixed. Revised the DESCRIPTION clauses of the Objects in syslogEntityControlGroup +------------------------------------------------------------+ 23 I think I would change => syslogCompliance MODULE-COMPLIANCE => STATUS current => DESCRIPTION => "The compliance statement for SNMP entities => which implement the SYSLOG-MIB. => " => Into something like: => syslogFullCompliance MODULE-COMPLIANCE => STATUS current => DESCRIPTION => "The compliance statement for SNMP entities which implement => the SYSLOG-MIB with support for writable objects. Such an => implentation can be both monitored and configured via SNMP. => " Action. Fixed. The Compliance section has been revised. +------------------------------------------------------------+ 24 I am not sure I completely understand the intent of => syslogNotificationCompliance. Is it the idea that an implementation => can claim compliance to just send notifications and nothing else? => If so, you may want to make that clear. => => Even then, I think I would include the syslogNotificationGroup in => both the other two MODULE-COMPLIANCE statements, so that if you => support it all, you only have to claim compliance with a single => MODULE-COMPLIANCE statement. Action. Fixed. The Compliance section has been revised. Full compliance can be claimed with syslogFullCompliance1 now. +------------------------------------------------------------+ 25 On page 27 I see: => => Even if the network itself is secure (for example by using IPSec), => => I know that at least one of the SECURITY ADs will want you to => s/IPSec/IPsec/. => The latest MIB security template has the fix already in it. Action. Fixed. +------------------------------------------------------------+ =>26 I see quite a few places where you use "MIB" while I think what you => mean is the/a "MIB Module". I know this is a nit. Nevertheless, => it seems you need to do a revision to at least fix the syntax errors, => so might as well addres this. Action. Fixed. +------------------------------------------------------------+ --------------020507020806060900040601 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 --------------020507020806060900040601-- From syslog-bounces@lists.ietf.org Wed Nov 08 18:00:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhwPJ-0008DT-Tf; Wed, 08 Nov 2006 18:00:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhwPH-0008DM-N8 for syslog@ietf.org; Wed, 08 Nov 2006 18:00:31 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhwPE-0008Q6-1E for syslog@ietf.org; Wed, 08 Nov 2006 18:00:31 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kA8N0QJW018214 for ; Thu, 9 Nov 2006 08:00:26 +0900 (JST) Received: from [127.0.0.1] (kiras8.priv.cysol.co.jp [192.168.0.158]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kA8N0PsN003673 for ; Thu, 9 Nov 2006 08:00:26 +0900 (JST) Message-ID: <45526189.3040202@cysols.com> Date: Thu, 09 Nov 2006 08:00:25 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Mib -10-, part 2 References: <065001c6f959$168c5920$22021eac@china.huawei.com> In-Reply-To: <065001c6f959$168c5920$22021eac@china.huawei.com> Content-Type: multipart/mixed; boundary="------------080207080101070409040506" X-Spam-Score: 0.0 (/) X-Scan-Signature: d9da51c9fdb90403a7d571fc0f0dbf29 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------080207080101070409040506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dave, I have revised and submitted draft-ietf-syslog-device-mib-11.txt. The actions taken for each of the points raised in your mails are given in the attached document. Please let me know if any of the points have not been addressed adequately. Cheers Glenn David Harrington wrote: > Hi Glenn, > > I want to remind you of some outstanding issues to resolve: > >>From tom petch, 8-16: > "I still have trouble with the mib document, not for any mibby reason > but simply > because, as I commented on the previous version, it seems to be > written in a > different language to the other I-D and, insofar as I understand that > language, > seems to be describing a different set of concepts to the other > documents." > > And 9-28: > "I have looked at this I-D and appreciate the increased explanation at > the > beginning. It leaves me clearer, but still thinking that this > document steers a > different course to the other syslog ones, in its focus on a group of > syslog > entities. It's not that there cannot be more than one syslog entity > running in > a given host, just that bundling them together into a table seems an > artificial > complication; other syslog MIB modules I see are scalar in approach." > > I am less concerned about the table of entities versus modeling a > single entity. Having this in a table makes it easier than forcing the > use of contexts to get at multiple instances of the MIB module on a > host, and is consistent with the hrSwRunTable of the Host Resources > MIB. Unless the WG raises objections, I believe the table approach is > acceptable. > > Consistent concepts and terminology is important. WG consensus is that > all the documents should be consistent. The other document editors > aligned their terminology, and you must do so for this document as > well. It is especially important that terminology used in the > management interface be consistent with the technology being managed. > > Please plan on submitting another official revision before Nov 12, > with all outstanding change requests addressed, so we can finish > another 2-week WGLC and still meet our November deadline. If you > question some of the change requests, please consult the chairs and we > will make a determination. > > Thanks, > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog --------------080207080101070409040506 Content-Type: text/plain; name="Dbh-Review-of-mib-09-10--.txtResponse" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Dbh-Review-of-mib-09-10--.txtResponse" The following comments relate to mail with subject [Syslog] Mib-09- review, part 1 +------------------------------------------------------------+ 1) There are multiple pages that exceed the maximum allowed lines per =>page. Action. Fixed +------------------------------------------------------------+ => =>2) The headers and footers do not appear to be standard. There should =>an abbreviated title for easch page after the first. => Action. Fixed +------------------------------------------------------------+ =>3) the terminology is not consistent with the other WG documents. => Action. Response. I think this is fixed. The MIB deals with an syslog entity. The other documents refer to a syslog receiver, relay, collector etc. depending on the context. I do not see any inconsistency or conflict. Please let me know if there are any specific inconsistencies. +------------------------------------------------------------+ => =>4) "roles a syslog entity maybe in" would be better as "roles of a =>syslog entity" (although then entity should be changed according to =>#3. => Action. Fixed. "syslog entity" remains. I do not think that is a problem. Let me know if it is.) +------------------------------------------------------------+ 5) I concur with Bert that the citations in section 2 seem =>inappropriate. => Action. Fixed. +------------------------------------------------------------+ =>6) I find the references to SA-Li, RA-Rj confusing since these are not =>used in the diagram. => Action. Fixed. The labels and caption are changed. +------------------------------------------------------------+ =>7) "The MIB comprises of four groups" would be better as "The MIB =>contains four groups" => Action. Fixed. +------------------------------------------------------------+ 8) Section 3 has a number of lists. You should decide if the list =>should contain sentences, or makes up one complete sentence. If it is =>one sentence, then each listed clause should end with a comma, and be =>consistent in style. If each item is a sentence, then the introductory =>phrase needs to be a sentence. I recommend making each item a =>sentence, so we can eliminate the "which" conrstructs. Action. Fixed. +------------------------------------------------------------+ 9) "asynchronously monitor" s/b "asynchronously report" => Action. Fixed. +------------------------------------------------------------+ 10) the name of SyslogMIB or syslogMIB should be consistent in the =>text. I recommend using SYSLOG-MIB, which is the correct name for the =>MIB module. Action. Fixed. +------------------------------------------------------------+ 11) in SyslogSeverity, I recommend removing the second sentnece in the =>description "The syslog protocol uses the values 0 (emergency) to 7 =>(debug)." since this is already spelled out in the SYNTAX clause, and =>shows that 99 (other) is also used. Why do we need 99? Are other =>values valid? Action. Fixed. If there is consensus in removing 99 (other), I will remove it. +------------------------------------------------------------+ =>12) SyslogService - can we make this just a service name. The port =>semantics are really ambiguous. How do distinguish a UDP port# from a =>TCP port#? Action. Response. We do not distinguish between TCP ports and UDP ports. The syslogEntityControlTransportDomain will tell whether TCP is used or UDP is used. +------------------------------------------------------------+ 13) For consistency with most other MIB modules being developed, I =>suggest defining a top-level breakdown of syslogNotifications (0), =>syslogObjects (1), and syslogConformance (2). Then put syslogSystem =>and syslogDevice under syslogObjects. See RFC4181 appendix D. Action. Fixed. +------------------------------------------------------------+ 14) transportAddressType is designed to be used with specific types of =>transportAddress. The syslogDefaultTransport object should probably be =>syslogDefaultTransportType. A transportAddressType seems inappropriate =>for use with syslogDefaultService, which does not necessarily resolve =>to one of the enumerated options. We should have a =>syslogDefaultTransport that is a transport address. If we want a =>Default service, that should probably be a separate object. => Action. Response. We are now using syslogDefaultTransportDomain. And in the SyslogEntityControlEntry we have syslogEntityControlBindAddrType InetAddressType, syslogEntityControlBindAddr InetAddress, syslogEntityControlTransportDomain TransportDomain, syslogEntityControlService SyslogService, The syslogEntityControlTransportDomain ( by default syslogDefaultTransportDomain) specifes the domain to which the syslogEntityControlBindAddrType,syslogEntityControlBindAddr and syslogEntityControlService apply. +------------------------------------------------------------+ 15) some objects are named xxxSeverity, but the description uses =>priority. We need to be consistent with the other documents about what =>this is called. Action. Fixed. The xxxFacility and xxxSeverity will be used to compute the Severity. The DESCRIPTION clauses are revised to clarify the above. +------------------------------------------------------------+ 16) the syslogDefaultMaxMessageSize description really needs work - =>480 is the minimum maximum size, not the recommended maximum size, so =>it should not be the default. The maximum message size also may depend =>on the transport protocol and the target system, so I'm not sure a =>default is a useful object. Who is the user of this default? The local =>system? If so, then it is an implementation detail and does not need =>to exposed in a mIB object. If it is for use by the remote system, =>then it shouldn't be a default value, but the actual value supported =>by the implementation. Action. Fixed. syslogDefaultMaxMessageSize is deleted. revised the DESCRIPTION of syslogEntityControlMaxMessageSize +------------------------------------------------------------+ 17) syslEntOpsTable uses abbreviated elements in the name. I don't see =>why they need to be abbreviated, or what the name actually means. The =>description does not mention "ops". => Action. Fixed. DESCRIPTION of syslogEntityOperationsTable is revised. +------------------------------------------------------------+ 18) object prefixes should be consistent for the whole module. The =>DefaultXXX uses syslog as the prefix, but here we use sysl. Why? See =>RFC4181 appendix C for naming guidelines. Action. Fixed. The namings have been revised. syslog is used uniformly. +------------------------------------------------------------+ 19) syslEntCtlTable contains static info; does that imply that =>syslEntOpsTable contains dynamci info? Or is syslEntOpsTable about the =>operational environment, and syslEntCtlTable about control info? The =>descritions should kae the purpose of the table unambiguous. Action. Fixed. The DESCRIPTION clauses for the tables have been revised. +------------------------------------------------------------+ =>20) In the SNMPv2 effort, we found that using integer indices made =>using the tabels more difficut for human readers. It would be much =>easier for a human to interpret the statistics here is it is easy to =>tell what the systlog entity is. So I recommend using an =>SnmpAdminString as the index. For systems that cannot, for whatever =>reason, determine a human-readable identifier for the index, the =>SnmpAdminString can always be "1", "2", etc. Action. Response. I agree with you. But I have adopted the simpler approach. Applications will match the indices with the corresponsding syslogEntityControlProcDescr to obtain the user specified description of the entity. That way I can leave the syslogEntityControlProcDescr with the default size restrictions of SnmpAdminString. +------------------------------------------------------------+ 21) what is the persistence of the index? If syslog entities happen to =>start in a different order, will the index# refer to the same entity =>after a reboot? If the MIB says they must be persistent across =>reboots, how difficult will that be for the OS that starts the =>applications? What value will the system keep to match up to the =>integer indicies to make sure they remain the same? Action. Response. The indices are not required to be persistent across system reboots. Users and applications are required to determine the index of each entity after a reboot. +------------------------------------------------------------+ 22) syslEntOpsMsgsDropped counts messages that could not be relayed. =>What about messages that cannot be queued for transmission for an =>original sender? Action. Fixed. The DESCRIPTION clause is revised "The number of messages that could not be queued for transmission by the syslog entity." +------------------------------------------------------------+ =>23) syslEntOpsMsgsIgnored - where are the "allowed specifications" =>defined? We don't want a value that can be interpreted differently by =>different entities, because then the values canot be compared across =>systems, or have consistent baselines for comparison across products, =>etc. Objects shoud be defined to be interoperable and unambiguous. Action. Fixed. The DESCRIPTION clause is revised to "The number of messages that were not processed by the syslog entity because the messages did not meet the allowed specifications. This will include messages that are not accepted as the message size was greater than the systems maximum message size and will exclude messages that are rejected because they are malformed. +------------------------------------------------------------+ 24) syslEntOpsLastMsgDeliveredTime - the system does not know when the =>message was delivered, only when it was transmitted or received. Action. Fixed. The Object name is changed to syslogEntityOperationsLastMsgTransmittedTime and DESCRIPTION has been revised to "The local time when the last message was transmitted by the syslog entity. " +------------------------------------------------------------+ 25) syslEntOpsLastError talks about "this process". Is this the syslog =>entity? This needs to be clear and unambiguous, and consistent with =>the terminology in the other WG documents. Action. Fixed. The description has been revised to "A description of the last error that was encountered by this syslog entity. " +------------------------------------------------------------+ 26) syslEntOpsLastError talks about the last error this process =>"encountered". The definition of encountered needs to be made unclear =>and unambiguous. Action. Response. Can you tell more about the ambiguity. I cannot figure out what needs to be clarified and disambiguated. +------------------------------------------------------------+ 27) what is the persistence of the syslEntOpsReference across reboots =>of the OS? Across reboots of the SNMP system? If it is not persistent, =>but the table is, what should the SNMP agent do - delete the =>references? Change the references to match the new SWRunIndex? Action. Fixed. Revised the DESCRIPTION of syslogEntityOperationsReference to "If the Host resource MIB is instantiated on the host then this entry will have the value of the hrSWRunIndex of the corresponding entry in the hrSWRunTable. Note that the hrSWRunIndex is not persistent across system reboots or software restarts. The value of syslogEntityOperationsReference should reference the latest value of the hrSWRunIndex of the corresponding entry in the hrSWRunTable. The special value of zero indicates that the Host resource MIB is not instantiated. " +------------------------------------------------------------+ The following comments relate to mail with subject [Syslog] Mib-09- review, part 2 [The sequence numbers have been Prefixed by 2.] +------------------------------------------------------------+ 201) syslEntCtlTable should describe what type of information is stored =>in the table, and the description should be more than "static info". Action. Fixed. The DESCRIPTION of syslogEntityControlTable has been revised. +------------------------------------------------------------+ 202) syslEntCtlEnty - what type of parameters? What process? Action. Fixed. The DESCRIPTION of syslogEntityControlEntry is revised. +------------------------------------------------------------+ 203) syslEntCtlBindAddress - does this field contain an address or a =>hostname? What does the seond sentence mean? Action. Fixed. The DESCRIPTION clause for syslogEntityControlBindAddr has been revised. => +------------------------------------------------------------+ 204) syslEntCtlTransport - why is this "default" transport instead of =>just transport? Action. Fixed. The DESCRIPTION of syslogEntityControlTransportDomain has been revised. +------------------------------------------------------------+ 205) is there a mismatch between transportaddresstype and =>syslEntCtlService? Is there a transportAddressType for this type of =>"address"? Action. Response. I did not get the question. +------------------------------------------------------------+ 206) syslEntCtlConfFileName - using lots of abbreviations in the name =>makes it hard for people to remember how the words were abbreviated. =>It would be better to use something like syslogEntCtlFilename. Why do =>we need Ent in the name? we never deal with anything other than =>entities, do we? syslogControlFile would be much easier to remember =>than syslEntCtlConfFileName. Action. Fixed. The object names have been revised. +------------------------------------------------------------+ 207) syslEntCtlConfFileName refers to syslogCtlSelectionTable and =>syslogCtlActionTable - where are these defined? Action. Fixed. The DESCRIPTION of syslogEntityControlConfFileName has been revised. => +------------------------------------------------------------+ 208) syslEntCtlStatus - again, what process? Action. Fixed. Changed process-> entity. => +------------------------------------------------------------+ 209) syslEntCtlStorageType - is this definition exactly the same as the =>StorageType T-C? Action. Response. Does it need to be exactly the same ? Let me know if there is a problem with the definiton. => +------------------------------------------------------------+ 210) ...RowStatus - spelling "iff" Action. Fixed. "iff" is not a spelling mistake. Its usage is intentional. But we can do with a simpler less precise "if". => +------------------------------------------------------------+ 211) syslEntStarted and syslEntStopped - spell out MO. I don't =>understand the second sentence; how does the manager know what =>syslEntOpsIndex is used? Action. Fixed. Changed MO-> Object. The manager will know the syslogEntityOperationsIndex from the instance identifiers in the trap/inform. Did I miss something ? +------------------------------------------------------------+ 212) It would be much better to use consistent naming between the =>objects/tables and the conformance clauses. The table refers to =>syslEnt, but conformance is for syslogDev; the objects are =>syslogDefault but the conformance is syslogSystem. Let'e make it easy =>to work with by being more consistent. => Action. Fixed. The names have been revised. +------------------------------------------------------------+ 213) why are notifications not mandatory for compliance? Action. Fixed. The compliance statements have been revised. +------------------------------------------------------------+ 214) The MIB module exposes some info from syslog, such as last error. =>The security considerations talk about securing snmp, but that does =>not make sense if you do not also secure the syslog transport. The =>security considerations should recommend securing syslog to match the =>snmp security. => Action. Response. I think that would be out of the scope of the MIB document's Security Considerations section. It is something that the Protocol document should deal with. Let me know if I am wrong. +------------------------------------------------------------+ 215) iana considerations talks about a base arc; this would be better =>reworded. Action. Fixed. The text has been revised. +------------------------------------------------------------+ 216) I thik rfc3164 is informative, no tnormative. => Action. Fixed. +------------------------------------------------------------+ 217) I suspect you are not usinng xml2rfc. If not, you need to make =>sure all the boilerplates are up-to-date. Please check the funding =>statement and the intellectual property clauses. => Action. Response. I am relying ID-nits checks. +------------------------------------------------------------+ 218) the change log is most effective if you track the chnages from =>published version to published version, not by MIB revision dates. Action. Noted. +------------------------------------------------------------+ The following comments relate to mail with subject [Syslog] Mib-10- review, part 2 [The sequence numbers have been Prefixed by 3.] +------------------------------------------------------------+ 301) syslEntCtlEntry should be changed to match the other prefixes =>(syslogEntityControlEntry) => Action. Fixed. Names have been revised. +------------------------------------------------------------+ 302) the same for syslEntOpsEntry, syslEntStarted, syslEntStopped, etc. => Action. Fixed. Names have been revised. +------------------------------------------------------------+ 303) I recommend chaging "operations related information" to "operations =>information" => Action. Fixed. +------------------------------------------------------------+ 304) I recommend changing syslogSystemGroup to syslogDefaultGroup if =>that's the prefix you keep on all the "Default" variables. => Action. Fixed. Changed syslogSystemGroup -> syslogDefaultGroup +------------------------------------------------------------+ 305) I recommend changing syslDevOpsGroup to syslogEntityOpsGroup, and =>syslDevCtlGroup to syslogEntityControlGroup. Why do we need two =>groups? Can you implement Ops without the Control table, now that one =>augments the other? => Action. Fixed. The namings for the conformance groups have been revised. +------------------------------------------------------------+ 306) /implememt/implement/ => Action. Fixed. +------------------------------------------------------------+ 307) Is it possible to support notifications only, since the =>notifications contain data from the tables not implemented? Where do =>the values come from? => Action. Response. Yes as far as external appearances are concerned the agent may not show any signs that the objects are implemented. (No Get/Set) But it can still send notifications. +------------------------------------------------------------+ 308) did you run the document through the idnits checker at =>http://tools.ietf.org/tools/idnits/? =>It still reports this problem: => The page length should not exceed 58 lines per page, but there was 38 => longer pages, the longest (page 2) being 60 lines => Action. Fixed. The only thing that idnits complains is about the Security Considerations section. That is very much there. +------------------------------------------------------------+ 309) did you run the MIB module through the smilint utility? =>Instructions can be found at =>http://www.ibr.cs.tu-bs.de/projects/libsmi/mailrobot.html?lang=de => Action. Response. Yes. I am running it through smilint -m -s -e -l 9 -i namelength-32 syslogMIB there are zero errors. +------------------------------------------------------------+ 310) Can you add "Intended status: Standards Track" to the header (see =>syslog-sign for an example). Action.Fixed +------------------------------------------------------------+ The following comments relate to mail with subject [Syslog] Mib-10- , part 2 [The sequence numbers have been Prefixed by 4.] +------------------------------------------------------------+ 401 From tom petch, 8-16: =>"I still have trouble with the mib document, not for any mibby =>reason but simply because, as I commented on the previous version, =>it seems to be written in a different language to the other I-D =>and, insofar as I understand that language, seems to be describing =>a different set of concepts to the other documents." => Action.Response. The terminology has been brought in line. In the MIB document the reference is to a syslog entity. That encompasses a collector, relay and sender +------------------------------------------------------------+ 402 And 9-28: =>"I have looked at this I-D and appreciate the increased explanation => at the beginning. It leaves me clearer, but still thinking that this =>document steers a different course to the other syslog ones, in its =>focus on a group of syslog entities. It's not that there cannot be =>more than one syslog entity running in a given host, just that =>bundling them together into a table seems an artificial =>complication; other syslog MIB modules I see are scalar in approach." Action. Response. In one scenario there may be more than one Syslog daemons running on different ports/network addresses. The MIB will handle this nicely. The grouping is a feature not a necessity. It provides flexibility that is useful in many scenarios. +------------------------------------------------------------+ --------------080207080101070409040506 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 --------------080207080101070409040506-- From syslog-bounces@lists.ietf.org Thu Nov 09 18:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJfZ-0003bx-LY; Thu, 09 Nov 2006 18:50:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJfG-0003N0-6M; Thu, 09 Nov 2006 18:50:34 -0500 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 1GiJfG-0007Zd-3g; Thu, 09 Nov 2006 18:50:34 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GiJfE-0004fF-QL; Thu, 09 Nov 2006 18:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 912192AC73; Thu, 9 Nov 2006 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GiJek-0004Mc-BM; Thu, 09 Nov 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 09 Nov 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-device-mib-11.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Syslog Management Information Base Author(s) : G. Keeni Filename : draft-ietf-syslog-device-mib-11.txt Pages : 44 Date : 2006-11-9 This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-device-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-device-mib-11.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-11-9162729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-device-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-device-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-9162729.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Thu Nov 09 19:28:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKFx-0001Mt-GF; Thu, 09 Nov 2006 19:28:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKFw-0001Mb-1f for syslog@ietf.org; Thu, 09 Nov 2006 19:28:28 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiKFu-0005M0-3u for syslog@ietf.org; Thu, 09 Nov 2006 19:28:28 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kAA0SCJW004418; Fri, 10 Nov 2006 09:28:12 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kAA0S8sN023231; Fri, 10 Nov 2006 09:28:12 +0900 (JST) Message-ID: <4553C798.7080705@cysols.com> Date: Fri, 10 Nov 2006 09:28:08 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: syslog@ietf.org, "Wijnen, Bert (Bert)" Subject: [Fwd: [Syslog] I-D ACTION:draft-ietf-syslog-device-mib-11.txt] Content-Type: multipart/mixed; boundary="------------060303040209080502010808" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------060303040209080502010808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: [Syslog] I-D ACTION:draft-ietf-syslog-device-mib-11.txt Date: Thu, 09 Nov 2006 18:50:02 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: syslog@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Syslog Management Information Base Author(s) : G. Keeni Filename : draft-ietf-syslog-device-mib-11.txt Pages : 44 Date : 2006-11-9 This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-device-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-device-mib-11.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. --------------060303040209080502010808 Content-Type: Message/External-body; name="draft-ietf-syslog-device-mib-11.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-syslog-device-mib-11.txt" Content-Type: text/plain Content-ID: <2006-11-9162729.I-D@ietf.org> --------------060303040209080502010808 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/GLENN/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="file:///C|/DOCUME%7E1/GLENN/LOCALS%7E1/TEMP/nsmail.txt" _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --------------060303040209080502010808 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 --------------060303040209080502010808-- From syslog-bounces@lists.ietf.org Mon Nov 13 12:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfFv-0004Hc-T6; Mon, 13 Nov 2006 12:05:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfFu-0004HQ-Jx for syslog@ietf.org; Mon, 13 Nov 2006 12:05:58 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjfFt-0007gf-5l for syslog@ietf.org; Mon, 13 Nov 2006 12:05:58 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id kADH5iTK006528; Mon, 13 Nov 2006 11:05:50 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Nov 2006 18:05:43 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550AF1D23D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Glenn M. Keeni" , "Wijnen, Bert (Bert)" Subject: RE: [Syslog] RE: Request for Reviewers - draft-ietf-syslog-device -mib-09.txt Date: Mon, 13 Nov 2006 18:05:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d 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 Thanks. I wil re-review. But may take a few weeks. I have quite a few MIB documents in my queue for review. Bert > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Wednesday, November 08, 2006 14:56 > To: Wijnen, Bert (Bert) > Cc: syslog@ietf.org > Subject: Re: [Syslog] RE: Request for Reviewers - > draft-ietf-syslog-device-mib-09.txt > > > Bert, > I have revised and submitted draft-ietf-syslog-device-mib-11.txt. > The actions taken for each of the points raised are given in the > attached document. Please let me know if any of the points have not > been addressed adequately. > Cheers > > Glenn > > Wijnen, Bert (Bert) wrote: > > David Harrington (co-chair of the Syslog WG) specifically asked me > > for a review of documents in WG Last Call. > > > > I am not subscribed to the SYSLOG WG mailing list, so pls copy > > me explicitly on any reactions that you want me to see. > > > > Bert > > > > ----- draft-ietf-syslog-device-mib-09.txt > > > > First some SMICng error messages resulting from syntax checking: > > > > C:\bwijnen\smicng\work>smicng syslog.inc > > W: f(syslog.mi2), (47,17) REVISION value "200609R04000Z" is not > > a valid extended UTC time > > E: f(syslog.mi2), (97,15) Name of "auth" duplicates an > existing one > > E: f(syslog.mi2), (102,15) Name of "cron" duplicates an > existing one > > E: f(syslog.mi2), (54,20) Sub-Id for item "syslogMIB" must be > > "number" or "name(number)" format > > W: f(syslog.mi2), (245,4) Sequence "SyslDevOpsEntry" and Row > > "syslEntOpsEntry" should have related names > > W: f(syslog.mi2), (418,4) Sequence "SyslDevCtlEntry" and Row > > "syslEntCtlEntry" should have related names > > E: f(syslog.mi2), (418,4) Row "syslEntCtlEntry" may not have > > columns with MAX-ACCESS of read-write if any column is > read-create > > > > *** 4 errors and 3 warnings in parsing > > > > > > I see on page 3, sect 2: > > > > status or the occurence of events. These messages are > handled by what > > has come to be known as the syslog application[RFCPROT] or device > > [RFC3164]. In this document we refer to a syslog application or > > > > Mmm RFCPROT and RFC3164 are both a protocol spec, not an > "application" > > or a "devie", are they? > > > > I see on page 5: > > > > The SyslogMIB module uses textual conventions defined in INET- > > ADDRESS-MIB[RFC4001], TRANSPORT-ADDRESS-MIB[RFC4001] and SNMP- > > FRAMEWORK-MIB[RFC3411]. > > > > I believe that the TRANSPORT-ADDRESS-MIB is described in RFC3419 > > and not in RFC4001. > > > > Page 6: > > > > LAST-UPDATED "200511250000Z" -- 25th November, 2005 > > > > While in the DESCRIPTION clause you have a copyright of 2006!!?? > > > > Further it is in conflict with the latest revision clause > > REVISION "200609R04000Z" -- 9th September, 2006 > > AND... that one has an R in there that is not valid either. > > > > Page 6: > > Copyright (C) The Internet Society (2006). The initial > > version of this MIB module was published in RFC yyyy; > > for full legal notices see the RFC itself. Supplementary > > information may be available at: > > http://www.ietf.org/copyrights/ianamib.html. > > " > > -- RFC Ed.: replace XXXX with the actual RFC number & > remove this > > -- note > > > > I think the "RFC yyyy" should read "RFC XXXX" in order to bein sync > > with the RFCEd. note. > > Further, I do NOT think that the copyrights for iana maintained MIB > > modules is applicable here. I think you picked up the incorrect > > template for MIB copyright. So probably you need to use: > > > > Copyright (C) The Internet Society (2006). This > version of this > > MIB module is part of RFC XXXX; see the RFC itself for full > > legal notices." > > > > > > The read-write objects under syslogSystem MUST add text to the > > DESCRIPTION clauses that state the expected persistency behaviour. > > > > For > > syslogDefaultTransport OBJECT-TYPE > > SYNTAX TransportAddressType > > I wonder how you represent syslog-transport over tls. > > I guess you could use "unknown" but that seems not very > satisfactory. > > You could use one of the tcp transports I guess, but you would loose > > the info about the fact that it is over tls, no? > > > > Same question of course for syslEntCtlTransport object. > > > >>From the DESCRIPTION clause of > > syslEntOpsTable OBJECT-TYPE > > SYNTAX SEQUENCE OF SyslDevOpsEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A table containing information about the syslog entities > > serviced by an SNMP agent. > > > > I cannot see why the "Ops" string is in the name??? > > It is OK if that is what the WG wants, but personally, I would > > rather name it > > syslogEntityTable > > which seems a much more meaningfull name. > > > > For > > syslEntCtlTable OBJECT-TYPE > > SYNTAX SEQUENCE OF SyslDevCtlEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A table containing static information about > > the syslog entity. > > " > > ::= { syslogDevice 2 } > > > > I think that in the description clause I would state that this table > > is to have control over the configuration of syslog Entities. > > I think I would name it > > > > syslogEntityCtlTable or syslogEntityControlTable > > > > > > I further note that I find it a naming inconsistency to use "sysl" > > as the prefix here instead of "syslog". This happens in the above > > 2 tables only. The rest of the MIB module nicely has syslog as > > prefix. > > > > I see: > > > > syslEntOpsTable OBJECT-TYPE > > SYNTAX SEQUENCE OF SyslDevOpsEntry > > MAX-ACCESS not-accessible > > > > Normal practice is that the SEQUENCE OF would in tis case be: > > syslEntOpsTable OBJECT-TYPE > > SYNTAX SEQUENCE OF SyslEntOpsEntry > > ^^^ > > Same story for: > > syslEntCtlTable OBJECT-TYPE > > SYNTAX SEQUENCE OF SyslDevCtlEntry > > > > > > For > > syslEntCtlEntry OBJECT-TYPE > > SYNTAX SyslDevCtlEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The parameters pertaining to a syslog process." > > INDEX { syslEntOpsIndex } > > ::= { syslEntCtlTable 1 } > > > > I wonder if this is a sparse augmentation (it seems so because > > otherwise it might have been an AUGMENTs). > > I wonder though if this is intentional or accidental. > > I personally think I would have made this the base table > > and maybe used an AUGMENTS for the read-only (syslEntOpsTable). > > > > The Counter32 object in the syslEntOpsTable MUST specify if/when > > a discontinuity can occur and which timer indicates such > discontinuity. > > Probably the only discontinuity is when the SNMP agent restarts, > > but I am not sure. If so it would be sysUptime that serves as the > > discontinuity timer. > > > > For: > > syslEntOpsLastMsgDeliveredTime OBJECT-TYPE > > SYNTAX TimeStamp > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The local time when the last message was delivered > > by the syslog process. > > " > > > > I would think it is better to say "was relayed or sent"? > > Because you do not actually know (in many cases) if the > > message indeed does get delivered to the other end, do you? > > > > For: > > syslEntOpsLastError OBJECT-TYPE > > SYNTAX SnmpAdminString > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "A description of the last error that was encountered > > by this process. > > " > > > > I am not sure I understand what "this process" is? > > Is it the agent (I guess not)? Is it the syslog entity? > > Or is it something else? > > > > For: > > syslEntOpsReference OBJECT-TYPE > > SYNTAX Integer32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "If the Host resource MIB is serviced on the host then > > this entry will have the value of the hrSWRunIndex > > of the corresponding entry in the hrSWRunTable. > > Otherwise this object will be inaccessible, > > " > > > > First, I would change "is serviced" into "is instantiated" > or "is supportted". > > Further I see that hrSWRunIndex is defined as: > > hrSWOSIndex OBJECT-TYPE > > SYNTAX Integer32 (1..2147483647) > > So I would expect the SYNTAX for syslEntOpsReference to also be > > SYNTAX Integer32 (1..2147483647) > > But... The last sentence of the DESCRIPTION clause says: > > Otherwise this object will be inaccessible, > > (should have a period at the end instead of a comma by theway) > > and that is also something that is VERY UNCLEAR. > > Maybe a "nosuchInstance" exception would be better. > > Maybe the best is to define the object as: > > syslEntOpsReference OBJECT-TYPE > > SYNTAX Integer32 (0..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "If the Host resource MIB is instantiated on the > host then > > this entry will have the value of the hrSWRunIndex > > of the corresponding entry in the hrSWRunTable. > > The special value of zero indicates that the > Host resource > > MIB is not instantiated. > > " > > > > I see: > > syslEntCtlTable OBJECT-TYPE > > SYNTAX SEQUENCE OF SyslDevCtlEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A table containing static information about > > the syslog entity. > > " > > > > First I am not sure it is really static, because it allows to change > > the values. But in any event, I would describe that this table is > > intended to configure syslogEntities. > > > > For syslEntCtlProcDescr I wonder if this value is/can be used > > anywhere else. If yes, pls say something about it. > > > > For: > > syslEntCtlBindAddr OBJECT-TYPE > > SYNTAX InetAddress > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The specific IP address or hostname the syslog process > > will bind to. If a hostname is specified, the IPv4 or > > IPv6 address corresponding to the hostname will be used. > > " > > ::= { syslEntCtlEntry 3 } > > > > I am not sure what "if a hostname is specified..." means. > > If it is a FQDN, then the InetAddressType would be 'dns' > > And yoiu MUST specify when that name is resolved into an IP address. > > But probably you mean that if it is just some local hostname, that > > in that case an IPv4 or IPv6 address shoudl be specified. > That is not > > 100% clear to me though. So pls clarify. > > > > You MUST also add some text that states that the format of > this address > > is controlled by the value of the corresponding > syslEntCtlBindAddrType > > object. > > > > For: > > syslEntCtlConfFileName OBJECT-TYPE > > SYNTAX SnmpAdminString > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The fullpath name of the configuration file where the > > syslog entity's message selection and corresponding > > action rules will be read from. > > Data is loaded from this file into the > > syslogCtlSelectionTable and the syslogCtlLogActionTable. > > If the objects loaded from the file specified by this > > object have an access level of read-create, this file MUST > > be writable so that modifications to the corresponding > > objects, if any, will be effected in this file. > > If the system does not support the specification of a > > configuration file, this field will not be accessible. > > " > > DEFVAL { "/etc/syslog.conf" } > > ::= { syslEntCtlEntry 7 } > > > > I wonder where is/are the syslogCtlSelectionTable and the > > syslogCtlLogActionTable tables defined? I cannot find them > > so I am not sure what this means. > > I think that instead of > > If the system does not support the specification of a > > configuration file, this field will not be accessible. > > I would make this object a zero-length string. Much cleaner > > and much easier on both agent and NMS. > > > > For: > > syslEntCtlStatus OBJECT-TYPE > > SYNTAX INTEGER { > > unknown (1), > > started (2), > > suspended(3), > > stopped (4) > > } > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The status of the process. > > " > > DEFVAL { unknown } > > > > What is "the process" ?? > > > > I think I would add a DEFVAL for syslEntCtlStorageType > > Any value that the WG feels appropriate is fine. > > > > For syslEntCtlRowStatus > > - s/iff/if/ > > - I am surprised to see that one needs to go to notInService > > state in order to change any column in the row. There are > > various that could very well be changed (maybe even all) > > while in active state. And such is much easier on both > > agent and manager. > > > > The two NOTIFICATIONs could easily be combined into a > > syslogEntitySTatusChanged NOTIFICATION-TYPE > > Just a minor optimization I guess > > > > I would think/hope that there is some relation between > theobjects in the > > syslogSystemGroup and those in the syslogDevCtlGroup. > > For example, if no maxMessage size is specified in > syslEntCtlMaxMessageSize, > > then the maxmessagesize from syslogDefaultMaxMessageSize is used? > > But the DESCRIPTION clauses of the OBJCTS say nothing about this, > > so I am not sure how to determine which value to use when? > > > > I think I would change > > syslogCompliance MODULE-COMPLIANCE > > STATUS current > > DESCRIPTION > > "The compliance statement for SNMP entities > > which implement the SYSLOG-MIB. > > " > > Into something like: > > syslogFullCompliance MODULE-COMPLIANCE > > STATUS current > > DESCRIPTION > > "The compliance statement for SNMP entities > which implement > > the SYSLOG-MIB with support for writable > objects. Such an > > implentation can be both monitored and > configured via SNMP. > > " > > > > I am not sure I completely understand the intent of > > syslogNotificationCompliance. Is it the idea that an implementation > > can claim compliance to just send notifications and nothing else? > > If so, you may want to make that clear. > > > > Even then, I think I would include the syslogNotificationGroup in > > both the other two MODULE-COMPLIANCE statements, so that if you > > support it all, you only have to claim compliance with a single > > MODULE-COMPLIANCE statement. > > > > On page 27 I see: > > > > Even if the network itself is secure (for example by > using IPSec), > > > > I know that at least one of the SECURITY ADs will want you to > > s/IPSec/IPsec/. > > The latest MIB security template has the fix already in it. > > > > I see quite a few places where you use "MIB" while I think what you > > mean is the/a "MIB Module". I know this is a nit. Nevertheless, > > it seems you need to do a revision to at least fix the > syntax errors, > > so might as well addres this. > > > > Bert > > > > ----------- original review message: > >> > http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt > >>>> Transmission of syslog messages over UDP > >>>> > >> > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 > >>>> .txt > >>>> > >>>> TLS Transport Mapping for SYSLOG > >>>> > >> > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 > >>>> .txt > >>>> > >>>> Syslog Management Information Base > >>>> > >> > http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx > >>>> t > >>>> > >>>> Signed syslog Messages > >>>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt > >>>> (We expect this document to be updated this week.) > >>>> > >>>> David Harrington > >>>> dharrington@huawei.com > >>>> dbharrington@comcast.net > >>>> ietfdbh@comcast.net > >>>> > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 14 13:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2hH-000061-02; Tue, 14 Nov 2006 13:07:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2hF-00005o-7X for syslog@ietf.org; Tue, 14 Nov 2006 13:07:45 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk2hC-0002Kf-VV for syslog@ietf.org; Tue, 14 Nov 2006 13:07:45 -0500 Received: from harrington73653 (c-24-128-66-115.hsd1.nh.comcast.net[24.128.66.115]) by comcast.net (sccrmhc11) with SMTP id <2006111418074201100rkf9re>; Tue, 14 Nov 2006 18:07:42 +0000 From: "David B Harrington" To: Date: Tue, 14 Nov 2006 13:04:57 -0500 Message-ID: <0bbe01c70817$6b1c8650$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccICFttH594vUF7RhyYbk3lama8vAADj4Sg X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Syslog] syslog-tls version number X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Tuesday, November 14, 2006 11:17 AM > > After taking another look at the syslog over TLS mapping, I am > > wondering why you have a version number in the transport mapping at > > all. Do you really think there will be different versions of syslog > > message encapsulation over TLS? > > http://www1.ietf.org/mail-archive/web/syslog/current/msg01194.html : > > > One "major" change to the document is a "version" field for > > Syslog TLS > > > transport is added to the frame header. The field is to > > make port reusing > > > possible if the transport mapping document is updated in > > the future. An IANA > > > paragraph is added accordingly. To me, this looks like over engineering. You have a length field followed by a space followed by the syslog message - there is not much to get wrong here. And if it proves to be wrong, we loose a port number. I find it kind of unusual to version transport mappings - we usually simply accept the risk that if the mapping is broken, we may loose a port number. NETCONF over SSH does not have a version number. SNMP over SSH does not have a version number. Whatever we do, we should be consistent or have a strong reason for not being consistent. /js -- Juergen Schoenwaelder International University Bremen (Jacobs University Bremen as of Spring 2007) P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 15 11:55:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkO1S-0002rC-1i; Wed, 15 Nov 2006 11:54:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkO1R-0002pN-56 for syslog@ietf.org; Wed, 15 Nov 2006 11:54:01 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkO1P-0008EK-RT for syslog@ietf.org; Wed, 15 Nov 2006 11:54:01 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6728B5919E for ; Wed, 15 Nov 2006 17:53:59 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08449-01; Wed, 15 Nov 2006 17:53:56 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 3CE495ACE4; Wed, 15 Nov 2006 17:53:56 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id D0CA88C8634; Wed, 15 Nov 2006 17:53:53 +0100 (CET) Date: Wed, 15 Nov 2006 17:53:53 +0100 From: Juergen Schoenwaelder To: syslog@ietf.org Message-ID: <20061115165353.GA2081@boskop.local> Mail-Followup-To: syslog@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Syslog] minor comments on draft-ietf-syslog-protocol-17.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I have just read draft-ietf-syslog-protocol-17.txt and I found some minor issues and I thought I let you know about them. a) The text describing example 1 in section 6.5 seems to be contradictionary: [...] The encoding is defined by the BOM, and also advertised in STRUCTURED-DATA. There is no STRUCTURED-DATA present in the message, this is indicated by "-" in the STRUCTURED- DATA field. I think the second sentence should be removed (but read on). b) The text describing example 2 in section 6.5. seems to have no STRUCTURED-DATA but this is not explained. I assume that the sentence from a) should actually belongs to example 2. c) I am puzzled why the "enc" parameter is useful. Why does it make sense to repeat the primary indicator (BOM)? I think a justification is needed or the "enc" parameter should be dropped. /js PS: I am new to this list so please forgive my ignorance if I happen to make "stupid" comments. -- Juergen Schoenwaelder International University Bremen (Jacobs University Bremen as of Spring 2007) P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 15 12:00:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkO7X-0005vP-PS; Wed, 15 Nov 2006 12:00:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkO7V-0005uK-G4 for syslog@ietf.org; Wed, 15 Nov 2006 12:00:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkO7U-0000be-5H for syslog@ietf.org; Wed, 15 Nov 2006 12:00:17 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2006 09:00:14 -0800 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 kAFH0Fpc015182; Wed, 15 Nov 2006 09:00:15 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAFH0FdF008674; Wed, 15 Nov 2006 09:00:15 -0800 (PST) Date: Wed, 15 Nov 2006 09:00:14 -0800 (PST) From: Chris Lonvick To: Juergen Schoenwaelder Subject: about enc - was: Re: [Syslog] minor comments on draft-ietf-syslog-protocol-17.txt In-Reply-To: <20061115165353.GA2081@boskop.local> Message-ID: References: <20061115165353.GA2081@boskop.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1523; t=1163610015; x=1164474015; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20about=20enc=20-=20was=3A=20Re=3A=20[Syslog]=20minor=20comment s=20on=20draft-ietf-syslog-protocol-17.txt |Sender:=20; bh=c9THSk5AJar6V1+Ak27PMztb+aSWPdn9oN5i1FCXPpY=; b=bDRu5/ugMveNZ8gQ3fT4EhYT2/MltlMZ8quoF7PBhyezLAhs+gJqkSlFPx/+YShfpbdjV4g5 tjAs2uW+WEmngnCrz8oIsvfNP4CVhjgZQAOTqBzMHJXrxqVWtLMRngEa; Authentication-Results: sj-dkim-6; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Juergen, enc has been dropped from syslog-protocol. Thanks, Chris On Wed, 15 Nov 2006, Juergen Schoenwaelder wrote: > Hi, > > I have just read draft-ietf-syslog-protocol-17.txt and I found some > minor issues and I thought I let you know about them. > > a) The text describing example 1 in section 6.5 seems to be > contradictionary: > > [...] The encoding is defined by the BOM, > and also advertised in STRUCTURED-DATA. There is no STRUCTURED-DATA > present in the message, this is indicated by "-" in the STRUCTURED- > DATA field. > > I think the second sentence should be removed (but read on). > > b) The text describing example 2 in section 6.5. seems to have no > STRUCTURED-DATA but this is not explained. I assume that the > sentence from a) should actually belongs to example 2. > > c) I am puzzled why the "enc" parameter is useful. Why does it make > sense to repeat the primary indicator (BOM)? I think a > justification is needed or the "enc" parameter should be dropped. > > /js > > PS: I am new to this list so please forgive my ignorance if I happen > to make "stupid" comments. > > -- > Juergen Schoenwaelder International University Bremen > (Jacobs University Bremen as of Spring 2007) > P.O. Box 750 561, 28725 Bremen, Germany > > _______________________________________________ > 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 Nov 15 12:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkOCB-0007Y2-Sk; Wed, 15 Nov 2006 12:05:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkOCB-0007Xx-25 for syslog@ietf.org; Wed, 15 Nov 2006 12:05:07 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkOC9-0001Ck-HU for syslog@ietf.org; Wed, 15 Nov 2006 12:05:07 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id B345227C00A; Wed, 15 Nov 2006 18:09:22 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27579-10; Wed, 15 Nov 2006 18:09:22 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 7614F27C008; Wed, 15 Nov 2006 18:09:22 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 18:04:52 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] minor comments on draft-ietf-syslog-protocol-17.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Nov 2006 18:04:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F857D@grfint2.intern.adiscon.com> In-Reply-To: <20061115165353.GA2081@boskop.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] minor comments on draft-ietf-syslog-protocol-17.txt Thread-Index: AccI1xxhEhovBehWQQWgvVG7k52+VQAANbnQ From: "Rainer Gerhards" To: , X-OriginalArrivalTime: 15 Nov 2006 17:04:52.0077 (UTC) FILETIME=[2A6811D0:01C708D8] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Juergen,=20 I am close to publishing the -18 version, you made it right in time.=20 a) and c) have been resolve by dropping "enc" as chris said. I have added an additional sentence on the non-presence of STRUCTURED-DATA to care for b). Thanks for your comments! Rainer > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Wednesday, November 15, 2006 5:54 PM > To: syslog@ietf.org > Subject: [Syslog] minor comments on draft-ietf-syslog-protocol-17.txt >=20 > Hi, >=20 > I have just read draft-ietf-syslog-protocol-17.txt and I found some > minor issues and I thought I let you know about them. >=20 > a) The text describing example 1 in section 6.5 seems to be > contradictionary: >=20 > [...] The encoding is defined by the BOM, > and also advertised in STRUCTURED-DATA. There is no=20 > STRUCTURED-DATA > present in the message, this is indicated by "-" in the=20 > STRUCTURED- > DATA field. >=20 > I think the second sentence should be removed (but read on). >=20 > b) The text describing example 2 in section 6.5. seems to have no > STRUCTURED-DATA but this is not explained. I assume that the > sentence from a) should actually belongs to example 2. >=20 > c) I am puzzled why the "enc" parameter is useful. Why does it make > sense to repeat the primary indicator (BOM)? I think a > justification is needed or the "enc" parameter should be dropped. >=20 > /js >=20 > PS: I am new to this list so please forgive my ignorance if I happen > to make "stupid" comments. >=20 > --=20 > Juergen Schoenwaelder International University Bremen > (Jacobs University Bremen as=20 > of Spring 2007) > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=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 Nov 21 13:13:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gma5Q-0006Xe-QX; Tue, 21 Nov 2006 13:11:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gma5P-0006XZ-Ju for syslog@ietf.org; Tue, 21 Nov 2006 13:11:11 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gma5O-0007IS-A0 for syslog@ietf.org; Tue, 21 Nov 2006 13:11:11 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2006 10:11:09 -0800 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 kALIB9tk017221 for ; Tue, 21 Nov 2006 10:11:09 -0800 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 kALIB8io003628 for ; Tue, 21 Nov 2006 10:11:09 -0800 (PST) Date: Tue, 21 Nov 2006 10:11:08 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=737; t=1164132669; x=1164996669; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20ITU=20alarm=20levels=20in=20draft-ietf-syslog-protocol=20ID |Sender:=20; bh=chhUcAf6bugVZxtg0AxYyHClqmAXRcKyAD8KTvzJMBY=; b=dcu1sPApp5yGcgYRwvBiUPtU+0UdTUTkSszmqzK2D2HxOdi9YfoOmN+T5uXlIBqIdtNq14Cv uGB6uWwa7MDv15SmEF6CRo+IaTHv3AmZqj3/pqwEcYCs5qvWIGMaaQPD; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Syslog] ITU alarm levels in draft-ietf-syslog-protocol ID X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, David and I had a talk about this. I still feel that the ITU Alarm state is underspecified in draft-ietf-syslog-protocol since we do have a mechanism to fully specify it. I'm willing to allow that the current Section 6.1.1 be moved to the Apendix of draft-ietf-syslog-protocol if we can find someone to write a document that specifies a full mapping of the the ITU alarms as SD Params. We could place a non-normative reference in draft-ietf-syslog-protocol to say that current work is being undertaken to fully specify this in a complete mapping. David and I will review this with our ADs to see if it should become a WG document. Can we get someone to write this document? Thanks, Chris & David _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 21 18:45:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmfHY-0004kE-Vl; Tue, 21 Nov 2006 18:44:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmfHX-0004ip-1C for syslog@ietf.org; Tue, 21 Nov 2006 18:44:03 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmfHU-0006Yx-LZ for syslog@ietf.org; Tue, 21 Nov 2006 18:44:03 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2006112123440001500pr6ume>; Tue, 21 Nov 2006 23:44:00 +0000 From: "David Harrington" To: Date: Tue, 21 Nov 2006 18:41:08 -0500 Message-ID: <126c01c70dc6$84f84fa0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_126D_01C70D9C.9C2247A0" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccNxikySfyauRdWTgeqq4EjcWrEQg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: Subject: [Syslog] Shepherding document for udp-08 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_126D_01C70D9C.9C2247A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have reviewed a pre-publication copy of -08- and am satisifed it represents WG consensus and is of a quality sufficient for advancement to Proposed Standard. Barring serious objection from the WG, revision -08- will be submitted to the IESG for advancement, accompanied by the attached shepherding document. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG ------=_NextPart_000_126D_01C70D9C.9C2247A0 Content-Type: text/plain; name="shepherding document for syslog-transport-udp.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="shepherding document for syslog-transport-udp.txt" Shepherding document for syslog-transport-udp-08 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? David Harrington I believe that this version is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by the Working Group and by people = outside of the Working Group. There are no concerns about the reviews. The=20 recent reviews may be found in the mailing list archive: http://www1.ietf.org/mail-archive/web/syslog/current/msg01242.html http://www1.ietf.org/mail-archive/web/syslog/current/msg01246.html In particular, since UDP lacks congestion control, we consulted TSVWG, = and have followed the recommendations concerning provisioning to account = for the syslog traffic. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML No. We have sought reviews from a number of experts and are satisfied = this document has received adequate expert review. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, = or has concerns whether there really is a need for it. In any event, if those issues have been discussed in the WG and the WG has indicated that it still wishes to advance the = document, detail those concerns here. There are no specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The Working Group as a whole understands the document and supports it moving forward. UDP is widely supported as a transport for syslog. (1.f) Has anyone threatened an appeal or otherwise indicated = extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. = (It should be in a separate email because this questionnaire will be entered into the ID Tracker.) No appeals have been threatened. (1.g) Has the Document Shepherd verified that the document = satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Yes. The document was generated using xml2rfc, has passed automated = checking using idnits 1.118 , and passed a manual check of idnits by the = shepherd. (1.h) Has the document split its references into normative and informative? Are there normative references to documents = that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative = references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split and all referenced documents are RFCs in good standing. This document is co-dependent upon draft-ietf-syslog-protocol. These = documents are being submitted together. (1.i) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport protocol. Working Group Summary Was there anything in WG process that is worth noting? = For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document has been ready for a very long time. The holdup has been that the Working Group decided to revise draft-ietf-syslog-protocol. = This action has been completed. Document Quality Are there existing implementations of the protocol? Have = a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? This document describes the traditional udp transport for syslog. draft-ietf-syslog-protocol makes changes to the syntax of the syslog fields but this is just the udp transport. It could be said that all existing implementations of syslog use this specification. =3D=3D=3D ------=_NextPart_000_126D_01C70D9C.9C2247A0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ------=_NextPart_000_126D_01C70D9C.9C2247A0-- From syslog-bounces@lists.ietf.org Tue Nov 21 19:29:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmfzA-0006gB-3u; Tue, 21 Nov 2006 19:29:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmfz8-0006e2-Ua for syslog@ietf.org; Tue, 21 Nov 2006 19:29:06 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmfz7-0003Sg-Ku for syslog@ietf.org; Tue, 21 Nov 2006 19:29:06 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 21 Nov 2006 16:29:05 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAM0T4Rp013903; Tue, 21 Nov 2006 19:29:04 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAM0T4DM011556; Tue, 21 Nov 2006 19:29:04 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 19:29:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Shepherding document for udp-08 Date: Tue, 21 Nov 2006 19:29:25 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122023A1264@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Shepherding document for udp-08 Thread-Index: AccNxikySfyauRdWTgeqq4EjcWrEQgABtSVQ From: "Anton Okmianski \(aokmians\)" To: "David Harrington" , X-OriginalArrivalTime: 22 Nov 2006 00:29:04.0176 (UTC) FILETIME=[36C62300:01C70DCD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1645; t=1164155344; x=1165019344; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=20=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:=20RE=3A=20[Syslog]=20Shepherding=20document=20for=20udp-08 |Sender:=20 |To:=20=22David=20Harrington=22=20, =20; bh=qFVD5BV9bOhgkOT9UCGaEFZy+f/wL7fKaegq5K1Zfb8=; b=EdOu7XJjTckBV3jd6ZsXnFkc2VtW9cbjkAiBYa+/MugabYX+8KrZI5G/WIn1NWuK4d4z3QZ5 8tyXSJLDgk5HSv3TBAK2sYJSFHXpfOonQAUTXom/nEL8XxuxnhWSwb0Z; Authentication-Results: rtp-dkim-1; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 FYI for the group...=20 I submitted revision 08 to IETF editor and you should get an official email soon. =20 Three changes in this draft: =20 1. Marked draft as Standards Track. =20 =20 2. Per IESG review comments, added the following paragraph to the Congestion Control section: =20 "If the potentially unrestricted use of syslog data being transferred over UDP in a particular deployment can saturate the link, then the network path should be provisioned so the offered load (including syslog packets) does not exceed the path capacity. Otherwise, some of the syslog packets could be lost, or cause the loss of other UDP packets." =20 3. Per comment from Rich Graveman, added this to the section on Sequenced Delivery: =20 "If present, Structured Data element 'sequenceId' contained within syslog messages MAY help in establishing the sequence of messages from a single sender." =20 Thanks, Anton.=20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Tuesday, November 21, 2006 6:41 PM > To: syslog@ietf.org > Subject: [Syslog] Shepherding document for udp-08 >=20 > Hi, >=20 > I have reviewed a pre-publication copy of -08- and am=20 > satisifed it represents WG consensus and is of a quality=20 > sufficient for advancement to Proposed Standard. >=20 > Barring serious objection from the WG, revision -08- will be=20 > submitted to the IESG for advancement, accompanied by the=20 > attached shepherding document. >=20 > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 21 20:15:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmghM-0000j5-6h; Tue, 21 Nov 2006 20:14:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmghL-0000iH-1F for syslog@ietf.org; Tue, 21 Nov 2006 20:14:47 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmgh6-0002uo-9Z for syslog@ietf.org; Tue, 21 Nov 2006 20:14:46 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J930054SY1DZ8@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 22 Nov 2006 09:12:49 +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 <0J9300EGJY1AP4@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 22 Nov 2006 09:12:49 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J93000L7Y12I6@szxml03-in.huawei.com> for syslog@ietf.org; Wed, 22 Nov 2006 09:12:46 +0800 (CST) Date: Wed, 22 Nov 2006 09:12:38 +0800 From: Miao Fuyou To: syslog@ietf.org Message-id: <00d601c70dd3$4fd46a90$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_382YWTKKSFtxSs3EHTp9sg)" Thread-index: AccN00y0qV2GLbfNQWeHwgDicYI+RA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f9c0d585568a86447c98453afdf94aa0 Cc: Subject: [Syslog] Updated Syslog-tls Document X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. --Boundary_(ID_382YWTKKSFtxSs3EHTp9sg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, There are two major changes since last update. 1, Section 3 is removed. It is an introductory text on TLS, and is neccesary because TLS is already a normative reference. 2, Updated the section 4.3.2 (original 5.3.2), removed the text about TLS layer alert to signal a syslog-transport event Regards Miao --Boundary_(ID_382YWTKKSFtxSs3EHTp9sg) Content-type: text/plain; name=draft-ietf-syslog-transport-tls-04.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-ietf-syslog-transport-tls-04.txt Syslog Working Group F. Miao Internet-Draft M. Yuzhi Intended status: Standards Track Huawei Technologies Expires: May 25, 2007 November 21, 2006 TLS Transport Mapping for Syslog draft-ietf-syslog-transport-tls-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract 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. Miao & Yuzhi Expires May 25, 2007 [Page 1] Internet-Draft TLS Transport Mapping for Syslog November 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Requirements for Syslog . . . . . . . . . . . . . . . 3 3. TLS to Secure Syslog . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 5 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. Frame Length . . . . . . . . . . . . . . . . . . . . . 6 4.3.2. Version . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 7 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Generic Certificate . . . . . . . . . . . . . . . . . . . 8 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. VERSION . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Miao & Yuzhi Expires May 25, 2007 [Page 2] Internet-Draft TLS Transport Mapping for Syslog November 2006 1. Introduction This document describes the use of Transport Layer Security (TLS [6]) 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. 1.1. Terminology The following definitions are used in this document: o A sender is an application that can generate and send a Syslog [2] message to another application. o A receiver is an application that can receive a Syslog message. o A relay is an application that can receive Syslog messages and forward them to another receiver. o A collector is an application that can receive messages but does not relay them to any other receiver. o A TLS client is an application that can initiate a TLS connection by sending a Client Hello to a peer. o A TLS server is an application that can receive a Client Hello from a peer and reply with a Server Hello. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 2. Security Requirements for Syslog Syslog messages may pass several hops to arrive at the intended receiver. Some intermediary networks may not be trusted by the sender/relay, receiver, or all because the network is in a different security domain or at a different security level from the receiver, relay, or sender. Another security concern is that the sender/relay, or receiver itself is in an insecure network. There are several threats to be addressed for Syslog security. The primary threats are: o Masquerade. An unauthorized sender/relay may send messages to a legitimate receiver, or an unauthorized receiver tries to deceive a legitimate sender/relay into sending Syslog messages to it. Miao & Yuzhi Expires May 25, 2007 [Page 3] Internet-Draft TLS Transport Mapping for Syslog November 2006 o Modification. An attacker between the sender/relay and receiver may modify an in-transit Syslog message from the sender/relay and then forward the message to receiver. Such modification may make the receiver misunderstand the message or cause the receiver to behave in undesirable ways. o Disclosure. An unauthorized entity may examine the content of the Syslog messages, gaining unauthorized access to the information. Some data in Syslog messages is sensitive and may be useful to an attacker, such as the password of an authorized administrator or user. The secondary threat is: o Message stream modification. An attacker may delete a Syslog message from a series of messages, replay a message or alter the delivery sequence. Syslog protocol itself is not based on message order, but an event in a Syslog message may relate semantically to events in other messages, so message ordering may be important to understanding a sequence of events. The following threats are deemed to be of lesser importance for Syslog, and are not addressed in this document: o Denial of Service o Traffic Analysis 3. TLS to Secure Syslog TLS can be used as a secure transport to counter all the primary and secondary threats to Syslog described in section 2: o Confidentiality to counter disclosure of the message contents o Integrity check to counter modifications to a message o Peer authentication to counter masquerade o Sequence number along with integrity check to counter message stream modification The security service is also applicable to BSD Syslog defined in RFC3164 [7]. But, it is not ensured that the protocol specification defined in this document is applicable to BSD Syslog. Miao & Yuzhi Expires May 25, 2007 [Page 4] Internet-Draft TLS Transport Mapping for Syslog November 2006 4. Protocol Elements 4.1. Port Assignment A Syslog sender/relay is always a TLS client and a Syslog receiver is always a TLS server. The TCP port NNN has been allocated as the default port for Syslog over TLS, as defined in this document. Note to RFC Editor: please replace NNN with the IANA-assigned value, and remove this note. 4.2. Initiation The sender/relay should initiate a connection to the receiver and then send the TLS Client Hello to begin the TLS handshake. When the TLS handshake has finished the sender/relay may then send the first Syslog message. TLS uses certificate [4] to authenticate the peers. When a sender/ relay authenticates a receiver it MUST validate the certificate. It SHOULD check the common name (CN) of the certificate against the host name of the receiver if it has knowledge of a common name/host name mapping. If the common name does not match the host name, the sender/relay SHOULD send an "access_denied" error alert using the TLS alert protocol to terminate the handshake, and then it SHOULD close the connection. When a receiver authenticates a sender/relay, the receiver MUST validate the certificate. A sender's (or relay's) certificate may be: o An unique certificate, which is issued to a host and whose Common Name may be host name, IP address, MAC, or device ID. o A generic certificate, which is issued to a class of application or device. For example, all cable modems from a vendor may be issued the same generic certificate. A sender/relay certificate may be issued by an operator when a device/application is being provisioned or by a vendor when the device/application is manufactured. This document does not define how the sender/relay certificate is issued. Syslog applications SHOULD be implemented in a manner that permits administrators to select the cryptographic level they desire. It SHOULD be an administrator decision, as a matter of local policy, Miao & Yuzhi Expires May 25, 2007 [Page 5] Internet-Draft TLS Transport Mapping for Syslog November 2006 what security level (e.g. cryptographic algorithms and length of keys) is required. TLS permits the resumption of an earlier TLS session or the use of another active session when a new session is requested, in order to save the expense of another full TLS handshake. The security parameters of the resumed session are reused for the requested session. The security parameters SHOULD be checked against security requirement of requested session to make sure the resumed session provides proper security. 4.3. Sending data All Syslog messages MUST be sent as TLS "application data". It is possible that there are multiple Syslog messages in one TLS record, or a Syslog message is transferred in multiple TLS records. The application data is defined with the following ABNF [5] expression: APPLICATION-DATA = VERSION SP 1*SYSLOG-FRAME VERSION = NONZERO-DIGIT *1DIGIT SYSLOG-FRAME = FRAME-LEN SP SYSLOG-MSG FRAME-LEN = NONZERO-DIGIT *DIGIT SP = " " DIGIT = "0" / NONZERO-DIGIT NONZERO-DIGIT = %x31-39 SYSLOG-MSG is defined in Syslog [2] protocol. 4.3.1. Frame Length The frame length is the octet count of a SYSLOG frame including the FRAME-HEADER and SP parts. A receiver MUST use the frame length field to delimit a Syslog message. There is no upper limit for a frame length per se. However, in order to establish a baseline for interoperability, the specification requires that a receiver MUST be able to process frame with size up to and including 2048 octets. It SHOULD be able to receive frame with size up to and including 8192 octets. Miao & Yuzhi Expires May 25, 2007 [Page 6] Internet-Draft TLS Transport Mapping for Syslog November 2006 4.3.2. Version The version is to identify the version of the TLS transport mapping for Syslog, and the version is 1. If a receiver does not support the version in the messages it received, it MAY just save the APPLICATION-DATA in local storage or send a close_notify to signal the closure of the connection. If a sender/relay finds connections are closed just after successful TLS handshake for three times with same transport mapping version, it SHOULD not connect the receiver again with the same transport mapping version. 4.4. Closure A Syslog sender/relay MUST close the associated TLS connection if the connection is not expected to deliver Syslog message later. It MUST send a TLS close_notify alert before closing the connection. A sender/relay MAY choose not to wait for the receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the receiver side. Once the receiver gets close_notify from the sender/relay, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the sender/relay (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a receiver MAY close a connection. The receiver MUST attempt to initiate an exchange of close_notify alerts with the sender/relay before closing the connection. Receivers those are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the sender/relay side. When the sender/relay has received the close_notify alert from the receiver and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert. 5. Security Consideration 5.1. Authentication TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. TLS authentication and the establishment of secrets is based on certificates and asymmetric cryptography. This makes TLS transport much more expensive than non-TLS plain transport. An attacker may Miao & Yuzhi Expires May 25, 2007 [Page 7] Internet-Draft TLS Transport Mapping for Syslog November 2006 initialize many TLS connections to a receiver as a denial of service attack. Since a receiver may act upon received data, for Syslog over TLS, the receiver SHOULD authenticate the sender/relay to ensure that information received is authentic. When confidentiality is a concern, a sender/relay MUST authenticate the receiver to make sure it is talking to the right peer. 5.2. Generic Certificate When a certificate is issued to a class of device or application, the certificate may be shared by multiple hosts. Multiple hosts know the private key of the certificate. When the certificate in one host is compromised, then the certificate for all hosts that share the certificate is compromised. An attacker may impersonate a legitimate sender to send Syslog message to a receiver. 6. IANA Consideration 6.1. Port Number IANA is requested to assign a TCP port number in the range 1..1023 in the http://www.iana.org/assignments/port-numbers registry which will be the default port for Syslog over TLS, as defined in this document. 6.2. VERSION IANA must maintain a registry of VERSION values as described in Section 4.3.2. Version numbers MUST be incremented for any new Syslog TLS transport mapping specification that changes any part of the frame or other parts. Changes include addition or removal of fields or a change of syntax or semantics of existing fields. VERSION numbers must be registered via the Standards Action method as described in RFC2434 [3]. IANA must register the VERSIONs shown in table 1. +---------+---------------------------------+ | VERSION | FORMAT | +---------+---------------------------------+ | 1 | According to this specification | +---------+---------------------------------+ Table 1: Version Number Miao & Yuzhi Expires May 25, 2007 [Page 8] Internet-Draft TLS Transport Mapping for Syslog November 2006 7. Acknowledgments Authors appreciate Eric Rescorla, Anton Okmianski, Rainer Gerhards, Balazs Scheidler and Chris Lonvick for their effort on issues resolving discussion. Authors would also like to appreciate Balazs Scheidler, Tom Petch and other persons for their input on security threats of Syslog. The author would like to acknowledge David Harrington for his detailed reviews of the content and grammar of the document. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Gerhards, R., "The syslog Protocol", draft-ietf-syslog-protocol-17 (work in progress), June 2006. [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. 8.2. Informative References [7] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. Miao & Yuzhi Expires May 25, 2007 [Page 9] Internet-Draft TLS Transport Mapping for Syslog November 2006 Authors' Addresses Miao Fuyou Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Haidian District, Beijing 100085 P. R. China Phone: +86 10 8288 2008 Email: miaofy@huawei.com URI: www.huawei.com Ma Yuzhi Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Haidian District, Beijing 100085 P. R. China Phone: +86 10 8288 2008 Email: myz@huawei.com URI: www.huawei.com Miao & Yuzhi Expires May 25, 2007 [Page 10] Internet-Draft TLS Transport Mapping for Syslog November 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Miao & Yuzhi Expires May 25, 2007 [Page 11] --Boundary_(ID_382YWTKKSFtxSs3EHTp9sg) 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 --Boundary_(ID_382YWTKKSFtxSs3EHTp9sg)-- From syslog-bounces@lists.ietf.org Wed Nov 22 03:10:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmnAB-0006w7-Tv; Wed, 22 Nov 2006 03:08:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmnAA-0006vo-Hr for syslog@ietf.org; Wed, 22 Nov 2006 03:08:58 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmnA8-0000RV-3e for syslog@ietf.org; Wed, 22 Nov 2006 03:08:58 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 4224059739; Wed, 22 Nov 2006 09:08:53 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11497-08; Wed, 22 Nov 2006 09:08:50 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 4EEFF59703; Wed, 22 Nov 2006 09:08:50 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id B9CB58CE5E6; Wed, 22 Nov 2006 09:08:46 +0100 (CET) Date: Wed, 22 Nov 2006 09:08:45 +0100 From: Juergen Schoenwaelder To: Miao Fuyou Subject: Re: [Syslog] Updated Syslog-tls Document Message-ID: <20061122080845.GA14562@boskop.local> Mail-Followup-To: Miao Fuyou , syslog@ietf.org References: <00d601c70dd3$4fd46a90$800c6f0a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d601c70dd3$4fd46a90$800c6f0a@china.huawei.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de 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 Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Wed, Nov 22, 2006 at 09:12:38AM +0800, Miao Fuyou wrote: > There are two major changes since last update. > 1, Section 3 is removed. It is an introductory text on TLS, and is neccesary > because TLS is already a normative reference. > 2, Updated the section 4.3.2 (original 5.3.2), removed the text about TLS > layer alert to signal a syslog-transport event I questioned the need for a version number for the TLS transport in private conversation and now I bring this up again here. I believe we should agree on a single solution scheme and not introduce any options here since signalling of a version mismatch is difficult in a fire and forget situation. The current text says: > If a receiver does not support the version in the messages it > received, it MAY just save the APPLICATION-DATA in local storage or > send a close_notify to signal the closure of the connection. If a > sender/relay finds connections are closed just after successful TLS > handshake for three times with same transport mapping version, it > SHOULD not connect the receiver again with the same transport mapping > version. This does not at all sound very convincing to me (and I assume what the author wanted to say is not well said because I believe the trigger for not trying again would be a close after sending the first syslog message and not after the successful TLS handshake). Is there not a potential attack possible here by successfully "killing" a TCP connection three times in a row? /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 04:17:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmoDM-00013j-1L; Wed, 22 Nov 2006 04:16:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmoCG-0000le-OK for syslog@ietf.org; Wed, 22 Nov 2006 04:15:12 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gmo9S-0008JM-CT for syslog@ietf.org; Wed, 22 Nov 2006 04:12:20 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id DABAE27C009; Wed, 22 Nov 2006 10:16:23 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22500-05; Wed, 22 Nov 2006 10:16:23 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 2567227C008; Wed, 22 Nov 2006 10:16:22 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 10:12:11 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Updated Syslog-tls Document Date: Wed, 22 Nov 2006 10:12:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8647@grfint2.intern.adiscon.com> In-Reply-To: <20061122080845.GA14562@boskop.local> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Updated Syslog-tls Document thread-index: AccODdyUqkyu75CgS2e3aMTZWM0f4gABtZng From: "Rainer Gerhards" To: , "Miao Fuyou" X-OriginalArrivalTime: 22 Nov 2006 09:12:11.0938 (UTC) FILETIME=[4B568820:01C70E16] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Wednesday, November 22, 2006 9:09 AM > To: Miao Fuyou > Cc: syslog@ietf.org > Subject: Re: [Syslog] Updated Syslog-tls Document >=20 > On Wed, Nov 22, 2006 at 09:12:38AM +0800, Miao Fuyou wrote: > =20 > > There are two major changes since last update. > > 1, Section 3 is removed. It is an introductory text on TLS,=20 > and is neccesary > > because TLS is already a normative reference.=20 > > 2, Updated the section 4.3.2 (original 5.3.2), removed the=20 > text about TLS > > layer alert to signal a syslog-transport event >=20 > I questioned the need for a version number for the TLS transport in > private conversation and now I bring this up again here.=20 Was that private? I thought it was on-list. Anyhow... I concur with your initial recommendation of removing the version number from the transport header. The point at that time was that a version in transport specs is unusual. If there is need to revise a transport header, a new port is assigend. Sure, ports are a scarce ressource, but how likely is an incompatible change to the transport header? > I believe we > should agree on a single solution scheme and not introduce any options > here since signalling of a version mismatch is difficult in a fire and > forget situation. The current text says: >=20 > > If a receiver does not support the version in the messages it > > received, it MAY just save the APPLICATION-DATA in local=20 > storage or > > send a close_notify to signal the closure of the=20 > connection. If a > > sender/relay finds connections are closed just after=20 > successful TLS > > handshake for three times with same transport mapping version, it > > SHOULD not connect the receiver again with the same=20 > transport mapping > > version. >=20 > This does not at all sound very convincing to me (and I assume what > the author wanted to say is not well said because I believe the > trigger for not trying again would be a close after sending the first > syslog message and not after the successful TLS handshake).=20 I, too, assume this was meant... > Is there > not a potential attack possible here by successfully "killing" a TCP > connection three times in a row? ... and I am not happy with it either. There may be different reasons for tearing down the session, especially in a troubleshooting scenario. We should keep in mind that one important application for syslog is troubleshooting failing networks, which increases the likelyhood of unexpected session terminations. I object the ultimate "non-delivery" SHOULD. If we use this clause, we should at least recommend a retry after a specified period. But my suggestion is to remove the version as well as this text. Rainer >=20 > /js >=20 > --=20 > Juergen Schoenwaelder {International|Jacobs}=20 > University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=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 Nov 22 04:41:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmobN-0001td-LE; Wed, 22 Nov 2006 04:41:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmobM-0001tX-JH for syslog@ietf.org; Wed, 22 Nov 2006 04:41:08 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmob8-0005bv-M5 for syslog@ietf.org; Wed, 22 Nov 2006 04:41:08 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9400MLJLIMJR@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 22 Nov 2006 17:39:58 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9400GEELIM4O@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 22 Nov 2006 17:39:58 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9400099LII0X@szxml04-in.huawei.com> for syslog@ietf.org; Wed, 22 Nov 2006 17:39:58 +0800 (CST) Date: Wed, 22 Nov 2006 17:39:54 +0800 From: Miao Fuyou Subject: RE: [Syslog] Updated Syslog-tls Document In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA1F8647@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' , j.schoenwaelder@iu-bremen.de Message-id: <010a01c70e1a$2a72be90$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccODdyUqkyu75CgS2e3aMTZWM0f4gABtZngAACdV5A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > > I questioned the need for a version number for the TLS transport in > > private conversation and now I bring this up again here. > > Was that private? I thought it was on-list. Anyhow... I The public messege can be found at: http://www1.ietf.org/mail-archive/web/syslog/current/msg01273.html It seems there was a rough concensus that the version number was welcomed to save port resource when we discussed this issue on the mailing list. That is the reason why a version number is there. > > This does not at all sound very convincing to me (and I assume what > > the author wanted to say is not well said because I believe the > > trigger for not trying again would be a close after sending > the first > > syslog message and not after the successful TLS handshake). > > I, too, assume this was meant... Yeah, this sentence should be improved if version number is kept there. > > > But my suggestion is to remove the version as well as this text. > So do I now... _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 05:12:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmp5Z-0004m1-Ah; Wed, 22 Nov 2006 05:12:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmp5Z-0004lv-04 for syslog@ietf.org; Wed, 22 Nov 2006 05:12:21 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmp5X-0003Nv-FM for syslog@ietf.org; Wed, 22 Nov 2006 05:12:20 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 8329F27C011; Wed, 22 Nov 2006 11:16:27 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22998-07; Wed, 22 Nov 2006 11:16:27 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id B64F427C010; Wed, 22 Nov 2006 11:16:26 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 11:12:16 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Updated Syslog-tls Document Date: Wed, 22 Nov 2006 11:12:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F864A@grfint2.intern.adiscon.com> In-Reply-To: <00d601c70dd3$4fd46a90$800c6f0a@china.huawei.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Updated Syslog-tls Document thread-index: AccN00y0qV2GLbfNQWeHwgDicYI+RAAQ2Vag From: "Rainer Gerhards" To: "Miao Fuyou" , X-OriginalArrivalTime: 22 Nov 2006 10:12:16.0583 (UTC) FILETIME=[AFDFB570:01C70E1E] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 Miao, thanks for the update. I have gone through the draft again and found some, mostly minor, issue. I have listed them below: ------------------------------------- 3.0 =3D=3D The security service is also applicable to BSD Syslog defined in RFC3164 [7]. But, it is not ensured that the protocol specification defined in this document is applicable to BSD Syslog. =3D=3D Do we really intend to support RFC 3164-style syslog (read: nothing known about the message format) over this transport? If so, the consequence is that implementations of -transport-tls must check for 3164 format and eventually be able to handle it. I suggest removing these two sentence, as it looks we encourage that case. If they stay, we should clearly state that a receiver is NOT REQUIRED to implement this. ------------------------------------- Section 4.3, inside the ABNF: > SP =3D " " I think this is problematic in respect to 2.4 of RFC 4234. I suggest replacing by SP =3D %d32 ------------------------------------- 5.1 =3D=3D When confidentiality is a concern, a sender/relay MUST authenticate the receiver to make sure it is talking to the right peer. =3D=3D I do not find the MUST is appropriate here: "when confidentiality is a concern" is not a hard fact. What does it mean? When MUST I implement authentication. Is my Implementation not compliant to this doc if I have the wrong understanding of "when confidentiality is a concern". Or MUST I always implement it, because confidentiality is probably very often a concern? I think this is a operator-issue not to be dealt with in the protocol. I suggest dropping this sentence or at last spell MUST in lower case. ------------------------------------- 5.2 Isn't that a security consideration (and belongs to that secition)? ------------------------------------- 6.2 IANA registry names must be suggested (of course this comment is irrelevant if we drop VERSION). ------------------------------------- Consistent Spelling Both version and VERSION is used for the respectively-named field. I suggest to resort to a single spelling. This also removes some ambiguities if the version field or the concept of a version is meant in some parts of the text. I suggest using VERSION consistently for the respective field. ------------------------------------- "Security Considerations" is missing I wonder I didn't spot this earlier. IMHO any document must have a "Security Considerations" section. Of course, the whole document talks about security, but does that obsolete the section showing the weaknesses of the protocol? For example, I have at least three candiates to be included: - Problems in relay scenario A relay may receive data via traditional syslog and forward it via a tls-encrypted channel to its next destination. In this case, the channel to the next hop is secured, but the trust level of the message is considerably lower. - there is no rule that a sender must use the same host name inside the -protocol HOSTNAME field as it uses in the certificate's common name. I think that has some security implications. - cipher suites and such are left to the operator. We should indicate the (serious) consequences of this selection --------------------------------------------- One note on the cipher suites: I know there has been some discussion previously, but I wasn't able to find the post in question in the archive. Probably you can help me out. Question: how do we guarantee a minimum interoperability of implementations of this document if we do not specify any cipher suite? --------------------------------------------- Rainer > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Wednesday, November 22, 2006 2:13 AM > To: syslog@ietf.org > Subject: [Syslog] Updated Syslog-tls Document >=20 > Hi, >=20 > There are two major changes since last update. > 1, Section 3 is removed. It is an introductory text on TLS,=20 > and is neccesary > because TLS is already a normative reference.=20 > 2, Updated the section 4.3.2 (original 5.3.2), removed the=20 > text about TLS > layer alert to signal a syslog-transport event >=20 > Regards > Miao >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 05:16:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmp9N-0005nq-5b; Wed, 22 Nov 2006 05:16:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmp9L-0005jK-U4 for syslog@ietf.org; Wed, 22 Nov 2006 05:16:15 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmp9K-0003xn-J0 for syslog@ietf.org; Wed, 22 Nov 2006 05:16:15 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 479AE27C011; Wed, 22 Nov 2006 11:20:23 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22998-09; Wed, 22 Nov 2006 11:20:23 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id A402B27C010; Wed, 22 Nov 2006 11:20:22 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 11:15:40 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Updated Syslog-tls Document Date: Wed, 22 Nov 2006 11:15:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F864B@grfint2.intern.adiscon.com> In-Reply-To: <010a01c70e1a$2a72be90$800c6f0a@china.huawei.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Updated Syslog-tls Document thread-index: AccODdyUqkyu75CgS2e3aMTZWM0f4gABtZngAACdV5AAAffgQA== From: "Rainer Gerhards" To: "Miao Fuyou" , X-OriginalArrivalTime: 22 Nov 2006 10:15:40.0137 (UTC) FILETIME=[29339590:01C70E1F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Wednesday, November 22, 2006 10:40 AM > To: Rainer Gerhards; j.schoenwaelder@iu-bremen.de > Cc: syslog@ietf.org > Subject: RE: [Syslog] Updated Syslog-tls Document >=20 >=20 > > > I questioned the need for a version number for the TLS=20 > transport in=20 > > > private conversation and now I bring this up again here. > >=20 > > Was that private? I thought it was on-list. Anyhow... I=20 >=20 > The public messege can be found at: > http://www1.ietf.org/mail-archive/web/syslog/current/msg01273.html >=20 > It seems there was a rough concensus that the version number=20 > was welcomed to > save port resource when we discussed this issue on the=20 > mailing list. That is > the reason why a version number is there.=20 Agreed, I am guilty of not saying "I agree" on the mailing list. But to me that did not look like consensus but simply an overlooked message (there were no responses at all...). Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 05:46:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmpbz-00008I-32; Wed, 22 Nov 2006 05:45:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmpbx-00008D-SL for syslog@ietf.org; Wed, 22 Nov 2006 05:45:49 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmpbv-00025y-HI for syslog@ietf.org; Wed, 22 Nov 2006 05:45:49 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id A39D727C011; Wed, 22 Nov 2006 11:49:55 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04178-01; Wed, 22 Nov 2006 11:49:55 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 1D87C27C010; Wed, 22 Nov 2006 11:49:54 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 11:45:44 +0100 Content-class: urn:content-classes:message Date: Wed, 22 Nov 2006 11:45:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8650@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: Revision 18 of Syslog-Protocol has been posted thread-index: AccOI1jHjtP6bETnSNGSfXPRVJTHCA== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 22 Nov 2006 10:45:44.0147 (UTC) FILETIME=[5C79AA30:01C70E23] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: bwijnen@lucent.com Subject: [Syslog] Revision 18 of Syslog-Protocol has been posted X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hello all, I have yesterday posted the latest revision of syslog-protocol to the draft editor. I expect it to come up on the I-D announcement list today. For those interested in a preview, I have made it available at http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-protocol-18.txt -protocol-18 contains changes requested during the last WGLC in August. Thankfully, there have been a number of excellent comments. I had prepared a change list for the chairs. Rather than now tearing that list apart and sending seperate replies to the mails (which will often miss the context), I have made this list available publically: http://www.syslog.cc/ietf/drafts/2nd-wglc-response-chris-public.html -- black text is orginal comment, green is me, red is chair or to be discussed (if "RG:" is present in front) -- Please note that discussion on ITU Preceived Severity has been re-initiated and I have not yet (re)moved that part from the document. Not included in this list are some editorial changes I did early in August. They are outlined here: http://www.mail-archive.com/syslog%40lists.ietf.org/msg00785.html I would appreciate any comments on the new draft. I would also once again like to express my gratitude to everyone who commented on the previous version. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 06:30:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmqIS-0006Ox-0w; Wed, 22 Nov 2006 06:29:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmqIQ-0006Or-OA for syslog@ietf.org; Wed, 22 Nov 2006 06:29:42 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmqIO-00024P-Dr for syslog@ietf.org; Wed, 22 Nov 2006 06:29:42 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 9A96327C011; Wed, 22 Nov 2006 12:33:48 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04378-10; Wed, 22 Nov 2006 12:33:48 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 3BB1927C010; Wed, 22 Nov 2006 12:33:47 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 12:29:14 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Shepherding document for udp-08 Date: Wed, 22 Nov 2006 12:29:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8659@grfint2.intern.adiscon.com> In-Reply-To: <126c01c70dc6$84f84fa0$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Shepherding document for udp-08 thread-index: AccNxikySfyauRdWTgeqq4EjcWrEQgAYs+UA From: "Rainer Gerhards" To: "David Harrington" , X-OriginalArrivalTime: 22 Nov 2006 11:29:14.0311 (UTC) FILETIME=[70411570:01C70E29] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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, there is one minor thing in the shepherding document I do not concur with: -- This document describes the traditional udp transport for syslog. draft-ietf-syslog-protocol makes changes to the syntax of the syslog fields but this is just the udp transport. It could be said that all existing implementations of syslog use this specification. --=20 There are some changes in -transport-udp compared to the traditional transport. I think it is somewhat dangerous to draw the conclusion drawn. But as I said - this is a minor comment and probably depend's on ones point of view... Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Wednesday, November 22, 2006 12:41 AM > To: syslog@ietf.org > Subject: [Syslog] Shepherding document for udp-08 >=20 > Hi, >=20 > I have reviewed a pre-publication copy of -08- and am satisifed it > represents WG consensus and is of a quality sufficient for advancement > to Proposed Standard. >=20 > Barring serious objection from the WG, revision -08- will be submitted > to the IESG for advancement, accompanied by the attached shepherding > document. >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 06:30:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmqJB-0007Ls-28; Wed, 22 Nov 2006 06:30:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmqJ9-0007Lg-Te for syslog@ietf.org; Wed, 22 Nov 2006 06:30:27 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmqJ8-0002OE-Ei for syslog@ietf.org; Wed, 22 Nov 2006 06:30:27 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 015A927C011; Wed, 22 Nov 2006 12:34:35 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15494-05; Wed, 22 Nov 2006 12:34:34 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 729AA27C010; Wed, 22 Nov 2006 12:34:34 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 12:30:24 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Shepherding document for udp-08 Date: Wed, 22 Nov 2006 12:30:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F865A@grfint2.intern.adiscon.com> In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122023A1264@xmb-rtp-20d.amer.cisco.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Shepherding document for udp-08 thread-index: AccNxikySfyauRdWTgeqq4EjcWrEQgABtSVQABcc7jA= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , "David Harrington" , X-OriginalArrivalTime: 22 Nov 2006 11:30:24.0267 (UTC) FILETIME=[99F385B0:01C70E29] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Assuming these are the only changes, I am happy with the document and think it is ready for publication (yes, I intend to start the "me too's" necessary to get us to publication). I have not reviewed the text but this mail (which should be sufficient as far as I understand). Rainer=20 > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Wednesday, November 22, 2006 1:29 AM > To: David Harrington; syslog@ietf.org > Subject: RE: [Syslog] Shepherding document for udp-08 >=20 > FYI for the group...=20 >=20 > I submitted revision 08 to IETF editor and you should get an official > email soon. =20 >=20 > Three changes in this draft: > =20 > 1. Marked draft as Standards Track. =20 > =20 > 2. Per IESG review comments, added the following paragraph to the > Congestion Control section: > =20 > "If the potentially unrestricted use of syslog data being transferred > over UDP in a particular deployment can saturate the link, then the > network path should be provisioned so the offered load=20 > (including syslog > packets) does not exceed the path capacity. Otherwise, some of the > syslog packets could be lost, or cause the loss of other UDP packets." > =20 > 3. Per comment from Rich Graveman, added this to the section on > Sequenced Delivery: > =20 > "If present, Structured Data element 'sequenceId' contained within > syslog messages MAY help in establishing the sequence of=20 > messages from a > single sender." =20 >=20 > Thanks, > Anton.=20 >=20 > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > > Sent: Tuesday, November 21, 2006 6:41 PM > > To: syslog@ietf.org > > Subject: [Syslog] Shepherding document for udp-08 > >=20 > > Hi, > >=20 > > I have reviewed a pre-publication copy of -08- and am=20 > > satisifed it represents WG consensus and is of a quality=20 > > sufficient for advancement to Proposed Standard. > >=20 > > Barring serious objection from the WG, revision -08- will be=20 > > submitted to the IESG for advancement, accompanied by the=20 > > attached shepherding document. > >=20 > > David Harrington > > dharrington@huawei.com > > 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 Wed Nov 22 06:39:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmqRi-0001Ef-15; Wed, 22 Nov 2006 06:39:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmqRg-0001CH-PK for syslog@ietf.org; Wed, 22 Nov 2006 06:39:16 -0500 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmqRe-0004UF-FL for syslog@ietf.org; Wed, 22 Nov 2006 06:39:16 -0500 Received: from pc6 (1Cust176.tnt27.lnd4.gbr.da.uu.net [62.188.154.176]) by galaxy.systems.pipex.net (Postfix) with SMTP id 48C65E00071E; Wed, 22 Nov 2006 11:39:12 +0000 (GMT) Message-ID: <039b01c70e22$7cd72560$0601a8c0@pc6> From: "tom.petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA1F8647@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Updated Syslog-tls Document Date: Wed, 22 Nov 2006 11:37:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Rainer Gerhards" To: ; "Miao Fuyou" Cc: Sent: Wednesday, November 22, 2006 10:12 AM Subject: RE: [Syslog] Updated Syslog-tls Document > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Wednesday, November 22, 2006 9:09 AM > To: Miao Fuyou > Cc: syslog@ietf.org > Subject: Re: [Syslog] Updated Syslog-tls Document > > On Wed, Nov 22, 2006 at 09:12:38AM +0800, Miao Fuyou wrote: > > > There are two major changes since last update. > > 1, Section 3 is removed. It is an introductory text on TLS, > and is neccesary > > because TLS is already a normative reference. > > 2, Updated the section 4.3.2 (original 5.3.2), removed the > text about TLS > > layer alert to signal a syslog-transport event > > I questioned the need for a version number for the TLS transport in > private conversation and now I bring this up again here. Was that private? I thought it was on-list. Anyhow... I concur with your initial recommendation of removing the version number from the transport header. The point at that time was that a version in transport specs is unusual. If there is need to revise a transport header, a new port is assigend. Sure, ports are a scarce ressource, but how likely is an incompatible change to the transport header? Ports may or may not be scarce but they are expensive. Introduce a new one and - anyone with firewall - anyone with an application level gateway - anyone with a packet filtering router has to go out and change each and every box to reflect the new assignment, a slow and costly process. This cost is often ignored by protocol designers. As to header change, the elephant in the room is the IPR hanging over this work which we can do no more about except wait to see what materialises; it could result in a change. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 08:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmsHW-0005zf-NK; Wed, 22 Nov 2006 08:36:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmsHU-0005zX-Ui for syslog@ietf.org; Wed, 22 Nov 2006 08:36:52 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmsHT-00016Q-LE for syslog@ietf.org; Wed, 22 Nov 2006 08:36:52 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 4789327C011; Wed, 22 Nov 2006 14:40:59 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17250-09; Wed, 22 Nov 2006 14:40:59 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 0A5CA27C010; Wed, 22 Nov 2006 14:40:58 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 14:36:48 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Updated Syslog-tls Document Date: Wed, 22 Nov 2006 14:36:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F865E@grfint2.intern.adiscon.com> In-Reply-To: <039b01c70e22$7cd72560$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Updated Syslog-tls Document thread-index: AccOLm1G+MzX7jc1SWqiSUTOE/8IIAADEoFw From: "Rainer Gerhards" To: "tom.petch" , X-OriginalArrivalTime: 22 Nov 2006 13:36:48.0349 (UTC) FILETIME=[426A98D0:01C70E3B] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) 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 Tom, > > Ports may or may not be scarce but they are expensive. =20 > Introduce a new one and > - anyone with firewall > - anyone with an application level gateway > - anyone with a packet filtering router > has to go out and change each and every box to reflect the=20 > new assignment, a > slow and costly process. This cost is often ignored by=20 > protocol designers. I agree with you on that. But I think the chance is extremely low that a considerate change is required. Even then, we could implement some version checking via special sequences at a later stage. But my root cause is that I do not expect a change. >=20 > As to header change, the elephant in the room is the IPR=20 > hanging over this work > which we can do no more about except wait to see what=20 > materialises; it could > result in a change. I do not want to get on the slippery slope of the IPR discussion here again. But: if there will be a valid patent on something as trivial as using an octet count followed by a space followed by the data, then you will probably never find anything at all that is unaffected by the IPR. So I consider the IPR discussion to be actually irrelevant. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 09:02:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmsgS-00017v-Bh; Wed, 22 Nov 2006 09:02:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmsgR-00017q-SB for syslog@ietf.org; Wed, 22 Nov 2006 09:02:39 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmsgQ-00053m-87 for syslog@ietf.org; Wed, 22 Nov 2006 09:02:39 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2006 06:02:37 -0800 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 kAME2bax019658 for ; Wed, 22 Nov 2006 06:02:37 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAME2bip003557 for ; Wed, 22 Nov 2006 06:02:37 -0800 (PST) Date: Wed, 22 Nov 2006 06:02:37 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9768; t=1164204157; x=1165068157; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Draft=20Shepherding=20document=20for=20draft-ietf-syslog-tran sport-tls-04.txt |Sender:=20; bh=YYEe5/1Z2YSZQHbYnFl9Z5Efv4e5DF7qQZ1dDIhe720=; b=feKoWWtsjcEkQpznshnyBAmsuVZWS0R/LMsHSlKKq1mSovkCYTaWGGqZGa3UhB6V34rcl6Ay j1I4TPC3VzOWlxV4tXcflSKmvbO+rAGMv4fjaGG1AmaP4pVxegSvk5ev; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: Subject: [Syslog] Draft Shepherding document for draft-ietf-syslog-transport-tls-04.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Below is the first draft for the shepherding document for draft-ietf-syslog-transport-tls-04.txt. Please review and send feedback to the list. All of this is pending final reviews of the latest document submitted. === Having passed a WG Last Call, draft-ietf-syslog-transport-tls-04.txt is ready for AD review. [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-transport-tls-04.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick === (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Chris Lonvick Yes; I believe that the document is ready for publication. === (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Adequate review has occurred from WG members, and it has been reviewed by others. The reviews of the WG Last Call for this document (-03 version) may be found here: Bert Wijnen's review (not a member of the WG mailing list) http://www1.ietf.org/mail-archive/web/syslog/current/msg01244.html John Calcote's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01199.html Other reviews of particular sections and concepts fill the WG mailing list. Of note is Eric Rescorla's review (of -02) http://www1.ietf.org/mail-archive/web/syslog/current/msg01100.html The issues raised in these reviews have been discussed on the mailing list and I am satisfied about the level of review. === (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I have no concerns. === (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no concerns about the technical merit of the document. === (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus to publish this document. === (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No appeals have been threatened. === (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? XXX - Let's see what --04 looks like - XXX === (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split into normative and informational references. The document is dependant upon draft-ietf-syslog-transport-udp-08.txt and draft-ietf-syslog-protocol-18.txt which are being submitted along with this document. === (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document IANA section is complete and the requested registries are clearly marked. === (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The ABNF in the document has been verified through http://www.apps.ietf.org/abnf.html === (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. 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. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was controversy around the IPR statement from Huawei from this document. The Working Group examined the issue and came to consensus that the statement would be accepted. There was controversy around the use of a version number within the payload. Since this implementation is close to the fire&forget model of traditional syslog/udp, no signalling of errors from the receiver will occur. There was a concern on the mailing list that if the method of inserting the payload into the transport were to change in the future, the recipient may not be able to parse the information. Hence the WG decided upon a version number at the start of the payload. The WG consensus at this time is to have a version number as a field in the payload. There was some controversy around the use of a special character to denote the end of the payload, or a counter at the start of the payload to indicate the length of the payload. The Working Group has consent that a counter is the best mechanism. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This protocol has very similar characteristics to implementations of syslog over ssl that are available at this time. The author of that implementation has indicated that he will make changes to conform to this specification. No vendors have announced that they will utilize this protocol. Some vendors have indicated interest in supporting this document. The above named reviewers did an outstanding and thorough job. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-transport-tls-04v.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick [AD] Sam Hartman === Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 09:16:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmsts-0007P6-Fu; Wed, 22 Nov 2006 09:16:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmstr-0007P1-9e for syslog@ietf.org; Wed, 22 Nov 2006 09:16:31 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmstq-0006Ql-Do for syslog@ietf.org; Wed, 22 Nov 2006 09:16:31 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id F22BA27C011; Wed, 22 Nov 2006 15:20:37 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18616-06; Wed, 22 Nov 2006 15:20:37 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 794C527C010; Wed, 22 Nov 2006 15:20:36 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 15:16:25 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Draft Shepherding document fordraft-ietf-syslog-transport-tls-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Nov 2006 15:16:21 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8664@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Draft Shepherding document fordraft-ietf-syslog-transport-tls-04.txt thread-index: AccOPvtQHfXyU7VRSAqwQV/01ZM6QAAAFfHg From: "Rainer Gerhards" To: "Chris Lonvick" , X-OriginalArrivalTime: 22 Nov 2006 14:16:25.0765 (UTC) FILETIME=[CB777D50:01C70E40] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f 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 Chris, I mostly agree (but keep my posting on -04 in mind). Some issue below... Rainer=20 > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Wednesday, November 22, 2006 3:03 PM > To: syslog@ietf.org > Subject: [Syslog] Draft Shepherding document=20 > fordraft-ietf-syslog-transport-tls-04.txt >=20 > Hi, >=20 > Below is the first draft for the shepherding document for=20 > draft-ietf-syslog-transport-tls-04.txt. Please review and=20 > send feedback=20 > to the list. >=20 > All of this is pending final reviews of the latest document submitted. >=20 > =3D=3D=3D > Having passed a WG Last Call,=20 > draft-ietf-syslog-transport-tls-04.txt is=20 > ready for AD review. >=20 > [Area] SECURITY > [WG] syslog > [I-D] draft-ietf-syslog-transport-tls-04.txt > [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt > [Shep] Chris Lonvick >=20 > =3D=3D=3D > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for=20 > publication? > Chris Lonvick > Yes; I believe that the document is ready for publication. > =3D=3D=3D > (1.b) Has the document had adequate review both from key=20 > WG members > and from key non-WG members? Does the Document=20 > Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? >=20 > Adequate review has occurred from WG members, and it has been reviewed > by others. The reviews of the WG Last Call for this document (-03 > version) may be found here: >=20 > Bert Wijnen's review (not a member of the WG mailing list) > http://www1.ietf.org/mail-archive/web/syslog/current/msg01244.html >=20 > John Calcote's review > http://www1.ietf.org/mail-archive/web/syslog/current/msg01199.html >=20 > Other reviews of particular sections and concepts fill the WG mailing > list. Of note is Eric Rescorla's review (of -02) > http://www1.ietf.org/mail-archive/web/syslog/current/msg01100.html >=20 > The issues raised in these reviews have been discussed on the mailing > list and I am satisfied about the level of review. > =3D=3D=3D > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone=20 > familiar with > AAA, internationalization or XML? >=20 > I have no concerns. > =3D=3D=3D > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible=20 > Area Director > and/or the IESG should be aware of? For example,=20 > perhaps he > or she is uncomfortable with certain parts of the=20 > document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and=20 > has indicated > that it still wishes to advance the document, detail those > concerns here. >=20 > There are no concerns about the technical merit of the document. > =3D=3D=3D > (1.e) How solid is the WG consensus behind this=20 > document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole=20 > understand and > agree with it? >=20 > There is strong consensus to publish this document. > =3D=3D=3D > (1.f) Has anyone threatened an appeal or otherwise=20 > indicated extreme > discontent? If so, please summarise the areas of=20 > conflict in > separate email messages to the Responsible Area=20 > Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) >=20 > No appeals have been threatened. > =3D=3D=3D > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate=20 > checks are > not enough; this check needs to be thorough. Has=20 > the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? >=20 > XXX - Let's see what --04 looks like - XXX > =3D=3D=3D > (1.h) Has the document split its references into normative and > informative? Are there normative references to=20 > documents that > are not ready for advancement or are otherwise in=20 > an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there=20 > normative references > that are downward references, as described in=20 > [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. >=20 > The references are split into normative and informational references. > The document is dependant upon draft-ietf-syslog-transport-udp-08.txt > and draft-ietf-syslog-protocol-18.txt which are being submitted > along with this document. It is not dependent on draft-ietf-syslog-transport-udp-08.txt. I suggest you remove that dependency. -protocol is dependent on both tranports, but the transport so far only depend on -protocol. > =3D=3D=3D > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent=20 > with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly=20 > identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggested a > reasonable name for the new registry? See > [I-D.narten-iana-considerations-rfc2434bis]. If=20 > the document > describes an Expert Review process has Shepherd=20 > conferred with > the Responsible Area Director so that the IESG can=20 > appoint the > needed Expert during the IESG Evaluation? >=20 > The document IANA section is complete and the requested registries are > clearly marked. The registry name as required by I-D.narten-iana-considerations-rfc2434bis is not yet present. > =3D=3D=3D > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate=20 > correctly in > an automated checker? >=20 > The ABNF in the document has been verified through > http://www.apps.ietf.org/abnf.html > =3D=3D=3D > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Writeup? Recent examples can be found in the > "Action" announcements for approved documents. =20 > The approval > announcement contains the following sections: >=20 > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not,=20 > this may be > an indication that there are deficiencies in=20 > the abstract > or introduction. >=20 > This document describes the use of Transport Layer=20 > 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. >=20 > Working Group Summary > Was there anything in WG process that is worth=20 > noting? For > example, was there controversy about particular=20 > points or > were there decisions where the consensus was=20 > particularly > rough? >=20 > There was controversy around the IPR statement from Huawei from this=20 > document. The Working Group examined the issue and came to=20 > consensus that=20 > the statement would be accepted. >=20 > There was controversy around the use of a version number within the=20 > payload. Since this implementation is close to the=20 > fire&forget model of=20 > traditional syslog/udp, no signalling of errors from the=20 > receiver will=20 > occur. There was a concern on the mailing list that if the method of=20 > inserting the payload into the transport were to change in=20 > the future, the=20 > recipient may not be able to parse the information. Hence=20 > the WG decided=20 > upon a version number at the start of the payload. The WG=20 > consensus at=20 > this time is to have a version number as a field in the payload. I did have the impression that removal of the version number was consensus. Today, I learnt we didn't actaully discuss this. I can life with and without version number. I'd happily accept a chair decision. However, if we stick with the version number, I think we must look into the mechanism on what to do when the receiver does not accept it (see my review from earlier today). >=20 > There was some controversy around the use of a special=20 > character to denote > the end of the payload, or a counter at the start of the payload to=20 > indicate the length of the payload. The Working Group has=20 > consent that a=20 > counter is the best mechanism. >=20 >=20 > Document Quality > Are there existing implementations of the=20 > protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any=20 > reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive=20 > issues? If > there was a MIB Doctor, Media Type or other=20 > expert review, > what was its course (briefly)? In the case of=20 > a Media Type > review, on what date was the request posted? >=20 > This protocol has very similar characteristics to implementations of=20 > syslog over ssl that are available at this time. The author of that=20 > implementation has indicated that he will make changes to=20 > conform to this=20 > specification. I am not sure if we can really say this. True, both use syslog over ssl and the overall idea is exactly the same. The details, however, differ greatly. Currently existing syslog/ssl uses octet-stuffing for framing (LF inserted as end of record marker) while -transport-tls utilizes octet-counting. While this is a small difference in design, it will make existing implementations and -transport-tls implementations non-interoperable. On the other hand, it should be extremely easy to adopt existing code to the new way of doing things (even concurrently to existing practice). Maybe this is worth noting. > No vendors have announced that they will utilize this protocol. Some=20 > vendors have indicated interest in supporting this document. > The above named reviewers did an outstanding and thorough job. >=20 >=20 > Personnel > Who is the Document Shepherd for this document?=20 > Who is the > Responsible Area Director? > [Area] SECURITY > [WG] syslog > [I-D] draft-ietf-syslog-transport-tls-04v.txt > [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt > [Shep] Chris Lonvick > [AD] Sam Hartman =20 > =3D=3D=3D >=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 Wed Nov 22 09:27:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmt3o-0005PT-7n; Wed, 22 Nov 2006 09:26:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmt3m-0005PM-De for syslog@ietf.org; Wed, 22 Nov 2006 09:26:46 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmt3k-0007K8-Op for syslog@ietf.org; Wed, 22 Nov 2006 09:26:46 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 22 Nov 2006 06:26:44 -0800 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 kAMEQivK001479 for ; Wed, 22 Nov 2006 06:26:44 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAMEQiW5005884 for ; Wed, 22 Nov 2006 06:26:44 -0800 (PST) Date: Wed, 22 Nov 2006 06:26:43 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8739; t=1164205604; x=1165069604; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Draft=20Shepherding=20document=20for=20draft-ietf-syslog-prot ocol-18.txt |Sender:=20; bh=XRfKZ6pYuWm7mzmzCMcx91Rbowl6Mm9AhOiHDDIoeoc=; b=QRP7Ob4NrRSuWXp1SDlx7Xz25DdI6mTCWeHclxQNgYQI2S6spUD40zVWe4j7PqOiBktri8oM qAWoENjUMuegF/Ktw8s9oq+AXaCY8XNxo6D4dbsuN9DrC7ohTLCtts1Q; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: Subject: [Syslog] Draft Shepherding document for draft-ietf-syslog-protocol-18.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, Below is the first draft for the shepherding document for draft-ietf-syslog-protocol-18.txt. Please review and send feedback to the list. All of this is pending final reviews of the latest document submitted. === Having passed a WG Last Call, draft-ietf-syslog-protocol-18.txt is ready for AD review. [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-protocol-18.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick === (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Chris Lonvick Yes; I believe that the document is ready for publication. === (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Adequate review has occurred from WG members, and it has been reviewed by others. The reviews of the WG Last Call for this document (-17 version) may be found here: Bert Wijnen's review (not a member of the WG mailing list) http://www1.ietf.org/mail-archive/web/syslog/current/msg01243.html Richard Graveman's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01240.html Sharon Chisolm's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01232.html Tom Petch's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01167.html David Harrington's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01144.html The issues raised in these reviews have been discussed on the mailing list and I am satisfied about the level of review. === (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. === (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. === None. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? === There is strong consensus to publish this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No appeals have been threatened. === (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? XXX - Let's see what -18 looks like - XXX === (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split into normative and informational references. The document is dependant upon draft-ietf-syslog-transport-udp-07.txt and draft-ietf-syslog-transport-tls-04.txt which are being submitted along with this document. === (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document IANA section is complete and the requested registries are clearly marked. === (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The ABNF in the document has been verified through http://www.apps.ietf.org/abnf.html === (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. 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. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing worth noting. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No one has come forth to claim that they have an existing implementation of this protocol at this time. No vendors have announced that they will utilize this protocol. Some vendors have indicated interest in supporting this document. The above named reviewers did an outstanding and thorough job. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-protocol-18.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick [AD] Sam Hartman === Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 09:33:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtA9-0007pi-G9; Wed, 22 Nov 2006 09:33:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtA7-0007pa-SC for syslog@ietf.org; Wed, 22 Nov 2006 09:33:19 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmtA6-0008Ex-3N for syslog@ietf.org; Wed, 22 Nov 2006 09:33:19 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2006 06:33:17 -0800 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 kAMEXHQi009464; Wed, 22 Nov 2006 06:33:17 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAMEXHip024558; Wed, 22 Nov 2006 06:33:17 -0800 (PST) Date: Wed, 22 Nov 2006 06:33:16 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] Draft Shepherding document fordraft-ietf-syslog-transport-tls-04.txt In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8664@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA1F8664@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12945; t=1164205997; x=1165069997; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20RE=3A=20[Syslog]=20Draft=20Shepherding=20document=20fordraft- ietf-syslog-transport-tls-04.txt |Sender:=20; bh=s/4V7W7nIyK5FfdKR5loK9IpE3MEg9MiAMMYCCbpEo8=; b=m+Lu+7BxUUpeMkNXpL9Yh69lvimUTBQO+5R9L1cBuYeiL7nE7QUFZEuNU62UDL/1W6DjRlFi J6J6dXsaZxczMKhQ9Mm3xoSQ9KKJq8qEIDL94wgqaLMqErZU44Kt0R3G; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 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 Wed, 22 Nov 2006, Rainer Gerhards wrote: > Chris, > > I mostly agree (but keep my posting on -04 in mind). Some issue below... > > Rainer > >> -----Original Message----- >> From: Chris Lonvick [mailto:clonvick@cisco.com] >> Sent: Wednesday, November 22, 2006 3:03 PM >> To: syslog@ietf.org >> Subject: [Syslog] Draft Shepherding document >> fordraft-ietf-syslog-transport-tls-04.txt >> >> Hi, >> >> Below is the first draft for the shepherding document for >> draft-ietf-syslog-transport-tls-04.txt. Please review and >> send feedback >> to the list. >> >> All of this is pending final reviews of the latest document submitted. >> >> === >> Having passed a WG Last Call, >> draft-ietf-syslog-transport-tls-04.txt is >> ready for AD review. >> >> [Area] SECURITY >> [WG] syslog >> [I-D] draft-ietf-syslog-transport-tls-04.txt >> [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt >> [Shep] Chris Lonvick >> >> === >> (1.a) Who is the Document Shepherd for this document? Has the >> Document Shepherd personally reviewed this version of the >> document and, in particular, does he or she believe this >> version is ready for forwarding to the IESG for >> publication? >> Chris Lonvick >> Yes; I believe that the document is ready for publication. >> === >> (1.b) Has the document had adequate review both from key >> WG members >> and from key non-WG members? Does the Document >> Shepherd have >> any concerns about the depth or breadth of the reviews that >> have been performed? >> >> Adequate review has occurred from WG members, and it has been reviewed >> by others. The reviews of the WG Last Call for this document (-03 >> version) may be found here: >> >> Bert Wijnen's review (not a member of the WG mailing list) >> http://www1.ietf.org/mail-archive/web/syslog/current/msg01244.html >> >> John Calcote's review >> http://www1.ietf.org/mail-archive/web/syslog/current/msg01199.html >> >> Other reviews of particular sections and concepts fill the WG mailing >> list. Of note is Eric Rescorla's review (of -02) >> http://www1.ietf.org/mail-archive/web/syslog/current/msg01100.html >> >> The issues raised in these reviews have been discussed on the mailing >> list and I am satisfied about the level of review. >> === >> (1.c) Does the Document Shepherd have concerns that the document >> needs more review from a particular or broader perspective, >> e.g., security, operational complexity, someone >> familiar with >> AAA, internationalization or XML? >> >> I have no concerns. >> === >> (1.d) Does the Document Shepherd have any specific concerns or >> issues with this document that the Responsible >> Area Director >> and/or the IESG should be aware of? For example, >> perhaps he >> or she is uncomfortable with certain parts of the >> document, or >> has concerns whether there really is a need for it. In any >> event, if the WG has discussed those issues and >> has indicated >> that it still wishes to advance the document, detail those >> concerns here. >> >> There are no concerns about the technical merit of the document. >> === >> (1.e) How solid is the WG consensus behind this >> document? Does it >> represent the strong concurrence of a few individuals, with >> others being silent, or does the WG as a whole >> understand and >> agree with it? >> >> There is strong consensus to publish this document. >> === >> (1.f) Has anyone threatened an appeal or otherwise >> indicated extreme >> discontent? If so, please summarise the areas of >> conflict in >> separate email messages to the Responsible Area >> Director. (It >> should be in a separate email because this questionnaire is >> entered into the ID Tracker.) >> >> No appeals have been threatened. >> === >> (1.g) Has the Document Shepherd personally verified that the >> document satisfies all ID nits? (See >> http://www.ietf.org/ID-Checklist.html and >> http://tools.ietf.org/tools/idnits/). Boilerplate >> checks are >> not enough; this check needs to be thorough. Has >> the document >> met all formal review criteria it needs to, such as the MIB >> Doctor, media type and URI type reviews? >> >> XXX - Let's see what --04 looks like - XXX >> === >> (1.h) Has the document split its references into normative and >> informative? Are there normative references to >> documents that >> are not ready for advancement or are otherwise in >> an unclear >> state? If such normative references exist, what is the >> strategy for their completion? Are there >> normative references >> that are downward references, as described in >> [RFC3967]? If >> so, list these downward references to support the Area >> Director in the Last Call procedure for them [RFC3967]. >> >> The references are split into normative and informational references. >> The document is dependant upon draft-ietf-syslog-transport-udp-08.txt >> and draft-ietf-syslog-protocol-18.txt which are being submitted >> along with this document. > > > It is not dependent on draft-ietf-syslog-transport-udp-08.txt. I suggest > you remove that dependency. -protocol is dependent on both tranports, > but the transport so far only depend on -protocol. Will do. > >> === >> (1.i) Has the Document Shepherd verified that the document IANA >> consideration section exists and is consistent >> with the body >> of the document? If the document specifies protocol >> extensions, are reservations requested in appropriate IANA >> registries? Are the IANA registries clearly >> identified? If >> the document creates a new registry, does it define the >> proposed initial contents of the registry and an allocation >> procedure for future registrations? Does it suggested a >> reasonable name for the new registry? See >> [I-D.narten-iana-considerations-rfc2434bis]. If >> the document >> describes an Expert Review process has Shepherd >> conferred with >> the Responsible Area Director so that the IESG can >> appoint the >> needed Expert during the IESG Evaluation? >> >> The document IANA section is complete and the requested registries are >> clearly marked. > > The registry name as required by > I-D.narten-iana-considerations-rfc2434bis is not yet present. Noted. That can be changed in AUTH48 if we have no other changes. > >> === >> (1.j) Has the Document Shepherd verified that sections of the >> document that are written in a formal language, such as XML >> code, BNF rules, MIB definitions, etc., validate >> correctly in >> an automated checker? >> >> The ABNF in the document has been verified through >> http://www.apps.ietf.org/abnf.html >> === >> (1.k) The IESG approval announcement includes a Document >> Announcement Write-Up. Please provide such a Document >> Announcement Writeup? Recent examples can be found in the >> "Action" announcements for approved documents. >> The approval >> announcement contains the following sections: >> >> Technical Summary >> Relevant content can frequently be found in the abstract >> and/or introduction of the document. If not, >> this may be >> an indication that there are deficiencies in >> the abstract >> or introduction. >> >> 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. >> >> Working Group Summary >> Was there anything in WG process that is worth >> noting? For >> example, was there controversy about particular >> points or >> were there decisions where the consensus was >> particularly >> rough? >> >> There was controversy around the IPR statement from Huawei from this >> document. The Working Group examined the issue and came to >> consensus that >> the statement would be accepted. >> >> There was controversy around the use of a version number within the >> payload. Since this implementation is close to the >> fire&forget model of >> traditional syslog/udp, no signalling of errors from the >> receiver will >> occur. There was a concern on the mailing list that if the method of >> inserting the payload into the transport were to change in >> the future, the >> recipient may not be able to parse the information. Hence >> the WG decided >> upon a version number at the start of the payload. The WG >> consensus at >> this time is to have a version number as a field in the payload. > > I did have the impression that removal of the version number was > consensus. Today, I learnt we didn't actaully discuss this. I can life > with and without version number. I'd happily accept a chair decision. > However, if we stick with the version number, I think we must look into > the mechanism on what to do when the receiver does not accept it (see my > review from earlier today). > I'm still looking at the recent comments on that. >> >> There was some controversy around the use of a special >> character to denote >> the end of the payload, or a counter at the start of the payload to >> indicate the length of the payload. The Working Group has >> consent that a >> counter is the best mechanism. >> >> >> Document Quality >> Are there existing implementations of the >> protocol? Have a >> significant number of vendors indicated their plan to >> implement the specification? Are there any >> reviewers that >> merit special mention as having done a thorough review, >> e.g., one that resulted in important changes or a >> conclusion that the document had no substantive >> issues? If >> there was a MIB Doctor, Media Type or other >> expert review, >> what was its course (briefly)? In the case of >> a Media Type >> review, on what date was the request posted? >> >> This protocol has very similar characteristics to implementations of >> syslog over ssl that are available at this time. The author of that >> implementation has indicated that he will make changes to >> conform to this >> specification. > > I am not sure if we can really say this. True, both use syslog over ssl > and the overall idea is exactly the same. The details, however, differ > greatly. Currently existing syslog/ssl uses octet-stuffing for framing > (LF inserted as end of record marker) while -transport-tls utilizes > octet-counting. While this is a small difference in design, it will make > existing implementations and -transport-tls implementations > non-interoperable. On the other hand, it should be extremely easy to > adopt existing code to the new way of doing things (even concurrently to > existing practice). Maybe this is worth noting. I'll change the text to be: This protocol has very similar characteristics to implementations of syslog over ssl that are available at this time. Members of the Working Group have noted that it should be a very small change to bring those implementations in line with this specification. > >> No vendors have announced that they will utilize this protocol. Some >> vendors have indicated interest in supporting this document. >> The above named reviewers did an outstanding and thorough job. >> >> >> Personnel >> Who is the Document Shepherd for this document? >> Who is the >> Responsible Area Director? >> [Area] SECURITY >> [WG] syslog >> [I-D] draft-ietf-syslog-transport-tls-04v.txt >> [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt >> [Shep] Chris Lonvick >> [AD] Sam Hartman >> === >> >> Thanks, >> Chris >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 09:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtKU-0004DR-8Q; Wed, 22 Nov 2006 09:44:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtKT-0004DK-Ke for syslog@ietf.org; Wed, 22 Nov 2006 09:44:01 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmtKS-0001W3-Bs for syslog@ietf.org; Wed, 22 Nov 2006 09:44:01 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 9EBDA27C011; Wed, 22 Nov 2006 15:48:07 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18975-07; Wed, 22 Nov 2006 15:48:07 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id C2ABF27C010; Wed, 22 Nov 2006 15:48:06 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 15:43:56 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Draft Shepherding document fordraft-ietf-syslog-transport-tls-04.txt Date: Wed, 22 Nov 2006 15:43:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8666@grfint2.intern.adiscon.com> In-Reply-To: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Draft Shepherding document fordraft-ietf-syslog-transport-tls-04.txt thread-index: AccOQzWIRpJok06rQSKW1buDNUC6SgAAVC6w From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 22 Nov 2006 14:43:56.0708 (UTC) FILETIME=[A3816640:01C70E44] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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, > This protocol has very similar characteristics to implementations of=20 > syslog over ssl that are available at this time. Members of=20 > the Working=20 > Group have noted that it should be a very small change to bring those=20 > implementations in line with this specification. from my perspective, that text is excellent. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 10:28:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmu1U-0001Ew-RA; Wed, 22 Nov 2006 10:28:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmu1T-0001Ef-J1 for syslog@ietf.org; Wed, 22 Nov 2006 10:28:27 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmu1P-0006EC-5v for syslog@ietf.org; Wed, 22 Nov 2006 10:28:27 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 9FBBA27C011; Wed, 22 Nov 2006 16:32:25 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19815-10; Wed, 22 Nov 2006 16:32:25 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 1F3A427C010; Wed, 22 Nov 2006 16:32:25 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 16:28:14 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Draft Shepherding document fordraft-ietf-syslog-protocol-18.txt Date: Wed, 22 Nov 2006 16:28:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8669@grfint2.intern.adiscon.com> In-Reply-To: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Draft Shepherding document fordraft-ietf-syslog-protocol-18.txt thread-index: AccOQlfJYPLR1tK2Q8+q3HU19FwB6wAB4Byw From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 22 Nov 2006 15:28:15.0001 (UTC) FILETIME=[D3F8B890:01C70E4A] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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, > Document Quality > Are there existing implementations of the=20 > protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any=20 > reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive=20 > issues? If > there was a MIB Doctor, Media Type or other=20 > expert review, > what was its course (briefly)? In the case of=20 > a Media Type > review, on what date was the request posted? >=20 > No one has come forth to claim that they have an existing=20 > implementation=20 > of this protocol at this time. > No vendors have announced that they will utilize this protocol. Some=20 > vendors have indicated interest in supporting this document. > The above named reviewers did an outstanding and thorough job. Though not a major application, I have implemented syslog-protocol-15 in rsyslog. Please see: http://www.rsyslog.com/index.php?module=3DStatic_Docs&func=3Dview&f=3D/sy= slog- protocol.html at least, it is open source and other can have a look at it. I plan to update the implementation as soon as I have the impression the draft will move on without any futher changes or discussion. -transport-tls is not yet implemented but will probably happen within the same timeframe (also based on the impression that there won't be any major change). Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 20:25:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn3KG-0007fm-UQ; Wed, 22 Nov 2006 20:24:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn3KG-0007dV-1Q for syslog@ietf.org; Wed, 22 Nov 2006 20:24:28 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn3KE-0005Vt-Ay for syslog@ietf.org; Wed, 22 Nov 2006 20:24:28 -0500 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 <0J9500B2QT7GK3@szxga03-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 09:23:40 +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 <0J950091FT7FQ6@szxga03-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 09:23:40 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J95007UDT7C95@szxml04-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 09:23:39 +0800 (CST) Date: Thu, 23 Nov 2006 09:23:35 +0800 From: Miao Fuyou Subject: RE: [Syslog] Updated Syslog-tls Document In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA1F864B@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' Message-id: <00ab01c70e9d$ff7b3f30$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccODdyUqkyu75CgS2e3aMTZWM0f4gABtZngAACdV5AAAffgQAAfbqUw X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > > The public messege can be found at: > > http://www1.ietf.org/mail-archive/web/syslog/current/msg01273.html > > > > It seems there was a rough concensus that the version number was > > welcomed to save port resource when we discussed this issue on the > > mailing list. That is the reason why a version number is there. > > Agreed, I am guilty of not saying "I agree" on the mailing > list. But to me that did not look like consensus but simply > an overlooked message (there were no responses at all...). > Don't feel guilty because you did say "I applaude":-) http://www1.ietf.org/mail-archive/web/syslog/current/msg01198.html I also found support from other active WG members. Anyway, let's reconsider the decision and make it right! > Rainer > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 22 21:43:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn4XR-00024M-PP; Wed, 22 Nov 2006 21:42:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn4XP-00024H-N9 for syslog@ietf.org; Wed, 22 Nov 2006 21:42:08 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn4XN-0005HO-0u for syslog@ietf.org; Wed, 22 Nov 2006 21:42:07 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J950082ZWMWZX@szxga01-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 10:37:44 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9500KX6WMVBP@szxga01-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 10:37:44 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J950071KWMR8G@szxml03-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 10:37:43 +0800 (CST) Date: Thu, 23 Nov 2006 10:37:39 +0800 From: Miao Fuyou Subject: RE: [Syslog] Updated Syslog-tls Document In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA1F864A@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' , syslog@ietf.org Message-id: <00ac01c70ea8$5824a680$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccN00y0qV2GLbfNQWeHwgDicYI+RAAQ2VagACHUuVA= X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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, Thanks for your thorough review! Some responses are inline. > ------------------------------------- > 3.0 > == > The security service is also applicable to BSD Syslog defined in > RFC3164 [7]. But, it is not ensured that the protocol > specification > defined in this document is applicable to BSD Syslog. > == > > Do we really intend to support RFC 3164-style syslog (read: > nothing known about the message format) over this transport? > If so, the consequence is that implementations of > -transport-tls must check for > 3164 format and eventually be able to handle it. > > I suggest removing these two sentence, as it looks we > encourage that case. If they stay, we should clearly state > that a receiver is NOT REQUIRED to implement this. > Agreed. More comments from WG is welcome! > ------------------------------------- > Section 4.3, inside the ABNF: > > > SP = " " > > I think this is problematic in respect to 2.4 of RFC 4234. I > suggest replacing by > > SP = %d32 > I checked the ABNF with: http://rtg.ietf.org/~fenner/abnf.cgi It seems the tools suggest to use " " rather than %d32. I checked RFC4234, it says that it permits the specification of literal text strings directly, enclosed in quotation-marks. I will changed it back to %d32 to keep it consitent with the syslog protocol. > ------------------------------------- > 5.1 > > == > When confidentiality is a concern, a sender/relay MUST authenticate > the receiver to make sure it is talking to the right peer. > == > > I do not find the MUST is appropriate here: "when > confidentiality is a concern" is not a hard fact. What does > it mean? When MUST I implement authentication. Is my > Implementation not compliant to this doc if I have the wrong > understanding of "when confidentiality is a concern". Or MUST > I always implement it, because confidentiality is probably > very often a concern? > > I think this is a operator-issue not to be dealt with in the > protocol. I suggest dropping this sentence or at last spell > MUST in lower case. > Probably lower case. The point is confidentility is meaningless without authenticaion. > ------------------------------------- > 5.2 > Isn't that a security consideration (and belongs to that secition)? > RFC3552 request the residual risk should be descripted in the security consideration section. The section is about residual risk of generic certificate. > ------------------------------------- > 6.2 > IANA registry names must be suggested (of course this comment > is irrelevant if we drop VERSION). > > ------------------------------------- > Consistent Spelling > Both version and VERSION is used for the respectively-named > field. I suggest to resort to a single spelling. This also > removes some ambiguities if the version field or the concept > of a version is meant in some parts of the text. I suggest > using VERSION consistently for the respective field. > Agreed. > ------------------------------------- > "Security Considerations" is missing > I wonder I didn't spot this earlier. IMHO any document must > have a "Security Considerations" section. Of course, the > whole document talks about security, but does that obsolete > the section showing the weaknesses of the protocol? > Section 5 is Security Consideration, but maybe I should add a S to it (Security Considerations):-) > For example, I have at least three candiates to be included: > > - Problems in relay scenario > A relay may receive data via traditional syslog and forward > it via a tls-encrypted channel to its next destination. In > this case, the channel to the next hop is secured, but the > trust level of the message is considerably lower. > > - there is no rule that a sender must use the same host name > inside the -protocol HOSTNAME field as it uses in the > certificate's common name. I think that has some security > implications. > TLS transport does not check HOSTNAME in syslog message because transport must not depend on content of the payload (or else a relay must check the content of each message). > - cipher suites and such are left to the operator. We should > indicate the (serious) consequences of this selection > > --------------------------------------------- > One note on the cipher suites: > I know there has been some discussion previously, but I > wasn't able to find the post in question in the archive. > Probably you can help me out. > > Question: how do we guarantee a minimum interoperability of > implementations of this document if we do not specify any > cipher suite? > Tom and I discussed this issue on the mailing list. TLS protocol has its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS specification says that if application profile(syslog-tls in this case) does not specify a mandatory cipher suite, TLS mandatory suite will apply. So, no need to specify one in this specification. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 23 01:04:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn7gd-0004U9-Kt; Thu, 23 Nov 2006 01:03:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn7gb-0004Tt-10 for syslog@ietf.org; Thu, 23 Nov 2006 01:03:49 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn7gS-0005d7-5s for syslog@ietf.org; Thu, 23 Nov 2006 01:03:49 -0500 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 <0J9600LCE64Q5V@szxga03-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 14:02:51 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J960079T64Q8H@szxga03-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 14:02:50 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J960076P64MTV@szxml03-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 14:02:50 +0800 (CST) Date: Thu, 23 Nov 2006 14:02:46 +0800 From: Miao Fuyou Subject: RE: [Syslog] Draft Shepherding documentfordraft-ietf-syslog-protocol-18.txt In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA1F8669@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' , 'Chris Lonvick' Message-id: <00b701c70ec4$ff8b5a10$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccOQlfJYPLR1tK2Q8+q3HU19FwB6wAB4BywAB6nLYA= X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Some implementation information about syslog-tls: I asked some graduate students in an university to implement the specification. The implementation is based on openssl and rsyslog. The implementation was finished on October and proved it works. The implementation implemented version number and use "user_canceled" TLS alert to indicate a unsupported version number. > === > Having passed a WG Last Call, > draft-ietf-syslog-transport-tls-04.txt is ready for AD review. > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Wednesday, November 22, 2006 11:28 PM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: RE: [Syslog] Draft Shepherding > documentfordraft-ietf-syslog-protocol-18.txt > > Chris, > > > Document Quality > > Are there existing implementations of the protocol? > > Have a > > significant number of vendors indicated their plan to > > implement the specification? Are there any reviewers > > that > > merit special mention as having done a > thorough review, > > e.g., one that resulted in important changes or a > > conclusion that the document had no > substantive issues? > > If > > there was a MIB Doctor, Media Type or other expert > > review, > > what was its course (briefly)? In the case > of a Media > > Type > > review, on what date was the request posted? > > > > No one has come forth to claim that they have an existing > > implementation of this protocol at this time. > > No vendors have announced that they will utilize this > protocol. Some > > vendors have indicated interest in supporting this document. > > The above named reviewers did an outstanding and thorough job. > > Though not a major application, I have implemented > syslog-protocol-15 in rsyslog. Please see: > > http://www.rsyslog.com/index.php?module=Static_Docs&func=view& > f=/syslog- > protocol.html > > at least, it is open source and other can have a look at it. > I plan to update the implementation as soon as I have the > impression the draft will move on without any futher changes > or discussion. > > -transport-tls is not yet implemented but will probably > happen within the same timeframe (also based on the > impression that there won't be any major change). > > 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 Thu Nov 23 02:25:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn8wW-00084f-FQ; Thu, 23 Nov 2006 02:24:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn8wU-00083s-Rm for syslog@ietf.org; Thu, 23 Nov 2006 02:24:18 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn8wT-0002jO-DM for syslog@ietf.org; Thu, 23 Nov 2006 02:24:18 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id B321827C012; Thu, 23 Nov 2006 08:28:22 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05714-09; Thu, 23 Nov 2006 08:28:22 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 0DD7427C011; Thu, 23 Nov 2006 08:28:21 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 08:24:14 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Updated Syslog-tls Document MIME-Version: 1.0 Date: Thu, 23 Nov 2006 08:24:07 +0100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F867D@grfint2.intern.adiscon.com> In-Reply-To: <00ab01c70e9d$ff7b3f30$800c6f0a@china.huawei.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Updated Syslog-tls Document thread-index: AccODdyUqkyu75CgS2e3aMTZWM0f4gABtZngAACdV5AAAffgQAAfbqUwAAzQa7A= From: "Rainer Gerhards" To: "Miao Fuyou" X-OriginalArrivalTime: 23 Nov 2006 07:24:14.0081 (UTC) FILETIME=[60A5BF10:01C70ED0] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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,=20 > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Thursday, November 23, 2006 2:24 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] Updated Syslog-tls Document >=20 >=20 > > > The public messege can be found at: > > > http://www1.ietf.org/mail-archive/web/syslog/current/msg01273.html > > >=20 > > > It seems there was a rough concensus that the version number was=20 > > > welcomed to save port resource when we discussed this=20 > issue on the=20 > > > mailing list. That is the reason why a version number is there. > >=20 > > Agreed, I am guilty of not saying "I agree" on the mailing=20 > > list. But to me that did not look like consensus but simply=20 > > an overlooked message (there were no responses at all...). > >=20 >=20 > Don't feel guilty because you did say "I applaude":-)=20 > http://www1.ietf.org/mail-archive/web/syslog/current/msg01198.html >=20 > I also found support from other active WG members.=20 Yes, I know I did say that at that time. But the new Argument from Juergen was convincing to me. During the nearly 4 years of -protocol, we have often revised our view based on new arguments and I think this good. > Anyway, let's reconsider the decision and make it right! Good point. It would be helpful if some other WG members could voice an opinion. We are on a thight deadline. There are only very few things for dicsussion in -transport-tls. If we act fast, I am confident Miao will be able to very quickly create a new revision (if necessary). Rainer >=20 > > Rainer > >=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 Nov 23 02:48:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn9JA-0002Ye-O3; Thu, 23 Nov 2006 02:47:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn9JA-0002X1-2o for syslog@ietf.org; Thu, 23 Nov 2006 02:47:44 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn9J8-00068q-Di for syslog@ietf.org; Thu, 23 Nov 2006 02:47:44 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 316BD27C012; Thu, 23 Nov 2006 08:51:48 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07416-04; Thu, 23 Nov 2006 08:51:48 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 537B927C011; Thu, 23 Nov 2006 08:51:46 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 08:47:39 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Updated Syslog-tls Document MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Nov 2006 08:47:34 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F867E@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <00ac01c70ea8$5824a680$800c6f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Updated Syslog-tls Document thread-index: AccN00y0qV2GLbfNQWeHwgDicYI+RAAQ2VagACHUuVAADQ6CgA== From: "Rainer Gerhards" To: "Miao Fuyou" , X-OriginalArrivalTime: 23 Nov 2006 07:47:39.0514 (UTC) FILETIME=[A659CDA0:01C70ED3] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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 Miao, Rainer=20 > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Thursday, November 23, 2006 3:38 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Updated Syslog-tls Document >=20 > Hi, Rainer, >=20 > Thanks for your thorough review! >=20 > Some responses are inline.=20 >=20 > > ------------------------------------- > > 3.0 > > =3D=3D > > The security service is also applicable to BSD Syslog defined in > > RFC3164 [7]. But, it is not ensured that the protocol=20 > > specification > > defined in this document is applicable to BSD Syslog. > > =3D=3D > >=20 > > Do we really intend to support RFC 3164-style syslog (read:=20 > > nothing known about the message format) over this transport?=20 > > If so, the consequence is that implementations of=20 > > -transport-tls must check for > > 3164 format and eventually be able to handle it. > >=20 > > I suggest removing these two sentence, as it looks we=20 > > encourage that case. If they stay, we should clearly state=20 > > that a receiver is NOT REQUIRED to implement this. > >=20 >=20 > Agreed. More comments from WG is welcome! >=20 > > ------------------------------------- > > Section 4.3, inside the ABNF: > >=20 > > > SP =3D " " > >=20 > > I think this is problematic in respect to 2.4 of RFC 4234. I=20 > > suggest replacing by > >=20 > > SP =3D %d32 > >=20 >=20 > I checked the ABNF with: > http://rtg.ietf.org/~fenner/abnf.cgi >=20 > It seems the tools suggest to use " " rather than %d32. I=20 > checked RFC4234, > it says that it permits the specification of literal text=20 > strings directly, > enclosed in quotation-marks.=20 >=20 > I will changed it back to %d32 to keep it consitent with the syslog > protocol.=20 >=20 Interesting. I am using http://www.apps.ietf.org/abnf.html. I will also try the one you used and do an additional verification on -protocol with it. However, I still find that %d32 is more precise than " " and I also have the impression that RFC 4234 recommends that form (but I may be wrong). Bottom line: I am more happy with %d32 (or %x20 as I think all others are in hex in the doc). > > ------------------------------------- > > 5.1 > >=20 > > =3D=3D > > When confidentiality is a concern, a sender/relay MUST=20 > authenticate > > the receiver to make sure it is talking to the right peer. > > =3D=3D > >=20 > > I do not find the MUST is appropriate here: "when=20 > > confidentiality is a concern" is not a hard fact. What does=20 > > it mean? When MUST I implement authentication. Is my=20 > > Implementation not compliant to this doc if I have the wrong=20 > > understanding of "when confidentiality is a concern". Or MUST=20 > > I always implement it, because confidentiality is probably=20 > > very often a concern? > >=20 > > I think this is a operator-issue not to be dealt with in the=20 > > protocol. I suggest dropping this sentence or at last spell=20 > > MUST in lower case. > >=20 >=20 > Probably lower case. The point is confidentility is=20 > meaningless without > authenticaion.=20 Well... maybe it is just a wording issue. Are we actually REQUIREING a sender to authenticate the receiver in all cases? If so, we should state that. My impression so far is that this is something that is optional and at the discretion of the sender or the operator configuring it. If so, we should state that clearly too. As an implementor, I am unsure what to do if I use the above text as a guideline. >=20 > > ------------------------------------- > > 5.2 > > Isn't that a security consideration (and belongs to that secition)? > >=20 >=20 > RFC3552 request the residual risk should be descripted in the security > consideration section. The section is about residual risk of generic > certificate. >=20 see below... > > ------------------------------------- > > 6.2 > > IANA registry names must be suggested (of course this comment=20 > > is irrelevant if we drop VERSION). > >=20 > > ------------------------------------- > > Consistent Spelling > > Both version and VERSION is used for the respectively-named=20 > > field. I suggest to resort to a single spelling. This also=20 > > removes some ambiguities if the version field or the concept=20 > > of a version is meant in some parts of the text. I suggest=20 > > using VERSION consistently for the respective field. > >=20 >=20 > Agreed. >=20 > > ------------------------------------- > > "Security Considerations" is missing > > I wonder I didn't spot this earlier. IMHO any document must=20 > > have a "Security Considerations" section. Of course, the=20 > > whole document talks about security, but does that obsolete=20 > > the section showing the weaknesses of the protocol? > >=20 >=20 > Section 5 is Security Consideration, but maybe I should add a S to it > (Security Considerations):-)=20 (also on 5.2) - I must have been blind. I've gone several time through the document and always overlooked the title of section 5. I am not sure if the additional "s" had helped my ignorance ;) So I think you can disregard my comment. >=20 > > For example, I have at least three candiates to be included: > >=20 > > - Problems in relay scenario > > A relay may receive data via traditional syslog and forward=20 > > it via a tls-encrypted channel to its next destination. In=20 > > this case, the channel to the next hop is secured, but the=20 > > trust level of the message is considerably lower. > >=20 >=20 >=20 > > - there is no rule that a sender must use the same host name=20 > > inside the -protocol HOSTNAME field as it uses in the=20 > > certificate's common name. I think that has some security=20 > > implications. > >=20 >=20 > TLS transport does not check HOSTNAME in syslog message=20 > because transport > must not depend on content of the payload (or else a relay=20 > must check the > content of each message).=20 wouldn't it still be useful to put that information into the security considerations? Would it be useful to add something to the security considerations of -protocol (on the lines of "if the transport provides identification of the sender, a receiver MAY / SHOULD verify the provided HOSTNAME)"? WG comment appreciated. >=20 > > - cipher suites and such are left to the operator. We should=20 > > indicate the (serious) consequences of this selection > >=20 > > --------------------------------------------- > > One note on the cipher suites: > > I know there has been some discussion previously, but I=20 > > wasn't able to find the post in question in the archive.=20 > > Probably you can help me out. > >=20 > > Question: how do we guarantee a minimum interoperability of=20 > > implementations of this document if we do not specify any=20 > > cipher suite? > >=20 >=20 > Tom and I discussed this issue on the mailing list. TLS=20 > protocol has its > mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS=20 > specification says > that if application profile(syslog-tls in this case) does not=20 > specify a > mandatory cipher suite, TLS mandatory suite will apply. So, no need to > specify one in this specification. Ahh... that was the message I did not find in the archive. Thanks for bringing it up again. That obiously solves the interop problem. However, I am still of the view that we should advise operators to use strong suites in the security considerations section. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 23 05:34:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnBtJ-000474-Qx; Thu, 23 Nov 2006 05:33:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnBtJ-00046z-2a for syslog@ietf.org; Thu, 23 Nov 2006 05:33:13 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnBtH-00053F-A3 for syslog@ietf.org; Thu, 23 Nov 2006 05:33:13 -0500 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 <0J9600MN7I9QVD@szxga03-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 18:25:02 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9600DMEI9P7A@szxga03-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 18:25:02 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9600FUSI9M6W@szxml03-in.huawei.com> for syslog@ietf.org; Thu, 23 Nov 2006 18:25:01 +0800 (CST) Date: Thu, 23 Nov 2006 18:24:58 +0800 From: Miao Fuyou Subject: RE: [Syslog] Updated Syslog-tls Document In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA1F867E@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' , syslog@ietf.org Message-id: <00ca01c70ee9$a097cbe0$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccN00y0qV2GLbfNQWeHwgDicYI+RAAQ2VagACHUuVAADQ6CgAAElJTg X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > > Probably lower case. The point is confidentility is meaningless > > without authenticaion. > > Well... maybe it is just a wording issue. Are we actually > REQUIREING a sender to authenticate the receiver in all > cases? If so, we should state that. My impression so far is > that this is something that is optional and at the discretion > of the sender or the operator configuring it. If so, we > should state that clearly too. As an implementor, I am unsure > what to do if I use the above text as a guideline. > It does not define what authentication to use. I will check the text to make sure it expressed this point. > > > > TLS transport does not check HOSTNAME in syslog message because > > transport must not depend on content of the payload (or > else a relay > > must check the content of each message). > > wouldn't it still be useful to put that information into the > security considerations? Would it be useful to add something > to the security considerations of -protocol (on the lines of > "if the transport provides identification of the sender, a > receiver MAY / SHOULD verify the provided HOSTNAME)"? > > WG comment appreciated. I am not sure, but my perception is -transport and -protocol should be as independent to each other as possbile. > > Tom and I discussed this issue on the mailing list. TLS > protocol has > > its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS > > specification says that if application profile(syslog-tls in this > > case) does not specify a mandatory cipher suite, TLS > mandatory suite > > will apply. So, no need to specify one in this specification. > > Ahh... that was the message I did not find in the archive. > Thanks for bringing it up again. That obiously solves the > interop problem. However, I am still of the view that we > should advise operators to use strong suites in the security > considerations section. > Yes, I think TLS also advises the operator strong suites. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 23 12:57:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIoC-0001V1-Fc; Thu, 23 Nov 2006 12:56:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIoA-0001Uw-SP for syslog@ietf.org; Thu, 23 Nov 2006 12:56:22 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnIo8-0008N5-Eq for syslog@ietf.org; Thu, 23 Nov 2006 12:56:22 -0500 Received: from pc6 (1Cust13.tnt30.lnd3.gbr.da.uu.net [62.188.122.13]) by astro.systems.pipex.net (Postfix) with SMTP id DE589E00047C; Thu, 23 Nov 2006 17:56:05 +0000 (GMT) Message-ID: <001601c70f20$4d49c9c0$0601a8c0@pc6> From: "tom.petch" To: "Rainer Gerhards" , "Miao Fuyou" , References: <577465F99B41C842AAFBE9ED71E70ABA1F867E@grfint2.intern.adiscon.com> Subject: Ciphersuites Re: [Syslog] Updated Syslog-tls Document Date: Thu, 23 Nov 2006 17:56:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Miao Fuyou" ; Sent: Thursday, November 23, 2006 8:47 AM Subject: RE: [Syslog] Updated Syslog-tls Document Hi Miao, Rainer > > > - cipher suites and such are left to the operator. We should > > indicate the (serious) consequences of this selection > > > > --------------------------------------------- > > One note on the cipher suites: > > I know there has been some discussion previously, but I > > wasn't able to find the post in question in the archive. > > Probably you can help me out. > > > > Question: how do we guarantee a minimum interoperability of > > implementations of this document if we do not specify any > > cipher suite? > > > > Tom and I discussed this issue on the mailing list. TLS > protocol has its > mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS > specification says > that if application profile(syslog-tls in this case) does not > specify a > mandatory cipher suite, TLS mandatory suite will apply. So, no need to > specify one in this specification. Ahh... that was the message I did not find in the archive. Thanks for bringing it up again. That obiously solves the interop problem. However, I am still of the view that we should advise operators to use strong suites in the security considerations section. I raised it because I wanted a cipher suite spelt out in the I-D rather then leaving it as an exercise in ingenuity for the reader to find where it is specified. The pro and con of not specifying it in our I-D is that as the views in the security community change (and some would regard the default as too weak - eg US government) so the mandatory to implement is changed for us without us noticing. Tom Petch ___ ____________________________________________ 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 Nov 23 22:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRMw-0000bT-SO; Thu, 23 Nov 2006 22:04:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnRMv-0000bL-Ai for syslog@ietf.org; Thu, 23 Nov 2006 22:04:49 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnRMo-0004Eb-JV for syslog@ietf.org; Thu, 23 Nov 2006 22:04:49 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J97006XZSICSM@szxga02-in.huawei.com> for syslog@ietf.org; Fri, 24 Nov 2006 11:03:49 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9700DX8SIC3M@szxga02-in.huawei.com> for syslog@ietf.org; Fri, 24 Nov 2006 11:03:48 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9700HKASI8O7@szxml04-in.huawei.com> for syslog@ietf.org; Fri, 24 Nov 2006 11:03:48 +0800 (CST) Date: Fri, 24 Nov 2006 11:03:43 +0800 From: Miao Fuyou Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document In-reply-to: <001601c70f20$4d49c9c0$0601a8c0@pc6> To: "'tom.petch'" , 'Rainer Gerhards' , syslog@ietf.org Message-id: <001601c70f75$2718de80$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccPKLQ3t+vVVOaETp+wrkYE6EjMFgAScKIA X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org My observation about ciphersuite: 1, TLS wg can do a better job on ciphersuite selection than a profile developer. 2, TLS specification will be updated if the mandatory cipher is too weak to provide appropriate protection, but profile-specific suite may not be updated accordingly. 3, Before TLS mandate a stronger cipher suite, TLS_RSA_WITH_3DES_EDE_CBC_SHA is strong enough for most syslog application. If a operator want a stronger cipher suite for highly sensitive syslog application, he still has the freedom to specify one, mandatory cipher suite is only MUST to implementer rather than operator. So, my view is ciphersuite is not neccessary to be defined in this specification, and it is not good to specify in this specification. Thanks, Miao > > > > Tom and I discussed this issue on the mailing list. TLS > protocol has > > its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS > > specification says that if application profile(syslog-tls in this > > case) does not specify a mandatory cipher suite, TLS > mandatory suite > > will apply. So, no need to specify one in this specification. > > Ahh... that was the message I did not find in the archive. > Thanks for bringing it up again. That obiously solves the > interop problem. However, I am still of the view that we > should advise operators to use strong suites in the security > considerations section. > > > > I raised it because I wanted a cipher suite spelt out in the > I-D rather then leaving it as an exercise in ingenuity for > the reader to find where it is specified. The pro and con of > not specifying it in our I-D is that as the views in the > security community change (and some would regard the default > as too weak - eg US government) so the mandatory to implement > is changed for us without us noticing. > > Tom Petch > > ___ _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 24 02:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnVIJ-0000pA-Dd; Fri, 24 Nov 2006 02:16:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnVII-0000p5-Ma for syslog@ietf.org; Fri, 24 Nov 2006 02:16:18 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnVIH-00077r-8d for syslog@ietf.org; Fri, 24 Nov 2006 02:16:18 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 013A027C012; Fri, 24 Nov 2006 08:20:09 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09244-08; Fri, 24 Nov 2006 08:20:08 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id AE21B27C011; Fri, 24 Nov 2006 08:20:08 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 08:16:05 +0100 Content-class: urn:content-classes:message Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Nov 2006 08:15:59 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F86A5@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <001601c70f75$2718de80$800c6f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ciphersuites Re: [Syslog] Updated Syslog-tls Document thread-index: AccPKLQ3t+vVVOaETp+wrkYE6EjMFgAScKIAAAlsiiA= From: "Rainer Gerhards" To: "Miao Fuyou" , "tom.petch" , X-OriginalArrivalTime: 24 Nov 2006 07:16:05.0263 (UTC) FILETIME=[67B3C9F0:01C70F98] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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, Miao, might it be a compromise to add a sentence to -transport-tls that tells an implementor to look for mandatory to implement suites inside the TLS document. Something like "Minimum Interoperability between different implementations of this specification is achieved via the mandatory to implement cipher suites specified in ." That would be a reminder that might be helpful. Rainer > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Friday, November 24, 2006 4:04 AM > To: 'tom.petch'; Rainer Gerhards; syslog@ietf.org > Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document >=20 > =20 > My observation about ciphersuite: > 1, TLS wg can do a better job on ciphersuite selection than a profile > developer.=20 > 2, TLS specification will be updated if the mandatory cipher=20 > is too weak to > provide appropriate protection, but profile-specific suite may not be > updated accordingly.=20 > 3, Before TLS mandate a stronger cipher suite,=20 > TLS_RSA_WITH_3DES_EDE_CBC_SHA > is strong enough for most syslog application. If a operator=20 > want a stronger > cipher suite for highly sensitive syslog application, he still has the > freedom to specify one, mandatory cipher suite is only MUST=20 > to implementer > rather than operator.=20 >=20 > So, my view is ciphersuite is not neccessary to be defined in this > specification, and it is not good to specify in this specification.=20 >=20 > Thanks, > Miao > > > > > > Tom and I discussed this issue on the mailing list. TLS=20 > > protocol has=20 > > > its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS=20 > > > specification says that if application profile(syslog-tls in this=20 > > > case) does not specify a mandatory cipher suite, TLS=20 > > mandatory suite=20 > > > will apply. So, no need to specify one in this specification. > >=20 > > Ahh... that was the message I did not find in the archive.=20 > > Thanks for bringing it up again. That obiously solves the=20 > > interop problem. However, I am still of the view that we=20 > > should advise operators to use strong suites in the security=20 > > considerations section. > >=20 > > > >=20 > > I raised it because I wanted a cipher suite spelt out in the=20 > > I-D rather then leaving it as an exercise in ingenuity for=20 > > the reader to find where it is specified. The pro and con of=20 > > not specifying it in our I-D is that as the views in the=20 > > security community change (and some would regard the default=20 > > as too weak - eg US government) so the mandatory to implement=20 > > is changed for us without us noticing. > >=20 > > Tom Petch > >=20 > > ___ >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From cjyoujsd@yahoo.com.cn Sat Nov 25 03:38:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnt39-0002Lx-Vw for SYSLOG-ARCHIVE@LISTS.IETF.ORG; Sat, 25 Nov 2006 03:38:15 -0500 Received: from [221.210.36.105] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gnt33-00055s-LN for SYSLOG-ARCHIVE@LISTS.IETF.ORG; Sat, 25 Nov 2006 03:38:15 -0500 Received: from njmktg4 (unknown [72.250.175.20]) by smtp65 (Coremail) with SMTP id 01jZzrRfTf8xi3SS.1 for ; Sat, 25 Nov 2006 16:38:08 +0800 (CST) X-Originating-IP: [72.250.175.20] Subject: =?iso-2022-jp?B?GyRCIVo9RU1XIVslNSE8JVMlOSROJDRNeE1RMEZGYhsoQg==?= From: =?shift-jis?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C705C8.29FCA610" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C705C8.29FCA610 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCISEiI0V2JTUlJCVIJE4ycTB3RVBPPyEmJDQwRkZiJEckOSIjGyhCDQobJEIiTSEhGyhCaHR0 cDovL3ZpZm4uY29tLz9oYXJ1MjEyDQoNChskQiIhRXYlNSUkJUgkRyRPISIycTB3RVBPPzt+JEsh WkVQTz9OQSFbJF4kPyRPIVpHLzJxSHEhW0V5JE4bKEINChskQiEhTkE2YkBBNWEkTzBsQFokNyRG JCokaiReJDskcyEjGyhCDQobJEIiITQwQTRMNU5BJEckNE14TVFEOiQxJF4kORsoQg0KGyRCIiEk NE14TVE7fiRPTXhNUTUsTHMkciRoJC8kKkZJJF8yPCQ1JCQhIxsoQg0KDQobJEIiKCMxIzg6UEwk S34kTkp9JE5FUE8/ISZNeE1RJE8wbEBaJCpDRyRqJDckRiQkJF4kOSIoGyhCDQobJEIhISEhISEb KEJodHRwOi8vdmlmbi5jb20vP2hhcnUyMTINCg0KGyRCISEwQj80JDckRiQ0TXhNUSQ3JEZEOiQx JGskaCQmISIbKEIyNBskQjt+NFZCUDF+ISZFMERsNElNfRsoQg0KGyRCISEhISEhSVRMQCRKRUAk LCQiJGokXiQ3JD8kaSQqNSQ3WiRLJCpMZCQkOWckbyQ7MjwkNSQkGyhCDQoNCg0KGyRCISEhIUdb Py5JVE1XJE8kMyRBJGlLeCIqISEbKEJpbmZvbWFpbEB3d3cuaHJiYWMubmV0DQoNChskQiEhISEb KEJVc2VsZXNzbmVzcyB0byBzZXJ2ZRskQiIqISEbKEJpbmZvbWFpbEB3d3cuaHJiYWMubmV0DQoN Cg== ------=_NextPart_000_0006_01C705C8.29FCA610 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9 Mj4NCjxESVY+PEZPTlQgc2l6ZT0zPhskQiEhIiNFdiU1JSQlSCROMnEwd0VQTz8hJiQ0MEZGYiRH JDkiIxsoQjxCUj4bJEIiTSEhGyhCPC9GT05UPjxGT05UIHNpemU9Mz48QSANCmhyZWY9Imh0dHA6 Ly92aWZuLmNvbS8/aGFydTIxMiI+aHR0cDovL3ZpZm4uY29tLz9oYXJ1MjEyPC9BPjwvRk9OVD48 Rk9OVCANCnNpemU9Mz48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mz48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIA0Kc2l6ZT0zPhskQiIhRXYlNSUkJUgkRyRPISIycTB3RVBP Pzt+JEshWkVQTz9OQSFbJF4kPyRPIVpHLzJxSHEhW0V5JE4bKEI8QlI+GyRCISFOQTZiQEE1YSRP MGxAWiQ3JEYkKiRqJF4kOyRzISMbKEI8QlI+GyRCIiE0MEE0TDVOQSRHJDRNeE1RRDokMSReJDkb KEI8QlI+GyRCIiEkNE14TVE7fiRPTXhNUTUsTHMkciRoJC8kKkZJJF8yPCQ1JCQhIxsoQjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0zPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0zPhskQiIoIzEjODpQTCRLfiROSn0kTkVQTz8hJk14TVEkTzBsQFokKkNHJGokNyRG JCQkXiQ5IigbKEI8QlI+GyRCISEhISEhGyhCPEEgDQpocmVmPSJodHRwOi8vdmlmbi5jb20vP2hh cnUyMTIiPmh0dHA6Ly92aWZuLmNvbS8/aGFydTIxMjwvQT48L0ZPTlQ+PEZPTlQgDQpzaXplPTM+ PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTM+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCANCnNpemU9Mz4bJEIhITBCPzQkNyRGJDRNeE1RJDckRkQ6JDEkayRoJCYhIhsoQjI0 GyRCO340VkJQMX4hJkUwRGw0SU19GyhCPEJSPhskQiEhISEhIUlUTEAkSkVAJCwkIiRqJF4kNyQ/ JGkkKjUkN1okSyQqTGQkJDlnJG8kOzI8JDUkJBsoQjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0zPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEJSPhskQiEhISFHWz8uSVRNVyRPJDMk QSRpS3giKiEhGyhCPEEgDQpocmVmPSJtYWlsdG86aW5mb21haWxAd3d3LmhyYmFjLm5ldCI+aW5m b21haWxAd3d3LmhyYmFjLm5ldDwvQT48QSANCmhyZWY9Im1haWx0bzpvZmZpY2VfbmV3c19oaW1p dHN1QHlhaG9vLmNvLmpwIj48L0E+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4bJEIh ISEhGyhCVXNlbGVzc25lc3MgdG8gc2VydmUbJEIiKiEhGyhCPEEgDQpocmVmPSJtYWlsdG86aW5m b21haWxAd3d3LmhyYmFjLm5ldCI+aW5mb21haWxAd3d3LmhyYmFjLm5ldDwvQT48QSANCmhyZWY9 Im1haWx0bzpvZmZpY2VfbmV3c19oaW1pdHN1QHlhaG9vLmNvLmpwIj48L0E+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0006_01C705C8.29FCA610-- From syslog-bounces@lists.ietf.org Sun Nov 26 10:52:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoMHF-00063O-Vy; Sun, 26 Nov 2006 10:50:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoMH3-0005Ue-HM; Sun, 26 Nov 2006 10:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GoMH3-0000r8-62; Sun, 26 Nov 2006 10:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id CF859175A1; Sun, 26 Nov 2006 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GoMGY-00011I-DY; Sun, 26 Nov 2006 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 26 Nov 2006 10:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-udp-08.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 : Transmission of syslog messages over UDP Author(s) : A. Okmianski Filename : draft-ietf-syslog-transport-udp-08.txt Pages : 11 Date : 2006-11-26 This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-08.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-udp-08.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-udp-08.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-11-26091404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-udp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-udp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-26091404.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 Sun Nov 26 10:52:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoMHG-000646-58; Sun, 26 Nov 2006 10:50:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoMH3-0005Up-Ip; Sun, 26 Nov 2006 10:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GoMH3-0000rB-8S; Sun, 26 Nov 2006 10:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id E7A25175A2; Sun, 26 Nov 2006 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GoMGY-00011L-EF; Sun, 26 Nov 2006 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 26 Nov 2006 10:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-04.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --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-04.txt Pages : 11 Date : 2006-11-26 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-04.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-04.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-04.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-11-26091633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-tls-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-tls-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-26091633.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Mon Nov 27 02:07:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoaZR-0002hZ-HG; Mon, 27 Nov 2006 02:06:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoaZP-0002gP-T7 for syslog@ietf.org; Mon, 27 Nov 2006 02:06:27 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoaZO-0008VT-0C for syslog@ietf.org; Mon, 27 Nov 2006 02:06:27 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9D00LDUND8BL@szxga02-in.huawei.com> for syslog@ietf.org; Mon, 27 Nov 2006 14:58:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9D009SWND892@szxga02-in.huawei.com> for syslog@ietf.org; Mon, 27 Nov 2006 14:58:20 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9D0040IND4OY@szxml04-in.huawei.com> for syslog@ietf.org; Mon, 27 Nov 2006 14:58:20 +0800 (CST) Date: Mon, 27 Nov 2006 14:58:16 +0800 From: Miao Fuyou Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA1F86A5@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' , "'tom.petch'" , syslog@ietf.org Message-id: <00f001c711f1$6a0a29f0$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AccPKLQ3t+vVVOaETp+wrkYE6EjMFgAScKIAAAlsiiAAljqyAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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, It looks good. I tend to add some sentences like the one Rainer proposed. Any objection? Thanks, Miao > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Friday, November 24, 2006 3:16 PM > To: Miao Fuyou; tom.petch; syslog@ietf.org > Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document > > Tom, Miao, > > might it be a compromise to add a sentence to -transport-tls > that tells an implementor to look for mandatory to implement > suites inside the TLS document. Something like > > "Minimum Interoperability between different implementations > of this specification is achieved via the mandatory to > implement cipher suites specified in ." > > That would be a reminder that might be helpful. > > Rainer > > > -----Original Message----- > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > Sent: Friday, November 24, 2006 4:04 AM > > To: 'tom.petch'; Rainer Gerhards; syslog@ietf.org > > Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document > > > > > > My observation about ciphersuite: > > 1, TLS wg can do a better job on ciphersuite selection than > a profile > > developer. > > 2, TLS specification will be updated if the mandatory cipher is too > > weak to provide appropriate protection, but > profile-specific suite may > > not be updated accordingly. > > 3, Before TLS mandate a stronger cipher suite, > > TLS_RSA_WITH_3DES_EDE_CBC_SHA is strong enough for most syslog > > application. If a operator want a stronger cipher suite for highly > > sensitive syslog application, he still has the freedom to > specify one, > > mandatory cipher suite is only MUST to implementer rather than > > operator. > > > > So, my view is ciphersuite is not neccessary to be defined in this > > specification, and it is not good to specify in this specification. > > > > Thanks, > > Miao > > > > > > > > Tom and I discussed this issue on the mailing list. TLS > > > protocol has > > > > its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS > > > > specification says that if application > profile(syslog-tls in this > > > > case) does not specify a mandatory cipher suite, TLS > > > mandatory suite > > > > will apply. So, no need to specify one in this specification. > > > > > > Ahh... that was the message I did not find in the archive. > > > Thanks for bringing it up again. That obiously solves the interop > > > problem. However, I am still of the view that we should advise > > > operators to use strong suites in the security considerations > > > section. > > > > > > > > > > > > I raised it because I wanted a cipher suite spelt out in the I-D > > > rather then leaving it as an exercise in ingenuity for > the reader to > > > find where it is specified. The pro and con of not > specifying it in > > > our I-D is that as the views in the security community > change (and > > > some would regard the default as too weak - eg US > government) so the > > > mandatory to implement is changed for us without us noticing. > > > > > > Tom Petch > > > > > > ___ > > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 27 02:47:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GobCg-0004H7-FW; Mon, 27 Nov 2006 02:47:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GobCe-0004H2-7F for syslog@ietf.org; Mon, 27 Nov 2006 02:47:00 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GobCc-0001Xr-Gr for syslog@ietf.org; Mon, 27 Nov 2006 02:47:00 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9D00LD9ORBBL@szxga02-in.huawei.com> for syslog@ietf.org; Mon, 27 Nov 2006 15:28:23 +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 <0J9D0093EORA92@szxga02-in.huawei.com> for syslog@ietf.org; Mon, 27 Nov 2006 15:28:23 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9D00A33OR7V9@szxml03-in.huawei.com> for syslog@ietf.org; Mon, 27 Nov 2006 15:28:22 +0800 (CST) Date: Mon, 27 Nov 2006 15:28:21 +0800 From: Miao Fuyou To: syslog@ietf.org Message-id: <00f101c711f5$9dd462b0$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AccR9Z2A0Z9wtyR+Sq2kxnfnv5088A== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Syslog] Towards closure of syslog-tls issues X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, Unfortunately (or fortunately), there are several issues raised after the chair start shepherding process. As the editor, I would like close the issues as soon as possible, and get the doucment updated. 1, Version. The wg seems have concensus on removing version from the transport mapping this time. If there is a objection, please reply. If no, I would remove it. 2, RFC3164. There is a proposal to remove RFC3164 support from the draft. I tend to accept the proposal. Please comment if you have a different idea! 3, Ciphersuite. Tom proposed to specify cipher suite in the transport document, but I still don't find necessity to do so. I tend to agree to Rainer's proposal: http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html 4, ABNF issues. I will change " " format back to %d format. 5, Receiver authentication when confidentiality is concern, from "MUST" to "must", and probably some more sentences about receiver authentication is required. Please feedback if you have different ideas to the proposals above! Thanks! Regards, Miao _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 27 17:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoobA-0004hv-G0; Mon, 27 Nov 2006 17:05:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goob8-0004hQ-9k for syslog@ietf.org; Mon, 27 Nov 2006 17:05:10 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goob6-0007f9-Uf for syslog@ietf.org; Mon, 27 Nov 2006 17:05:10 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 27 Nov 2006 14:05:08 -0800 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 kARM58xN020777; Mon, 27 Nov 2006 14:05:08 -0800 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 kARM57io008237; Mon, 27 Nov 2006 14:05:07 -0800 (PST) Date: Mon, 27 Nov 2006 14:05:07 -0800 (PST) From: Chris Lonvick To: Miao Fuyou Subject: Re: [Syslog] Towards closure of syslog-tls issues In-Reply-To: <00f101c711f5$9dd462b0$800c6f0a@china.huawei.com> Message-ID: References: <00f101c711f5$9dd462b0$800c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2549; t=1164665108; x=1165529108; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20Towards=20closure=20of=20syslog-tls=20issu es |Sender:=20; bh=OqOdjMVxZ8/024L8Wmjm7Sx3WK0Q3kvhgYs8a2t1rMA=; b=VdhjvWfZt4o3V8haxYv99QY8WeHBaf7xlIyZqwk0aE4N/7DFBhkNNcWkey2XOckUG2Vv6eH0 wFz7WA8LMexAx1J30jtQ0/ZFw5O54eQKaM+qXmSXjnLKbOfdwhkE6FiL; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Miao, On Mon, 27 Nov 2006, Miao Fuyou wrote: > Hi, > > Unfortunately (or fortunately), there are several issues raised after the > chair start shepherding process. As the editor, I would like close the > issues as soon as possible, and get the doucment updated. > > 1, Version. The wg seems have concensus on removing version from the > transport mapping this time. If there is a objection, please reply. If no, I > would remove it. Please remove the version. We have consensus to do this. Tom Petch does raise an important point that I will bring up to our ADs. Essentially, TLS does not have any mechanism to allow for an indication of the contents that it is protecting. This results in the need for separate ports for implementations of foo/TLS and bar/TLS, even to the point of foo.v2/TLS needs a different port from foo.v1/TLS. Both IPsec and SSH (as examples of other secure transports) are able to embed an indication of the payload within the transport protocol and reuse their ports. To that end, even the byte-count is a bit of a problem, but we'll live with that. Remove Section 6.2 as well. > 2, RFC3164. There is a proposal to remove RFC3164 support from the draft. I > tend to accept the proposal. Please comment if you have a different idea! Go ahead and remove that reference. > 3, Ciphersuite. Tom proposed to specify cipher suite in the transport > document, but I still don't find necessity to do so. I tend to agree to > Rainer's proposal: > http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html In addition to that - reference the latest TLS RFC and note that there are updates to that which need to be considered - note that the latest ciphers and their relative strengths may be found in BCP86 - note that implementors and deployers should keep aware of current literature (This should be about 3 sentences.) > 4, ABNF issues. I will change " " format back to %d format. OK > 5, Receiver authentication when confidentiality is concern, from "MUST" to > "must", and probably some more sentences about receiver authentication is > required. OK Please make these changes and submit -05 so we can submit this to the IESG. Thanks, Chris > > Please feedback if you have different ideas to the proposals above! Thanks! > > Regards, > Miao > > > > _______________________________________________ > 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 Nov 27 17:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goobd-00050F-9U; Mon, 27 Nov 2006 17:05:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goobb-0004zH-IP for syslog@ietf.org; Mon, 27 Nov 2006 17:05:39 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoobZ-0007hg-9j for syslog@ietf.org; Mon, 27 Nov 2006 17:05:39 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20061127220536b1200mvt74e>; Mon, 27 Nov 2006 22:05:36 +0000 From: "David Harrington" To: Date: Mon, 27 Nov 2006 17:02:50 -0500 Message-ID: <03e501c7126f$c862b390$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccSb3bKWMC1S6oTTrq1XGOdDB2Muw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Syslog] Updated IPR disclosure X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The syslog WG co-chairs were notified that a request was being made to Huawei by a company experienced in IETF IPR disclosures, that Huawei modify their terms related to the TLS transport document. Huawei has chosen to change their terms as requested. The new terms can be seen at https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=763 The new disclosure is relevant to tls-03. We have requested Huawei to also post an update relevant to tls-04, which was just published. The changes apparently are meant to tighten the language a bit, and to make Huawei terms more consistent with those of other companies filing disclosures within the IETF. The co-chairs are not lawyers, and cannot provide legal advice about the changes. The WG needs to consider whether the modified terms are acceptable for this document to be advanced to the standards-track. Please send your comments to the co-chairs as soon as possible. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 27 17:32:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gop17-0008OI-TE; Mon, 27 Nov 2006 17:32:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gop16-0008LS-Vh for syslog@ietf.org; Mon, 27 Nov 2006 17:32:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gop15-0004Iw-KR for syslog@ietf.org; Mon, 27 Nov 2006 17:32:00 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 27 Nov 2006 14:31:58 -0800 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 kARMVwJi019972; Mon, 27 Nov 2006 14:31:58 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kARMVwip008781; Mon, 27 Nov 2006 14:31:58 -0800 (PST) Date: Mon, 27 Nov 2006 14:31:57 -0800 (PST) From: Chris Lonvick To: David Harrington In-Reply-To: <03e501c7126f$c862b390$0600a8c0@china.huawei.com> Message-ID: References: <03e501c7126f$c862b390$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2122; t=1164666718; x=1165530718; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20Updated=20IPR=20disclosure |Sender:=20; bh=iaW2NHJzz44VJHb1AxvYElYhRg5OGSOhffjoSUkoVqc=; b=Woqn6kyrMN3eSewfTKdXPg2ygcNBWauDY6itU/IIv3RR2ChITOzQvO8Nn9xuUwuWviztAKkd O1TffIhnJPahtN2D03xLhJW3zTvDAiBSOSZqikH6wu80xupwkWXYRKtj; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: syslog@ietf.org Subject: [Syslog] Re: Updated IPR disclosure X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-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, Cisco asked Huawei to make this change. Essentially the prior statement appeared to be similar to the IPR statements made by Cisco and other companies but it had differences that were not acceptable to the Cisco legal team. Hence, Cisco would not have been willing to implement the standard produced. Huawei's legal team looked into this and they have made these changes. The new statement appears to me (as David says, we are not lawyers) to be much closer to the intent of Cisco's, and others, IPR statements. I'm asking Cisco's legal team to review this and I will post Cisco's response when I have that. (Working Group Chair Hat OFF): On behalf of Cisco, I would like to thank Huawei for addressing this issue. I must note once again that the IETF will not make any determination of the validity of any IPR claimed. Huawei has been following the IETF rules on disclosure and statement of terms. Thanks, Chris On Mon, 27 Nov 2006, David Harrington wrote: > Hi, > > The syslog WG co-chairs were notified that a request was being made > to Huawei by a company experienced in IETF IPR disclosures, that > Huawei modify their terms related to the TLS transport document. > Huawei has chosen to change their terms as requested. > > The new terms can be seen at > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=763 > > The new disclosure is relevant to tls-03. We have requested Huawei to > also post an update relevant to tls-04, which was just published. > > The changes apparently are meant to tighten the language a bit, and to > make Huawei terms more consistent with those of other companies filing > disclosures within the IETF. > > The co-chairs are not lawyers, and cannot provide legal advice about > the changes. > > The WG needs to consider whether the modified terms are acceptable for > this document to be advanced to the standards-track. Please send your > comments to the co-chairs as soon as possible. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 27 19:30:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goqqw-00030d-EO; Mon, 27 Nov 2006 19:29:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goqqv-00030V-FF for syslog@ietf.org; Mon, 27 Nov 2006 19:29:37 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goqqu-0000JP-70 for syslog@ietf.org; Mon, 27 Nov 2006 19:29:37 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061128002935b1100snp43e>; Tue, 28 Nov 2006 00:29:35 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , "'Miao Fuyou'" , Subject: RE: [Syslog] Updated Syslog-tls Document Date: Mon, 27 Nov 2006 19:26:50 -0500 Message-ID: <03ff01c71283$e6aa3a80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccN00y0qV2GLbfNQWeHwgDicYI+RAAQ2VagACHUuVAADQ6CgADsE1Hg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F867E@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Thursday, November 23, 2006 2:48 AM > To: Miao Fuyou; syslog@ietf.org > Subject: RE: [Syslog] Updated Syslog-tls Document > > > ------------------------------------- > > > 5.1 > > > > > > == > > > When confidentiality is a concern, a sender/relay MUST > > authenticate > > > the receiver to make sure it is talking to the right peer. > > > == > > > > > > I do not find the MUST is appropriate here: "when > > > confidentiality is a concern" is not a hard fact. What does > > > it mean? When MUST I implement authentication. Is my > > > Implementation not compliant to this doc if I have the wrong > > > understanding of "when confidentiality is a concern". Or MUST > > > I always implement it, because confidentiality is probably > > > very often a concern? > > > > > > I think this is a operator-issue not to be dealt with in the > > > protocol. I suggest dropping this sentence or at last spell > > > MUST in lower case. > > > > > > > Probably lower case. The point is confidentility is > > meaningless without > > authenticaion. > > Well... maybe it is just a wording issue. Are we actually REQUIREING a > sender to authenticate the receiver in all cases? If so, we > should state > that. My impression so far is that this is something that is optional > and at the discretion of the sender or the operator configuring it. If > so, we should state that clearly too. As an implementor, I am unsure > what to do if I use the above text as a guideline. > Standards do not typically require an operator to use the technology in a specific manner; Standards do typically require implementers to implement in a way so that operators CAN configure the technology in the preferred (interoperable) manner. MUST is used when the on-the-wire format/information/etc. must be interoperable for the protocol to work properly. I do not like seeing "must" in a document; either it deserves to be a MUST, i.e. it impacts on-the-wire interoperability, or it is an implementation/usage decision and we should not mandate it. If you use a lower case "must", then you'll need to convince me as co-chair that the usage is justifed before I send it to the IESG. Dbh _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 27 20:06:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GorPl-0005b6-Ro; Mon, 27 Nov 2006 20:05:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GorPk-0005at-V7 for syslog@ietf.org; Mon, 27 Nov 2006 20:05:36 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GorPj-0007VA-NU for syslog@ietf.org; Mon, 27 Nov 2006 20:05:36 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20061128010534b1400s79hve>; Tue, 28 Nov 2006 01:05:35 +0000 From: "David Harrington" To: Date: Mon, 27 Nov 2006 20:02:47 -0500 Message-ID: <040301c71288$edada1a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccSiGpTxvJFaP9bTDqCU6ipCPgYaw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Syslog] Proposed schedule X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Chris and I have discussed the last calls and the status of the documents. We believe the -protocol-, -udp-, and -tls- documents have received adequate review, and are (almost) ready for submission to the IESG. If the WG reaches consensus on the remaining issues, and revisions are published reflecting the consensus, then we plan to submit them for advancement by the end of this week. We believe there have been enough changes to the text of -sign- and -mib- to require an additional last call for these documents. There are a number of reviews that have been performed on these documents, and a number of issues discussed and resolved. Not all requested changes (that the chairs approve as consensus) are reflected in the latest official revisions. We are in discussions with the editors about getting the documents updated so we can take them to WGLC again. We expect -sign- will be republished within the next week or so, and then we will start a WGLC. Assuming no major problems develop, we hope to have a syslog-sign document submitted to the IESG by mid-December. The -mib- document had a number of significant changes, and a number of detailed changes requested, and the chairs have not finished reviewing the document changes versus the requested changes yet. Once we are satisfied the current list of comments has been addressed properly, we will ask Glen to publish a new revision and we will start a WGLC. If all goes well, we may have this done by mid-December, but we accept that it may take as long as late January to complete the document, run another WG last call (in non-holiday weeks), and make adjustments to be ready for submission to the IESG. Good work everybody, and thanks for staying involved to get these documents to completion. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net bcc: the area directors _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 27 20:10:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GorUc-0001oa-42; Mon, 27 Nov 2006 20:10:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GorUb-0001kA-4v for syslog@ietf.org; Mon, 27 Nov 2006 20:10:37 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GorUZ-0008MZ-Tb for syslog@ietf.org; Mon, 27 Nov 2006 20:10:37 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061128011035b1100smpqce>; Tue, 28 Nov 2006 01:10:35 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog] Shepherding document for udp-08 Date: Mon, 27 Nov 2006 20:07:50 -0500 Message-ID: <040401c71289$a0687bd0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccNxikySfyauRdWTgeqq4EjcWrEQgAYs+UAARgXgFA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8659@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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, Yes, I/we should correct this. Do we have any information about vendors that have implemented the current UDP specification? dbh > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Wednesday, November 22, 2006 6:29 AM > To: David Harrington; syslog@ietf.org > Subject: RE: [Syslog] Shepherding document for udp-08 > > David, > > there is one minor thing in the shepherding document I do not concur > with: > > -- > This document describes the traditional udp transport for syslog. > draft-ietf-syslog-protocol makes changes to the syntax of the syslog > fields but this is just the udp transport. It could be said that > all existing implementations of syslog use this specification. > -- > > There are some changes in -transport-udp compared to the traditional > transport. I think it is somewhat dangerous to draw the conclusion > drawn. > > But as I said - this is a minor comment and probably depend's on ones > point of view... > > Rainer > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Wednesday, November 22, 2006 12:41 AM > > To: syslog@ietf.org > > Subject: [Syslog] Shepherding document for udp-08 > > > > Hi, > > > > I have reviewed a pre-publication copy of -08- and am satisifed it > > represents WG consensus and is of a quality sufficient for > advancement > > to Proposed Standard. > > > > Barring serious objection from the WG, revision -08- will > be submitted > > to the IESG for advancement, accompanied by the attached > shepherding > > document. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > co-chair, Syslog WG > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Nov 27 21:09:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosOM-0007tQ-BB; Mon, 27 Nov 2006 21:08:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosOK-0007tA-6O for syslog@ietf.org; Mon, 27 Nov 2006 21:08:12 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GosOI-0001wo-AC for syslog@ietf.org; Mon, 27 Nov 2006 21:08:12 -0500 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 <0J9F00L454KBWW@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 28 Nov 2006 10:07:23 +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 <0J9F000TD4KAU2@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 28 Nov 2006 10:07:23 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9F00CU74K7YU@szxml04-in.huawei.com> for syslog@ietf.org; Tue, 28 Nov 2006 10:07:22 +0800 (CST) Date: Tue, 28 Nov 2006 10:07:19 +0800 From: Miao Fuyou Subject: RE: [Syslog] Updated Syslog-tls Document In-reply-to: <03ff01c71283$e6aa3a80$0600a8c0@china.huawei.com> To: 'David Harrington' , 'Rainer Gerhards' , syslog@ietf.org Message-id: <00ea01c71291$ef25ac90$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccN00y0qV2GLbfNQWeHwgDicYI+RAAQ2VagACHUuVAADQ6CgADsE1HgAANumSA= X-Spam-Score: 0.0 (/) 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 I am changing the sentence to: "For the deployment where confidentiality is a concern, receiver authentication is required for sender/relay to make sure it is talking to the right peer. It is up to the operator to decide whether confidentiality is a concern for a specific deployment. " This sentence serves as a tip for deployer rather than something about on-the-wire protocol. Thanks, Miao > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, November 28, 2006 8:27 AM > To: 'Rainer Gerhards'; 'Miao Fuyou'; syslog@ietf.org > Subject: RE: [Syslog] Updated Syslog-tls Document > > > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Thursday, November 23, 2006 2:48 AM > > To: Miao Fuyou; syslog@ietf.org > > Subject: RE: [Syslog] Updated Syslog-tls Document > > > > ------------------------------------- > > > > 5.1 > > > > > > > > == > > > > When confidentiality is a concern, a sender/relay MUST > > > authenticate > > > > the receiver to make sure it is talking to the right peer. > > > > == > > > > > > > > I do not find the MUST is appropriate here: "when > confidentiality > > > > is a concern" is not a hard fact. What does it mean? > When MUST I > > > > implement authentication. Is my Implementation not compliant to > > > > this doc if I have the wrong understanding of "when > > > > confidentiality is a concern". Or MUST I always implement it, > > > > because confidentiality is probably very often a concern? > > > > > > > > I think this is a operator-issue not to be dealt with in the > > > > protocol. I suggest dropping this sentence or at last > spell MUST > > > > in lower case. > > > > > > > > > > Probably lower case. The point is confidentility is meaningless > > > without authenticaion. > > > > Well... maybe it is just a wording issue. Are we actually REQUIREING > a > > sender to authenticate the receiver in all cases? If so, we should > > state that. My impression so far is that this is something that is > optional > > and at the discretion of the sender or the operator configuring it. > If > > so, we should state that clearly too. As an implementor, I > am unsure > > what to do if I use the above text as a guideline. > > > > Standards do not typically require an operator to use the > technology in a specific manner; Standards do typically > require implementers to implement in a way so that operators > CAN configure the technology in the preferred (interoperable) manner. > > MUST is used when the on-the-wire format/information/etc. > must be interoperable for the protocol to work properly. > > I do not like seeing "must" in a document; either it deserves > to be a MUST, i.e. it impacts on-the-wire interoperability, > or it is an implementation/usage decision and we should not > mandate it. If you use a lower case "must", then you'll need > to convince me as co-chair that the usage is justifed before > I send it to the IESG. > > Dbh > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 28 00:50:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Govqh-00080c-A4; Tue, 28 Nov 2006 00:49:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Govqg-0007zr-40 for syslog@ietf.org; Tue, 28 Nov 2006 00:49:42 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GovpK-0000ZC-Mt for syslog@ietf.org; Tue, 28 Nov 2006 00:48:20 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061128054818b1100sn8o9e>; Tue, 28 Nov 2006 05:48:18 +0000 From: "David Harrington" To: "'Miao Fuyou'" , "'Rainer Gerhards'" , Subject: RE: [Syslog] Updated Syslog-tls Document Date: Tue, 28 Nov 2006 00:45:32 -0500 Message-ID: <042901c712b0$6c037b20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccN00y0qV2GLbfNQWeHwgDicYI+RAAQ2VagACHUuVAADQ6CgADsE1HgAANumSAAB9ly0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <00ea01c71291$ef25ac90$800c6f0a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 That wording satisfies me. dbh > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com] > Sent: Monday, November 27, 2006 9:07 PM > To: 'David Harrington'; 'Rainer Gerhards'; syslog@ietf.org > Subject: RE: [Syslog] Updated Syslog-tls Document > > > I am changing the sentence to: > > "For the deployment where confidentiality is a concern, receiver > authentication is required for sender/relay to make sure it > is talking to > the right peer. It is up to the operator to decide whether > confidentiality > is a concern for a specific deployment. " > > This sentence serves as a tip for deployer rather than something about > on-the-wire protocol. > > Thanks, > Miao > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Tuesday, November 28, 2006 8:27 AM > > To: 'Rainer Gerhards'; 'Miao Fuyou'; syslog@ietf.org > > Subject: RE: [Syslog] Updated Syslog-tls Document > > > > > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Thursday, November 23, 2006 2:48 AM > > > To: Miao Fuyou; syslog@ietf.org > > > Subject: RE: [Syslog] Updated Syslog-tls Document > > > > > ------------------------------------- > > > > > 5.1 > > > > > > > > > > == > > > > > When confidentiality is a concern, a sender/relay MUST > > > > authenticate > > > > > the receiver to make sure it is talking to the right peer. > > > > > == > > > > > > > > > > I do not find the MUST is appropriate here: "when > > confidentiality > > > > > is a concern" is not a hard fact. What does it mean? > > When MUST I > > > > > implement authentication. Is my Implementation not > compliant to > > > > > this doc if I have the wrong understanding of "when > > > > > confidentiality is a concern". Or MUST I always implement it, > > > > > because confidentiality is probably very often a concern? > > > > > > > > > > I think this is a operator-issue not to be dealt with in the > > > > > protocol. I suggest dropping this sentence or at last > > spell MUST > > > > > in lower case. > > > > > > > > > > > > > Probably lower case. The point is confidentility is meaningless > > > > without authenticaion. > > > > > > Well... maybe it is just a wording issue. Are we actually > REQUIREING > > a > > > sender to authenticate the receiver in all cases? If so, > we should > > > state that. My impression so far is that this is something that is > > optional > > > and at the discretion of the sender or the operator > configuring it. > > If > > > so, we should state that clearly too. As an implementor, I > > am unsure > > > what to do if I use the above text as a guideline. > > > > > > > Standards do not typically require an operator to use the > > technology in a specific manner; Standards do typically > > require implementers to implement in a way so that operators > > CAN configure the technology in the preferred > (interoperable) manner. > > > > MUST is used when the on-the-wire format/information/etc. > > must be interoperable for the protocol to work properly. > > > > I do not like seeing "must" in a document; either it deserves > > to be a MUST, i.e. it impacts on-the-wire interoperability, > > or it is an implementation/usage decision and we should not > > mandate it. If you use a lower case "must", then you'll need > > to convince me as co-chair that the usage is justifed before > > I send it to the IESG. > > > > Dbh > > > > > > > > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 28 03:38:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoySx-0007Vx-LD; Tue, 28 Nov 2006 03:37:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoySv-0007Vp-Uy for syslog@ietf.org; Tue, 28 Nov 2006 03:37:21 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoySu-0006Yu-Fm for syslog@ietf.org; Tue, 28 Nov 2006 03:37:21 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6F87327C011; Tue, 28 Nov 2006 09:40:59 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27599-04; Tue, 28 Nov 2006 09:40:59 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 20DD027C010; Tue, 28 Nov 2006 09:40:59 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 09:37:07 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Re: Updated IPR disclosure MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Nov 2006 09:37:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F871A@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Re: Updated IPR disclosure thread-index: AccSc/Fr4lqXMZ+NTi2Nq/KSdnEWDAAVDaLg References: <03e501c7126f$c862b390$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "Chris Lonvick" , "David Harrington" X-OriginalArrivalTime: 28 Nov 2006 08:37:07.0602 (UTC) FILETIME=[6388D720:01C712C8] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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, My comment is not on the essence of the patent (outside the scope of the IETF) but on the licensing terms. I find them quite acceptable and thank Huawei for the clarifying and right-in-time update. In short: I have no concerns, we should advance -transport-tls. Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Monday, November 27, 2006 11:32 PM > To: David Harrington > Cc: syslog@ietf.org > Subject: [Syslog] Re: Updated IPR disclosure >=20 > Hi Everyone, >=20 > Cisco asked Huawei to make this change. Essentially the prior > statement > appeared to be similar to the IPR statements made by Cisco and other > companies but it had differences that were not acceptable to the Cisco > legal team. Hence, Cisco would not have been willing to implement the > standard produced. Huawei's legal team looked into this and they have > made these changes. >=20 > The new statement appears to me (as David says, we are not lawyers) to > be > much closer to the intent of Cisco's, and others, IPR statements. I'm > asking Cisco's legal team to review this and I will post Cisco's > response > when I have that. >=20 > (Working Group Chair Hat OFF): On behalf of Cisco, I would like to > thank > Huawei for addressing this issue. >=20 > I must note once again that the IETF will not make any determination of > the validity of any IPR claimed. Huawei has been following the IETF > rules > on disclosure and statement of terms. >=20 > Thanks, > Chris >=20 > On Mon, 27 Nov 2006, David Harrington wrote: >=20 > > Hi, > > > > The syslog WG co-chairs were notified that a request was being made > > to Huawei by a company experienced in IETF IPR disclosures, that > > Huawei modify their terms related to the TLS transport document. > > Huawei has chosen to change their terms as requested. > > > > The new terms can be seen at > > = https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D763 > > > > The new disclosure is relevant to tls-03. We have requested Huawei to > > also post an update relevant to tls-04, which was just published. > > > > The changes apparently are meant to tighten the language a bit, and > to > > make Huawei terms more consistent with those of other companies > filing > > disclosures within the IETF. > > > > The co-chairs are not lawyers, and cannot provide legal advice about > > the changes. > > > > The WG needs to consider whether the modified terms are acceptable > for > > this document to be advanced to the standards-track. Please send your > > comments to the co-chairs as soon as possible. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 28 04:37:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GozP0-0005s8-Oh; Tue, 28 Nov 2006 04:37:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GozP0-0005s0-94 for syslog@ietf.org; Tue, 28 Nov 2006 04:37:22 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GozOx-0005V2-Oj for syslog@ietf.org; Tue, 28 Nov 2006 04:37:22 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 39DAD27C011; Tue, 28 Nov 2006 10:41:09 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27828-06; Tue, 28 Nov 2006 10:41:09 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id DAD3627C010; Tue, 28 Nov 2006 10:41:08 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 10:37:17 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Updated Syslog-tls Document MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Nov 2006 10:36:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8723@grfint2.intern.adiscon.com> In-Reply-To: <042901c712b0$6c037b20$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Updated Syslog-tls Document thread-index: AccN00y0qV2GLbfNQWeHwgDicYI+RAAQ2VagACHUuVAADQ6CgADsE1HgAANumSAAB9ly0AAIPX/A References: <00ea01c71291$ef25ac90$800c6f0a@china.huawei.com> <042901c712b0$6c037b20$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" , "Miao Fuyou" , X-OriginalArrivalTime: 28 Nov 2006 09:37:17.0687 (UTC) FILETIME=[CB501870:01C712D0] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 Just for the records: I am also statisfied with this wording. Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, November 28, 2006 6:46 AM > To: 'Miao Fuyou'; Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Updated Syslog-tls Document >=20 > That wording satisfies me. >=20 > dbh >=20 > > -----Original Message----- > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > Sent: Monday, November 27, 2006 9:07 PM > > To: 'David Harrington'; 'Rainer Gerhards'; syslog@ietf.org > > Subject: RE: [Syslog] Updated Syslog-tls Document > > > > > > I am changing the sentence to: > > > > "For the deployment where confidentiality is a concern, receiver > > authentication is required for sender/relay to make sure it > > is talking to > > the right peer. It is up to the operator to decide whether > > confidentiality > > is a concern for a specific deployment. " > > > > This sentence serves as a tip for deployer rather than something > about > > on-the-wire protocol. > > > > Thanks, > > Miao > > > > > -----Original Message----- > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Tuesday, November 28, 2006 8:27 AM > > > To: 'Rainer Gerhards'; 'Miao Fuyou'; syslog@ietf.org > > > Subject: RE: [Syslog] Updated Syslog-tls Document > > > > > > > > > > > > > -----Original Message----- > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > > Sent: Thursday, November 23, 2006 2:48 AM > > > > To: Miao Fuyou; syslog@ietf.org > > > > Subject: RE: [Syslog] Updated Syslog-tls Document > > > > > > ------------------------------------- > > > > > > 5.1 > > > > > > > > > > > > =3D=3D > > > > > > When confidentiality is a concern, a sender/relay MUST > > > > > authenticate > > > > > > the receiver to make sure it is talking to the right > peer. > > > > > > =3D=3D > > > > > > > > > > > > I do not find the MUST is appropriate here: "when > > > confidentiality > > > > > > is a concern" is not a hard fact. What does it mean? > > > When MUST I > > > > > > implement authentication. Is my Implementation not > > compliant to > > > > > > this doc if I have the wrong understanding of "when > > > > > > confidentiality is a concern". Or MUST I always implement > it, > > > > > > because confidentiality is probably very often a concern? > > > > > > > > > > > > I think this is a operator-issue not to be dealt with in the >=20 > > > > > > protocol. I suggest dropping this sentence or at last > > > spell MUST > > > > > > in lower case. > > > > > > > > > > > > > > > > Probably lower case. The point is confidentility is > meaningless > > > > > without authenticaion. > > > > > > > > Well... maybe it is just a wording issue. Are we actually > > REQUIREING > > > a > > > > sender to authenticate the receiver in all cases? If so, > > we should > > > > state that. My impression so far is that this is something that > is > > > optional > > > > and at the discretion of the sender or the operator > > configuring it. > > > If > > > > so, we should state that clearly too. As an implementor, I > > > am unsure > > > > what to do if I use the above text as a guideline. > > > > > > > > > > Standards do not typically require an operator to use the > > > technology in a specific manner; Standards do typically > > > require implementers to implement in a way so that operators > > > CAN configure the technology in the preferred > > (interoperable) manner. > > > > > > MUST is used when the on-the-wire format/information/etc. > > > must be interoperable for the protocol to work properly. > > > > > > I do not like seeing "must" in a document; either it deserves > > > to be a MUST, i.e. it impacts on-the-wire interoperability, > > > or it is an implementation/usage decision and we should not > > > mandate it. If you use a lower case "must", then you'll need > > > to convince me as co-chair that the usage is justifed before > > > I send it to the IESG. > > > > > > Dbh > > > > > > > > > > > > > > > > > > > > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 28 04:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GozR5-0000GT-V9; Tue, 28 Nov 2006 04:39:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GozR4-0000GH-SU for syslog@ietf.org; Tue, 28 Nov 2006 04:39:30 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GozR3-0006F2-Ea for syslog@ietf.org; Tue, 28 Nov 2006 04:39:30 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 459BB27C011; Tue, 28 Nov 2006 10:43:19 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27828-07; Tue, 28 Nov 2006 10:43:19 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 052CA27C010; Tue, 28 Nov 2006 10:43:18 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 10:39:28 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Shepherding document for udp-08 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Nov 2006 10:38:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8724@grfint2.intern.adiscon.com> In-Reply-To: <040401c71289$a0687bd0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Shepherding document for udp-08 thread-index: AccNxikySfyauRdWTgeqq4EjcWrEQgAYs+UAARgXgFAAEeGOYA== References: <577465F99B41C842AAFBE9ED71E70ABA1F8659@grfint2.intern.adiscon.com> <040401c71289$a0687bd0$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" X-OriginalArrivalTime: 28 Nov 2006 09:39:28.0210 (UTC) FILETIME=[191C5320:01C712D1] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, November 28, 2006 2:08 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: RE: [Syslog] Shepherding document for udp-08 >=20 > Hi, >=20 > Yes, I/we should correct this. >=20 > Do we have any information about vendors that have implemented the > current UDP specification? As of my end: not yet. I'll try to have a look into rsyslog this week and see if there is anything that makes it an issue. Rainer >=20 > dbh >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Wednesday, November 22, 2006 6:29 AM > > To: David Harrington; syslog@ietf.org > > Subject: RE: [Syslog] Shepherding document for udp-08 > > > > David, > > > > there is one minor thing in the shepherding document I do not concur > > with: > > > > -- > > This document describes the traditional udp transport for syslog. > > draft-ietf-syslog-protocol makes changes to the syntax of the syslog > > fields but this is just the udp transport. It could be said that > > all existing implementations of syslog use this specification. > > -- > > > > There are some changes in -transport-udp compared to the traditional > > transport. I think it is somewhat dangerous to draw the conclusion > > drawn. > > > > But as I said - this is a minor comment and probably depend's on > ones > > point of view... > > > > Rainer > > > > > -----Original Message----- > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Wednesday, November 22, 2006 12:41 AM > > > To: syslog@ietf.org > > > Subject: [Syslog] Shepherding document for udp-08 > > > > > > Hi, > > > > > > I have reviewed a pre-publication copy of -08- and am satisifed it > > > represents WG consensus and is of a quality sufficient for > > advancement > > > to Proposed Standard. > > > > > > Barring serious objection from the WG, revision -08- will > > be submitted > > > to the IESG for advancement, accompanied by the attached > > shepherding > > > document. > > > > > > David Harrington > > > dharrington@huawei.com > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > co-chair, Syslog WG > > > > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 28 07:23:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yK-0002YT-F5; Tue, 28 Nov 2006 07:22:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yI-0002Wd-Me for syslog@ietf.org; Tue, 28 Nov 2006 07:21:58 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp1y7-0004Hv-Lz for syslog@ietf.org; Tue, 28 Nov 2006 07:21:50 -0500 Received: from pc6 (1Cust13.tnt4.lnd4.gbr.da.uu.net [62.188.133.13]) by blaster.systems.pipex.net (Postfix) with SMTP id 6A58CE00053E; Tue, 28 Nov 2006 12:21:31 +0000 (GMT) Message-ID: <051801c712df$6279b9a0$0601a8c0@pc6> From: "tom.petch" To: "Miao Fuyou" , "'Rainer Gerhards'" , References: <00f001c711f1$6a0a29f0$800c6f0a@china.huawei.com> Subject: Re: Ciphersuites Re: [Syslog] Updated Syslog-tls Document Date: Tue, 28 Nov 2006 12:05:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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: "Miao Fuyou" To: "'Rainer Gerhards'" ; "'tom.petch'" ; Sent: Monday, November 27, 2006 7:58 AM Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document > > Hi, > > It looks good. I tend to add some sentences like the one Rainer proposed. > Any objection? WFM Tom Petch > > Thanks, > Miao > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Friday, November 24, 2006 3:16 PM > > To: Miao Fuyou; tom.petch; syslog@ietf.org > > Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document > > > > Tom, Miao, > > > > might it be a compromise to add a sentence to -transport-tls > > that tells an implementor to look for mandatory to implement > > suites inside the TLS document. Something like > > > > "Minimum Interoperability between different implementations > > of this specification is achieved via the mandatory to > > implement cipher suites specified in ." > > > > That would be a reminder that might be helpful. > > > > Rainer > > > > > -----Original Message----- > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > Sent: Friday, November 24, 2006 4:04 AM > > > To: 'tom.petch'; Rainer Gerhards; syslog@ietf.org > > > Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document > > > > > > > > > My observation about ciphersuite: > > > 1, TLS wg can do a better job on ciphersuite selection than > > a profile > > > developer. > > > 2, TLS specification will be updated if the mandatory cipher is too > > > weak to provide appropriate protection, but > > profile-specific suite may > > > not be updated accordingly. > > > 3, Before TLS mandate a stronger cipher suite, > > > TLS_RSA_WITH_3DES_EDE_CBC_SHA is strong enough for most syslog > > > application. If a operator want a stronger cipher suite for highly > > > sensitive syslog application, he still has the freedom to > > specify one, > > > mandatory cipher suite is only MUST to implementer rather than > > > operator. > > > > > > So, my view is ciphersuite is not neccessary to be defined in this > > > specification, and it is not good to specify in this specification. > > > > > > Thanks, > > > Miao > > > > > > > > > > Tom and I discussed this issue on the mailing list. TLS > > > > protocol has > > > > > its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS > > > > > specification says that if application > > profile(syslog-tls in this > > > > > case) does not specify a mandatory cipher suite, TLS > > > > mandatory suite > > > > > will apply. So, no need to specify one in this specification. > > > > > > > > Ahh... that was the message I did not find in the archive. > > > > Thanks for bringing it up again. That obiously solves the interop > > > > problem. However, I am still of the view that we should advise > > > > operators to use strong suites in the security considerations > > > > section. > > > > > > > > > > > > > > > > I raised it because I wanted a cipher suite spelt out in the I-D > > > > rather then leaving it as an exercise in ingenuity for > > the reader to > > > > find where it is specified. The pro and con of not > > specifying it in > > > > our I-D is that as the views in the security community > > change (and > > > > some would regard the default as too weak - eg US > > government) so the > > > > mandatory to implement is changed for us without us noticing. > > > > > > > > Tom Petch > > > > > > > > ___ > > > > > > > > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 28 07:23:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yK-0002XQ-4F; Tue, 28 Nov 2006 07:22:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yI-0002Wd-Lu for syslog@ietf.org; Tue, 28 Nov 2006 07:21:58 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp1y7-0004I6-M0 for syslog@ietf.org; Tue, 28 Nov 2006 07:21:50 -0500 Received: from pc6 (1Cust13.tnt4.lnd4.gbr.da.uu.net [62.188.133.13]) by blaster.systems.pipex.net (Postfix) with SMTP id B34ECE0005FB; Tue, 28 Nov 2006 12:21:38 +0000 (GMT) Message-ID: <051a01c712df$644fb220$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , "Miao Fuyou" References: <00f101c711f5$9dd462b0$800c6f0a@china.huawei.com> Subject: TLS RFC was Re: [Syslog] Towards closure of syslog-tls issues Date: Tue, 28 Nov 2006 12:18:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org The latest TLS RFC is RFC4346 which is amended by RFC4366, RFC4680 and RFC4681 as rfc-index states; the last does not include RFC4507, which I would. However, the TLS WG is working on draft-ietf-tls-rfc4346-bis which changes the PRF (away from MD5) inter alia and calls it TLS v1.2. IFrom syslog-bounces@lists.ietf.org Tue Nov 28 07:23:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yK-0002YT-F5; Tue, 28 Nov 2006 07:22:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yI-0002Wd-Me for syslog@ietf.org; Tue, 28 Nov 2006 07:21:58 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp1y7-0004Hv-Lz for syslog@ietf.org; Tue, 28 Nov 2006 07:21:50 -0500 Received: from pc6 (1Cust13.tnt4.lnd4.gbr.da.uu.net [62.188.133.13]) by blaster.systems.pipex.net (Postfix) with SMTP id 6A58CE00053E; Tue, 28 Nov 2006 12:21:31 +0000 (GMT) Message-ID: <051801c712df$6279b9a0$0601a8c0@pc6> From: "tom.petch" To: "Miao Fuyou" , "'Rainer Gerhards'" , References: <00f001c711f1$6a0a29f0$800c6f0a@china.huawei.com> Subject: Re: Ciphersuites Re: [Syslog] Updated Syslog-tls Document Date: Tue, 28 Nov 2006 12:05:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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: "Miao Fuyou" To: "'Rainer Gerhards'" ; "'tom.petch'" ; Sent: Monday, November 27, 2006 7:58 AM Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document > > Hi, > > It looks good. I tend to add some sentences like the one Rainer proposed. > Any objection? WFM Tom Petch > > Thanks, > Miao > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Friday, November 24, 2006 3:16 PM > > To: Miao Fuyou; tom.petch; syslog@ietf.org > > Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document > > > > Tom, Miao, > > > > might it be a compromise to add a sentence to -transport-tls > > that tells an implementor to look for mandatory to implement > > suites inside the TLS document. Something like > > > > "Minimum Interoperability between different implementations > > of this specification is achieved via the mandatory to > > implement cipher suites specified in ." > > > > That would be a reminder that might be helpful. > > > > Rainer > > > > > -----Original Message----- > > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > > Sent: Friday, November 24, 2006 4:04 AM > > > To: 'tom.petch'; Rainer Gerhards; syslog@ietf.org > > > Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document > > > > > > > > > My observation about ciphersuite: > > > 1, TLS wg can do a better job on ciphersuite selection than > > a profile > > > developer. > > > 2, TLS specification will be updated if the mandatory cipher is too > > > weak to provide appropriate protection, but > > profile-specific suite may > > > not be updated accordingly. > > > 3, Before TLS mandate a stronger cipher suite, > > > TLS_RSA_WITH_3DES_EDE_CBC_SHA is strong enough for most syslog > > > application. If a operator want a stronger cipher suite for highly > > > sensitive syslog application, he still has the freedom to > > specify one, > > > MO, that I-D is too far away from completion to be worth waiting for but, in the sentence that notes "that implementors and deployers should keep aware of current literature" I would include a reference to include ongoing work in the IETF on TLS. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: "Miao Fuyou" Cc: Sent: Monday, November 27, 2006 11:05 PM Subject: Re: [Syslog] Towards closure of syslog-tls issues > Hi Miao, > > On Mon, 27 Nov 2006, Miao Fuyou wrote: > > > Hi, > > > > Unfortunately (or fortunately), there are several issues raised after the > > chair start shepherding process. As the editor, I would like close the > > issues as soon as possible, and get the doucment updated. > > > > 1, Version. The wg seems have concensus on removing version from the > > transport mapping this time. If there is a objection, please reply. If no, I > > would remove it. > > Please remove the version. We have consensus to do this. Tom Petch does > raise an important point that I will bring up to our ADs. Essentially, > TLS does not have any mechanism to allow for an indication of the contents > that it is protecting. This results in the need for separate ports for > implementations of foo/TLS and bar/TLS, even to the point of foo.v2/TLS > needs a different port from foo.v1/TLS. Both IPsec and SSH (as examples > of other secure transports) are able to embed an indication of the payload > within the transport protocol and reuse their ports. To that end, even > the byte-count is a bit of a problem, but we'll live with that. > > Remove Section 6.2 as well. > > > > 2, RFC3164. There is a proposal to remove RFC3164 support from the draft. I > > tend to accept the proposal. Please comment if you have a different idea! > > Go ahead and remove that reference. > > > > 3, Ciphersuite. Tom proposed to specify cipher suite in the transport > > document, but I still don't find necessity to do so. I tend to agree to > > Rainer's proposal: > > http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html > > In addition to that > - reference the latest TLS RFC and note that there are updates to that > which need to be considered > - note that the latest ciphers and their relative strengths may be > found in BCP86 > - note that implementors and deployers should keep aware of current > literature > (This should be about 3 sentences.) > > > > 4, ABNF issues. I will change " " format back to %d format. > > OK > > > 5, Receiver authentication when confidentiality is concern, from "MUST" to > > "must", and probably some more sentences about receiver authentication is > > required. > > OK > > Please make these changes and submit -05 so we can submit this to the > IESG. > > Thanks, > Chris > > > > > Please feedback if you have different ideas to the proposals above! Thanks! > > > > Regards, > > Miao _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog mandatory cipher suite is only MUST to implementer rather than > > > operator. > > > > > > So, my view is ciphersuite is not neccessary to be defined in this > > > specification, and it is not good to specify in this specification. > > > > > > Thanks, > > > Miao > > > > > > > > > > Tom and I discussed this issue on the mailing list. TLS > > > > protocol has > > > > > its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS > > > > > specification says that if application > > profile(syslog-tls in this > > > > > case) does not specify a mandatory cipher suite, TLS > > > > mandatory suite > > > > > will apply. So, no need to specify one in this specification. > > > > > > > > Ahh... that was the message I did not find in the archive. > > > > Thanks for bringing it up again. That obiously solves the interop > > > > problem. However, I am still of the view that we should advise > > > > operators to use strong suites in the security considerations > > > > section. > > > > > > > > > > > > > > > > I raised it because I wanted a cipher suite spelt out in the I-D > > > > rather then leaving it as an exercise in ingenuity for > > the reader to > > > > find where it is specified. The pro and con of not > > specifying it in > > > > our I-D is that as the views in the security community > > change (and > > > > some would regard the default as too weak - eg US > > government) so the > > > > mandatory to implement is changed for us without us noticing. > > > > > > > > Tom Petch > > > > > > > > ___ > > > > > > > > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 28 07:23:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yK-0002XQ-4F; Tue, 28 Nov 2006 07:22:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yI-0002Wd-Lu for syslog@ietf.org; Tue, 28 Nov 2006 07:21:58 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp1y7-0004I6-M0 for syslog@ietf.org; Tue, 28 Nov 2006 07:21:50 -0500 Received: from pc6 (1Cust13.tnt4.lnd4.gbr.da.uu.net [62.188.133.13]) by blaster.systems.pipex.net (Postfix) with SMTP id B34ECE0005FB; Tue, 28 Nov 2006 12:21:38 +0000 (GMT) Message-ID: <051a01c712df$644fb220$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , "Miao Fuyou" References: <00f101c711f5$9dd462b0$800c6f0a@china.huawei.com> Subject: TLS RFC was Re: [Syslog] Towards closure of syslog-tls issues Date: Tue, 28 Nov 2006 12:18:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org The latest TLS RFC is RFC4346 which is amended by RFC4366, RFC4680 and RFC4681 as rfc-index states; the last does not include RFC4507, which I would. However, the TLS WG is working on draft-ietf-tls-rfc4346-bis which changes the PRF (away from MD5) inter alia and calls it TLS v1.2. IMO, that I-D is too far away from completion to be worth waiting for but, in the sentence that notes "that implementors and deployers should keep aware of current literature" I would include a reference to include ongoing work in the IETF on TLS. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: "Miao Fuyou" Cc: Sent: Monday, November 27, 2006 11:05 PM Subject: Re: [Syslog] Towards closure of syslog-tls issues > Hi Miao, > > On Mon, 27 Nov 2006, Miao Fuyou wrote: > > > Hi, > > > > Unfortunately (or fortunately), there are several issues raised after the > > chair start shepherding process. As the editor, I would like close the > > issues as soon as possible, and get the doucment updated. > > > > 1, Version. The wg seems have concensus on removing version from the > > transport mapping this time. If there is a objection, please reply. If no, I > > would remove it. > > Please remove the version. We have consensus to do this. Tom Petch does > raise an important point that I will bring up to our ADs. Essentially, > TLS does not have any mechanism to allow for an indication of the contents > that it is protecting. This results in the need for separate ports for > implementations of foo/TLS and bar/TLS, even to the point of foo.v2/TLS > needs a different port from foo.v1/TLS. Both IPsec and SSH (as examples > of other secure transports) are able to embed an indication of the payload > within the transport protocol and reuse their ports. To that end, even > the byte-count is a bit of a problem, but we'll live with that. > > Remove Section 6.2 as well. > > > > 2, RFC3164. There is a proposal to remove RFC3164 support from the draft. I > > tend to accept the proposal. Please comment if you have a different idea! > > Go ahead and remove that reference. > > > > 3, Ciphersuite. Tom proposed to specify cipher suite in the transport > > document, but I still don't find necessity to do so. I tend to agree to > > Rainer's proposal: > > http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html > > In addition to that > - reference the latest TLS RFC and note that there are updates to that > which need to be considered > - note that the latest ciphers and their relative strengths may be > found in BCP86 > - note that implementors and deployers should keep aware of current > literature > (This should be about 3 sentences.) > > > > 4, ABNF issues. I will change " " format back to %d format. > > OK > > > 5, Receiver authentication when confidentiality is concern, from "MUST" to > > "must", and probably some more sentences about receiver authentication is > > required. > > OK > > Please make these changes and submit -05 so we can submit this to the > IESG. > > Thanks, > Chris > > > > > Please feedback if you have different ideas to the proposals above! Thanks! > > > > Regards, > > Miao _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 28 07:42:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2H6-0007Ua-9c; Tue, 28 Nov 2006 07:41:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2H4-0007Tb-6m for syslog@ietf.org; Tue, 28 Nov 2006 07:41:22 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp2H2-00009w-LW for syslog@ietf.org; Tue, 28 Nov 2006 07:41:22 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id BE39427C011; Tue, 28 Nov 2006 13:45:05 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01498-03; Tue, 28 Nov 2006 13:45:05 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 5608C27C010; Tue, 28 Nov 2006 13:45:05 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:41:11 +0100 Content-class: urn:content-classes:message Subject: RE: TLS RFC was Re: [Syslog] Towards closure of syslog-tls issues MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Nov 2006 13:41:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8742@grfint2.intern.adiscon.com> In-Reply-To: <051a01c712df$644fb220$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS RFC was Re: [Syslog] Towards closure of syslog-tls issues thread-index: AccS6AKp50yJSJJoRIiwB+zuQFK4lgAAjTIg References: <00f101c711f5$9dd462b0$800c6f0a@china.huawei.com> <051a01c712df$644fb220$0601a8c0@pc6> From: "Rainer Gerhards" To: "tom.petch" , "Chris Lonvick" , "Miao Fuyou" X-OriginalArrivalTime: 28 Nov 2006 12:41:11.0959 (UTC) FILETIME=[7C406270:01C712EA] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Tom, > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Tuesday, November 28, 2006 12:18 PM > To: Chris Lonvick; Miao Fuyou > Cc: syslog@ietf.org > Subject: TLS RFC was Re: [Syslog] Towards closure of syslog-tls issues >=20 > The latest TLS RFC is RFC4346 which is amended by RFC4366, RFC4680 and > RFC4681 > as rfc-index states; the last does not include RFC4507, which I would. >=20 > However, the TLS WG is working on draft-ietf-tls-rfc4346-bis which > changes the > PRF (away from MD5) inter alia and calls it TLS v1.2. IMO, that I-D is > too far > away from completion to be worth waiting for but, in the sentence that > notes >=20 > "that implementors and deployers should keep aware of current > literature" >=20 > I would include a reference to include ongoing work in the IETF on TLS. I am not sure here, but I think any reference to ongoing work will put the I-D to a hold. The reasoning is that any draft expires and after at most 6 month there is nothing left that could be referenced. If I am right with this opinion, I consider it better not to mention any specific effort. I also think that the text Miao proposed should be sufficiently enough to alert an implementor (and operator) to watch for further references. Just my 2 cts... Rainer >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Chris Lonvick" > To: "Miao Fuyou" > Cc: > Sent: Monday, November 27, 2006 11:05 PM > Subject: Re: [Syslog] Towards closure of syslog-tls issues >=20 >=20 > > Hi Miao, > > > > On Mon, 27 Nov 2006, Miao Fuyou wrote: > > > > > Hi, > > > > > > Unfortunately (or fortunately), there are several issues raised > after the > > > chair start shepherding process. As the editor, I would like close > the > > > issues as soon as possible, and get the doucment updated. > > > > > > 1, Version. The wg seems have concensus on removing version from > the > > > transport mapping this time. If there is a objection, please reply. > If no, I > > > would remove it. > > > > Please remove the version. We have consensus to do this. Tom Petch > does > > raise an important point that I will bring up to our ADs. > Essentially, > > TLS does not have any mechanism to allow for an indication of the > contents > > that it is protecting. This results in the need for separate ports > for > > implementations of foo/TLS and bar/TLS, even to the point of > foo.v2/TLS > > needs a different port from foo.v1/TLS. Both IPsec and SSH (as > examples > > of other secure transports) are able to embed an indication of the > payload > > within the transport protocol and reuse their ports. To that end, > even > > the byte-count is a bit of a problem, but we'll live with that. > > > > Remove Section 6.2 as well. > > > > > > > 2, RFC3164. There is a proposal to remove RFC3164 support from the > draft. I > > > tend to accept the proposal. Please comment if you have a different > idea! > > > > Go ahead and remove that reference. > > > > > > > 3, Ciphersuite. Tom proposed to specify cipher suite in the > transport > > > document, but I still don't find necessity to do so. I tend to > agree to > > > Rainer's proposal: > > > http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html > > > > In addition to that > > - reference the latest TLS RFC and note that there are updates to > that > > which need to be considered > > - note that the latest ciphers and their relative strengths may be > > found in BCP86 > > - note that implementors and deployers should keep aware of current > > literature > > (This should be about 3 sentences.) > > > > > > > 4, ABNF issues. I will change " " format back to %d format. > > > > OK > > > > > 5, Receiver authentication when confidentiality is concern, from > "MUST" to > > > "must", and probably some more sentences about receiver > authentication is > > > required. > > > > OK > > > > Please make these changes and submit -05 so we can submit this to the > > IESG. > > > > Thanks, > > Chris > > > > > > > > Please feedback if you have different ideas to the proposals above! > Thanks! > > > > > > Regards, > > > Miao >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 29 10:51:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRhZ-00011R-M3; Wed, 29 Nov 2006 10:50:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRhL-0000lt-IH; Wed, 29 Nov 2006 10:50:11 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRhC-0004aP-95; Wed, 29 Nov 2006 10:50:11 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1019626E12; Wed, 29 Nov 2006 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GpRhB-000184-TO; Wed, 29 Nov 2006 10:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 29 Nov 2006 10:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-05.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : TLS Transport Mapping for Syslog Author(s) : F. Miao, M. Yuzhi Filename : draft-ietf-syslog-transport-tls-05.txt Pages : 10 Date : 2006-11-29 This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of Syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-transport-tls-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-transport-tls-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-29071326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-tls-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-tls-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-29071326.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 Nov 29 11:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpS34-0006cr-It; Wed, 29 Nov 2006 11:12:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpS33-0006ce-CK for syslog@ietf.org; Wed, 29 Nov 2006 11:12:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpS31-0000Cv-M0 for syslog@ietf.org; Wed, 29 Nov 2006 11:12:37 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 29 Nov 2006 08:12:35 -0800 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 kATGCXJh019917 for ; Wed, 29 Nov 2006 08:12:33 -0800 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 kATGCXio016102 for ; Wed, 29 Nov 2006 08:12:33 -0800 (PST) Date: Wed, 29 Nov 2006 08:12:33 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9547; t=1164816753; x=1165680753; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Near=20Final=20Shepherding=20Document=20for=20draft-ietf-sysl og-transport-tls-05.txt |Sender:=20; bh=QCJtW+qT7d2z21WsU3jwP8APa/qZTlN4i5YCF28tBCQ=; b=gUJS8E/Xww8rzQke2ZwQ4ET8O+NlNDFdLGSWeNcVMxl8WfVLEjZW5f3RWxp+h6PJRqJpMzBh gfZ4Y7kWRsuxXTz3VT2OT8Lh2/Z3b68V60W7/MOKv4zWJHdS/nLhaYe6; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: Subject: [Syslog] Near Final Shepherding Document for draft-ietf-syslog-transport-tls-05.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Please review this and the latest version of the document. Send in any comments very soon as we would like to submit this to the IESG by Friday. If I don't hear anything, then this will become the final shepherding document. Thanks, Chris === Having passed a WG Last Call, draft-ietf-syslog-transport-tls-05.txt is ready for AD review. [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-transport-tls-05.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick === (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Chris Lonvick Yes; I believe that the document is ready for publication. === (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Adequate review has occurred from WG members, and it has been reviewed by others. The reviews of the WG Last Call for this document (-03 version) may be found here: Bert Wijnen's review (not a member of the WG mailing list) http://www1.ietf.org/mail-archive/web/syslog/current/msg01244.html John Calcote's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01199.html Other reviews of particular sections and concepts fill the WG mailing list. Of note is Eric Rescorla's review (of -02) http://www1.ietf.org/mail-archive/web/syslog/current/msg01100.html The issues raised in these reviews have been discussed on the mailing list and most of them were fixed in version -04. A very few minor issues were also addressed from that which resulted in vresion -05. I am satisfied about the level of review. === (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I have no concerns. === (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no concerns about the technical merit of the document. === (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus to publish this document. === (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No appeals have been threatened. === (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Normative reference [3] is not used in the document. This reference will be dropped by the RFC Editor during AUTH48. There is an extraneous blank line in the Acknowlegements section which will be removed during AUTH48. === (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split into normative and informational references. The document is dependant upon draft-ietf-syslog-protocol-19.txt which is being submitted along with this document. === (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document IANA section is complete. No registries are requested. === (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The ABNF in the document has been verified through http://www.apps.ietf.org/abnf.html === (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. 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. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was controversy around the IPR statement from Huawei from this document. The Working Group examined the issue and came to consensus that the statement would be accepted. There was some controversy around the use of a special character to denote the end of the payload, or a counter at the start of the payload to indicate the length of the payload. The Working Group has consent that a counter is the best mechanism. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This protocol has very similar characteristics to implementations of syslog over ssl that are available at this time. Members of the Working Group have noted that it should be a very small change to bring those implementations in line with this specification. No vendors have announced that they will utilize this protocol. Some vendors have indicated interest in supporting this document. A group of university researchers have implemented this protocol and found that it is practicable. The above named reviewers did an outstanding and thorough job. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-transport-tls-05.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick [AD] Sam Hartman === _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 29 13:10:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpTsK-0005lj-SX; Wed, 29 Nov 2006 13:09:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpTsJ-0005iT-FZ for syslog@ietf.org; Wed, 29 Nov 2006 13:09:39 -0500 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpTsF-0001xw-Oa for syslog@ietf.org; Wed, 29 Nov 2006 13:09:39 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20061129180935b1200t51a3e>; Wed, 29 Nov 2006 18:09:35 +0000 From: "David Harrington" To: Date: Wed, 29 Nov 2006 13:06:48 -0500 Message-ID: <063401c713e1$23eb21d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0635_01C713B7.3B1519D0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccT4QqDpjfiuFTYRSeZi4wICF5qjQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: Subject: [Syslog] Udp shepreherding document. X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0635_01C713B7.3B1519D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Here is the revised shepherding document for -udp-08 I modified the section. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net ------=_NextPart_000_0635_01C713B7.3B1519D0 Content-Type: text/plain; name="shepherding document for syslog-transport-udp.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="shepherding document for syslog-transport-udp.txt" Shepherding document for syslog-transport-udp-08 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? David Harrington I believe that this version is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by the Working Group and by people = outside of the Working Group. There are no concerns about the reviews. The=20 recent reviews may be found in the mailing list archive: http://www1.ietf.org/mail-archive/web/syslog/current/msg01242.html http://www1.ietf.org/mail-archive/web/syslog/current/msg01246.html In particular, since UDP lacks congestion control, we consulted TSVWG, = and have followed the recommendations concerning provisioning to account = for the syslog traffic. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML No. We have sought reviews from a number of experts and are satisfied = this document has received adequate expert review. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, = or has concerns whether there really is a need for it. In any event, if those issues have been discussed in the WG and the WG has indicated that it still wishes to advance the = document, detail those concerns here. There are no specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The Working Group as a whole understands the document and supports it moving forward. UDP is widely supported as a transport for syslog. (1.f) Has anyone threatened an appeal or otherwise indicated = extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. = (It should be in a separate email because this questionnaire will be entered into the ID Tracker.) No appeals have been threatened. (1.g) Has the Document Shepherd verified that the document = satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Yes. The document was generated using xml2rfc, has passed automated = checking using idnits 1.118 , and passed a manual check of idnits by the = shepherd. (1.h) Has the document split its references into normative and informative? Are there normative references to documents = that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative = references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split and all referenced documents are RFCs in good standing. This document is co-dependent upon draft-ietf-syslog-protocol. These = documents are being submitted together. (1.i) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport protocol. Working Group Summary Was there anything in WG process that is worth noting? = For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document has been ready for a very long time. The holdup has been that the Working Group decided to revise draft-ietf-syslog-protocol. = This action has been completed. Document Quality Are there existing implementations of the protocol? Have = a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? This document describes a standardized udp transport for syslog that is similar to that found in various existing implementations. Because the=20 working group paid a great deal of attention to backwards compatibility = issues, most=20 implementations will be able to support this transport with little work. We have had through reviews done by a number of people, including Bert = Wijnen, Richard Graveman of the OIF, and others, and the consensus has been that = this document is well-written and complete. =20 =3D=3D=3D ------=_NextPart_000_0635_01C713B7.3B1519D0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ------=_NextPart_000_0635_01C713B7.3B1519D0-- From syslog-bounces@lists.ietf.org Wed Nov 29 16:18:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWoa-0004K9-0R; Wed, 29 Nov 2006 16:18:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWga-0005lk-RR; Wed, 29 Nov 2006 16:09:44 -0500 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWgY-00064j-CQ; Wed, 29 Nov 2006 16:09:44 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20061129210941b1400p9t3ue>; Wed, 29 Nov 2006 21:09:41 +0000 From: "David Harrington" To: , "'Sam Hartman'" Date: Wed, 29 Nov 2006 16:06:53 -0500 Message-ID: <069801c713fa$4ce13d90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0699_01C713D0.640B3590" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccT+io+cug0peHXQmecNlqX0zp2Ag== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 X-Mailman-Approved-At: Wed, 29 Nov 2006 16:17:58 -0500 Cc: 'David Harrington' Subject: [Syslog] Shepherding document for draft-ietf-syslog-transport-udp-08 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0699_01C713D0.640B3590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sam, Please publish draft-ietf-syslog-transport-udp-08 as a Proposed Standard RFC. Attached is the shepherding document for draft-ietf-syslog-transport-udp-08, including the Document Announcement Write-Up and contact information. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG ------=_NextPart_000_0699_01C713D0.640B3590 Content-Type: text/plain; name="shepherding document for syslog-transport-udp.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="shepherding document for syslog-transport-udp.txt" Shepherding document for draft-ietf-syslog-transport-udp-08 [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-transport-udp-08.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] David Harrington (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? David Harrington I believe that this version is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by the Working Group and by people = outside of the Working Group. There are no concerns about the reviews. The=20 recent reviews may be found in the mailing list archive: http://www1.ietf.org/mail-archive/web/syslog/current/msg01242.html http://www1.ietf.org/mail-archive/web/syslog/current/msg01246.html In particular, since UDP lacks congestion control, we consulted TSVWG, = and have followed the recommendations concerning provisioning to account = for the syslog traffic. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML No. We have sought reviews from a number of experts and are satisfied = this document has received adequate expert review. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, = or has concerns whether there really is a need for it. In any event, if those issues have been discussed in the WG and the WG has indicated that it still wishes to advance the = document, detail those concerns here. There are no specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The Working Group as a whole understands the document and supports it moving forward. UDP is widely supported as a transport for syslog. (1.f) Has anyone threatened an appeal or otherwise indicated = extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. = (It should be in a separate email because this questionnaire will be entered into the ID Tracker.) No appeals have been threatened. (1.g) Has the Document Shepherd verified that the document = satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Yes. The document was generated using xml2rfc, has passed automated = checking using idnits 1.118 , and passed a manual check of idnits by the = shepherd. (1.h) Has the document split its references into normative and informative? Are there normative references to documents = that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative = references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split and all referenced documents are RFCs in good standing. This document is co-dependent upon draft-ietf-syslog-protocol. These = documents are being submitted together. (1.i) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport protocol. Working Group Summary Was there anything in WG process that is worth noting? = For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document has been ready for a very long time. The holdup has been that the Working Group decided to revise draft-ietf-syslog-protocol. = This action has been completed. Document Quality Are there existing implementations of the protocol? Have = a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? This document describes a standardized udp transport for syslog that is similar to that found in various existing implementations. Because the=20 working group paid a great deal of attention to backwards compatibility = issues, most=20 implementations will be able to support this transport with little work. We have had through reviews done by a number of people, including Bert = Wijnen, Richard Graveman of the OIF, and others, and the consensus has been that = this document is well-written and complete. [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-transport-udp-08.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] David Harrington ------=_NextPart_000_0699_01C713D0.640B3590 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ------=_NextPart_000_0699_01C713D0.640B3590-- From syslog-bounces@lists.ietf.org Wed Nov 29 16:20:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWqo-0005lm-1g; Wed, 29 Nov 2006 16:20:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWqn-0005lh-9w for syslog@ietf.org; Wed, 29 Nov 2006 16:20:17 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWqk-00076w-CT for syslog@ietf.org; Wed, 29 Nov 2006 16:20:17 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061129212013b1100nq5u5e>; Wed, 29 Nov 2006 21:20:13 +0000 From: "David Harrington" To: Date: Wed, 29 Nov 2006 16:17:23 -0500 Message-ID: <06a701c713fb$c5e114d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_06A8_01C713D1.DD0B0CD0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccT+1L00uwZUJOaT4SkxVJkcySXWw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: Subject: [Syslog] Shepherding document for -sign- X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_06A8_01C713D1.DD0B0CD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Here is the preliminary shperherding document for -sign- It is complete through revision -19-, and -20- should become available this week so I can finalize. Comments welcome. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net ------=_NextPart_000_06A8_01C713D1.DD0B0CD0 Content-Type: text/plain; name="shepherding document for syslog-sign.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="shepherding document for syslog-sign.txt" Shepherding document for syslog-sign (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? David Harrington I believe that this version is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by the Working Group and by people = outside of the Working Group. There are no concerns about the reviews. The=20 recent reviews may be found in the mailing list archive: http://www1.ietf.org/mail-archive/web/syslog/current/msg01209.html http://www1.ietf.org/mail-archive/web/syslog/current/msg01190.html http://www1.ietf.org/mail-archive/web/syslog/current/msg01227.html (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML No.=20 (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, = or has concerns whether there really is a need for it. In any event, if those issues have been discussed in the WG and the WG has indicated that it still wishes to advance the = document, detail those concerns here. There are no specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The Working Group as a whole understands the document and supports it moving forward.=20 (1.f) Has anyone threatened an appeal or otherwise indicated = extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. = (It should be in a separate email because this questionnaire will be entered into the ID Tracker.) No appeals have been threatened. (1.g) Has the Document Shepherd verified that the document = satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. [todo] Yes. The document was generated using xml2rfc, has passed = automated checking using idnits 1.118 , and passed a manual check of = idnits by the shepherd. (1.h) Has the document split its references into normative and informative? Are there normative references to documents = that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative = references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split and all referenced documents are RFCs in good standing. This document has informative dependencies upon other = draft-ietf-syslog-* internet drafts. These documents are being = submitted together. (1.i) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document describes a mechanism to add origin authentication, message integrity, replay-resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification draws upon the work defined in RFC xxxx, "The syslog Protocol", however it may be used atop any message delivery mechanism, even that defined in RFC 3164, "The BSD syslog Protocol", or in the RAW mode of "RFC 3195, "The Reliable Delivery of syslog". Working Group Summary Was there anything in WG process that is worth noting? = For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document has been ready for a very long time. The holdup has been that the Working Group decided to revise draft-ietf-syslog-protocol. = This action has been completed. Document Quality Are there existing implementations of the protocol? Have = a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? There are a number of implementations of syslog-sign available for = different operating systems. =3D=3D=3D ------=_NextPart_000_06A8_01C713D1.DD0B0CD0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ------=_NextPart_000_06A8_01C713D1.DD0B0CD0-- From syslog-bounces@lists.ietf.org Wed Nov 29 16:53:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXMK-0006nN-Je; Wed, 29 Nov 2006 16:52:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXMI-0006n6-Kw for syslog@ietf.org; Wed, 29 Nov 2006 16:52:50 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpXMF-0002hi-Un for syslog@ietf.org; Wed, 29 Nov 2006 16:52:50 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 29 Nov 2006 13:52:47 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kATLqlnl015349 for ; Wed, 29 Nov 2006 13:52:47 -0800 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 kATLqkOW002444 for ; Wed, 29 Nov 2006 13:52:47 -0800 (PST) Date: Wed, 29 Nov 2006 13:52:46 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8410; t=1164837167; x=1165701167; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Near=20final=20shepherding=20document=20for=20draft-ietf-sysl og-protocol-19.txt |Sender:=20; bh=Ye9d5tNhMxLxK+axUivTxsZVOv3RsR3So5NnTbJSZGU=; b=Way/BNlbKD3IcpCfveEEG6vvYuGK3kACmSqFDjs6940zfCH7kxNATIOP1dxZ6ScUF7vyHE61 x072dMO+BizunDONYSswQ+ZybYgnU17/hrjoBh4nRlx6KHvC/LUOokq8; Authentication-Results: sj-dkim-8; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: Subject: [Syslog] Near final shepherding document for draft-ietf-syslog-protocol-19.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 Folks, Rainer has submitted version -19 of syslog-protocol to the ID Editor. We should see it tomorrow. It is identical to the version -18 except that the ITU Alarm MIB table has been removed. We do have a volunteer to write that in a separate document but we will not have an initial version of that before this document goes to the IESG. Please review this and give me comments back as soon as you can. I would like to submit this to the IESG tomorrow or Friday. Thanks, Chris === Having passed a WG Last Call, draft-ietf-syslog-protocol-19.txt is ready for AD review. [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-protocol-19.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick === (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Chris Lonvick Yes; I believe that the document is ready for publication. === (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Adequate review has occurred from WG members, and it has been reviewed by others. The reviews of the WG Last Call for this document (-17 version) may be found here: Bert Wijnen's review (not a member of the WG mailing list) http://www1.ietf.org/mail-archive/web/syslog/current/msg01243.html Richard Graveman's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01240.html Sharon Chisolm's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01232.html Tom Petch's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01167.html David Harrington's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01144.html The issues raised in these reviews have been discussed on the mailing list and most of them were fixed in version -18. A very few minor issues were also addressed from that which resulted in vresion -19. I am satisfied about the level of review. === (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. === (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. === (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus to publish this document. === (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No appeals have been threatened. === (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? I have reviewed the document. Section 12 is a Note to the RFC Editor to say that other documents are dependent upon this one. This will be dropped by the RFC Editor. Reference [10] is unused and will be removed by the RFC Editor or during Auth48. === (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split into normative and informational references. The document is dependant upon draft-ietf-syslog-transport-udp-08.txt and draft-ietf-syslog-transport-tls-05.txt which are being submitted along with this document. === (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document IANA section is complete and the requested registries are clearly marked. === (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The ABNF in the document has been verified through http://www.apps.ietf.org/abnf.html === (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. 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. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing worth noting. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? One implementation of the protocol has been produced. No vendors have announced that they will utilize this protocol. Some vendors have indicated interest in supporting this document. The above named reviewers did an outstanding and thorough job. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-protocol-19.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick [AD] Sam Hartman === Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 30 05:33:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpjDg-0002kg-UK; Thu, 30 Nov 2006 05:32:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpjDf-0002kY-Nq for syslog@ietf.org; Thu, 30 Nov 2006 05:32:43 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpjDe-0005oU-EL for syslog@ietf.org; Thu, 30 Nov 2006 05:32:43 -0500 Received: from pc6 (1Cust85.tnt104.lnd4.gbr.da.uu.net [213.116.56.85]) by astro.systems.pipex.net (Postfix) with SMTP id 36EEAE0003B8; Thu, 30 Nov 2006 10:32:26 +0000 (GMT) Message-ID: <02af01c71462$78082a20$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , "Miao Fuyou" References: <00f101c711f5$9dd462b0$800c6f0a@china.huawei.com> Subject: Re: [Syslog] Towards closure of syslog-tls issues Date: Thu, 30 Nov 2006 10:17:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris I agreed (mostly) with the actions in your e-mail but do not see them all reflected in -05. See Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: "Miao Fuyou" Cc: Sent: Monday, November 27, 2006 11:05 PM Subject: Re: [Syslog] Towards closure of syslog-tls issues > > > 3, Ciphersuite. Tom proposed to specify cipher suite in the transport > > document, but I still don't find necessity to do so. I tend to agree to > > Rainer's proposal: > > http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html > > In addition to that > - reference the latest TLS RFC and note that there are updates to that > which need to be considered This I see, at least the latest RFC part > - note that the latest ciphers and their relative strengths may be > found in BCP86 This I do not see and would like to > - note that implementors and deployers should keep aware of current > literature Likewise, this I do not see and would like to > (This should be about 3 sentences.) > > > Please make these changes and submit -05 so we can submit this to the > IESG. > > Thanks, > Chris > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 30 06:34:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpkAn-0006Ia-Lh; Thu, 30 Nov 2006 06:33:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpkAm-0006IU-CP for syslog@ietf.org; Thu, 30 Nov 2006 06:33:48 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpkAl-0000kC-L9 for syslog@ietf.org; Thu, 30 Nov 2006 06:33:48 -0500 Received: from pc6 (1Cust134.tnt110.lnd4.gbr.da.uu.net [62.188.174.134]) by astro.systems.pipex.net (Postfix) with SMTP id 25C0CE0002E8; Thu, 30 Nov 2006 11:33:43 +0000 (GMT) Message-ID: <055501c7146b$05fbe940$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] Near Final Shepherding Document fordraft-ietf-syslog-transport-tls-05.txt Date: Thu, 30 Nov 2006 10:31:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 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 Chris I would say that there was controversy about the use of ports and that that should be reflected in the shepherding document. I would not be surprised to see this issue come up in IETF Last Call and it would be better to show that we had at least considered it. Something along the lines of "There was also some controversy about the use of a dedicated port for this, initial version of syslog over TLS; the consensus was that a dedicated port should be requested and that there should be no indication of version with the consequence that any future change to the protocol might require a different port number." Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Wednesday, November 29, 2006 5:12 PM Subject: [Syslog] Near Final Shepherding Document fordraft-ietf-syslog-transport-tls-05.txt > Hi, > > Please review this and the latest version of the document. Send in any > comments very soon as we would like to submit this to the IESG by Friday. > If I don't hear anything, then this will become the final shepherding > document. > > Thanks, > Chris > > === > Having passed a WG Last Call, draft-ietf-syslog-transport-tls-05.txt is > ready for AD review. > > [Area] SECURITY > [WG] syslog > [I-D] draft-ietf-syslog-transport-tls-05.txt > [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt > [Shep] Chris Lonvick > > > === > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? > Chris Lonvick > Yes; I believe that the document is ready for publication. > === > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? > > Adequate review has occurred from WG members, and it has been reviewed > by others. The reviews of the WG Last Call for this document (-03 > version) may be found here: > > > Bert Wijnen's review (not a member of the WG mailing list) > http://www1.ietf.org/mail-archive/web/syslog/current/msg01244.html > > John Calcote's review > http://www1.ietf.org/mail-archive/web/syslog/current/msg01199.html > > Other reviews of particular sections and concepts fill the WG mailing > list. Of note is Eric Rescorla's review (of -02) > http://www1.ietf.org/mail-archive/web/syslog/current/msg01100.html > > > The issues raised in these reviews have been discussed on the mailing > list and most of them were fixed in version -04. A very few minor issues > were also addressed from that which resulted in vresion -05. I am > satisfied about the level of review. > === > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? > > I have no concerns. > === > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. > > There are no concerns about the technical merit of the document. > === > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > > There is strong consensus to publish this document. > === > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) > > No appeals have been threatened. > === > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? > > Normative reference [3] is not used in the document. This reference will > be dropped by the RFC Editor during AUTH48. > > There is an extraneous blank line in the Acknowlegements section which > will be removed during AUTH48. > === > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. > > The references are split into normative and informational references. > The document is dependant upon draft-ietf-syslog-protocol-19.txt which > is being submitted along with this document. > === > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggested a > reasonable name for the new registry? See > [I-D.narten-iana-considerations-rfc2434bis]. If the document > describes an Expert Review process has Shepherd conferred with > the Responsible Area Director so that the IESG can appoint the > needed Expert during the IESG Evaluation? > > The document IANA section is complete. No registries are requested. > === > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? > > The ABNF in the document has been verified through > http://www.apps.ietf.org/abnf.html > === > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Writeup? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. > > > 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. > > > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? > > > There was controversy around the IPR statement from Huawei from this > document. The Working Group examined the issue and came to consensus > that the statement would be accepted. > > There was some controversy around the use of a special character to denote > the end of the payload, or a counter at the start of the payload to > indicate the length of the payload. The Working Group has consent that a > counter is the best mechanism. > > > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? > > > This protocol has very similar characteristics to implementations of > syslog over ssl that are available at this time. Members of the Working > Group have noted that it should be a very small change to bring those > implementations in line with this specification. > > No vendors have announced that they will utilize this protocol. Some > vendors have indicated interest in supporting this document. A group > of university researchers have implemented this protocol and found that > it is practicable. > > The above named reviewers did an outstanding and thorough job. > > > Personnel > Who is the Document Shepherd for this document? Who is the > Responsible Area Director? > [Area] SECURITY > [WG] syslog > [I-D] draft-ietf-syslog-transport-tls-05.txt > [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt > [Shep] Chris Lonvick > [AD] Sam Hartman > === > > _______________________________________________ > 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 Nov 30 12:48:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpq09-0005MM-BU; Thu, 30 Nov 2006 12:47:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpq08-0005J0-F6 for syslog@ietf.org; Thu, 30 Nov 2006 12:47:12 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpq06-0005HY-OW for syslog@ietf.org; Thu, 30 Nov 2006 12:47:12 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2006 09:47:11 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kAUHlA9M015792; Thu, 30 Nov 2006 09:47:10 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAUHl9W5002457; Thu, 30 Nov 2006 09:47:10 -0800 (PST) Date: Thu, 30 Nov 2006 09:47:09 -0800 (PST) From: Chris Lonvick To: "tom.petch" Subject: Re: [Syslog] Near Final Shepherding Document fordraft-ietf-syslog-transport-tls-05.txt In-Reply-To: <055501c7146b$05fbe940$0601a8c0@pc6> Message-ID: References: <055501c7146b$05fbe940$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11390; t=1164908830; x=1165772830; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20Near=20Final=20Shepherding=20Document=20fo rdraft-ietf-syslog-transport-tls-05.txt |Sender:=20; bh=MRMUyQP2YX2hU4eO9j5IHY4hHLEVNJIzlauVBuZLxIw=; b=ktCT502Q6HRecKBaAyfawO2euqYc25CdN5v3r7GSOpkeGwI3ROBbQI2W/5NAeEzpNzjq6p99 yh0WMUfnf+qw89E81XZA8TBDZWjrrYRNE7BONqUvHuG9EPP3YCPdDPsX; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Tom, Noted. I'll add that and should have a new shepherding document out later today. Thanks, Chris On Thu, 30 Nov 2006, tom.petch wrote: > Chris > > I would say that there was controversy about the use of ports and that that > should be reflected in the shepherding document. I would not be surprised to > see this > issue come up in IETF Last Call and it would be better to show that we had at > least considered it. Something along the lines of > > "There was also some controversy about the use of a dedicated port for this, > initial version of syslog over TLS; the consensus was that a dedicated port > should be requested and that there should be no indication of version with the > consequence that any future change to the protocol might require a different > port number." > > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" > To: > Sent: Wednesday, November 29, 2006 5:12 PM > Subject: [Syslog] Near Final Shepherding Document > fordraft-ietf-syslog-transport-tls-05.txt > > >> Hi, >> >> Please review this and the latest version of the document. Send in any >> comments very soon as we would like to submit this to the IESG by Friday. >> If I don't hear anything, then this will become the final shepherding >> document. >> >> Thanks, >> Chris >> >> === >> Having passed a WG Last Call, draft-ietf-syslog-transport-tls-05.txt is >> ready for AD review. >> >> [Area] SECURITY >> [WG] syslog >> [I-D] draft-ietf-syslog-transport-tls-05.txt >> [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt >> [Shep] Chris Lonvick >> >> >> === >> (1.a) Who is the Document Shepherd for this document? Has the >> Document Shepherd personally reviewed this version of the >> document and, in particular, does he or she believe this >> version is ready for forwarding to the IESG for publication? >> Chris Lonvick >> Yes; I believe that the document is ready for publication. >> === >> (1.b) Has the document had adequate review both from key WG members >> and from key non-WG members? Does the Document Shepherd have >> any concerns about the depth or breadth of the reviews that >> have been performed? >> >> Adequate review has occurred from WG members, and it has been reviewed >> by others. The reviews of the WG Last Call for this document (-03 >> version) may be found here: >> >> >> Bert Wijnen's review (not a member of the WG mailing list) >> http://www1.ietf.org/mail-archive/web/syslog/current/msg01244.html >> >> John Calcote's review >> http://www1.ietf.org/mail-archive/web/syslog/current/msg01199.html >> >> Other reviews of particular sections and concepts fill the WG mailing >> list. Of note is Eric Rescorla's review (of -02) >> http://www1.ietf.org/mail-archive/web/syslog/current/msg01100.html >> >> >> The issues raised in these reviews have been discussed on the mailing >> list and most of them were fixed in version -04. A very few minor issues >> were also addressed from that which resulted in vresion -05. I am >> satisfied about the level of review. >> === >> (1.c) Does the Document Shepherd have concerns that the document >> needs more review from a particular or broader perspective, >> e.g., security, operational complexity, someone familiar with >> AAA, internationalization or XML? >> >> I have no concerns. >> === >> (1.d) Does the Document Shepherd have any specific concerns or >> issues with this document that the Responsible Area Director >> and/or the IESG should be aware of? For example, perhaps he >> or she is uncomfortable with certain parts of the document, or >> has concerns whether there really is a need for it. In any >> event, if the WG has discussed those issues and has indicated >> that it still wishes to advance the document, detail those >> concerns here. >> >> There are no concerns about the technical merit of the document. >> === >> (1.e) How solid is the WG consensus behind this document? Does it >> represent the strong concurrence of a few individuals, with >> others being silent, or does the WG as a whole understand and >> agree with it? >> >> There is strong consensus to publish this document. >> === >> (1.f) Has anyone threatened an appeal or otherwise indicated extreme >> discontent? If so, please summarise the areas of conflict in >> separate email messages to the Responsible Area Director. (It >> should be in a separate email because this questionnaire is >> entered into the ID Tracker.) >> >> No appeals have been threatened. >> === >> (1.g) Has the Document Shepherd personally verified that the >> document satisfies all ID nits? (See >> http://www.ietf.org/ID-Checklist.html and >> http://tools.ietf.org/tools/idnits/). Boilerplate checks are >> not enough; this check needs to be thorough. Has the document >> met all formal review criteria it needs to, such as the MIB >> Doctor, media type and URI type reviews? >> >> Normative reference [3] is not used in the document. This reference will >> be dropped by the RFC Editor during AUTH48. >> >> There is an extraneous blank line in the Acknowlegements section which >> will be removed during AUTH48. >> === >> (1.h) Has the document split its references into normative and >> informative? Are there normative references to documents that >> are not ready for advancement or are otherwise in an unclear >> state? If such normative references exist, what is the >> strategy for their completion? Are there normative references >> that are downward references, as described in [RFC3967]? If >> so, list these downward references to support the Area >> Director in the Last Call procedure for them [RFC3967]. >> >> The references are split into normative and informational references. >> The document is dependant upon draft-ietf-syslog-protocol-19.txt which >> is being submitted along with this document. >> === >> (1.i) Has the Document Shepherd verified that the document IANA >> consideration section exists and is consistent with the body >> of the document? If the document specifies protocol >> extensions, are reservations requested in appropriate IANA >> registries? Are the IANA registries clearly identified? If >> the document creates a new registry, does it define the >> proposed initial contents of the registry and an allocation >> procedure for future registrations? Does it suggested a >> reasonable name for the new registry? See >> [I-D.narten-iana-considerations-rfc2434bis]. If the document >> describes an Expert Review process has Shepherd conferred with >> the Responsible Area Director so that the IESG can appoint the >> needed Expert during the IESG Evaluation? >> >> The document IANA section is complete. No registries are requested. >> === >> (1.j) Has the Document Shepherd verified that sections of the >> document that are written in a formal language, such as XML >> code, BNF rules, MIB definitions, etc., validate correctly in >> an automated checker? >> >> The ABNF in the document has been verified through >> http://www.apps.ietf.org/abnf.html >> === >> (1.k) The IESG approval announcement includes a Document >> Announcement Write-Up. Please provide such a Document >> Announcement Writeup? Recent examples can be found in the >> "Action" announcements for approved documents. The approval >> announcement contains the following sections: >> >> >> Technical Summary >> Relevant content can frequently be found in the abstract >> and/or introduction of the document. If not, this may be >> an indication that there are deficiencies in the abstract >> or introduction. >> >> >> 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. >> >> >> Working Group Summary >> Was there anything in WG process that is worth noting? For >> example, was there controversy about particular points or >> were there decisions where the consensus was particularly >> rough? >> >> >> There was controversy around the IPR statement from Huawei from this >> document. The Working Group examined the issue and came to consensus >> that the statement would be accepted. >> >> There was some controversy around the use of a special character to denote >> the end of the payload, or a counter at the start of the payload to >> indicate the length of the payload. The Working Group has consent that a >> counter is the best mechanism. >> >> >> Document Quality >> Are there existing implementations of the protocol? Have a >> significant number of vendors indicated their plan to >> implement the specification? Are there any reviewers that >> merit special mention as having done a thorough review, >> e.g., one that resulted in important changes or a >> conclusion that the document had no substantive issues? If >> there was a MIB Doctor, Media Type or other expert review, >> what was its course (briefly)? In the case of a Media Type >> review, on what date was the request posted? >> >> >> This protocol has very similar characteristics to implementations of >> syslog over ssl that are available at this time. Members of the Working >> Group have noted that it should be a very small change to bring those >> implementations in line with this specification. >> >> No vendors have announced that they will utilize this protocol. Some >> vendors have indicated interest in supporting this document. A group >> of university researchers have implemented this protocol and found that >> it is practicable. >> >> The above named reviewers did an outstanding and thorough job. >> >> >> Personnel >> Who is the Document Shepherd for this document? Who is the >> Responsible Area Director? >> [Area] SECURITY >> [WG] syslog >> [I-D] draft-ietf-syslog-transport-tls-05.txt >> [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt >> [Shep] Chris Lonvick >> [AD] Sam Hartman >> === >> >> _______________________________________________ >> 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 Nov 30 12:48:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppzX-000570-Uc; Thu, 30 Nov 2006 12:46:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppzX-00056m-Ba for syslog@ietf.org; Thu, 30 Nov 2006 12:46:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GppzU-0005Bm-KH for syslog@ietf.org; Thu, 30 Nov 2006 12:46:35 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2006 09:46:32 -0800 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 kAUHkVpp015282; Thu, 30 Nov 2006 09:46:31 -0800 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 kAUHkUio009595; Thu, 30 Nov 2006 09:46:31 -0800 (PST) Date: Thu, 30 Nov 2006 09:46:30 -0800 (PST) From: Chris Lonvick To: Miao Fuyou Subject: Re: [Syslog] Towards closure of syslog-tls issues In-Reply-To: <02af01c71462$78082a20$0601a8c0@pc6> Message-ID: References: <00f101c711f5$9dd462b0$800c6f0a@china.huawei.com> <02af01c71462$78082a20$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1686; t=1164908791; x=1165772791; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20Towards=20closure=20of=20syslog-tls=20issu es |Sender:=20; bh=ivVmYEDVO1FgWzeq57k5RcereJXfHBaPorM6mVqUvMA=; b=CKnU/YvAmJZY8V/ljyimrxnEvwe42t8pKhT+2Yt6DQgph+1MxFnKmYSUgh2lKY1gq7+zzH6x cdjPNRWd3aq3IlIKFdpiiSvfRkpKuq/0Ztjv1GoDxA6/hezeFJpQoOpt; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); 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 Hi Miao, I agree that these should be in the ID before submission to the IESG. Please make these changes for version -06 and submit to the ID Editor. Once these are in I will submit to Sam and the IESG. Go ahead and take care of the other minor nits that are pointed out in the shepherding document for -05 as well. Thanks, Chris On Thu, 30 Nov 2006, tom.petch wrote: > Chris > > I agreed (mostly) with the actions in your e-mail but do not see them all > reflected in -05. See > > Tom Petch > > > ----- Original Message ----- > From: "Chris Lonvick" > To: "Miao Fuyou" > Cc: > Sent: Monday, November 27, 2006 11:05 PM > Subject: Re: [Syslog] Towards closure of syslog-tls issues >> >>> 3, Ciphersuite. Tom proposed to specify cipher suite in the transport >>> document, but I still don't find necessity to do so. I tend to agree to >>> Rainer's proposal: >>> http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html >> >> In addition to that >> - reference the latest TLS RFC and note that there are updates to that >> which need to be considered > > This I see, at least the latest RFC part > >> - note that the latest ciphers and their relative strengths may be >> found in BCP86 > > This I do not see and would like to > >> - note that implementors and deployers should keep aware of current >> literature > > Likewise, this I do not see and would like to > >> (This should be about 3 sentences.) >> > > >> >> Please make these changes and submit -05 so we can submit this to the >> IESG. >> >> Thanks, >> Chris >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Nov 30 15:52:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpsrq-0003Ne-8g; Thu, 30 Nov 2006 15:50:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpsra-0002ys-ST; Thu, 30 Nov 2006 15:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GpsrY-0005eO-HH; Thu, 30 Nov 2006 15:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 26F8E175C8; Thu, 30 Nov 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gpsr3-0003oY-O6; Thu, 30 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 30 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-protocol-19.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-19.txt Pages : 47 Date : 2006-11-30 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 anticipated original design goals for 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-19.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-19.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-19.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-11-30134223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-protocol-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-protocol-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-30134223.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--