From rfc-editor@rfc-editor.org Tue Mar 10 11:12:13 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92593A6C84; Tue, 10 Mar 2009 11:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.888 X-Spam-Level: X-Spam-Status: No, score=-16.888 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkn1jjjJSyAn; Tue, 10 Mar 2009 11:12:13 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 2CFC928B797; Tue, 10 Mar 2009 11:12:13 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id CFA4C24B690; Tue, 10 Mar 2009 11:10:55 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090310181055.CFA4C24B690@bosco.isi.edu> Date: Tue, 10 Mar 2009 11:10:55 -0700 (PDT) Cc: syslog@ietf.org, rfc-editor@rfc-editor.org Subject: [Syslog] RFC 5424 on The Syslog Protocol X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:12:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5424 Title: The Syslog Protocol Author: R. Gerhards Status: Standards Track Date: March 2009 Mailbox: rgerhards@adiscon.com Pages: 38 Characters: 85162 Obsoletes: RFC3164 I-D Tag: draft-ietf-syslog-protocol-23.txt URL: http://www.rfc-editor.org/rfc/rfc5424.txt 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 original design goals for traditional syslog in mind. The need 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. [STANDARDS TRACK] This document is a product of the Security Issues in Network Event Logging Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Mar 10 11:12:29 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B1A3A6A34; Tue, 10 Mar 2009 11:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.889 X-Spam-Level: X-Spam-Status: No, score=-16.889 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aSeevb0pAix; Tue, 10 Mar 2009 11:12:29 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 31A763A6407; Tue, 10 Mar 2009 11:12:29 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id E44E524B692; Tue, 10 Mar 2009 11:11:11 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090310181111.E44E524B692@bosco.isi.edu> Date: Tue, 10 Mar 2009 11:11:11 -0700 (PDT) Cc: syslog@ietf.org, rfc-editor@rfc-editor.org Subject: [Syslog] RFC 5425 on Transport Layer Security (TLS) Transport Mapping for Syslog X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:12:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5425 Title: Transport Layer Security (TLS) Transport Mapping for Syslog Author: F. Miao, Ed., Y. Ma, Ed., J. Salowey, Ed. Status: Standards Track Date: March 2009 Mailbox: miaofy@huawei.com, myz@huawei.com, jsalowey@cisco.com Pages: 13 Characters: 28159 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-syslog-transport-tls-14.txt URL: http://www.rfc-editor.org/rfc/rfc5425.txt 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. [STANDARDS TRACK] This document is a product of the Security Issues in Network Event Logging Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Mar 10 11:14:54 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B32A3A68AD; Tue, 10 Mar 2009 11:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.891 X-Spam-Level: X-Spam-Status: No, score=-16.891 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sShKdyW0ol4T; Tue, 10 Mar 2009 11:14:53 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 2728F28C1BD; Tue, 10 Mar 2009 11:12:47 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id DB64324B694; Tue, 10 Mar 2009 11:11:29 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090310181129.DB64324B694@bosco.isi.edu> Date: Tue, 10 Mar 2009 11:11:29 -0700 (PDT) Cc: syslog@ietf.org, rfc-editor@rfc-editor.org Subject: [Syslog] RFC 5426 on Transmission of Syslog Messages over UDP X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:14:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5426 Title: Transmission of Syslog Messages over UDP Author: A. Okmianski Status: Standards Track Date: March 2009 Mailbox: aokmians@cisco.com Pages: 9 Characters: 19354 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-syslog-transport-udp-12.txt URL: http://www.rfc-editor.org/rfc/rfc5426.txt 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. [STANDARDS TRACK] This document is a product of the Security Issues in Network Event Logging Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From clonvick@cisco.com Tue Mar 10 12:04:14 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5AE93A6850 for ; Tue, 10 Mar 2009 12:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmqihQbL-6A4 for ; Tue, 10 Mar 2009 12:04:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E74FA3A6A26 for ; Tue, 10 Mar 2009 12:04:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,337,1233532800"; d="scan'208";a="264874494" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 Mar 2009 19:04:09 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2AJ49o6024855 for ; Tue, 10 Mar 2009 12:04:09 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2AJ49cD028068 for ; Tue, 10 Mar 2009 19:04:09 GMT Date: Tue, 10 Mar 2009 12:04:09 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=440; t=1236711849; x=1237575849; 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:=20syslog=20RFCs |Sender:=20; bh=6IpFGaM8XQEn9Rk8SP3nalUOue6ZBTvzIz8EREWAGeE=; b=ObX2QURT9gsuwtlTeAtXGmlK4ALgMhA9v5DRB3k4pJc7+sdKKhx9ChQddT 3BWNRJPeWOea5Ep1wq+DbPKmJ6ES+AM08wqbQD4kkTBZ6l32yeRooV0mDBfi Xltl3+uEg9; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Syslog] syslog RFCs X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 19:04:14 -0000 Hi Folks, Congratulations to all of us. We now have published RFCs on syslog and two transports. RFC 5424 on The Syslog Protocol RFC 5425 on Transport Layer Security (TLS) Transport Mapping for Syslog RFC 5426 on Transmission of Syslog Messages over UDP Many thanks to everyone in the Working Group and especially you authors and reviewers who have put in the time and effort to get this done. :-) Best regards, Chris From aokmians@cisco.com Tue Mar 10 18:07:06 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD4A3A6A1F for ; Tue, 10 Mar 2009 18:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGJYhxiPH1ZY for ; Tue, 10 Mar 2009 18:07:05 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9D6473A69F0 for ; Tue, 10 Mar 2009 18:07:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,338,1233532800"; d="scan'208";a="39394539" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Mar 2009 01:07:40 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2B17ehP008939 for ; Tue, 10 Mar 2009 21:07:40 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2B17evE018339 for ; Wed, 11 Mar 2009 01:07:40 GMT Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 21:07:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Mar 2009 21:07:38 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122069493EA@xmb-rtp-20d.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] syslog RFCs Thread-Index: AcmhsyeMPT52XO3JT0WnVYAnYYFzvgAMjC+Q References: From: "Anton Okmyanskiy (aokmians)" To: "Chris Lonvick (clonvick)" , X-OriginalArrivalTime: 11 Mar 2009 01:07:39.0434 (UTC) FILETIME=[C5C478A0:01C9A1E5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1111; t=1236733660; x=1237597660; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=20=22Anton=20Okmyanskiy=20(aokmians)=22=20 |Subject:=20RE=3A=20[Syslog]=20syslog=20RFCs |Sender:=20 |To:=20=22Chris=20Lonvick=20(clonvick)=22=20,=20; bh=hckFovpLRQ4rCBYcNrKSwnA8xAbkSgfdX/z1r+EMc1Y=; b=AWVS8qaoX1JuHdjoo8vZnB4eE1AtpTEoqktYfQah8mmZSfJHPfYhNZoXWs YqOUqkZR8LuENM3Hl3d2361eBTMR2EOCCDnzq4rMcRJZxM3jVSDgEt57W7Wn druVk5gJNX; Authentication-Results: rtp-dkim-2; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Syslog] syslog RFCs X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 01:07:07 -0000 Congratulations to all! It only took 5 years. ;) But if this get adopted and sticks around for 20 years, it would be worth the effort.=20 Rainer, thanks for carrying the bulk of the work load.=20 Cheers, Anton.=20 > -----Original Message----- > From: syslog-bounces@ietf.org=20 > [mailto:syslog-bounces@ietf.org] On Behalf Of Chris Lonvick (clonvick) > Sent: Tuesday, March 10, 2009 12:04 PM > To: syslog@ietf.org > Subject: [Syslog] syslog RFCs >=20 > Hi Folks, >=20 > Congratulations to all of us. We now have published RFCs on=20 > syslog and two transports. >=20 > RFC 5424 on The Syslog Protocol > RFC 5425 on Transport Layer Security (TLS) Transport Mapping=20 > for Syslog RFC 5426 on Transmission of Syslog Messages over UDP >=20 > Many thanks to everyone in the Working Group and especially=20 > you authors and reviewers who have put in the time and effort=20 > to get this done. >=20 > :-) > Best regards, > Chris > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog >=20 From rgerhards@hq.adiscon.com Wed Mar 11 02:11:03 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9D73A692C for ; Wed, 11 Mar 2009 02:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2wnfyKY0SsF for ; Wed, 11 Mar 2009 02:11:03 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id ADC0A3A69E9 for ; Wed, 11 Mar 2009 02:11:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 7338C241C004; Wed, 11 Mar 2009 10:11:25 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNW8meuaIm0U; Wed, 11 Mar 2009 10:11:25 +0100 (CET) Received: from GRFEXC.intern.adiscon.com (p54AC52CA.dip.t-dialin.net [84.172.82.202]) by mailin.adiscon.com (Postfix) with ESMTP id D4D43241C002; Wed, 11 Mar 2009 10:11:24 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Mar 2009 10:11:34 +0100 Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71FB7@GRFEXC.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] syslog RFCs Thread-Index: AcmhsyeMPT52XO3JT0WnVYAnYYFzvgAMjC+QABDqbZA= References: <98AE08B66FAD1742BED6CB9522B73122069493EA@xmb-rtp-20d.amer.cisco.com> From: "Rainer Gerhards" To: "Anton Okmyanskiy \(aokmians\)" Cc: syslog@ietf.org Subject: Re: [Syslog] syslog RFCs X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 09:11:04 -0000 Thanks everyone, I am very happy that we finally could publish. Also, we already have = three implementations, if I count correctly (in order of appearance): - rsyslog - BSD syslog (modified by Martin Sch=FCtte) - syslog-ng with a fourth one (MonitorWare on Windows) coming up. Some new drafts also build on the foundation we have laid. I think this = is quite promising, maybe we manage to stay 20 years in business ;) I also doubt if I had the bulk of work load, there were many excellent contributions! A special thanks to everyone who helped. Rainer > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of Anton Okmyanskiy (aokmians) > Sent: Wednesday, March 11, 2009 2:08 AM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: Re: [Syslog] syslog RFCs >=20 > Congratulations to all! >=20 > It only took 5 years. ;) But if this get adopted and sticks around = for > 20 years, it would be worth the effort. >=20 > Rainer, thanks for carrying the bulk of the work load. >=20 > Cheers, > Anton. >=20 > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of Chris Lonvick > (clonvick) > > Sent: Tuesday, March 10, 2009 12:04 PM > > To: syslog@ietf.org > > Subject: [Syslog] syslog RFCs > > > > Hi Folks, > > > > Congratulations to all of us. We now have published RFCs on > > syslog and two transports. > > > > RFC 5424 on The Syslog Protocol > > RFC 5425 on Transport Layer Security (TLS) Transport Mapping > > for Syslog RFC 5426 on Transmission of Syslog Messages over UDP > > > > Many thanks to everyone in the Working Group and especially > > you authors and reviewers who have put in the time and effort > > to get this done. > > > > :-) > > Best regards, > > Chris > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From ietfdbh@comcast.net Fri Mar 13 13:25:33 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E58A3A6A09 for ; Fri, 13 Mar 2009 13:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Uawt74odanB for ; Fri, 13 Mar 2009 13:25:31 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id AA9123A69E0 for ; Fri, 13 Mar 2009 13:25:31 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA03.westchester.pa.mail.comcast.net with comcast id Sj2U1b00z0Fqzac53kSBFa; Fri, 13 Mar 2009 20:26:11 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA08.westchester.pa.mail.comcast.net with comcast id SkTx1b00Y0UQ6dC3UkTx4n; Fri, 13 Mar 2009 20:27:58 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , "'Anton Okmyanskiy \(aokmians\)'" References: <98AE08B66FAD1742BED6CB9522B73122069493EA@xmb-rtp-20d.amer.cisco.com> <9B6E2A8877C38245BFB15CC491A11DA71FB7@GRFEXC.intern.adiscon.com> Date: Fri, 13 Mar 2009 15:26:09 -0500 Message-ID: <0b5101c9a419$f22d4300$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71FB7@GRFEXC.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmhsyeMPT52XO3JT0WnVYAnYYFzvgAMjC+QABDqbZAAfBQR8A== Cc: syslog@ietf.org Subject: Re: [Syslog] syslog RFCs X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 20:25:33 -0000 Hi, If the implementers are willing to file a report on their implementation, we can advance the documents to Draft Standard. The reports need to identify whether the implementations support each portion of the relevant specifications - the header format, the SDEs, the various security mechanisms, etc.=20 If you are an implemneter willing to file a report, let me know and I will help explain the process to be followed. If you are a deployer, and willing to file a report of your deployment experience for these standards, we may be able to advance the drafts to Full Standard. dbh > -----Original Message----- > From: syslog-bounces@ietf.org=20 > [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, March 11, 2009 4:12 AM > To: Anton Okmyanskiy (aokmians) > Cc: syslog@ietf.org > Subject: Re: [Syslog] syslog RFCs >=20 > Thanks everyone, >=20 > I am very happy that we finally could publish. Also, we=20 > already have three > implementations, if I count correctly (in order of appearance): >=20 > - rsyslog > - BSD syslog (modified by Martin Sch=FCtte) > - syslog-ng >=20 > with a fourth one (MonitorWare on Windows) coming up. >=20 > Some new drafts also build on the foundation we have laid. I=20 > think this is > quite promising, maybe we manage to stay 20 years in business ;) >=20 > I also doubt if I had the bulk of work load, there were many excellent > contributions! A special thanks to everyone who helped. >=20 > Rainer >=20 > > -----Original Message----- > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > > Behalf Of Anton Okmyanskiy (aokmians) > > Sent: Wednesday, March 11, 2009 2:08 AM > > To: Chris Lonvick (clonvick); syslog@ietf.org > > Subject: Re: [Syslog] syslog RFCs > >=20 > > Congratulations to all! > >=20 > > It only took 5 years. ;) But if this get adopted and=20 > sticks around for > > 20 years, it would be worth the effort. > >=20 > > Rainer, thanks for carrying the bulk of the work load. > >=20 > > Cheers, > > Anton. > >=20 > > > -----Original Message----- > > > From: syslog-bounces@ietf.org > > > [mailto:syslog-bounces@ietf.org] On Behalf Of Chris Lonvick > > (clonvick) > > > Sent: Tuesday, March 10, 2009 12:04 PM > > > To: syslog@ietf.org > > > Subject: [Syslog] syslog RFCs > > > > > > Hi Folks, > > > > > > Congratulations to all of us. We now have published RFCs on > > > syslog and two transports. > > > > > > RFC 5424 on The Syslog Protocol > > > RFC 5425 on Transport Layer Security (TLS) Transport Mapping > > > for Syslog RFC 5426 on Transmission of Syslog Messages over UDP > > > > > > Many thanks to everyone in the Working Group and especially > > > you authors and reviewers who have put in the time and effort > > > to get this done. > > > > > > :-) > > > Best regards, > > > Chris > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@ietf.org > > > https://www.ietf.org/mailman/listinfo/syslog > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog >=20 From alex@cisco.com Mon Mar 16 08:57:16 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1549128C17D for ; Mon, 16 Mar 2009 08:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKCXuozdo8rj for ; Mon, 16 Mar 2009 08:57:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DF43628C155 for ; Mon, 16 Mar 2009 08:57:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,373,1233532800"; d="scan'208";a="142229252" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2009 15:57:57 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2GFvvtd008317; Mon, 16 Mar 2009 08:57:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2GFvuVu005960; Mon, 16 Mar 2009 15:57:57 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 08:57:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Mar 2009 08:57:56 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB075E9BB8@xmb-sjc-236.amer.cisco.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E7ACF6A8@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Configuration parameters thread-index: AcmGQYgclCYxlQ+GQ1q34WzgDVughwMQx9AwBN1WvoA= References: <808FD6E27AD4884E94820BC333B2DB7727E78B734D@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727E7ACF6A8@NOK-EUMSG-01.mgdnok.nokia.com> From: "Alexander Clemm (alex)" To: , "Chris Lonvick (clonvick)" X-OriginalArrivalTime: 16 Mar 2009 15:57:56.0642 (UTC) FILETIME=[F8F85020:01C9A64F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5566; t=1237219077; x=1238083077; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=20Configurati on=20parameters |Sender:=20; bh=YQ3pPl1MpP+qFAhDVEY4kOkwhgNyKQGtkcpY4NnrPqw=; b=uBTLXqnDxKhlv2F9atJDJSpuh2FwnMvCsry4gasnHMbA6qR7qeG5G4XWbl QCZux0BDUskY7sKu6ZJURvnKH1QuZLjl3c5QQJFfJ04pFSvn/KeUKLxELkNt 0BoJ9Xd8H00juoXpqorx8hylntibh7ZAQgSkvZk3KZnznVRj32ydY=; Authentication-Results: sj-dkim-1; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Configuration parameters X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 15:57:16 -0000 Hi Pasi and Chris, by and large, the suggestions are fine, with one exception for the non-redundant signature blocks, where there are a couple of issues with the proposed scheme: a) Signature blocks cannot be empty. There must have been at least one message to be signed. Syslog-sign should not be used as a heartbeat mechanism to indicate that the originator is still alive. =20 b) It is possible that messages of successive Signature Blocks overlap in terms of the messages whose hashes they contain - for example, some implementation might want to implement some kind of "rolling" scheme in which the first block contains hashes for messages 1-10, the second for message 3-12, the third 8-17. =20 In the end, configuration is really going to be implementation specific. I will suggest a text that proposes one parameter to configure the maximum delay that is tolerable from the time of the message with the First Message Number to the sending of the Signature Block. =20 Thanks --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Thursday, February 19, 2009 3:41 AM To: Chris Lonvick (clonvick) Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Configuration parameters Chris Lonvick wrote: > It needs to be "Resend" as these are redundant. Let me give > a very simple case to show: > If we configure the sender to have: > - a Signature Block Count (CNT) of 50 > - sigRepeat=3D2 > - sigResendDelay=3D30sec > - sigResendCount=3D34 > then: > time Sender Collector > 0s ---syslog messages 1-50---> > 14s ---sig block for msgs 1-50---> > 44s ---syslog messages 51-60---> > 44s ---sig block for msgs 1-50---> (R1,1) > 52s ---syslog messages 61-95---> > 52s ---sig block for msgs 1-50---> (R1,2) > 60s ---syslog messages 95-100---> > 60s ---sig block for msgs 51-100---> > > > For the first 14 seconds, the device sends 50 messages and then the > Signature Block for them. Thirty seconds later, the sigResendDelay > timer trips to send the first redundant Signature Block of the first > 50 messages - shown as (R1,1). Eight seconds after that, the sender > sees that it has sent 34 messages since sending out the previous > redundant Signature Block so it sends out the second redundant > Signature Block of the first 50 messages - shown as (R1,2). Thanks for the explanation -- I think I now understood this! > I do take your point that there is nothing to kick out the initial > signature block on a slow system. Same example: > time Sender Collector > 0s ---syslog messages 1-47---> > ...eight years later, still nothing else... > > So there should be a sigMaxInterval. > > I would rewrite it as follows: > =3D=3D=3D > 6.1.2. Configuration Parameters for Signature Blocks > Perhaps we should deal with non-redundant signature blocks first, and retransmissions afterward? How about: The following parameters control how often Signature Blocks are generated (note that the maximum message length may also force generating a Signature Block; see Sections 4.2.6 and 4.2.7): sigMaxInterval =3D generate a new Signature Block if this many = seconds have elapsed since the previous new Signature Block (not counting retransmissions). Note that this applies even when no other syslog messages have been sent since the previous Signature Block. sigMaxCount =3D generate a Signature Block if this many other syslog messages have been sent since the previous new Signature Block (not counting retransmissions). (Changed "send" to "generate" here) > To ensure reliably delivery (see Section 8.5), it is useful to send > the same Signature Block multiple times. This is controlled by the > "sigRepeat" parameter: > > sigRepeat =3D number of times a Signature Block is resent. > It is RECOMMENDED to use a value greater than 0 in particular > when the UDP transport [RFC5426] is used. > > The following parameters control how often the redundant Signature > Blocks are sent. How about: The retransmitted Signature Blocks are not sent immediately after the original transmission, but slightly later. The following parameters control when the retransmissions are done (note that these are independent of the parameters controlling when new Signature Blocks are generated): > sigResendDelay =3D send a redundant Signature Block if this many > seconds have elapsed since sending the original Signature > Block, or any previous redundant Signature Blocks. How about: sigResendDelay =3D retransmit if this many seconds have elapsed since the previous sending of this Signature Block. ("any" could refer to any Signature Block, even a new one.) > sigResendCount =3D send a Signature Block if this many other > syslog messages have been sent since sending the original > Signature Block, or any previous redundant Signature Blocks. How about: sigResendCount =3D retransmit if this many other syslog messages have been sent since the previous sending of this Signature Block. Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From bazsi@balabit.hu Mon Mar 16 13:28:58 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E73B3A697D for ; Mon, 16 Mar 2009 13:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.485 X-Spam-Level: * X-Spam-Status: No, score=1.485 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0r-+HVs7a9e for ; Mon, 16 Mar 2009 13:28:57 -0700 (PDT) Received: from lists.balabit.hu (support.balabit.hu [195.70.41.86]) by core3.amsl.com (Postfix) with ESMTP id 5A5323A6829 for ; Mon, 16 Mar 2009 13:28:56 -0700 (PDT) Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id 5A8DE39D2AA for ; Mon, 16 Mar 2009 21:29:36 +0100 (CET) From: Balazs Scheidler To: David Harrington In-Reply-To: <0b5101c9a419$f22d4300$0600a8c0@china.huawei.com> References: <98AE08B66FAD1742BED6CB9522B73122069493EA@xmb-rtp-20d.amer.cisco.com> <9B6E2A8877C38245BFB15CC491A11DA71FB7@GRFEXC.intern.adiscon.com> <0b5101c9a419$f22d4300$0600a8c0@china.huawei.com> Content-Type: text/plain Date: Mon, 16 Mar 2009 21:29:35 +0100 Message-Id: <1237235375.27336.15.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org Subject: Re: [Syslog] syslog RFCs X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 20:28:58 -0000 On Fri, 2009-03-13 at 15:26 -0500, David Harrington wrote: > Hi, > > If the implementers are willing to file a report on their > implementation, we can advance the documents to Draft Standard. > The reports need to identify whether the implementations support each > portion of the relevant specifications - the header format, the SDEs, > the various security mechanisms, etc. > > If you are an implemneter willing to file a report, let me know and I > will help explain the process to be followed. > > If you are a deployer, and willing to file a report of your deployment > experience for these standards, we may be able to advance the drafts > to Full Standard. > I might be interested with syslog-ng. Can you point me to the right direction how such a report is written and submitted? -- Bazsi From alex@cisco.com Mon Mar 16 17:11:48 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A33E28C188 for ; Mon, 16 Mar 2009 17:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arHTEW5HkpnC for ; Mon, 16 Mar 2009 17:11:47 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 47DCE3A695A for ; Mon, 16 Mar 2009 17:11:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,375,1233532800"; d="scan'208";a="67629734" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 17 Mar 2009 00:07:43 +0000 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 n2H07hP1009809; Mon, 16 Mar 2009 17:07:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2H07hjw013762; Tue, 17 Mar 2009 00:07:43 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 17:07:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Mar 2009 17:07:41 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Last minor clarifications/nits thread-index: AcmHdaO+Qkp999AbTiWTBRQhYXi2OgfHVVEg References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com> From: "Alexander Clemm (alex)" To: , X-OriginalArrivalTime: 17 Mar 2009 00:07:43.0266 (UTC) FILETIME=[64C34820:01C9A694] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2866; t=1237248463; x=1238112463; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=20Last=20mino r=20clarifications/nits |Sender:=20; bh=fu2F6AIkdRq0EvFPUkzCYinV64qaYYtmx0Yl1CiEEp8=; b=SoG/KjWc6U/Fy+zl9zKGUkkapbP4+IXYy1xI+tZ1oc+Kw7DZJZxMSx4jgm sJY23ABJilpU0VA5pHB3N4KMgHM4SDMmMJ1r+KfD227GIMx/PqBek/gGZRPV Y3JHGbQcUZkXW3+0zsgx2D/kJtp3ziztmvhAMcaNLmvpUWMd2P6KY=; Authentication-Results: sj-dkim-1; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 00:11:48 -0000 Hi, On the first item, yes, the first item (RSID) is clearly a counter; a time stamp cannot be used, nor can a value that is arbitrarily generated. =20 To use a time stamp would require a parameter that is differently defined than the current RSID. One approach would be to define a "union" of some sort - or introduce a second parameter to indicate how to interpret the RSID (if it represents a counter or a time stamp, is persisted or not). At this point, I would refrain from either. However, I do think it is fair to state there is no requirement that RSIDs be sequential - all that is required is that they increase; they don't have to increment just by 1. I think this leaves sufficient flexibility for the implementation to distinguish reboot sessions even in the absence of a persistence support, while keeping the scheme sufficiently simple. =20 --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Thursday, February 05, 2009 1:39 AM To: syslog@ietf.org Subject: [Syslog] Syslog-sign: Last minor clarifications/nits I've now gone through all the emails and comments (I think), and this email should contain all the stuff that wasn't covered by the earlier emails yesterday and today: In http://www.ietf.org/mail-archive/web/syslog/current/msg02030.html, Martin asked whether it's OK to use time() (or similar) as RSID. A strict reading of the current text does not seem to allow this. However, if the originator can't reliably store a persistent RSID counter, using a timestamp as RSID would probably provide more useful information to the collector than always sending 0 (even though timestamps are not always increasing, most of the time they are). What do others think? I think Sections 4.2.8 and 5.3.2.8 still need to be clearer about what octets exactly are signed. Here's my suggestion: The signature is calculated over the completely formatted Signature Block message (starting from the first octet of PRI and continuing to the last octet of MSG, or STRUCTURED-DATA if MSG is not present), before the SIGN parameter (SD Parameter Name and the space before it [" SIGN"], "=3D", and the corresponding value) is added. Section 5.3.2.8: The signature is calculated over the completely formatted Certificate Block message, before the SIGN parameter is added (see Section 4.2.8). Sections 5.3.2, 5.3.2.9, and 9.1 misspell Total Payload Block Length as TBPL (instead of TPBL). Depending on what format (OpenPGP MPI style or ASN.1/DER) we'll use for key blob type 'K', the example in 5.3.2.9 may or may not need updating. Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From ietfdbh@comcast.net Tue Mar 17 12:11:12 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B553A6980 for ; Tue, 17 Mar 2009 12:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZYREd4jB3kD for ; Tue, 17 Mar 2009 12:11:11 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 4F8F63A6A9E for ; Tue, 17 Mar 2009 12:11:11 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA03.westchester.pa.mail.comcast.net with comcast id UE9M1b09F0QuhwU53KBvHD; Tue, 17 Mar 2009 19:11:55 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id UKBu1b00X0UQ6dC3NKBunH; Tue, 17 Mar 2009 19:11:55 +0000 From: "David Harrington" To: "'Balazs Scheidler'" References: <98AE08B66FAD1742BED6CB9522B73122069493EA@xmb-rtp-20d.amer.cisco.com> <9B6E2A8877C38245BFB15CC491A11DA71FB7@GRFEXC.intern.adiscon.com> <0b5101c9a419$f22d4300$0600a8c0@china.huawei.com> <1237235375.27336.15.camel@bzorp.balabit> Date: Tue, 17 Mar 2009 15:11:53 -0400 Message-ID: <019001c9a734$3c0ddfd0$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 In-reply-to: <1237235375.27336.15.camel@bzorp.balabit> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: Acmmde+4+8TmPK82TxuOVz7lZ3GDuwAvOj3Q Cc: syslog@ietf.org Subject: Re: [Syslog] syslog RFCs X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 19:11:12 -0000 Hi, An implementation report needs to list the features in the standard, and those that have been implemented by the specific implementation. I suppose we should try to organize an interoperability test. I will put together a list of features for each of the RFCs, and post a report template to the list. Sample implementation reports can be found at http://www.ietf.org/IESG/implementation.html dbh > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu] > Sent: Monday, March 16, 2009 4:30 PM > To: David Harrington > Cc: 'Rainer Gerhards'; 'Anton Okmyanskiy (aokmians)'; syslog@ietf.org > Subject: Re: [Syslog] syslog RFCs > > On Fri, 2009-03-13 at 15:26 -0500, David Harrington wrote: > > Hi, > > > > If the implementers are willing to file a report on their > > implementation, we can advance the documents to Draft Standard. > > The reports need to identify whether the implementations > support each > > portion of the relevant specifications - the header format, > the SDEs, > > the various security mechanisms, etc. > > > > If you are an implemneter willing to file a report, let me > know and I > > will help explain the process to be followed. > > > > If you are a deployer, and willing to file a report of your > deployment > > experience for these standards, we may be able to advance the drafts > > to Full Standard. > > > > I might be interested with syslog-ng. Can you point me to the right > direction how such a report is written and submitted? > > -- > Bazsi > > > From lists@mschuette.name Thu Mar 19 13:14:56 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A395328C0FE for ; Thu, 19 Mar 2009 13:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LLilFgTWpj0 for ; Thu, 19 Mar 2009 13:14:56 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id D44333A69F7 for ; Thu, 19 Mar 2009 13:14:55 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id CDF6D9622A for ; Thu, 19 Mar 2009 21:15:39 +0100 (CET) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id Q1Me7bSPFp6G for ; Thu, 19 Mar 2009 21:15:28 +0100 (CET) Received: from cordelia.mschuette.name (BAEe897.bae.pppool.de [77.132.232.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 5D2DE794CB for ; Thu, 19 Mar 2009 21:15:27 +0100 (CET) Message-ID: <49C2A7DD.8020506@mschuette.name> Date: Thu, 19 Mar 2009 21:15:25 +0100 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.19 (X11/20090216) MIME-Version: 1.0 To: syslog@ietf.org References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com> <85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 20:14:56 -0000 Alexander Clemm (alex) schrieb: > On the first item, yes, the first item (RSID) is clearly a counter; a > time stamp cannot be used, nor can a value that is arbitrarily > generated. > > To use a time stamp would require a parameter that is differently > defined than the current RSID. Excuse my persistance here, but: why? Especially if they do not have to be sequential. Is there any reason to define RSID as a counter instead of an increasing ID? When is a counter like 1-2-5-6 better than IDs like 1234400000-1234500000-1234600000-12374700000? -- Martin From web-usrn@ISI.EDU Thu Mar 19 15:15:38 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2924D3A6BF7 for ; Thu, 19 Mar 2009 15:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.245 X-Spam-Level: X-Spam-Status: No, score=-17.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJjiaq8afWne for ; Thu, 19 Mar 2009 15:15:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 528E53A6902 for ; Thu, 19 Mar 2009 15:15:37 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2JMFZ5w000879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Mar 2009 15:15:36 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n2JMFYoQ000856; Thu, 19 Mar 2009 15:15:34 -0700 (PDT) Date: Thu, 19 Mar 2009 15:15:34 -0700 (PDT) Message-Id: <200903192215.n2JMFYoQ000856@boreas.isi.edu> To: miaofy@huawei.com, myz@huawei.com, jsalowey@cisco.com, tim.polk@nist.gov, pasi.eronen@nokia.com, clonvick@cisco.com, ietfdbh@comcast.net From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Fri, 20 Mar 2009 18:41:43 -0700 Cc: ah@TR-Sys.de, syslog@ietf.org, rfc-editor@rfc-editor.org Subject: [Syslog] [Editorial Errata Reported] RFC5425 (1733) X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 22:15:38 -0000 The following errata report has been submitted for RFC5425, "Transport Layer Security (TLS) Transport Mapping for Syslog". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5425&eid=1733 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 4.2.1, pg.6 Original Text ------------- o End-entity certificate matching: The transport sender or receiver is configured with information necessary to identify the valid end-entity certificates of its authorized peers. The end-entity certificates can be self-signed, and no certification path validation is needed. Implementations MUST support certificate | fingerprints in Section 4.2.2 and MAY allow other formats for end-entity certificates such as a DER-encoded certificate. This method provides an alternative to a PKI that is simple to deploy and still maintains a reasonable level of security. Corrected Text -------------- o End-entity certificate matching: The transport sender or receiver is configured with information necessary to identify the valid end-entity certificates of its authorized peers. The end-entity certificates can be self-signed, and no certification path validation is needed. Implementations MUST support certificate | fingerprints as specified in Section 4.2.2 and MAY allow other ^^^^^^^^^^^^^ formats for end-entity certificates such as a DER-encoded certificate. This method provides an alternative to a PKI that is simple to deploy and still maintains a reasonable level of security. Notes ----- Clarification; keep for update! Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5425 (draft-ietf-syslog-transport-tls-14) -------------------------------------- Title : Transport Layer Security (TLS) Transport Mapping for Syslog Publication Date : March 2009 Author(s) : F. Miao, Ed., Y. Ma, Ed., J. Salowey, Ed. Category : PROPOSED STANDARD Source : Security Issues in Network Event Logging Area : Security Stream : IETF Verifying Party : IESG From web-usrn@ISI.EDU Thu Mar 19 15:18:21 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33933A6988 for ; Thu, 19 Mar 2009 15:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.248 X-Spam-Level: X-Spam-Status: No, score=-17.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFtdsm1oRzc3 for ; Thu, 19 Mar 2009 15:18:20 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id C5E963A6902 for ; Thu, 19 Mar 2009 15:18:20 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2JMHcN0001282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Mar 2009 15:17:39 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n2JMHcM0001281; Thu, 19 Mar 2009 15:17:38 -0700 (PDT) Date: Thu, 19 Mar 2009 15:17:38 -0700 (PDT) Message-Id: <200903192217.n2JMHcM0001281@boreas.isi.edu> To: miaofy@huawei.com, myz@huawei.com, jsalowey@cisco.com, tim.polk@nist.gov, pasi.eronen@nokia.com, clonvick@cisco.com, ietfdbh@comcast.net From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Fri, 20 Mar 2009 18:41:43 -0700 Cc: ah@TR-Sys.de, syslog@ietf.org, rfc-editor@rfc-editor.org Subject: [Syslog] [Editorial Errata Reported] RFC5425 (1734) X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 22:18:21 -0000 The following errata report has been submitted for RFC5425, "Transport Layer Security (TLS) Transport Mapping for Syslog". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5425&eid=1734 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 5.1, pg.8 Original Text ------------- In the simplest case, the transport sender and receiver are | configured with information necessary to identity the valid end-entity certificates of its authorized peers. Corrected Text -------------- In the simplest case, the transport sender and receiver are | configured with information necessary to identify the valid end-entity certificates of its authorized peers. Notes ----- Typo: s/identity/identify/ ^ ^ (keep for update!) Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5425 (draft-ietf-syslog-transport-tls-14) -------------------------------------- Title : Transport Layer Security (TLS) Transport Mapping for Syslog Publication Date : March 2009 Author(s) : F. Miao, Ed., Y. Ma, Ed., J. Salowey, Ed. Category : PROPOSED STANDARD Source : Security Issues in Network Event Logging Area : Security Stream : IETF Verifying Party : IESG From alex@cisco.com Sun Mar 22 10:05:39 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D28E3A6A60 for ; Sun, 22 Mar 2009 10:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB6EtjYQ7qYf for ; Sun, 22 Mar 2009 10:05:38 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 651AA3A689C for ; Sun, 22 Mar 2009 10:05:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,403,1233532800"; d="scan'208";a="68519916" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2009 17:06:27 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2MH6REm024072; Sun, 22 Mar 2009 10:06:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n2MH6RmG010420; Sun, 22 Mar 2009 17:06:27 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Mar 2009 10:06:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Mar 2009 10:06:25 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com> In-Reply-To: <49C2A7DD.8020506@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Last minor clarifications/nits thread-index: Acmoz34OjcOdy3jJSJy7kyOvYzHzjAA0eaiw References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com> <49C2A7DD.8020506@mschuette.name> From: "Alexander Clemm (alex)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 22 Mar 2009 17:06:27.0497 (UTC) FILETIME=[89B58190:01C9AB10] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2543; t=1237741587; x=1238605587; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=20Last=20mino r=20clarifications/nits |Sender:=20; bh=oIOv2/DFDSyna5Ix6qAv8pJCfjfzGr4VqLDnfBsHjdA=; b=s28o3hbWrOvBeKV6qAPzlNK96sJgM2fwdL4ORSUo71ZS5kzC9zJgrQJ9Hc DvX1vADnLWrQGfnvt/XjwJdI4gCjF20UFmX4XA+gyjaRlNBUShyZf9DIfp2y vlWd+DWrcI; Authentication-Results: sj-dkim-4; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 17:05:39 -0000 Hello Martin, I have clarified in the text that what I think it is you are suggesting = will be allowed. But it is not a time stamp. A time stamp would be = something like 2008-10-16T20:23:03+02:00. =20 While it still suggests that the RSID should increase by 1, it is not = required. It is merely required to simply increase (no problem with an = RSID reflecting a "time stamp"), unless it is set to 0. Here is what = the section in question reads now: The Reboot Session ID is a decimal value that has a length between 1 and 10 octets. The acceptable values for this are between 0 and 9999999999. Leading zeroes MUST be omitted. A Reboot Session ID is expected to increase whenever an originator reboots in order to allow collectors to distinguish messages and message signatures across reboots. The Reboot Session ID SHOULD increase by 1, starting with a value of 1. Note that in this case, an originator is required to retain the previous Reboot Session ID across reboots. In cases where an originator is not able to guarantee that the Reboot Session ID is always increased after a reboot, the Reboot Session ID MUST always be set to a value of 0. If the value can no longer be increased (e.g., because it reaches 9999999999), then manual intervention may be required to subsequently reset it. Implementors MAY wish to consider using the snmpEngineBoots value as a source for this counter as defined in [RFC3414]. Does this accommodate your concern? --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf = Of Martin Sch=FCtte Sent: Thursday, March 19, 2009 1:15 PM To: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits Alexander Clemm (alex) schrieb: > On the first item, yes, the first item (RSID) is clearly a counter; a > time stamp cannot be used, nor can a value that is arbitrarily > generated. =20 >=20 > To use a time stamp would require a parameter that is differently > defined than the current RSID. Excuse my persistance here, but: why? Especially if they do not have to be sequential. Is there any reason to define RSID as a counter instead of an increasing = ID? When is a counter like 1-2-5-6 better than IDs like=20 1234400000-1234500000-1234600000-12374700000? --=20 Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From Pasi.Eronen@nokia.com Sun Mar 22 14:11:33 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6863A6ACF for ; Sun, 22 Mar 2009 14:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-KBt3OsHBTL for ; Sun, 22 Mar 2009 14:11:31 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id BA34D3A6814 for ; Sun, 22 Mar 2009 14:11:28 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2MLCEsC010498; Sun, 22 Mar 2009 16:12:15 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Mar 2009 23:12:07 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Mar 2009 23:12:06 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sun, 22 Mar 2009 22:12:06 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Sun, 22 Mar 2009 22:12:06 +0100 From: To: , Date: Sun, 22 Mar 2009 22:12:02 +0100 Thread-Topic: [Syslog] Syslog-sign: Last minor clarifications/nits Thread-Index: Acmoz34OjcOdy3jJSJy7kyOvYzHzjAA0eaiwAGQ6O2A= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com> <49C2A7DD.8020506@mschuette.name> <85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Mar 2009 21:12:06.0776 (UTC) FILETIME=[DB00FF80:01C9AB32] X-Nokia-AV: Clean Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 21:11:33 -0000 Hi Alex, By "timestamp", at least I've meant "POSIX timestamp (seconds since 1/1/1970) when the syslog daemon started". But even with the new text, I'm still having trouble determining whether this would be=20 an acceptable value for RSID... Best regards, Pasi > -----Original Message----- > From: syslog-bounces@ietf.org=20 > [mailto:syslog-bounces@ietf.org] On Behalf Of ext Alexander=20 > Clemm (alex) > Sent: 22 March, 2009 19:06 > To: Martin Sch=FCtte; syslog@ietf.org > Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits >=20 > Hello Martin, >=20 > I have clarified in the text that what I think it is you are > suggesting will be allowed. But it is not a time stamp. A time > stamp would be something like 2008-10-16T20:23:03+02:00. >=20 > While it still suggests that the RSID should increase by 1, it is > not required. It is merely required to simply increase (no problem > with an RSID reflecting a "time stamp"), unless it is set to 0. > Here is what the section in question reads now: >=20 > The Reboot Session ID is a decimal value that has a length > between 1 and 10 octets. The acceptable values for this are > between 0 and 9999999999. Leading zeroes MUST be omitted. >=20 > A Reboot Session ID is expected to increase whenever an originator > reboots in order to allow collectors to distinguish messages and > message signatures across reboots. The Reboot Session ID SHOULD > increase by 1, starting with a value of 1. Note that in this case, > an originator is required to retain the previous Reboot Session ID > across reboots. >=20 > In cases where an originator is not able to guarantee that the > Reboot Session ID is always increased after a reboot, the Reboot > Session ID MUST always be set to a value of 0. If the value can > no longer be increased (e.g., because it reaches 9999999999), > then manual intervention may be required to subsequently reset > it. Implementors MAY wish to consider using the snmpEngineBoots > value as a source for this counter as defined in [RFC3414]. >=20 > Does this accommodate your concern? > --- Alex >=20 > -----Original Message----- > From: syslog-bounces@ietf.org=20 > [mailto:syslog-bounces@ietf.org] On Behalf Of Martin Sch=FCtte > Sent: Thursday, March 19, 2009 1:15 PM > To: syslog@ietf.org > Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits >=20 > Alexander Clemm (alex) schrieb: > > On the first item, yes, the first item (RSID) is clearly a=20 > counter; a > > time stamp cannot be used, nor can a value that is arbitrarily > > generated. =20 > >=20 > > To use a time stamp would require a parameter that is differently > > defined than the current RSID. >=20 > Excuse my persistance here, but: why? > Especially if they do not have to be sequential. >=20 > Is there any reason to define RSID as a counter instead of an=20 > increasing=20 > ID? When is a counter like 1-2-5-6 better than IDs like=20 > 1234400000-1234500000-1234600000-12374700000? >=20 > --=20 > Martin > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog >=20 From clonvick@cisco.com Sun Mar 22 15:09:08 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2737B3A68BC for ; Sun, 22 Mar 2009 15:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjNr9s9OnQRU for ; Sun, 22 Mar 2009 15:09:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 02A963A68AC for ; Sun, 22 Mar 2009 15:09:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,403,1233532800"; d="scan'208";a="272146220" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Mar 2009 22:09:56 +0000 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 n2MM9u18028733; Sun, 22 Mar 2009 15:09:56 -0700 Received: from sjc-cde-010.cisco.com (sjc-cde-010.cisco.com [128.107.183.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2MM9use028008; Sun, 22 Mar 2009 22:09:56 GMT Date: Sun, 22 Mar 2009 15:09:56 -0700 (PDT) From: Chris Lonvick To: Pasi.Eronen@nokia.com In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com> Message-ID: References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com> <49C2A7DD.8020506@mschuette.name> <85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com> <808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-832100416-1237759796=:7887" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5658; t=1237759796; x=1238623796; 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]=20Syslog-sign=3A=20Last=20mino r=20clarifications/nits |Sender:=20; bh=5Zq4dKizIBCmzyl5MnM/6j9LIvIT6hkWKFHm74e1hDA=; b=iVV+9XSbb0CnJGzpYOA4CipkeVA1ictiBvumj74Bojj+LB0F5OuyCa5xLc V0VfiR/dojMXSIh7iIQ6uWLym/n13Y36Jh77fVgopGWsCnPD+8BpT1BqjqVa ScUvFHwIjg; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 22:09:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-832100416-1237759796=:7887 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, There does seem to be some conflicts in the section; if it SHOULD start=20 with 1 and increment by 1 then how do we get to SnmpEngineReboots? PROPOSED: =3D=3D=3D 4.2.2. Reboot Session ID The Reboot Session ID is a decimal value that has a length between 1 and 10 octets. The acceptable values for this are between 0 and 9999999999. Leading zeroes MUST be omitted. A Reboot Session ID is expected to increase whenever an originator reboots in order to allow collectors to distinguish messages and message signatures across reboots. There are several ways in which this may be accomplished. In one way, the Reboot Session ID may increase by 1, starting with a value of 1. Note that in this case, an originator is required to retain the previous Reboot Session ID across reboots. In another way, a value of the unix time (number of seconds since 1 January 1970 [reference?] may be used. In yet another way, implementors wish to consider using the snmpEngineBoots value as a source for this counter as defined in [RFC3414]. In cases where an originator is not able to guarantee that the Reboot Session ID is always increased after a reboot, the Reboot Session ID MUST always be set to a value of 0. If the value can no longer be increased (e.g., because it reaches 9999999999), then manual intervention may be required to subsequently reset it. If a reboot of an originator takes place, Signature Block messages MAY use a new PROCID. However, Signature Block messages of the same originator MUST continue to use the same APP-NAME and MSGID. =3D=3D=3D Does this work for everyone? Thanks, Chris On Sun, 22 Mar 2009, Pasi.Eronen@nokia.com wrote: > > Hi Alex, > > By "timestamp", at least I've meant "POSIX timestamp (seconds since > 1/1/1970) when the syslog daemon started". But even with the new > text, I'm still having trouble determining whether this would be > an acceptable value for RSID... > > Best regards, > Pasi > >> -----Original Message----- >> From: syslog-bounces@ietf.org >> [mailto:syslog-bounces@ietf.org] On Behalf Of ext Alexander >> Clemm (alex) >> Sent: 22 March, 2009 19:06 >> To: Martin Sch=FCtte; syslog@ietf.org >> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits >> >> Hello Martin, >> >> I have clarified in the text that what I think it is you are >> suggesting will be allowed. But it is not a time stamp. A time >> stamp would be something like 2008-10-16T20:23:03+02:00. >> >> While it still suggests that the RSID should increase by 1, it is >> not required. It is merely required to simply increase (no problem >> with an RSID reflecting a "time stamp"), unless it is set to 0. >> Here is what the section in question reads now: >> >> The Reboot Session ID is a decimal value that has a length >> between 1 and 10 octets. The acceptable values for this are >> between 0 and 9999999999. Leading zeroes MUST be omitted. >> >> A Reboot Session ID is expected to increase whenever an originator >> reboots in order to allow collectors to distinguish messages and >> message signatures across reboots. The Reboot Session ID SHOULD >> increase by 1, starting with a value of 1. Note that in this case, >> an originator is required to retain the previous Reboot Session ID >> across reboots. >> >> In cases where an originator is not able to guarantee that the >> Reboot Session ID is always increased after a reboot, the Reboot >> Session ID MUST always be set to a value of 0. If the value can >> no longer be increased (e.g., because it reaches 9999999999), >> then manual intervention may be required to subsequently reset >> it. Implementors MAY wish to consider using the snmpEngineBoots >> value as a source for this counter as defined in [RFC3414]. >> >> Does this accommodate your concern? >> --- Alex >> >> -----Original Message----- >> From: syslog-bounces@ietf.org >> [mailto:syslog-bounces@ietf.org] On Behalf Of Martin Sch=FCtte >> Sent: Thursday, March 19, 2009 1:15 PM >> To: syslog@ietf.org >> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits >> >> Alexander Clemm (alex) schrieb: >>> On the first item, yes, the first item (RSID) is clearly a >> counter; a >>> time stamp cannot be used, nor can a value that is arbitrarily >>> generated. >>> >>> To use a time stamp would require a parameter that is differently >>> defined than the current RSID. >> >> Excuse my persistance here, but: why? >> Especially if they do not have to be sequential. >> >> Is there any reason to define RSID as a counter instead of an >> increasing >> ID? When is a counter like 1-2-5-6 better than IDs like >> 1234400000-1234500000-1234600000-12374700000? >> >> -- >> Martin >> _______________________________________________ >> Syslog mailing list >> Syslog@ietf.org >> https://www.ietf.org/mailman/listinfo/syslog >> _______________________________________________ >> Syslog mailing list >> Syslog@ietf.org >> https://www.ietf.org/mailman/listinfo/syslog >> > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > ---559023410-832100416-1237759796=:7887-- From rgerhards@hq.adiscon.com Mon Mar 23 02:14:50 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5793A6B9B for ; Mon, 23 Mar 2009 02:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yvQZBrWAiMU for ; Mon, 23 Mar 2009 02:14:49 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 83A243A6BB4 for ; Mon, 23 Mar 2009 02:14:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 69202241C004; Mon, 23 Mar 2009 10:14:09 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOd+Kro3kBRF; Mon, 23 Mar 2009 10:14:09 +0100 (CET) Received: from GRFEXC.intern.adiscon.com (p54AC529E.dip.t-dialin.net [84.172.82.158]) by mailin.adiscon.com (Postfix) with ESMTP id 32DCE241C001; Mon, 23 Mar 2009 10:14:08 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Mar 2009 10:15:34 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9B6E2A8877C38245BFB15CC491A11DA702AD5A@GRFEXC.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Last minor clarifications/nits Thread-index: AcmrOwHXMjCY3a1+TjGvCUQDyO56BAAWhHNQ References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com><49C2A7DD.8020506@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com><808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com> From: "Rainer Gerhards" To: "Chris Lonvick" Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 09:14:50 -0000 > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of Chris Lonvick > Sent: Sunday, March 22, 2009 11:10 PM > To: Pasi.Eronen@nokia.com > Cc: syslog@ietf.org > Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits >=20 > Hi, >=20 > There does seem to be some conflicts in the section; if it SHOULD = start > with 1 and increment by 1 then how do we get to SnmpEngineReboots? What if we just say "must start at 1 and be strictly monotonically increasing"? I think this is the essence of what we need and permits any value to be used as seed as long as it can be assured that a higher RSID = will be emitted later in time than a lower one. This would also permit any = other second-counting time base reference to be used, e.g. = creation/compilation date of the software in question. If we refer to the POSIX timestamp, I am not sure if we refer to the 32 = or 64 Bit version of it (I even think I remember the bitness is not = preciesley defined?). In any case, we have subtle issues: if we talk about 32 bit, = the well-known 2038 problem is carried over to this draft. While 28 more = years to go sound reasonable, I'd still think it is worth pointing out. With 64 = Bit, the RSID will latch ~ 2110 when 64 bit Unix time goes beyond = 9,999,999,999 - that is probably not a real concern ;) With any time-based counter based on seconds, there is always the subtle issue of two or more restarts within a single second, which means the = RSID will not necessarily be strictly monotonically increasing. While the probability is (very) low for this case, it is not 0. So we cannot = outrule it. I have not yet checked if that can lead to permanent problems = (counters related to RSID which may occur twice). SNMP, as I understand RFC3414, seems to have solved this by requiring = the device to actually increment the counter and store it in non-volatile = memory. I think this is a good compromise and would suggest the we mandate this, = too, except that we permit any increment as long as the resulting sequence = will be strictly monotonically increasing (this is necessary to permit simply = copying over the SNMPEngineBoots counter from the SNMP subsystem, if syslogd has access to it). Also, RFC 3414 uses 2147483647 as a special value, while we use 0. I = suggest that we use 2147483647, too. Otherwise, a naive implementation may = forget to convert 2147483647 to 0 when copying over the SNMPEngineBoots from the = SNMP engine (this sounds natural to do if the syslogd has access to a SNMP subsystem). Rainer >=20 > PROPOSED: > =3D=3D=3D > 4.2.2. Reboot Session ID >=20 > The Reboot Session ID is a decimal value that has a length between > 1 > and 10 octets. The acceptable values for this are between 0 and > 9999999999. Leading zeroes MUST be omitted. >=20 > A Reboot Session ID is expected to increase whenever an originator > reboots in order to allow collectors to distinguish messages and > message signatures across reboots. There are several ways in = which > this may be accomplished. In one way, the Reboot Session ID may > increase by 1, starting with a value of 1. Note that in this = case, > an > originator is required to retain the previous Reboot Session ID > across > reboots. In another way, a value of the unix time (number of > seconds > since 1 January 1970 [reference?] may be used. In yet another = way, > implementors wish to consider using the snmpEngineBoots value as a > source for this counter as defined in [RFC3414]. >=20 > In cases where an originator is not able to guarantee that the > Reboot > Session ID is always increased after a reboot, the Reboot Session > ID > MUST always be set to a value of 0. If the value can no longer be > increased (e.g., because it reaches 9999999999), then manual > intervention may be required to subsequently reset it. >=20 > If a reboot of an originator takes place, Signature Block messages > MAY use a new PROCID. However, Signature Block messages of the > same > originator MUST continue to use the same APP-NAME and MSGID. > =3D=3D=3D >=20 > Does this work for everyone? >=20 > Thanks, > Chris >=20 > On Sun, 22 Mar 2009, Pasi.Eronen@nokia.com wrote: >=20 > > > > Hi Alex, > > > > By "timestamp", at least I've meant "POSIX timestamp (seconds since > > 1/1/1970) when the syslog daemon started". But even with the new > > text, I'm still having trouble determining whether this would be > > an acceptable value for RSID... > > > > Best regards, > > Pasi > > > >> -----Original Message----- > >> From: syslog-bounces@ietf.org > >> [mailto:syslog-bounces@ietf.org] On Behalf Of ext Alexander > >> Clemm (alex) > >> Sent: 22 March, 2009 19:06 > >> To: Martin Sch=FCtte; syslog@ietf.org > >> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > >> > >> Hello Martin, > >> > >> I have clarified in the text that what I think it is you are > >> suggesting will be allowed. But it is not a time stamp. A time > >> stamp would be something like 2008-10-16T20:23:03+02:00. > >> > >> While it still suggests that the RSID should increase by 1, it is > >> not required. It is merely required to simply increase (no problem > >> with an RSID reflecting a "time stamp"), unless it is set to 0. > >> Here is what the section in question reads now: > >> > >> The Reboot Session ID is a decimal value that has a length > >> between 1 and 10 octets. The acceptable values for this are > >> between 0 and 9999999999. Leading zeroes MUST be omitted. > >> > >> A Reboot Session ID is expected to increase whenever an > originator > >> reboots in order to allow collectors to distinguish messages and > >> message signatures across reboots. The Reboot Session ID SHOULD > >> increase by 1, starting with a value of 1. Note that in this > case, > >> an originator is required to retain the previous Reboot Session > ID > >> across reboots. > >> > >> In cases where an originator is not able to guarantee that the > >> Reboot Session ID is always increased after a reboot, the Reboot > >> Session ID MUST always be set to a value of 0. If the value can > >> no longer be increased (e.g., because it reaches 9999999999), > >> then manual intervention may be required to subsequently reset > >> it. Implementors MAY wish to consider using the snmpEngineBoots > >> value as a source for this counter as defined in [RFC3414]. > >> > >> Does this accommodate your concern? > >> --- Alex > >> > >> -----Original Message----- > >> From: syslog-bounces@ietf.org > >> [mailto:syslog-bounces@ietf.org] On Behalf Of Martin Sch=FCtte > >> Sent: Thursday, March 19, 2009 1:15 PM > >> To: syslog@ietf.org > >> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > >> > >> Alexander Clemm (alex) schrieb: > >>> On the first item, yes, the first item (RSID) is clearly a > >> counter; a > >>> time stamp cannot be used, nor can a value that is arbitrarily > >>> generated. > >>> > >>> To use a time stamp would require a parameter that is differently > >>> defined than the current RSID. > >> > >> Excuse my persistance here, but: why? > >> Especially if they do not have to be sequential. > >> > >> Is there any reason to define RSID as a counter instead of an > >> increasing > >> ID? When is a counter like 1-2-5-6 better than IDs like > >> 1234400000-1234500000-1234600000-12374700000? > >> > >> -- > >> Martin > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@ietf.org > >> https://www.ietf.org/mailman/listinfo/syslog > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@ietf.org > >> https://www.ietf.org/mailman/listinfo/syslog > >> > > > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > > From clonvick@cisco.com Mon Mar 23 06:43:18 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD5028C0FB for ; Mon, 23 Mar 2009 06:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbr4f8BqUq44 for ; Mon, 23 Mar 2009 06:43:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 29DD53A6922 for ; Mon, 23 Mar 2009 06:43:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,408,1233532800"; d="scan'208";a="145216609" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2009 13:44:07 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2NDi7r2020633; Mon, 23 Mar 2009 06:44:07 -0700 Received: from sjc-cde-010.cisco.com (sjc-cde-010.cisco.com [128.107.183.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2NDi7tv019665; Mon, 23 Mar 2009 13:44:07 GMT Date: Mon, 23 Mar 2009 06:44:07 -0700 (PDT) From: Chris Lonvick To: Rainer Gerhards In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA702AD5A@GRFEXC.intern.adiscon.com> Message-ID: References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com><49C2A7DD.8020506@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com><808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com> <9B6E2A8877C38245BFB15CC491A11DA702AD5A@GRFEXC.intern.adiscon.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1903590565-1237813943=:26659" Content-ID: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9780; t=1237815847; x=1238679847; 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]=20Syslog-sign=3A=20Last=20mino r=20clarifications/nits |Sender:=20; bh=E+BwrllDSZW33Hd3viDX2O6uulk+X+V3UIfjFqcnKI8=; b=qZRP+Ea3r/tNPahnr5aypup5PyEhGSnVoSe0/M2x4VusNsNQCFQO+2vPHN zmf3L3EPOe5kE4pUyMJrDpO9ulGx8hIhw8rv9xqXGTbkN2P5aLuJi5Lr6cRr 5F2ebe/J7Q; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:43:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1903590565-1237813943=:26659 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Rainer, Comments in line. On Mon, 23 Mar 2009, Rainer Gerhards wrote: > > >> -----Original Message----- >> From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On >> Behalf Of Chris Lonvick >> Sent: Sunday, March 22, 2009 11:10 PM >> To: Pasi.Eronen@nokia.com >> Cc: syslog@ietf.org >> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits >> >> Hi, >> >> There does seem to be some conflicts in the section; if it SHOULD start >> with 1 and increment by 1 then how do we get to SnmpEngineReboots? > > What if we just say "must start at 1 and be strictly monotonically > increasing"? I think this is the essence of what we need and permits any > value to be used as seed as long as it can be assured that a higher RSID = will > be emitted later in time than a lower one. This would also permit any oth= er > second-counting time base reference to be used, e.g. creation/compilation > date of the software in question. I'm OK with most of that. I wouldn't require it to start at "1" however.= =20 I'd assume that some sort of timestamp value may be used, or that if snmpEngineBoots is used then it is already past "1". > > If we refer to the POSIX timestamp, I am not sure if we refer to the 32 = or > 64 Bit version of it (I even think I remember the bitness is not preciesl= ey > defined?). In any case, we have subtle issues: if we talk about 32 bit, t= he > well-known 2038 problem is carried over to this draft. While 28 more year= s to > go sound reasonable, I'd still think it is worth pointing out. With 64 Bi= t, > the RSID will latch ~ 2110 when 64 bit Unix time goes beyond 9,999,999,99= 9 - > that is probably not a real concern ;) I see your point but that's outside of our scope to solve. :-) If we=20 have some verbiage in the document talking about using a time-based value= =20 for RSID, then at most we should have a line in the security=20 considerations section telling the implementer to be aware. > > With any time-based counter based on seconds, there is always the subtle > issue of two or more restarts within a single second, which means the RSI= D > will not necessarily be strictly monotonically increasing. While the > probability is (very) low for this case, it is not 0. So we cannot outrul= e > it. I have not yet checked if that can lead to permanent problems (counte= rs > related to RSID which may occur twice). Agreed. Again, an implementer would have to beware of that issue if they= =20 chose a time-based value. > > SNMP, as I understand RFC3414, seems to have solved this by requiring the > device to actually increment the counter and store it in non-volatile mem= ory. > I think this is a good compromise and would suggest the we mandate this, = too, > except that we permit any increment as long as the resulting sequence wil= l be > strictly monotonically increasing (this is necessary to permit simply cop= ying > over the SNMPEngineBoots counter from the SNMP subsystem, if syslogd has > access to it). This sounds good. ..I'm trying to remember if this is what was first=20 discussed for RSID when John Kelsey first proposed a counter for this. > > Also, RFC 3414 uses 2147483647 as a special value, while we use 0. I sug= gest > that we use 2147483647, too. Otherwise, a naive implementation may forget= to > convert 2147483647 to 0 when copying over the SNMPEngineBoots from the SN= MP > engine (this sounds natural to do if the syslogd has access to a SNMP > subsystem). I disagree on that. 2147483647 is the largest 32bit unsigned integer -=20 I'm guessing that's the reason it was chosen for 3414. If devices use a=20 64bit field (or larger) to store their RSID value then they will have to=20 proactively avoid using 2147483647. Thanks, Chris > > Rainer > >> >> PROPOSED: >> =3D=3D=3D >> 4.2.2. Reboot Session ID >> >> The Reboot Session ID is a decimal value that has a length between >> 1 >> and 10 octets. The acceptable values for this are between 0 and >> 9999999999. Leading zeroes MUST be omitted. >> >> A Reboot Session ID is expected to increase whenever an originator >> reboots in order to allow collectors to distinguish messages and >> message signatures across reboots. There are several ways in which >> this may be accomplished. In one way, the Reboot Session ID may >> increase by 1, starting with a value of 1. Note that in this case, >> an >> originator is required to retain the previous Reboot Session ID >> across >> reboots. In another way, a value of the unix time (number of >> seconds >> since 1 January 1970 [reference?] may be used. In yet another way, >> implementors wish to consider using the snmpEngineBoots value as a >> source for this counter as defined in [RFC3414]. >> >> In cases where an originator is not able to guarantee that the >> Reboot >> Session ID is always increased after a reboot, the Reboot Session >> ID >> MUST always be set to a value of 0. If the value can no longer be >> increased (e.g., because it reaches 9999999999), then manual >> intervention may be required to subsequently reset it. >> >> If a reboot of an originator takes place, Signature Block messages >> MAY use a new PROCID. However, Signature Block messages of the >> same >> originator MUST continue to use the same APP-NAME and MSGID. >> =3D=3D=3D >> >> Does this work for everyone? >> >> Thanks, >> Chris >> >> On Sun, 22 Mar 2009, Pasi.Eronen@nokia.com wrote: >> >>> >>> Hi Alex, >>> >>> By "timestamp", at least I've meant "POSIX timestamp (seconds since >>> 1/1/1970) when the syslog daemon started". But even with the new >>> text, I'm still having trouble determining whether this would be >>> an acceptable value for RSID... >>> >>> Best regards, >>> Pasi >>> >>>> -----Original Message----- >>>> From: syslog-bounces@ietf.org >>>> [mailto:syslog-bounces@ietf.org] On Behalf Of ext Alexander >>>> Clemm (alex) >>>> Sent: 22 March, 2009 19:06 >>>> To: Martin Sch=FCtte; syslog@ietf.org >>>> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits >>>> >>>> Hello Martin, >>>> >>>> I have clarified in the text that what I think it is you are >>>> suggesting will be allowed. But it is not a time stamp. A time >>>> stamp would be something like 2008-10-16T20:23:03+02:00. >>>> >>>> While it still suggests that the RSID should increase by 1, it is >>>> not required. It is merely required to simply increase (no problem >>>> with an RSID reflecting a "time stamp"), unless it is set to 0. >>>> Here is what the section in question reads now: >>>> >>>> The Reboot Session ID is a decimal value that has a length >>>> between 1 and 10 octets. The acceptable values for this are >>>> between 0 and 9999999999. Leading zeroes MUST be omitted. >>>> >>>> A Reboot Session ID is expected to increase whenever an >> originator >>>> reboots in order to allow collectors to distinguish messages and >>>> message signatures across reboots. The Reboot Session ID SHOULD >>>> increase by 1, starting with a value of 1. Note that in this >> case, >>>> an originator is required to retain the previous Reboot Session >> ID >>>> across reboots. >>>> >>>> In cases where an originator is not able to guarantee that the >>>> Reboot Session ID is always increased after a reboot, the Reboot >>>> Session ID MUST always be set to a value of 0. If the value can >>>> no longer be increased (e.g., because it reaches 9999999999), >>>> then manual intervention may be required to subsequently reset >>>> it. Implementors MAY wish to consider using the snmpEngineBoots >>>> value as a source for this counter as defined in [RFC3414]. >>>> >>>> Does this accommodate your concern? >>>> --- Alex >>>> >>>> -----Original Message----- >>>> From: syslog-bounces@ietf.org >>>> [mailto:syslog-bounces@ietf.org] On Behalf Of Martin Sch=FCtte >>>> Sent: Thursday, March 19, 2009 1:15 PM >>>> To: syslog@ietf.org >>>> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits >>>> >>>> Alexander Clemm (alex) schrieb: >>>>> On the first item, yes, the first item (RSID) is clearly a >>>> counter; a >>>>> time stamp cannot be used, nor can a value that is arbitrarily >>>>> generated. >>>>> >>>>> To use a time stamp would require a parameter that is differently >>>>> defined than the current RSID. >>>> >>>> Excuse my persistance here, but: why? >>>> Especially if they do not have to be sequential. >>>> >>>> Is there any reason to define RSID as a counter instead of an >>>> increasing >>>> ID? When is a counter like 1-2-5-6 better than IDs like >>>> 1234400000-1234500000-1234600000-12374700000? >>>> >>>> -- >>>> Martin >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@ietf.org >>>> https://www.ietf.org/mailman/listinfo/syslog >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@ietf.org >>>> https://www.ietf.org/mailman/listinfo/syslog >>>> >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@ietf.org >>> https://www.ietf.org/mailman/listinfo/syslog >>> > ---559023410-1903590565-1237813943=:26659-- From rgerhards@hq.adiscon.com Mon Mar 23 06:47:55 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973743A685C for ; Mon, 23 Mar 2009 06:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fc4AoJypslyn for ; Mon, 23 Mar 2009 06:47:54 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 6250E28C10E for ; Mon, 23 Mar 2009 06:47:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 93DC3241C004; Mon, 23 Mar 2009 14:48:07 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3VRTOKmLFhW; Mon, 23 Mar 2009 14:48:07 +0100 (CET) Received: from GRFEXC.intern.adiscon.com (p54AC529E.dip.t-dialin.net [84.172.82.158]) by mailin.adiscon.com (Postfix) with ESMTP id BA176241C001; Mon, 23 Mar 2009 14:48:06 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Mar 2009 14:48:37 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9B6E2A8877C38245BFB15CC491A11DA702AD5F@GRFEXC.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Last minor clarifications/nits Thread-index: AcmrvYTIaqWZjOjrShGDNOTsJECpjwAADkuw References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com><49C2A7DD.8020506@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com><808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com> <9B6E2A8877C38245BFB15CC491A11DA702AD5A@GRFEXC.intern.adiscon.com> From: "Rainer Gerhards" To: "Chris Lonvick" Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:47:55 -0000 Chris, > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Monday, March 23, 2009 2:44 PM > To: Rainer Gerhards > Cc: Pasi.Eronen@nokia.com; syslog@ietf.org > Subject: RE: [Syslog] Syslog-sign: Last minor clarifications/nits >=20 > Hi Rainer, >=20 > Comments in line. >=20 > On Mon, 23 Mar 2009, Rainer Gerhards wrote: >=20 > > > > > >> -----Original Message----- > >> From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > >> Behalf Of Chris Lonvick > >> Sent: Sunday, March 22, 2009 11:10 PM > >> To: Pasi.Eronen@nokia.com > >> Cc: syslog@ietf.org > >> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > >> > >> Hi, > >> > >> There does seem to be some conflicts in the section; if it SHOULD > start > >> with 1 and increment by 1 then how do we get to SnmpEngineReboots? > > > > What if we just say "must start at 1 and be strictly monotonically > > increasing"? I think this is the essence of what we need and permits > any > > value to be used as seed as long as it can be assured that a higher > RSID will > > be emitted later in time than a lower one. This would also permit = any > other > > second-counting time base reference to be used, e.g. > creation/compilation > > date of the software in question. >=20 > I'm OK with most of that. I wouldn't require it to start at "1" > however. > I'd assume that some sort of timestamp value may be used, or that if > snmpEngineBoots is used then it is already past "1". >=20 > > > > If we refer to the POSIX timestamp, I am not sure if we refer to the > 32 or > > 64 Bit version of it (I even think I remember the bitness is not > preciesley > > defined?). In any case, we have subtle issues: if we talk about 32 > bit, the > > well-known 2038 problem is carried over to this draft. While 28 more > years to > > go sound reasonable, I'd still think it is worth pointing out. With > 64 Bit, > > the RSID will latch ~ 2110 when 64 bit Unix time goes beyond > 9,999,999,999 - > > that is probably not a real concern ;) >=20 > I see your point but that's outside of our scope to solve. :-) If we > have some verbiage in the document talking about using a time-based > value > for RSID, then at most we should have a line in the security > considerations section telling the implementer to be aware. >=20 > > > > With any time-based counter based on seconds, there is always the > subtle > > issue of two or more restarts within a single second, which means = the > RSID > > will not necessarily be strictly monotonically increasing. While the > > probability is (very) low for this case, it is not 0. So we cannot > outrule > > it. I have not yet checked if that can lead to permanent problems > (counters > > related to RSID which may occur twice). >=20 > Agreed. Again, an implementer would have to beware of that issue if > they > chose a time-based value. >=20 > > > > SNMP, as I understand RFC3414, seems to have solved this by = requiring > the > > device to actually increment the counter and store it in = non-volatile > memory. > > I think this is a good compromise and would suggest the we mandate > this, too, > > except that we permit any increment as long as the resulting = sequence > will be > > strictly monotonically increasing (this is necessary to permit = simply > copying > > over the SNMPEngineBoots counter from the SNMP subsystem, if syslogd > has > > access to it). >=20 > This sounds good. ..I'm trying to remember if this is what was first > discussed for RSID when John Kelsey first proposed a counter for this. >=20 > > > > Also, RFC 3414 uses 2147483647 as a special value, while we use 0. = I > suggest > > that we use 2147483647, too. Otherwise, a naive implementation may > forget to > > convert 2147483647 to 0 when copying over the SNMPEngineBoots from > the SNMP > > engine (this sounds natural to do if the syslogd has access to a = SNMP > > subsystem). >=20 > I disagree on that. 2147483647 is the largest 32bit unsigned integer = - > I'm guessing that's the reason it was chosen for 3414. If devices use > a > 64bit field (or larger) to store their RSID value then they will have > to > proactively avoid using 2147483647. >=20 You are right - at that point I overlooked that we are not latching at 2^31-1. It does definitely not make sense to use some value right in the middle of the interval for a special case. Please disregard my = suggestion. Rainer From jon@callas.org Mon Mar 23 11:11:07 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5275428C20A for ; Mon, 23 Mar 2009 11:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Uxcze9Ruq+e for ; Mon, 23 Mar 2009 11:11:06 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by core3.amsl.com (Postfix) with ESMTP id 592913A69A2 for ; Mon, 23 Mar 2009 11:11:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id CA1012E4CC; Mon, 23 Mar 2009 11:13:51 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 79648-01; Mon, 23 Mar 2009 11:13:46 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 505232E0A8; Mon, 23 Mar 2009 11:13:46 -0700 (PDT) Received: from titania.merrymeet.com ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Mon, 23 Mar 2009 11:11:50 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 23 Mar 2009 11:11:50 -0700 Message-Id: <68BF89E6-77A8-42FE-990E-E46A2EB9CC3F@callas.org> From: Jon Callas To: Chris Lonvick In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Mar 2009 11:11:43 -0700 References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com><49C2A7DD.8020506@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com><808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com> <9B6E2A8877C38245BFB15CC491A11DA702AD5A@GRFEXC.intern.adiscon.com> X-Mailer: Apple Mail (2.930.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 18:11:07 -0000 >> >> SNMP, as I understand RFC3414, seems to have solved this by >> requiring the >> device to actually increment the counter and store it in non- >> volatile memory. >> I think this is a good compromise and would suggest the we mandate >> this, too, >> except that we permit any increment as long as the resulting >> sequence will be >> strictly monotonically increasing (this is necessary to permit >> simply copying >> over the SNMPEngineBoots counter from the SNMP subsystem, if >> syslogd has >> access to it). > > This sounds good. ..I'm trying to remember if this is what was > first discussed for RSID when John Kelsey first proposed a counter > for this. The original intent of RSID is an opaque unique value that could be used in a number of ways. It had no original semantics, beyond the obvious ones needed for a counter. Later, you and I observed that a timer more-or-less works as it's monotonically increasing and thus not going to repeat. We added in the SNMP things in Jan 2002. Here's text: 4.2.2. Reboot Session ID .... A Reboot Session ID is expected to increase whenever an originator reboots in order to allow collectors to distinguish messages and message signatures across reboots. Hence, an originator needs to retain the previous Reboot Session ID across reboots. ..... If the value reaches 9999999999, then manual intervention may be required to subsequently reset it to 1. Implementors MAY wish to consider using the snmpEngineBoots value as a source for this counter as defined in [RFC3414]. Kelsey's solo -01 draft says in its entirety: 2.3.4 Reboot Session ID The reboot session ID is a 48-bit quantity encoded in base 64 as eight bytes, which is required to never repeat or decrease in the lifetime of the device. That text remains in my -04 unaltered. In -05, the reference to snmpEngineBoots appears, and I remember you (Chris) and I discussing beforehand that it could be a timer (which meets the requirements of the original) or an SNMP equivalent. I will also note that it doesn't take a lot of lawyering to note that there are other implementations that meet the original requirements including a hash or hmac with frosting and sprinkles to manage collisions, (or even just ignoring the collision issue, in some cases), a 48-bit finite field, and many other things that are more complex than and technologically inferior to the naive reboot counter. I'll also note that if we went back to John's original of a 48-bit number in base64, then a 48-bit timestamp (truncate 64-bit time_t) is good enough, too. Jon From alex@cisco.com Mon Mar 23 17:50:13 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871C628C253 for ; Mon, 23 Mar 2009 17:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTBzcjuviePQ for ; Mon, 23 Mar 2009 17:50:12 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F3AD028C264 for ; Mon, 23 Mar 2009 17:50:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,410,1233532800"; d="scan'208";a="160422427" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2009 00:51:02 +0000 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 n2O0p2S4016255; Mon, 23 Mar 2009 17:51:02 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2O0p2R4027963; Tue, 24 Mar 2009 00:51:02 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 17:51:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Mar 2009 17:51:01 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB076B98BB@xmb-sjc-236.amer.cisco.com> In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA702AD5F@GRFEXC.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Last minor clarifications/nits thread-index: AcmrvYTIaqWZjOjrShGDNOTsJECpjwAADkuwABcmlNA= References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com><49C2A7DD.8020506@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com><808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com><9B6E2A8877C38245BFB15CC491A11DA702AD5A@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA702AD5F@GRFEXC.intern.adiscon.com> From: "Alexander Clemm (alex)" To: "Rainer Gerhards" , "Chris Lonvick (clonvick)" X-OriginalArrivalTime: 24 Mar 2009 00:51:02.0680 (UTC) FILETIME=[9B06A180:01C9AC1A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6782; t=1237855862; x=1238719862; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=20Last=20mino r=20clarifications/nits |Sender:=20; bh=MtjVODz1hAT1BAiJWsRiRUqQdsUh785XY007YPFQ2SA=; b=FmfFcvjNQaEacMxl1Z4+p1iR+lISuVblaOcvHde+VicYIGLgBrjKNTLUGj Sn4Xsa7djc8TNbQgJzw5fdA3nRazEGmWGQe1b/38UwEsrwnpzY04LFqVPRFk fNKmqDjYXN; Authentication-Results: sj-dkim-4; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:50:13 -0000 OK, to summarize, here goes: 4.2.2. Reboot Session ID The Reboot Session ID is a decimal value that has a length between 1 and 10 octets. The acceptable values for this are between 0 and 9999999999. Leading zeroes MUST be omitted. A Reboot Session ID is expected to strictly monotonically increase (i.e., to never repeat or decrease) whenever an originator reboots in order to allow collectors to distinguish messages and message signatures across reboots. There are several ways in which this may be accomplished. In one way, the Reboot Session ID may increase by 1, starting with a value of 1. Note that in this case, an originator is required to retain the previous Reboot Session ID across reboots. In another way, a value of the unix time (number of seconds since 1 January 1970) may be used. Implementers of this method need to beware of the possibility of multiple reboots occurring within a single second. Implementers need to also beware of the year 2038 problem, which will cause the unix time to wrap in the year 2038. In yet another way, implementers wish to consider using the snmpEngineBoots value as a source for this counter as defined in [RFC3414]. In cases where an originator is not able to guarantee that the Reboot Session ID is always increased after a reboot, the Reboot Session ID MUST always be set to a value of 0. If the value can no longer be increased (e.g., because it reaches 9999999999), then manual intervention may be required to subsequently reset it. If a reboot of an originator takes place, Signature Block messages MAY use a new PROCID. However, Signature Block messages of the same originator MUST continue to use the same APP-NAME and MSGID. --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of Rainer Gerhards Sent: Monday, March 23, 2009 6:49 AM To: Chris Lonvick (clonvick) Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits Chris, > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Monday, March 23, 2009 2:44 PM > To: Rainer Gerhards > Cc: Pasi.Eronen@nokia.com; syslog@ietf.org > Subject: RE: [Syslog] Syslog-sign: Last minor clarifications/nits >=20 > Hi Rainer, >=20 > Comments in line. >=20 > On Mon, 23 Mar 2009, Rainer Gerhards wrote: >=20 > > > > > >> -----Original Message----- > >> From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > >> Behalf Of Chris Lonvick > >> Sent: Sunday, March 22, 2009 11:10 PM > >> To: Pasi.Eronen@nokia.com > >> Cc: syslog@ietf.org > >> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > >> > >> Hi, > >> > >> There does seem to be some conflicts in the section; if it SHOULD > start > >> with 1 and increment by 1 then how do we get to SnmpEngineReboots? > > > > What if we just say "must start at 1 and be strictly monotonically > > increasing"? I think this is the essence of what we need and permits > any > > value to be used as seed as long as it can be assured that a higher > RSID will > > be emitted later in time than a lower one. This would also permit any > other > > second-counting time base reference to be used, e.g. > creation/compilation > > date of the software in question. >=20 > I'm OK with most of that. I wouldn't require it to start at "1" > however. > I'd assume that some sort of timestamp value may be used, or that if > snmpEngineBoots is used then it is already past "1". >=20 > > > > If we refer to the POSIX timestamp, I am not sure if we refer to the > 32 or > > 64 Bit version of it (I even think I remember the bitness is not > preciesley > > defined?). In any case, we have subtle issues: if we talk about 32 > bit, the > > well-known 2038 problem is carried over to this draft. While 28 more > years to > > go sound reasonable, I'd still think it is worth pointing out. With > 64 Bit, > > the RSID will latch ~ 2110 when 64 bit Unix time goes beyond > 9,999,999,999 - > > that is probably not a real concern ;) >=20 > I see your point but that's outside of our scope to solve. :-) If we > have some verbiage in the document talking about using a time-based > value > for RSID, then at most we should have a line in the security > considerations section telling the implementer to be aware. >=20 > > > > With any time-based counter based on seconds, there is always the > subtle > > issue of two or more restarts within a single second, which means the > RSID > > will not necessarily be strictly monotonically increasing. While the > > probability is (very) low for this case, it is not 0. So we cannot > outrule > > it. I have not yet checked if that can lead to permanent problems > (counters > > related to RSID which may occur twice). >=20 > Agreed. Again, an implementer would have to beware of that issue if > they > chose a time-based value. >=20 > > > > SNMP, as I understand RFC3414, seems to have solved this by requiring > the > > device to actually increment the counter and store it in non-volatile > memory. > > I think this is a good compromise and would suggest the we mandate > this, too, > > except that we permit any increment as long as the resulting sequence > will be > > strictly monotonically increasing (this is necessary to permit simply > copying > > over the SNMPEngineBoots counter from the SNMP subsystem, if syslogd > has > > access to it). >=20 > This sounds good. ..I'm trying to remember if this is what was first > discussed for RSID when John Kelsey first proposed a counter for this. >=20 > > > > Also, RFC 3414 uses 2147483647 as a special value, while we use 0. I > suggest > > that we use 2147483647, too. Otherwise, a naive implementation may > forget to > > convert 2147483647 to 0 when copying over the SNMPEngineBoots from > the SNMP > > engine (this sounds natural to do if the syslogd has access to a SNMP > > subsystem). >=20 > I disagree on that. 2147483647 is the largest 32bit unsigned integer - > I'm guessing that's the reason it was chosen for 3414. If devices use > a > 64bit field (or larger) to store their RSID value then they will have > to > proactively avoid using 2147483647. >=20 You are right - at that point I overlooked that we are not latching at 2^31-1. It does definitely not make sense to use some value right in the middle of the interval for a special case. Please disregard my suggestion. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From rgerhards@hq.adiscon.com Tue Mar 24 00:44:17 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FE6B3A6CB6 for ; Tue, 24 Mar 2009 00:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4c+mx038ttK for ; Tue, 24 Mar 2009 00:44:16 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id C2DD63A6CB8 for ; Tue, 24 Mar 2009 00:44:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id BC385241C004; Tue, 24 Mar 2009 08:44:39 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRIhx1L462iR; Tue, 24 Mar 2009 08:44:39 +0100 (CET) Received: from GRFEXC.intern.adiscon.com (p54AC513A.dip.t-dialin.net [84.172.81.58]) by mailin.adiscon.com (Postfix) with ESMTP id 964CB241C001; Tue, 24 Mar 2009 08:44:38 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 24 Mar 2009 08:45:00 +0100 Message-ID: <9B6E2A8877C38245BFB15CC491A11DA702AD65@GRFEXC.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Last minor clarifications/nits Thread-index: AcmrvYTIaqWZjOjrShGDNOTsJECpjwAADkuwABcmlNAADoSsUA== References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com><49C2A7DD.8020506@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com><808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com><9B6E2A8877C38245BFB15CC491A11DA702AD5A@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA702AD5F@GRFEXC.intern.adiscon.com> <85B2F271FDF6B949B3672BA5A7BB62FB076B98BB@xmb-sjc-236.amer.cisco.com> From: "Rainer Gerhards" To: "Alexander Clemm \(alex\)" , "Chris Lonvick \(clonvick\)" Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 07:44:17 -0000 This is fine with me. Rainer > -----Original Message----- > From: Alexander Clemm (alex) [mailto:alex@cisco.com] > Sent: Tuesday, March 24, 2009 1:51 AM > To: Rainer Gerhards; Chris Lonvick (clonvick) > Cc: syslog@ietf.org > Subject: RE: [Syslog] Syslog-sign: Last minor clarifications/nits >=20 > OK, to summarize, here goes: >=20 > 4.2.2. Reboot Session ID >=20 > The Reboot Session ID is a decimal value that has a length between = 1 > and 10 octets. The acceptable values for this are between 0 and > 9999999999. Leading zeroes MUST be omitted. >=20 > A Reboot Session ID is expected to strictly monotonically increase > (i.e., to never repeat or decrease) whenever an originator reboots > in > order to allow collectors to distinguish messages and message > signatures across reboots. There are several ways in which this = may > be accomplished. In one way, the Reboot Session ID may increase by > 1, starting with a value of 1. Note that in this case, an > originator > is required to retain the previous Reboot Session ID across = reboots. > In another way, a value of the unix time (number of seconds since 1 > January 1970) may be used. Implementers of this method need to > beware of the possibility of multiple reboots occurring within a > single second. Implementers need to also beware of the year 2038 > problem, which will cause the unix time to wrap in the year 2038. > In > yet another way, implementers wish to consider using the > snmpEngineBoots value as a source for this counter as defined in > [RFC3414]. >=20 > In cases where an originator is not able to guarantee that the > Reboot > Session ID is always increased after a reboot, the Reboot Session = ID > MUST always be set to a value of 0. If the value can no longer be > increased (e.g., because it reaches 9999999999), then manual > intervention may be required to subsequently reset it. >=20 > If a reboot of an originator takes place, Signature Block messages > MAY use a new PROCID. However, Signature Block messages of the = same > originator MUST continue to use the same APP-NAME and MSGID. >=20 > --- Alex > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf > Of Rainer Gerhards > Sent: Monday, March 23, 2009 6:49 AM > To: Chris Lonvick (clonvick) > Cc: syslog@ietf.org > Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits >=20 > Chris, >=20 > >=20 > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Monday, March 23, 2009 2:44 PM > > To: Rainer Gerhards > > Cc: Pasi.Eronen@nokia.com; syslog@ietf.org > > Subject: RE: [Syslog] Syslog-sign: Last minor clarifications/nits > > > > Hi Rainer, > > > > Comments in line. > > > > On Mon, 23 Mar 2009, Rainer Gerhards wrote: > > > > > > > > > > >> -----Original Message----- > > >> From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > > >> Behalf Of Chris Lonvick > > >> Sent: Sunday, March 22, 2009 11:10 PM > > >> To: Pasi.Eronen@nokia.com > > >> Cc: syslog@ietf.org > > >> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > > >> > > >> Hi, > > >> > > >> There does seem to be some conflicts in the section; if it SHOULD > > start > > >> with 1 and increment by 1 then how do we get to = SnmpEngineReboots? > > > > > > What if we just say "must start at 1 and be strictly monotonically > > > increasing"? I think this is the essence of what we need and > permits > > any > > > value to be used as seed as long as it can be assured that a = higher > > RSID will > > > be emitted later in time than a lower one. This would also permit > any > > other > > > second-counting time base reference to be used, e.g. > > creation/compilation > > > date of the software in question. > > > > I'm OK with most of that. I wouldn't require it to start at "1" > > however. > > I'd assume that some sort of timestamp value may be used, or that if > > snmpEngineBoots is used then it is already past "1". > > > > > > > > If we refer to the POSIX timestamp, I am not sure if we refer to > the > > 32 or > > > 64 Bit version of it (I even think I remember the bitness is not > > preciesley > > > defined?). In any case, we have subtle issues: if we talk about 32 > > bit, the > > > well-known 2038 problem is carried over to this draft. While 28 > more > > years to > > > go sound reasonable, I'd still think it is worth pointing out. = With > > 64 Bit, > > > the RSID will latch ~ 2110 when 64 bit Unix time goes beyond > > 9,999,999,999 - > > > that is probably not a real concern ;) > > > > I see your point but that's outside of our scope to solve. :-) If > we > > have some verbiage in the document talking about using a time-based > > value > > for RSID, then at most we should have a line in the security > > considerations section telling the implementer to be aware. > > > > > > > > With any time-based counter based on seconds, there is always the > > subtle > > > issue of two or more restarts within a single second, which means > the > > RSID > > > will not necessarily be strictly monotonically increasing. While > the > > > probability is (very) low for this case, it is not 0. So we cannot > > outrule > > > it. I have not yet checked if that can lead to permanent problems > > (counters > > > related to RSID which may occur twice). > > > > Agreed. Again, an implementer would have to beware of that issue if > > they > > chose a time-based value. > > > > > > > > SNMP, as I understand RFC3414, seems to have solved this by > requiring > > the > > > device to actually increment the counter and store it in > non-volatile > > memory. > > > I think this is a good compromise and would suggest the we mandate > > this, too, > > > except that we permit any increment as long as the resulting > sequence > > will be > > > strictly monotonically increasing (this is necessary to permit > simply > > copying > > > over the SNMPEngineBoots counter from the SNMP subsystem, if > syslogd > > has > > > access to it). > > > > This sounds good. ..I'm trying to remember if this is what was = first > > discussed for RSID when John Kelsey first proposed a counter for > this. > > > > > > > > Also, RFC 3414 uses 2147483647 as a special value, while we use = 0. > I > > suggest > > > that we use 2147483647, too. Otherwise, a naive implementation may > > forget to > > > convert 2147483647 to 0 when copying over the SNMPEngineBoots from > > the SNMP > > > engine (this sounds natural to do if the syslogd has access to a > SNMP > > > subsystem). > > > > I disagree on that. 2147483647 is the largest 32bit unsigned = integer > - > > I'm guessing that's the reason it was chosen for 3414. If devices > use > > a > > 64bit field (or larger) to store their RSID value then they will = have > > to > > proactively avoid using 2147483647. > > >=20 > You are right - at that point I overlooked that we are not latching at > 2^31-1. It does definitely not make sense to use some value right in > the > middle of the interval for a special case. Please disregard my > suggestion. >=20 > Rainer > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From ietfdbh@comcast.net Tue Mar 24 14:12:37 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7846E3A6B86 for ; Tue, 24 Mar 2009 14:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gygfl05kFkFi for ; Tue, 24 Mar 2009 14:12:36 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 327103A6989 for ; Tue, 24 Mar 2009 14:12:34 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA10.westchester.pa.mail.comcast.net with comcast id X62c1b08E0QuhwU5A9DSzf; Tue, 24 Mar 2009 21:13:26 +0000 Received: from Harrington73653 ([130.129.18.98]) by OMTA02.westchester.pa.mail.comcast.net with comcast id X9D91b01G26xVzW3N9DChS; Tue, 24 Mar 2009 21:13:24 +0000 From: "David Harrington" To: "'Alexander Clemm \(alex\)'" , "'Rainer Gerhards'" , "'Chris Lonvick \(clonvick\)'" References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com><49C2A7DD.8020506@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com><808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com><9B6E2A8877C38245BFB15CC491A11DA702AD5A@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA702AD5F@GRFEXC.intern.adiscon.com> <85B2F271FDF6B949B3672BA5A7BB62FB076B98BB@xmb-sjc-236.amer.cisco.com> Date: Tue, 24 Mar 2009 14:13:08 -0700 Message-ID: <002101c9acc5$5d226600$62128182@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: AcmrvYTIaqWZjOjrShGDNOTsJECpjwAADkuwABcmlNAAKq+QIA== In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB076B98BB@xmb-sjc-236.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:12:37 -0000 Hi, why are we allowing multiple ways to set this? Since our mission is to define standards, why not standardize one way? I think there are problems with rollover when using unix time or snmpBoots. If we simplify this to use a simple increasing value, then we avoid that complexity. dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Alexander Clemm (alex) > Sent: Monday, March 23, 2009 5:51 PM > To: Rainer Gerhards; Chris Lonvick (clonvick) > Cc: syslog@ietf.org > Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > > OK, to summarize, here goes: > > 4.2.2. Reboot Session ID > > The Reboot Session ID is a decimal value that has a length > between 1 > and 10 octets. The acceptable values for this are between 0 and > 9999999999. Leading zeroes MUST be omitted. > > A Reboot Session ID is expected to strictly monotonically increase > (i.e., to never repeat or decrease) whenever an originator > reboots in > order to allow collectors to distinguish messages and message > signatures across reboots. There are several ways in > which this may > be accomplished. In one way, the Reboot Session ID may increase by > 1, starting with a value of 1. Note that in this case, an > originator > is required to retain the previous Reboot Session ID > across reboots. > In another way, a value of the unix time (number of seconds since 1 > January 1970) may be used. Implementers of this method need to > beware of the possibility of multiple reboots occurring within a > single second. Implementers need to also beware of the year 2038 > problem, which will cause the unix time to wrap in the > year 2038. In > yet another way, implementers wish to consider using the > snmpEngineBoots value as a source for this counter as defined in > [RFC3414]. > > In cases where an originator is not able to guarantee that > the Reboot > Session ID is always increased after a reboot, the Reboot > Session ID > MUST always be set to a value of 0. If the value can no longer be > increased (e.g., because it reaches 9999999999), then manual > intervention may be required to subsequently reset it. > > If a reboot of an originator takes place, Signature Block messages > MAY use a new PROCID. However, Signature Block messages > of the same > originator MUST continue to use the same APP-NAME and MSGID. > > --- Alex > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf > Of Rainer Gerhards > Sent: Monday, March 23, 2009 6:49 AM > To: Chris Lonvick (clonvick) > Cc: syslog@ietf.org > Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > > Chris, > > > > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Monday, March 23, 2009 2:44 PM > > To: Rainer Gerhards > > Cc: Pasi.Eronen@nokia.com; syslog@ietf.org > > Subject: RE: [Syslog] Syslog-sign: Last minor clarifications/nits > > > > Hi Rainer, > > > > Comments in line. > > > > On Mon, 23 Mar 2009, Rainer Gerhards wrote: > > > > > > > > > > >> -----Original Message----- > > >> From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > > >> Behalf Of Chris Lonvick > > >> Sent: Sunday, March 22, 2009 11:10 PM > > >> To: Pasi.Eronen@nokia.com > > >> Cc: syslog@ietf.org > > >> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > > >> > > >> Hi, > > >> > > >> There does seem to be some conflicts in the section; if it SHOULD > > start > > >> with 1 and increment by 1 then how do we get to > SnmpEngineReboots? > > > > > > What if we just say "must start at 1 and be strictly monotonically > > > increasing"? I think this is the essence of what we need > and permits > > any > > > value to be used as seed as long as it can be assured > that a higher > > RSID will > > > be emitted later in time than a lower one. This would also permit > any > > other > > > second-counting time base reference to be used, e.g. > > creation/compilation > > > date of the software in question. > > > > I'm OK with most of that. I wouldn't require it to start at "1" > > however. > > I'd assume that some sort of timestamp value may be used, or that if > > snmpEngineBoots is used then it is already past "1". > > > > > > > > If we refer to the POSIX timestamp, I am not sure if we > refer to the > > 32 or > > > 64 Bit version of it (I even think I remember the bitness is not > > preciesley > > > defined?). In any case, we have subtle issues: if we talk about 32 > > bit, the > > > well-known 2038 problem is carried over to this draft. > While 28 more > > years to > > > go sound reasonable, I'd still think it is worth pointing > out. With > > 64 Bit, > > > the RSID will latch ~ 2110 when 64 bit Unix time goes beyond > > 9,999,999,999 - > > > that is probably not a real concern ;) > > > > I see your point but that's outside of our scope to solve. > :-) If we > > have some verbiage in the document talking about using a time-based > > value > > for RSID, then at most we should have a line in the security > > considerations section telling the implementer to be aware. > > > > > > > > With any time-based counter based on seconds, there is always the > > subtle > > > issue of two or more restarts within a single second, which means > the > > RSID > > > will not necessarily be strictly monotonically > increasing. While the > > > probability is (very) low for this case, it is not 0. So we cannot > > outrule > > > it. I have not yet checked if that can lead to permanent problems > > (counters > > > related to RSID which may occur twice). > > > > Agreed. Again, an implementer would have to beware of that issue if > > they > > chose a time-based value. > > > > > > > > SNMP, as I understand RFC3414, seems to have solved this by > requiring > > the > > > device to actually increment the counter and store it in > non-volatile > > memory. > > > I think this is a good compromise and would suggest the we mandate > > this, too, > > > except that we permit any increment as long as the resulting > sequence > > will be > > > strictly monotonically increasing (this is necessary to permit > simply > > copying > > > over the SNMPEngineBoots counter from the SNMP subsystem, > if syslogd > > has > > > access to it). > > > > This sounds good. ..I'm trying to remember if this is what > was first > > discussed for RSID when John Kelsey first proposed a > counter for this. > > > > > > > > Also, RFC 3414 uses 2147483647 as a special value, while > we use 0. > I > > suggest > > > that we use 2147483647, too. Otherwise, a naive implementation may > > forget to > > > convert 2147483647 to 0 when copying over the SNMPEngineBoots from > > the SNMP > > > engine (this sounds natural to do if the syslogd has access to a > SNMP > > > subsystem). > > > > I disagree on that. 2147483647 is the largest 32bit > unsigned integer > - > > I'm guessing that's the reason it was chosen for 3414. If > devices use > > a > > 64bit field (or larger) to store their RSID value then they > will have > > to > > proactively avoid using 2147483647. > > > > You are right - at that point I overlooked that we are not latching at > 2^31-1. It does definitely not make sense to use some value > right in the > middle of the interval for a special case. Please disregard my > suggestion. > > Rainer > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From lists@mschuette.name Tue Mar 24 14:34:56 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349993A6AFE for ; Tue, 24 Mar 2009 14:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8j9Sl4WMZet9 for ; Tue, 24 Mar 2009 14:34:55 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id 778393A6A6B for ; Tue, 24 Mar 2009 14:34:55 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 6532E86A39 for ; Tue, 24 Mar 2009 22:35:45 +0100 (CET) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id ROn0nVsIz2WP for ; Tue, 24 Mar 2009 22:35:28 +0100 (CET) Received: from cordelia.mschuette.name (BAEe944.bae.pppool.de [77.132.233.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id F29D0869BB for ; Tue, 24 Mar 2009 22:35:27 +0100 (CET) Message-ID: <49C9521F.6050707@mschuette.name> Date: Tue, 24 Mar 2009 22:35:27 +0100 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: syslog@ietf.org References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com><49C2A7DD.8020506@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com><808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com><9B6E2A8877C38245BFB15CC491A11DA702AD5A@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA702AD5F@GRFEXC.intern.adiscon.com> <85B2F271FDF6B949B3672BA5A7BB62FB076B98BB@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB076B98BB@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:34:56 -0000 Alexander Clemm (alex) schrieb: > OK, to summarize, here goes: I'm fine with that, because the start and increment values are no longer a MUST. IMHO the unix time does not even have to be mentioned explicitly because that only adds unnecessary semantic meaning to the value. -- Martin From jon@callas.org Tue Mar 24 14:45:22 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8052528C1EA for ; Tue, 24 Mar 2009 14:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93HAKecCsEix for ; Tue, 24 Mar 2009 14:45:21 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by core3.amsl.com (Postfix) with ESMTP id 8752828C1EF for ; Tue, 24 Mar 2009 14:45:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id E797B2E15B; Tue, 24 Mar 2009 14:46:13 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 24219-05; Tue, 24 Mar 2009 14:46:08 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 07D012E107; Tue, 24 Mar 2009 14:46:08 -0700 (PDT) Received: from kyang-d630.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Tue, 24 Mar 2009 14:46:06 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 24 Mar 2009 14:46:06 -0700 Message-Id: From: Jon Callas To: David Harrington In-Reply-To: <002101c9acc5$5d226600$62128182@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 14:45:38 -0700 References: <808FD6E27AD4884E94820BC333B2DB7727E78F2907@NOK-EUMSG-01.mgdnok.nokia.com><85B2F271FDF6B949B3672BA5A7BB62FB075EA025@xmb-sjc-236.amer.cisco.com><49C2A7DD.8020506@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB076B9358@xmb-sjc-236.amer.cisco.com><808FD6E27AD4884E94820BC333B2DB7727F2071CCA@NOK-EUMSG-01.mgdnok.nokia.com><9B6E2A8877C38245BFB15CC491A11DA702AD5A@GRFEXC.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA702AD5F@GRFEXC.intern.adiscon.com> <85B2F271FDF6B949B3672BA5A7BB62FB076B98BB@xmb-sjc-236.amer.cisco.com> <002101c9acc5$5d226600$62128182@china.huawei.com> X-Mailer: Apple Mail (2.930.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:45:22 -0000 On Mar 24, 2009, at 2:13 PM, David Harrington wrote: > Hi, > > why are we allowing multiple ways to set this? > Since our mission is to define standards, why not standardize one way? > > I think there are problems with rollover when using unix time or > snmpBoots. > If we simplify this to use a simple increasing value, then we avoid > that complexity. You are correct, but there will be the people who will fold in the other ways as well. If that's okay, that's okay. There's a problem that simplicity is in the eye of the beholder. A mere counter is perhaps the simplest, but could lead to operational issues, especially if you want to tie it together. A timestamp is simple in the sense that it's easy to get, but has rollover issues. Those are easy to deal with (including by making it be a 48-bit base64 value as Kelsey first had it), but you have to deal with them. SNMP values are simple if you have an SNMP framework, but not simple if you don't. What you said, "simple increasing value" simplifies definition, but pushes issues off to implementation and operations folks, who will pick one of the other obvious things -- they're each simple increasing values. Timestamp is merely sparse. Arguably even simpler is Kelsey's definition which said it was non- repeating, as opposed to increasing. But are they really any different, at the end of the day? The major debate I can see is whether it should stay a ten-digit decimal number or go back to a base64 48-bit binary number. Jon From root@core3.amsl.com Mon Mar 30 17:30:01 2009 Return-Path: X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8983D3A68DF; Mon, 30 Mar 2009 17:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090331003001.8983D3A68DF@core3.amsl.com> Date: Mon, 30 Mar 2009 17:30:01 -0700 (PDT) Cc: syslog@ietf.org Subject: [Syslog] I-D Action:draft-ietf-syslog-sign-25.txt X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 00:30:01 -0000 --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 : Signed syslog Messages Author(s) : J. Kelsey, et al. Filename : draft-ietf-syslog-sign-25.txt Pages : 44 Date : 2009-03-30 This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in [RFC5424], "The syslog Protocol". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-25.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-syslog-sign-25.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-30171541.I-D@ietf.org> --NextPart-- From rfc-editor@rfc-editor.org Tue Mar 31 16:08:39 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDBC43A6B47; Tue, 31 Mar 2009 16:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.924 X-Spam-Level: X-Spam-Status: No, score=-16.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nruTUtdiRKV9; Tue, 31 Mar 2009 16:08:38 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id DD1843A6B0F; Tue, 31 Mar 2009 16:08:38 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 7AEC726B6E4; Tue, 31 Mar 2009 16:09:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090331230902.7AEC726B6E4@bosco.isi.edu> Date: Tue, 31 Mar 2009 16:09:02 -0700 (PDT) Cc: syslog@ietf.org, rfc-editor@rfc-editor.org Subject: [Syslog] RFC 5427 on Textual Conventions for Syslog Management X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 23:08:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5427 Title: Textual Conventions for Syslog Management Author: G. Keeni Status: Standards Track Date: March 2009 Mailbox: glenn@cysols.com Pages: 8 Characters: 17829 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-syslog-tc-mib-08.txt URL: http://www.rfc-editor.org/rfc/rfc5427.txt This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS TRACK] This document is a product of the Security Issues in Network Event Logging Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute