From syslog-bounces@lists.ietf.org Fri Dec 01 02:55:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq3Dz-00018u-CL; Fri, 01 Dec 2006 02:54:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq3Dy-00018p-Co for syslog@ietf.org; Fri, 01 Dec 2006 02:54:22 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq3Ds-0001yI-Sk for syslog@ietf.org; Fri, 01 Dec 2006 02:54:22 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9L004OT4L3B7@szxga01-in.huawei.com> for syslog@ietf.org; Fri, 01 Dec 2006 15:53:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9L008OW4KYVC@szxga01-in.huawei.com> for syslog@ietf.org; Fri, 01 Dec 2006 15:53:26 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9L004Y74KUZ2@szxml04-in.huawei.com> for syslog@ietf.org; Fri, 01 Dec 2006 15:53:22 +0800 (CST) Date: Fri, 01 Dec 2006 15:53:18 +0800 From: Miao Fuyou Subject: RE: [Syslog] Towards closure of syslog-tls issues In-reply-to: To: 'Chris Lonvick' Message-id: <000001c7151d$c447c060$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_7BiV9lU60VAc9oMLaQHEFg)" Thread-index: AccUp3sOUXCuZfpvREyygNYrpBIZxAAdWPHg X-Spam-Score: 0.0 (/) X-Scan-Signature: 4824b9ef1b1988f2983d420e78cedc0a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. --Boundary_(ID_7BiV9lU60VAc9oMLaQHEFg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT 1, The text about cipher suite is updated: "TLS [6] specifies a mandatory cipher suite to enable minimum interoperability for TLS implementation. This specification does not specify a mandatory cipher suite other than the one in TLS specification, and the one for TLS applies to this specification for minimum interoperability purpose. If there is update to TLS specification in the future, the latest mandatory cipher suite in the update will apply to this specification, too. The implementors and deployers should be aware of the strengths of the public keys algorithm in the suite for exchanging symmetric keys, which is elaborated in BCP86 [3]. The implementors and deployers should also be aware of the latest TLS and other IETF cryptography standards including BCP86. " 2, There is unreferred reference in the -05, the nit is removed from -06. Thanks, Miao > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, December 01, 2006 1:47 AM > To: Miao Fuyou > Cc: syslog@ietf.org; tom.petch > Subject: Re: [Syslog] Towards closure of syslog-tls issues > > Hi Miao, > > I agree that these should be in the ID before submission to the IESG. > Please make these changes for version -06 and submit to the > ID Editor. > Once these are in I will submit to Sam and the IESG. > > Go ahead and take care of the other minor nits that are > pointed out in the shepherding document for -05 as well. > > Thanks, > Chris > > On Thu, 30 Nov 2006, tom.petch wrote: > > > Chris > > > > I agreed (mostly) with the actions in your e-mail but do > not see them > > all reflected in -05. See > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: "Miao Fuyou" > > Cc: > > Sent: Monday, November 27, 2006 11:05 PM > > Subject: Re: [Syslog] Towards closure of syslog-tls issues > >> > >>> 3, Ciphersuite. Tom proposed to specify cipher suite in the > >>> transport document, but I still don't find necessity to do so. I > >>> tend to agree to Rainer's proposal: > >>> http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html > >> > >> In addition to that > >> - reference the latest TLS RFC and note that there are > updates to that > >> which need to be considered > > > > This I see, at least the latest RFC part > > > >> - note that the latest ciphers and their relative strengths may be > >> found in BCP86 > > > > This I do not see and would like to > > > >> - note that implementors and deployers should keep aware of current > >> literature > > > > Likewise, this I do not see and would like to > > > >> (This should be about 3 sentences.) > >> > > > > > >> > >> Please make these changes and submit -05 so we can submit > this to the > >> IESG. > >> > >> Thanks, > >> Chris > >> > > > --Boundary_(ID_7BiV9lU60VAc9oMLaQHEFg) Content-type: text/plain; name=draft-ietf-syslog-transport-tls-06.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-ietf-syslog-transport-tls-06.txt Syslog Working Group F. Miao Internet-Draft M. Yuzhi Intended status: Standards Track Huawei Technologies Expires: June 4, 2007 December 01, 2006 TLS Transport Mapping for Syslog draft-ietf-syslog-transport-tls-06.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 4, 2007. Copyright Notice Copyright (C) The IETF Trust (2006). Abstract This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of Syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. Miao & Yuzhi Expires June 4, 2007 [Page 1] Internet-Draft TLS Transport Mapping for Syslog December 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Requirements for Syslog . . . . . . . . . . . . . . . 3 3. TLS to Secure Syslog . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 5 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. Frame Length . . . . . . . . . . . . . . . . . . . . . 6 4.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Generic Certificate . . . . . . . . . . . . . . . . . . . 7 5.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Miao & Yuzhi Expires June 4, 2007 [Page 2] Internet-Draft TLS Transport Mapping for Syslog December 2006 1. Introduction This document describes the use of Transport Layer Security (TLS [6]) to provide a secure connection for the transport of Syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. 1.1. Terminology The following definitions are used in this document: o A sender is an application that can generate and send a Syslog [2] message to another application. o A receiver is an application that can receive a Syslog message. o A relay is an application that can receive Syslog messages and forward them to another receiver. o A collector is an application that can receive messages but does not relay them to any other receiver. o A TLS client is an application that can initiate a TLS connection by sending a Client Hello to a peer. o A TLS server is an application that can receive a Client Hello from a peer and reply with a Server Hello. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 2. Security Requirements for Syslog Syslog messages may pass several hops to arrive at the intended receiver. Some intermediary networks may not be trusted by the sender/relay, receiver, or all because the network is in a different security domain or at a different security level from the receiver, relay, or sender. Another security concern is that the sender/relay, or receiver itself is in an insecure network. There are several threats to be addressed for Syslog security. The primary threats are: o Masquerade. An unauthorized sender/relay may send messages to a legitimate receiver, or an unauthorized receiver tries to deceive a legitimate sender/relay into sending Syslog messages to it. Miao & Yuzhi Expires June 4, 2007 [Page 3] Internet-Draft TLS Transport Mapping for Syslog December 2006 o Modification. An attacker between the sender/relay and receiver may modify an in-transit Syslog message from the sender/relay and then forward the message to receiver. Such modification may make the receiver misunderstand the message or cause the receiver to behave in undesirable ways. o Disclosure. An unauthorized entity may examine the content of the Syslog messages, gaining unauthorized access to the information. Some data in Syslog messages is sensitive and may be useful to an attacker, such as the password of an authorized administrator or user. The secondary threat is: o Message stream modification. An attacker may delete a Syslog message from a series of messages, replay a message or alter the delivery sequence. Syslog protocol itself is not based on message order, but an event in a Syslog message may relate semantically to events in other messages, so message ordering may be important to understanding a sequence of events. The following threats are deemed to be of lesser importance for Syslog, and are not addressed in this document: o Denial of Service o Traffic Analysis 3. TLS to Secure Syslog TLS can be used as a secure transport to counter all the primary and secondary threats to Syslog described in section 2: o Confidentiality to counter disclosure of the message contents o Integrity check to counter modifications to a message o Peer authentication to counter masquerade o Sequence number along with integrity check to counter message stream modification 4. Protocol Elements Miao & Yuzhi Expires June 4, 2007 [Page 4] Internet-Draft TLS Transport Mapping for Syslog December 2006 4.1. Port Assignment A Syslog sender/relay is always a TLS client and a Syslog receiver is always a TLS server. The TCP port NNN has been allocated as the default port for Syslog over TLS, as defined in this document. Note to RFC Editor: please replace NNN with the IANA-assigned value, and remove this note. 4.2. Initiation The sender/relay should initiate a connection to the receiver and then send the TLS Client Hello to begin the TLS handshake. When the TLS handshake has finished the sender/relay may then send the first Syslog message. TLS uses certificate [4] to authenticate the peers. When a sender/ relay authenticates a receiver it MUST validate the certificate. It SHOULD check the common name (CN) of the certificate against the host name of the receiver if it has knowledge of a common name/host name mapping. If the common name does not match the host name, the sender/relay SHOULD send an "access_denied" error alert using the TLS alert protocol to terminate the handshake, and then it SHOULD close the connection. When a receiver authenticates a sender/relay, the receiver MUST validate the certificate. A sender's (or relay's) certificate may be: o An unique certificate, which is issued to a host and whose Common Name may be host name, IP address, MAC, or device ID. o A generic certificate, which is issued to a class of application or device. For example, all cable modems from a vendor may be issued the same generic certificate. A sender/relay certificate may be issued by an operator when a device/application is being provisioned or by a vendor when the device/application is manufactured. This document does not define how the sender/relay certificate is issued. Syslog applications SHOULD be implemented in a manner that permits administrators to select the cryptographic level they desire. It SHOULD be an administrator decision, as a matter of local policy, what security level (e.g. cryptographic algorithms and length of keys) is required. Miao & Yuzhi Expires June 4, 2007 [Page 5] Internet-Draft TLS Transport Mapping for Syslog December 2006 TLS permits the resumption of an earlier TLS session or the use of another active session when a new session is requested, in order to save the expense of another full TLS handshake. The security parameters of the resumed session are reused for the requested session. The security parameters SHOULD be checked against security requirement of requested session to make sure the resumed session provides proper security. 4.3. Sending data All Syslog messages MUST be sent as TLS "application data". It is possible that there are multiple Syslog messages in one TLS record, or a Syslog message is transferred in multiple TLS records. The application data is defined with the following ABNF [5] expression: APPLICATION-DATA = 1*SYSLOG-FRAME SYSLOG-FRAME = FRAME-LEN SP SYSLOG-MSG FRAME-LEN = NONZERO-DIGIT *DIGIT SP = %d32 NONZERO-DIGIT = %d49-57 DIGIT = %d48 / NONZERO-DIGIT SYSLOG-MSG is defined in Syslog [2] protocol. 4.3.1. Frame Length The frame length is the octet count of a Syslog frame including the FRAME-HEADER and SP parts. A receiver MUST use the frame length field to delimit a Syslog message. There is no upper limit for a frame length per se. However, in order to establish a baseline for interoperability, the specification requires that a receiver MUST be able to process frame with size up to and including 2048 octets. It SHOULD be able to receive frame with size up to and including 8192 octets. 4.4. Closure A Syslog sender/relay MUST close the associated TLS connection if the connection is not expected to deliver Syslog message later. It MUST send a TLS close_notify alert before closing the connection. A sender/relay MAY choose not to wait for the receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the receiver side. Once the receiver gets close_notify from Miao & Yuzhi Expires June 4, 2007 [Page 6] Internet-Draft TLS Transport Mapping for Syslog December 2006 the sender/relay, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the sender/relay (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a receiver MAY close a connection. The receiver MUST attempt to initiate an exchange of close_notify alerts with the sender/relay before closing the connection. Receivers those are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the sender/relay side. When the sender/relay has received the close_notify alert from the receiver and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert. 5. Security Considerations 5.1. Authentication TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. TLS authentication and the establishment of secrets is based on certificates and asymmetric cryptography. This makes TLS transport much more expensive than non-TLS plain transport. An attacker may initialize many TLS connections to a receiver as a denial of service attack. Since a receiver may act upon received data, for Syslog over TLS, the receiver SHOULD authenticate the sender/relay to ensure that information received is authentic. For the deployment where confidentiality is a concern, receiver authentication is required for sender/relay to make sure it is talking to the right peer. It is up to the operator to decide whether confidentiality is a concern for a specific deployment. 5.2. Generic Certificate When a certificate is issued to a class of device or application, the certificate may be shared by multiple hosts. Multiple hosts know the private key of the certificate. When the certificate in one host is compromised, then the certificate for all hosts that share the certificate is compromised. An attacker may impersonate a legitimate sender to send Syslog message to a receiver. Miao & Yuzhi Expires June 4, 2007 [Page 7] Internet-Draft TLS Transport Mapping for Syslog December 2006 5.3. Cipher Suites TLS [6] specifies a mandatory cipher suite to enable minimum interoperability for TLS implementation. This specification does not specify a mandatory cipher suite other than the one in TLS specification, and the one for TLS applies to this specification for minimum interoperability purpose. If there is update to TLS specification in the future, the latest mandatory cipher suite in the update will apply to this specification, too. The implementors and deployers should be aware of the strengths of the public keys algorithm in the suite for exchanging symmetric keys, which is elaborated in BCP86 [3]. The implementors and deployers should also be aware of the latest TLS and other IETF cryptography standards including BCP86. 6. IANA Considerations 6.1. Port Number IANA is requested to assign a TCP port number in the range 1..1023 in the http://www.iana.org/assignments/port-numbers registry which will be the default port for Syslog over TLS, as defined in this document. 7. Acknowledgments Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton Okmianski, Balazs Scheidler, Bert Wijnen, and Chris Lonvick for their effort on issues resolving discussion. Authors would also like to appreciate Balazs Scheidler, Tom Petch and other persons for their input on security threats of Syslog. The authors would like to acknowledge David Harrington for his detailed reviews of the content and grammar of the document. 8. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Gerhards, R., "The syslog Protocol", draft-ietf-syslog-protocol-19 (work in progress), November 2006. [3] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. Miao & Yuzhi Expires June 4, 2007 [Page 8] Internet-Draft TLS Transport Mapping for Syslog December 2006 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. Authors' Addresses Miao Fuyou Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Haidian District, Beijing 100085 P. R. China Phone: +86 10 8288 2008 Email: miaofy@huawei.com URI: www.huawei.com Ma Yuzhi Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Haidian District, Beijing 100085 P. R. China Phone: +86 10 8288 2008 Email: myz@huawei.com URI: www.huawei.com Miao & Yuzhi Expires June 4, 2007 [Page 9] Internet-Draft TLS Transport Mapping for Syslog December 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Miao & Yuzhi Expires June 4, 2007 [Page 10] --Boundary_(ID_7BiV9lU60VAc9oMLaQHEFg) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --Boundary_(ID_7BiV9lU60VAc9oMLaQHEFg)-- From syslog-bounces@lists.ietf.org Fri Dec 01 03:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq3lB-0006it-Fz; Fri, 01 Dec 2006 03:28:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq3lA-0006YZ-74 for syslog@ietf.org; Fri, 01 Dec 2006 03:28:40 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq3l8-0000Wp-FO for syslog@ietf.org; Fri, 01 Dec 2006 03:28:40 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9L004OU62DB7@szxga01-in.huawei.com> for syslog@ietf.org; Fri, 01 Dec 2006 16:25:25 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9L00H1I62CH3@szxga01-in.huawei.com> for syslog@ietf.org; Fri, 01 Dec 2006 16:25:25 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9L00E0N6294P@szxml03-in.huawei.com> for syslog@ietf.org; Fri, 01 Dec 2006 16:25:24 +0800 (CST) Date: Fri, 01 Dec 2006 16:25:21 +0800 From: Miao Fuyou Subject: RE: [Syslog] Near Final Shepherding Document fordraft-ietf-syslog-transport-tls-05.txt In-reply-to: To: 'Chris Lonvick' Message-id: <000a01c71522$3dede260$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccT0TkTA+gSXohvRAWRrQl8+nDP3wBT+UMg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > The references are split into normative and informational references. > The document is dependant upon There is no informative reference any longer because we removed RFC3164 sentences from the document. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Dec 03 19:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr1o1-0001mB-R3; Sun, 03 Dec 2006 19:35:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr1o0-0001m1-WA for syslog@ietf.org; Sun, 03 Dec 2006 19:35:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr1nz-0002bP-LM for syslog@ietf.org; Sun, 03 Dec 2006 19:35:36 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 03 Dec 2006 16:35:35 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kB40ZZpD014126; Sun, 3 Dec 2006 16:35:35 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB40ZYio024882; Sun, 3 Dec 2006 16:35:34 -0800 (PST) Date: Sun, 3 Dec 2006 16:35:34 -0800 (PST) From: Chris Lonvick To: David Harrington Subject: Re: [Syslog] Re: Updated IPR disclosure In-Reply-To: Message-ID: References: <03e501c7126f$c862b390$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2634; t=1165192535; x=1166056535; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20Re=3A=20Updated=20IPR=20disclosure |Sender:=20; bh=blbmfberRYf/j+AzvygVEWgruMc/p003mrIfmJnhjco=; b=f/D0AjG7HIlJE7p+XaDG19lYKm1V7h7hzMP2n+H3zwG8llaua0YySjqJ005fhO9/OB4Q3ufa IRRzNQHXW5f8RXrH0eWE663uC/ZYAZwJswzYmTqVInI0IchJ3hK+f2mF; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi All, Cisco legal counsel has reviewed this and found it to be acceptable and written consistent with most other IPR statements. Again, Cisco thanks Huawei for addressing this issue. Thanks, Chris On Mon, 27 Nov 2006, Chris Lonvick wrote: > Hi Everyone, > > Cisco asked Huawei to make this change. Essentially the prior statement > appeared to be similar to the IPR statements made by Cisco and other > companies but it had differences that were not acceptable to the Cisco legal > team. Hence, Cisco would not have been willing to implement the standard > produced. Huawei's legal team looked into this and they have made these > changes. > > The new statement appears to me (as David says, we are not lawyers) to be > much closer to the intent of Cisco's, and others, IPR statements. I'm asking > Cisco's legal team to review this and I will post Cisco's response when I > have that. > > (Working Group Chair Hat OFF): On behalf of Cisco, I would like to thank > Huawei for addressing this issue. > > I must note once again that the IETF will not make any determination of the > validity of any IPR claimed. Huawei has been following the IETF rules on > disclosure and statement of terms. > > Thanks, > Chris > > On Mon, 27 Nov 2006, David Harrington wrote: > >> Hi, >> >> The syslog WG co-chairs were notified that a request was being made >> to Huawei by a company experienced in IETF IPR disclosures, that >> Huawei modify their terms related to the TLS transport document. >> Huawei has chosen to change their terms as requested. >> >> The new terms can be seen at >> https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=763 >> >> The new disclosure is relevant to tls-03. We have requested Huawei to >> also post an update relevant to tls-04, which was just published. >> >> The changes apparently are meant to tighten the language a bit, and to >> make Huawei terms more consistent with those of other companies filing >> disclosures within the IETF. >> >> The co-chairs are not lawyers, and cannot provide legal advice about >> the changes. >> >> The WG needs to consider whether the modified terms are acceptable for >> this document to be advanced to the standards-track. Please send your >> comments to the co-chairs as soon as possible. >> >> David Harrington >> dharrington@huawei.com >> dbharrington@comcast.net >> ietfdbh@comcast.net >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 04 07:17:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrCke-00058w-Cz; Mon, 04 Dec 2006 07:16:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrCkd-00058r-Cf for syslog@ietf.org; Mon, 04 Dec 2006 07:16:51 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrCkc-0005gV-4X for syslog@ietf.org; Mon, 04 Dec 2006 07:16:51 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061204121649b1100nu1qce>; Mon, 4 Dec 2006 12:16:49 +0000 From: "David Harrington" To: Date: Mon, 4 Dec 2006 07:13:44 -0500 Message-ID: <0a6c01c7179d$aae2e7d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccXnVNJWNzlEdcRSYiz1XWVfBXNLQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Syslog] IESG approval process X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, It is important for the WG to understand the process that we are entering, and the sequence of events. Here is a rough description of the process (you can read the relevant RFCs and internet-drafts to get the exact process.) 1) we submit the documents to the AD/IESG. ****Change control now rests with the IESG; we are not permitted to modify the document except as requested by the AD/IESG. 2) The AD will review the documents to determine if they are ready for general IETF review and for IESG review. The AD has the responsibility of "selling it" to the rest of the IESG. 3) The AD/IESG may ask experts to review the documents, for such things as security, congestion control, MIB review, etc. 4) The AD/IESG will ask the general IETF to review the documents. This is called IETF Last Call. Any issues raised will be recorded, and the IESG, in cosultation with the chairs, will need to determine whether changes should be made to address the issues. In general, this filters out all the issues for which we have already reached consensus. The chairs (document shepherds) decide whether the requested changes require consultation with the WG. 5) Once any raised issues are addressed to the IESG's satisfaction, the IESG should approve the documents. 6) The documents go to the RFC editor to be published as RFCs. The rfc editor will make minor changes to correct spelling and grammar, change boilerplates to the RFC boilerplates (if they differ from internet-draft boilerplates), etc. 7) AUTH48 is the final review by authors to correct spelling and grammar and contact addresses, and to make sure the editing done by the rfc-editor does not change any semantics inadvertently. The WG does NOT get a chance to review these changes, so the changes should only be editorial in nature. Once the document is published as an RFC, it is never changed, so AUTH48 is that final sanity check before we cast it in stone. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 04 12:06:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrHFj-0005cM-Vv; Mon, 04 Dec 2006 12:05:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrHFj-0005cC-5x for syslog@ietf.org; Mon, 04 Dec 2006 12:05:15 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrHFh-000262-UK for syslog@ietf.org; Mon, 04 Dec 2006 12:05:15 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20061204170513b1200t5fq3e>; Mon, 4 Dec 2006 17:05:13 +0000 From: "David Harrington" To: Date: Mon, 4 Dec 2006 12:01:56 -0500 Message-ID: <0ab801c717c5$f4be5920$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccXxaJ6fHF6zs2sQkmxAsiQaRP0yw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [Syslog] revisions going forward X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, So that you know how we will handle issues that are raised for duments that have been submitted to the AD. Once we submit the document it goes it into the ID tracker, and under IESG control. We are not allowed to revise the document unless instructed to do so by the area director. People will continue to find new small problems in the drafts that need correcting. This is going to happen. It is very common. Here is how we handle those issues. You can raise the issue on the WG list, or simply raise it with the chairs. The chairs will decide whether it is in scope. Spelling and grammar are in scope. Technical clarifications are in scope. New technical matter is generally out of scope, unless the protocol is broken without the fix (and the WG agrees). The chairs will need to be convinced a technical change is really required and not just an extension. Since editorial changes make it more difficult to see the requested changes, even editorial changes will be subject to chair/shepherd approval; if it isn't broken, we may decide to not fix it. We definitely do NOT want the editors to decide they could rewrite whole sections of text to be more elegant. We do not want changes at this point if we can help it. For editorial changes (spelling, grammar, contact info, etc.) the changes will be kept by the editors in a working draft, but not published. Remember, we are not allowed to publish revisions once it has been submitted, except by request of the AD. As new issues arise, we can address them in the working draft, but not publish. There will be a delay before the AD finishes his review and brings it to the rest of the IESG for review. At some point he will almost certainly ask us for a new document to address issues to that point, before he asks the rest of the IESG to perform their reviews. That is the point at which we can publish a revision. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 04 15:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrKm4-0003F4-Ur; Mon, 04 Dec 2006 15:50:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrKlk-0002ky-Pd; Mon, 04 Dec 2006 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GrKlk-0006fl-DG; Mon, 04 Dec 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 210BB175A5; Mon, 4 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GrKlF-000630-MS; Mon, 04 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 04 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-06.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : TLS Transport Mapping for Syslog Author(s) : F. Miao, M. Yuzhi Filename : draft-ietf-syslog-transport-tls-06.txt Pages : 10 Date : 2006-12-4 This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of Syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-transport-tls-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-transport-tls-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-4134736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-tls-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-tls-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-4134736.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Wed Dec 06 09:27:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrxjW-0005jR-IQ; Wed, 06 Dec 2006 09:26:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrxjT-0005jF-Du for syslog@ietf.org; Wed, 06 Dec 2006 09:26:48 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrxjS-0004qv-5H for syslog@ietf.org; Wed, 06 Dec 2006 09:26:47 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 06 Dec 2006 06:26:45 -0800 X-IronPort-AV: i="4.09,504,1157353200"; d="scan'208"; a="755809287:sNHT37764150" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kB6EQj8s029054 for ; Wed, 6 Dec 2006 06:26:45 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kB6EQjW5021178 for ; Wed, 6 Dec 2006 06:26:45 -0800 (PST) Date: Wed, 6 Dec 2006 06:26:45 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=511; t=1165415205; x=1166279205; 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:=20Submission=20of=20Shepherding=20Documents |Sender:=20; bh=19zCBhQTaWYBdwrh6BlKhz2jExiyVCgMq+/sSteWY2w=; b=gTGt0Uy0eHigQqOzRXdm5W20BSn2R7ymnODM17uHeef7/9XbZWYhO5cRzc6PDU2BTP8h1mHJ 6jFVf68xLae2qBu+u14RCG72gzcUmwv7S2s5rZtU8ywCmurFdLbchF7b; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Syslog] Submission of Shepherding Documents X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, David and I are pleased to announce that the shepherding documents for the following IDs have been submitted to the IESG. - draft-ietf-syslog-protocol-19.txt - draft-ietf-syslog-transport-tls-06.txt - draft-ietf-syslog-transport-udp-08.txt Our thanks go to the authors and the Working Group for putting in the time and effort to develop and review these documents. We now need to focus on getting syslog-device-mib and syslog-sign out the door. Many thanks, Chris & David _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 06 17:55:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5ea-0004Jg-7t; Wed, 06 Dec 2006 17:54:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5eZ-0004Jb-E8 for syslog@ietf.org; Wed, 06 Dec 2006 17:54:15 -0500 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs5eY-0000EX-Ut for syslog@ietf.org; Wed, 06 Dec 2006 17:54:15 -0500 Received: from harrington73653 (failure[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20061206225414b1300c4fp7e>; Wed, 6 Dec 2006 22:54:14 +0000 From: "David Harrington" To: Date: Wed, 6 Dec 2006 17:50:33 -0500 Message-ID: <0d5401c71989$086d1910$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb2LLQKXZaxt/eyS/2isochxRKHIAjQ4DbQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <057501c6f62d$5b7e8fa0$b07557c0@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Cc: Subject: [Syslog] Dbh re-Review of -mib-11, part 1 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, This is a check that my comments of 10/22 have been addressed in mib-11. > 1) There are multiple pages that exceed the maximum allowed lines per > page. Fixed. > > 2) The headers and footers do not appear to be standard. There should > an abbreviated title for easch page after the first. Fixed. > > 3) the terminology is not consistent with the other WG documents. Not fixed. Still a problem. The WG consensus was to use sender, receiver, relay, and collector. Other document were required to change to match this terminology. The MIB document uses entity, which is a term not found in the protocol draft. I find this change in terminology makes it difficult to interpret some objects in the mib module. > > 4) "roles a syslog entity maybe in" would be better as "roles of a > syslog entity" (although then entity should be changed according to > #3. See #3. > > 5) I concur with Bert that the citations in section 2 seem > inappropriate. I suggest rewriting the introduction to use the same terminology as the protocol draft. See #3. > > 6) I find the references to SA-Li, RA-Rj confusing since these are not > used in the diagram. Fixed, but replaced by "entity" which is a problem. See #3. > > 7) "The MIB comprises of four groups" would be better as "The MIB > contains four groups" Fixed. However, "group" is a reserved keyword in SMIv2 referring to compliance, so it should be replaced by "subtree" where that is its meaning. > > 8) Section 3 has a number of lists. You should decide if the list > should contain sentences, or makes up one complete sentence. If it is > one sentence, then each listed clause should end with a comma, and be > consistent in style. If each item is a sentence, then the introductory > phrase needs to be a sentence. I recommend making each item a > sentence, so we can eliminate the "which" conrstructs. Fixed. > > 9) "asynchronously monitor" s/b "asynchronously report" Fixed. > > 10) the name of SyslogMIB or syslogMIB should be consistent in the > text. I recommend using SYSLOG-MIB, which is the correct name for the > MIB module. Fixed. > > 11) in SyslogSeverity, I recommend removing the second sentnece in the > description "The syslog protocol uses the values 0 (emergency) to 7 > (debug)." since this is already spelled out in the SYNTAX clause, and > shows that 99 (other) is also used. Why do we need 99? Are other > values valid? Partially fixed. When is "other" used? > > 12) SyslogService - can we make this just a service name. The port > semantics are really ambiguous. How do distinguish a UDP port# from a > TCP port#? Not fixed. > > 13) For consistency with most other MIB modules being developed, I > suggest defining a top-level breakdown of syslogNotifications (0), > syslogObjects (1), and syslogConformance (2). Then put syslogSystem > and syslogDevice under syslogObjects. See RFC4181 appendix D. Fixed. > > 14) transportAddressType is designed to be used with specific types of > transportAddress. The syslogDefaultTransport object should probably be > syslogDefaultTransportType. A transportAddressType seems inappropriate > for use with syslogDefaultService, which does not necessarily resolve > to one of the enumerated options. We should have a > syslogDefaultTransport that is a transport address. If we want a > Default service, that should probably be a separate object. Partially fixed. How will the syslog/TLS transport address be specified in this object? > > 15) some objects are named xxxSeverity, but the description uses > priority. We need to be consistent with the other documents about what > this is called. Fixed. > > 16) the syslogDefaultMaxMessageSize description really needs work - > 480 is the minimum maximum size, not the recommended maximum size, so > it should not be the default. The maximum message size also may depend > on the transport protocol and the target system, so I'm not sure a > default is a useful object. Who is the user of this default? The local > system? If so, then it is an implementation detail and does not need > to exposed in a mIB object. If it is for use by the remote system, > then it shouldn't be a default value, but the actual value supported > by the implementation. Fixed (removed). > > 17) syslEntOpsTable uses abbreviated elements in the name. I don't see > why they need to be abbreviated, or what the name actually means. The > description does not mention "ops". Fixed. > > 18) object prefixes should be consistent for the whole module. The > DefaultXXX uses syslog as the prefix, but here we use sysl. Why? See > RFC4181 appendix C for naming guidelines. Fixed. > > 19) syslEntCtlTable contains static info; does that imply that > syslEntOpsTable contains dynamci info? Or is syslEntOpsTable about the > operational environment, and syslEntCtlTable about control info? The > descritions should kae the purpose of the table unambiguous. Fixed. > > 20) In the SNMPv2 effort, we found that using integer indices made > using the tabels more difficut for human readers. It would be much > easier for a human to interpret the statistics here is it is easy to > tell what the systlog entity is. So I recommend using an > SnmpAdminString as the index. For systems that cannot, for whatever > reason, determine a human-readable identifier for the index, the > SnmpAdminString can always be "1", "2", etc. Not fixed. > > 21) what is the persistence of the index? If syslog entities happen to > start in a different order, will the index# refer to the same entity > after a reboot? If the MIB says they must be persistent across > reboots, how difficult will that be for the OS that starts the > applications? What value will the system keep to match up to the > integer indicies to make sure they remain the same? Partially fixed. Is it important for interoperability to be able to correlate messages from before a system reboot and after a system reboot? If so, what object can be used to do this correlation since integer index can change across reboots? I suspect the ControlDescr object might be able to be used, but the description for ControlDescr does not specify the persistence of that object. All objects in the syslogEntityControlTable should probably persist across reboots if you want the syslog entity to be configured the same way across reboots. You have a problem, however. You are using an integer index that does not persist across reboots. How does the SNMP agent correlate the persistent configuration parameters with the appropriate application index after a reboot? How does a remote manager read this table and understand which row of configuration and monitoring info (like statistics) refers to which application? > > 22) syslEntOpsMsgsDropped counts messages that could not be relayed. > What about messages that cannot be queued for transmission for an > original sender? Fixed. > > 23) syslEntOpsMsgsIgnored - where are the "allowed specifications" > defined? We don't want a value that can be interpreted differently by > different entities, because then the values canot be compared across > systems, or have consistent baselines for comparison across products, > etc. Objects shoud be defined to be interoperable and unambiguous. Partially fixed. This is still ambiguous, and could be interpreted in different ways by different implemnenters resulting in non-interoperability. This needs to be unambiguous as to what gets counted. This object counts things outside the "allowed specifications" - again I ask where are the allowed specfications defined so an implementer knows what they are? > > 24) syslEntOpsLastMsgDeliveredTime - the system does not know when the > message was delivered, only when it was transmitted or received. Fixed. > > 25) syslEntOpsLastError talks about "this process". Is this the syslog > entity? This needs to be clear and unambiguous, and consistent with > the terminology in the other WG documents. I'm confused. Is an entity an application, such as login, or is the entity the thing that sends syslog messages, such as a syslog daemon, that sends messages for multiple applications? Does the last error refer to the last error seen by the login process, or by the syslog sender process (e.g. daemon)? Since entity refers to all the different roles - senders, receivers, relays, and collectors, does that mean we are keeping "last error" info at the receiver as well as at the sender, and at the relays as well? > > 26) syslEntOpsLastError talks about the last error this process > "encountered". The definition of encountered needs to be made unclear > and unambiguous. Not fixed. What does "encountered" mean? Sent/received/relayed/collected? While we're at it, what exactly does error mean? How do I know when I am encountering an error? Can I encounter other things, like warnings? I see that Error is a type of severity. Is that what we ar ecounting? Do we also want to count criticals, and alerts, and emergencies, etc. Or is that not what you mean by "encounter an error". > > 27) what is the persistence of the syslEntOpsReference across reboots > of the OS? Across reboots of the SNMP system? If it is not persistent, > but the table is, what should the SNMP agent do - delete the > references? Change the references to match the new SWRunIndex? > > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 06 20:45:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs8JE-0001hx-KJ; Wed, 06 Dec 2006 20:44:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs8JE-0001hn-0Y for syslog@ietf.org; Wed, 06 Dec 2006 20:44:24 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs8JC-00040k-NO for syslog@ietf.org; Wed, 06 Dec 2006 20:44:23 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20061207014421b1200t2e75e>; Thu, 7 Dec 2006 01:44:21 +0000 From: "David B Harrington" To: "'David Harrington'" , Date: Wed, 6 Dec 2006 20:41:19 -0500 Message-ID: <0de601c719a0$cbda6da0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb3yrMS6ODMYCInS4KDym8acG1uewhvdh5g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <001201c6f80f$22b39470$22021eac@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Subject: [Syslog] Dbh re-review of Mib-11-, part 2 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi this is a review of the requested changes from part 2 of my earlier review. > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, October 25, 2006 4:25 AM > To: syslog@ietf.org > Subject: Mib-09- review, part 2 > > Continued ... > > 1) syslEntCtlTable should describe what type of information is stored > in the table, and the description should be more than "static info". Fixed. > > 2) syslEntCtlEnty - what type of parameters? What process? > > 3) syslEntCtlBindAddress - does this field contain an address or a > hostname? What does the seond sentence mean? Partially fixed. When a manager application reads the addrtype an dfinds "dns", and then reads the address object, will the agent a hostname or the IPv4 or IPv6 address in the varbind? If it returns, say, an IPv4 address, does it change the AddrType field to match? Or do you intend it to return the dns hostname along with the dns addrtype? I cannot tell what is intended, and I expect other implementer swill have trouble knowing which is the right interpretation of the very ambiguous description. > > 4) syslEntCtlTransport - why is this "default" transport instead of > just transport? Fixed. > > 5) is there a mismatch between transportaddresstype and > syslEntCtlService? Is there a transportAddressType for this type of > "address"? Not fixed. I think you are using an enumeration to identify the format of the value in the next object, and then using a format in the next object that does not match any of the enumerated choices. This is obviously wrong. > > 6) syslEntCtlConfFileName - using lots of abbreviations in the name > makes it hard for people to remember how the words were abbreviated. > It would be better to use something like syslogEntCtlFilename. Why do > we need Ent in the name? we never deal with anything other than > entities, do we? syslogControlFile would be much easier to remember > than syslEntCtlConfFileName. Fixed (mostly). > > 7) syslEntCtlConfFileName refers to syslogCtlSelectionTable and > syslogCtlActionTable - where are these defined? Fixed. > > 8) syslEntCtlStatus - again, what process? Fixed. > > 9) syslEntCtlStorageType - is this definition exactly the same as the > StorageType T-C? I am not sure this is the same semantics as StorageType T-C. Your text is somewhat unclear when it says "backed up by non-volatile (permanent)" > > 10) ...RowStatus - spelling "iff" Fixed. > > 11) syslEntStarted and syslEntStopped - spell out MO. I don't > understand the second sentence; how does the manager know what > syslEntOpsIndex is used? Partially fixed. I still do not understand the second sentence. Can you reword this sentence? > > 12) It would be much better to use consistent naming between the > objects/tables and the conformance clauses. The table refers to > syslEnt, but conformance is for syslogDev; the objects are > syslogDefault but the conformance is syslogSystem. Let'e make it easy > to work with by being more consistent. Fixed. Much better. > > 13) why are notifications not mandatory for compliance? syslogFullCompliance2 says this means support for writable objects and notifications, but th enotification group has been left out of the manadatory-groups. If the intention is to leave out the notification, I would like to know why this is desirable. > > 14) The MIB module exposes some info from syslog, such as last error. > The security considerations talk about securing snmp, but that does > not make sense if you do not also secure the syslog transport. The > security considerations should recommend securing syslog to match the > snmp security. Not fixed. > > 15) iana considerations talks about a base arc; this would be better > reworded. Fixed. > > 16) I thik rfc3164 is informative, no tnormative. Fixed. > > 17) I suspect you are not usinng xml2rfc. If not, you need to make > sure all the boilerplates are up-to-date. Please check the funding > statement and the intellectual property clauses. Partially fixed. Needs updated boilerplates. > > 18) the change log is most effective if you track the chnages from > published version to published version, not by MIB revision dates. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 06 20:49:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs8OR-0005Kc-KR; Wed, 06 Dec 2006 20:49:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs8OQ-0005KW-Kj for syslog@ietf.org; Wed, 06 Dec 2006 20:49:46 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs8OP-0004kX-DL for syslog@ietf.org; Wed, 06 Dec 2006 20:49:46 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061207014943b1100eu7hue>; Thu, 7 Dec 2006 01:49:44 +0000 From: "David Harrington" To: Date: Wed, 6 Dec 2006 20:46:34 -0500 Message-ID: <0de701c719a1$8d1a5250$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccZoNASZ8m/dhGVQfGRAgl98g0UAw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Syslog] Review of mib-11, part 3 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, 1) The idnits checker reports the use of the old copyright and disclaimer boilerplates rather than the new copyright and disclaimer boilerplates. These need to be updated. 2) syslogEntityOperationsReference uses a lower case "should". Is it nto important for interoperability that this be done? If so, then this should be a "SHOULD". If not for interoperability, why are we saying it "should" be done? 3) I still have difficulty understanding why default parameters are listed in the MIB module. What is the use case that requires these objects in the MIB module? Who decides what the default values should be? Since they are read-write objects, I assume the purpose is to allow an NMS to set the default values they want the sender to use. What happens if there are multiple NMSs talking to the same sender? Then who decides? If each NMS gets to decide, than you need a table in which each row is "owned" by a particular NMS. I still don't see why this would be needed however. If the sender decides, and the objects exist only so the receivers can check and see what the sender will use for defaults, then why are the objects read-write? Once an NMS checks the defaults, what are they supposed to do with this information? I question whether this deserves to be in the MIB module at all, but if it kept, then at least the MIB module should include a description of why it is there and how it should be used. 4) RFCPROT is a reference in syslogDefaultTransportDomain; it probably shoul dbe shown as [RFCPROT] or the RFC editor may overlook it. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 08 23:07:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GstT7-0004uu-EU; Fri, 08 Dec 2006 23:05:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GstT5-0004uf-Ut for syslog@ietf.org; Fri, 08 Dec 2006 23:05:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GstT4-0006lw-Md for syslog@ietf.org; Fri, 08 Dec 2006 23:05:43 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 08 Dec 2006 20:05:42 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB945gko002894; Fri, 8 Dec 2006 20:05:42 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kB945fdE023421; Fri, 8 Dec 2006 20:05:41 -0800 (PST) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 20:05:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Dec 2006 20:05:40 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB02B85319@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-syslog-sign-20.txt Thread-Index: Acbc8+g/jZl4SDWATEChWON8ntejRg+UxBmA From: "Alexander Clemm \(alex\)" To: X-OriginalArrivalTime: 09 Dec 2006 04:05:41.0579 (UTC) FILETIME=[4ADA31B0:01C71B47] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=111; t=1165637142; x=1166501142; c=relaxed/simple; s=sjdkim2002; 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:=20draft-ietf-syslog-sign-20.txt |Sender:=20; bh=UCa8thCloyFqcDrJh5Y5J/BlQybWhVw+pVXBwXksLmk=; b=d9t3qjN1w4GHnqtiEYzp+PzT2CZo3W5ZDUW0d50AMUZAQYofRfHcqQicor7RhunU8V6a2VwH iJzlb3DxyI6wcrZU0AzaWmJebIZYAO2uMq61lb8s+rcrR2VKVxWpufLZ; Authentication-Results: sj-dkim-2; header.From=alex@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: dbharrington@comcast.net Subject: [Syslog] draft-ietf-syslog-sign-20.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hello, I have just submitted syslog-sign-20, which should be posted shortly. =20 Best regards --- Alex _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Dec 09 01:27:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsvfx-0006ir-9u; Sat, 09 Dec 2006 01:27:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsvfv-0006hE-7T for syslog@ietf.org; Sat, 09 Dec 2006 01:27:07 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsvfq-0001O7-Iz for syslog@ietf.org; Sat, 09 Dec 2006 01:27:07 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kB96QZJW014080 for ; Sat, 9 Dec 2006 15:26:35 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kB96QUsN007778 for ; Sat, 9 Dec 2006 15:26:35 +0900 (JST) Message-ID: <457A5716.2070005@cysols.com> Date: Sat, 09 Dec 2006 15:26:30 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 References: <0d5401c71989$086d1910$0600a8c0@china.huawei.com> In-Reply-To: <0d5401c71989$086d1910$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Dave, Thanks for the detailed review. I count a total of 13 + 7 + 4 = 24 issues raised in the three mails. Let me go through these and try to figure out how to address the issues, hopefully by 18/12/2006. Cheers Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 11 15:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6E-0000VM-Og; Mon, 11 Dec 2006 15:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts66-0000Rw-6T; Mon, 11 Dec 2006 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gts65-0004XV-Mh; Mon, 11 Dec 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id A538332990; Mon, 11 Dec 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gts65-0007hj-Hh; Mon, 11 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-sign-20.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Signed syslog Messages Author(s) : J. Kelsey, et al. Filename : draft-ietf-syslog-sign-20.txt Pages : 38 Date : 2006-12-11 This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification draws upon the work defined in RFC xxxx, "The syslog Protocol", however it may be used atop any message delivery mechanism, even that defined in RFC 3164, "The BSD syslog Protocol", or in the RAW mode of RFC 3195, "The Reliable Delivery of syslog". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-20.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-sign-20.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-sign-20.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-11134658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-sign-20.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-sign-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-11134658.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Tue Dec 12 10:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9ZQ-0005ky-Lo; Tue, 12 Dec 2006 10:29:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9ZQ-0005ks-5J for syslog@ietf.org; Tue, 12 Dec 2006 10:29:28 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu9ZM-0005SF-Hb for syslog@ietf.org; Tue, 12 Dec 2006 10:29:28 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061212152923b1100k66p9e>; Tue, 12 Dec 2006 15:29:23 +0000 From: "David Harrington" To: Date: Tue, 12 Dec 2006 10:26:20 -0500 Message-ID: <120b01c71e01$e02bdcc0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iACkS6mUBSSxIGQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Syslog] Working Group Last Call: syslog-sign-20 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, This message officially starts the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-20.txt The Working Group Last Call for this document will end December 28. The previous WGLC for this document was revision http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt It is recommended that reviewers especially consider the changes made between the two revisions, although the complete document should also be reviewed. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Dec 12 14:37:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDRK-0000zv-Ik; Tue, 12 Dec 2006 14:37:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDRK-0000zq-5E for syslog@ietf.org; Tue, 12 Dec 2006 14:37:22 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuDRH-00066N-U9 for syslog@ietf.org; Tue, 12 Dec 2006 14:37:22 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20061212193719b1300q4s4te>; Tue, 12 Dec 2006 19:37:19 +0000 From: "David Harrington" To: Date: Tue, 12 Dec 2006 14:33:55 -0500 Message-ID: <123501c71e24$82b03370$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcceI+giuEIWW2LDSDmJpBlwvMth8g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Syslog] WGLC sign-20 comments, part 1 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I started doing a quick review of sign-20. There have been quite a few changes in the text, including some that will have impact on the technical specification, so if you haven't reviewed the latest revision, you probably should to make sure the new text is acceptable. 1) the document passes idnits 1.122 2) I have some concerns about the RFC2119 keyword usages. There are quite a few lowercase "must" and "may" and other RFC2119 keywords throughout the document. This can cause quite a lot of delay during advancement since every IESG member is likely to question whether they are required for interoperability and should be capitalized keywords. 3) /A device needs to hence support persisting previous reboot session ID across reboots./The reboot session ID must be persistent across reboots./ More later. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Dec 12 15:40:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEPP-0000k8-6r; Tue, 12 Dec 2006 15:39:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEPN-0000k3-Ig for syslog@ietf.org; Tue, 12 Dec 2006 15:39:25 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuEPM-0002tM-BA for syslog@ietf.org; Tue, 12 Dec 2006 15:39:25 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20061212203923b1200bqe1be>; Tue, 12 Dec 2006 20:39:23 +0000 From: "David Harrington" To: Date: Tue, 12 Dec 2006 15:36:09 -0500 Message-ID: <124601c71e2d$2e77c030$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcceLKmfNw1SmUTjRsuOkJ+iGwewdg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Syslog] Syslog-mib-11 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, In my latest review of syslog-mib-11, I have started to believe that Tom was right when he questioned the MIB module design, which models multiple syslog entities in a table, so one SNMP engine deals with multiple syslog senders, relays, and/or recievers on the same host. This adds complexity in the MIB design that I am not convinced is necessary. As the terminology in the MIB document has gotten closer to other WG documents, this has become somewhat clearer to me. Tom recommended that the MIB module only model a single syslog entity. Different instantations of the MIB module can be represented as existing in different contexts (e.g. in different communities), so one SNMP engine can still deal with multiple syslog senders, relays, and/or receivers on the same host, but the MIB module itself becomes simpler. We should be sure the MIB module reflects real world requirements. I do not have much operational experience, so I need your input. In real deployments, is it **typical** to have multiple syslog stacks running on the same host, each with a different bind address and port number and config file? or is it more common for most applications to share one syslog process (e.g., daemon) that operates via one address/port? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Dec 12 16:02:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEkY-0005k9-KX; Tue, 12 Dec 2006 16:01:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEkX-0005ju-BW for syslog@ietf.org; Tue, 12 Dec 2006 16:01:17 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuEkT-0007Tt-1q for syslog@ietf.org; Tue, 12 Dec 2006 16:01:17 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 12 Dec 2006 13:01:12 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kBCL19AJ024094 for ; Tue, 12 Dec 2006 13:01:09 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBCL18io001560 for ; Tue, 12 Dec 2006 13:01:09 -0800 (PST) Date: Tue, 12 Dec 2006 13:01:08 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=549; t=1165957269; x=1166821269; 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:=20Diffs=20in=20syslog-sign=20IDs |Sender:=20; bh=xuzFAmI38mmAG5P3k9wY+r3LSlOxKOlxrrqckkQ5uBQ=; b=dXlRjBmKJGRgmRcC8ijp3njB1PZHe98OQwZuYvQpdQ0zO25spI32gWN0WdtIOGO14ltsWdMh 1fnG1yEVQ03XItLven77TdwGBmhnk2/dYaw5GdVJzgq26QHFHJ7bwO0j; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Syslog] Diffs in syslog-sign IDs X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, There have been many changes made to the syslog-sign ID during the last WGLC. As David announced, we are going to do another WGLC for this ID. To help you in your reviews, I have created some diffs. The differences between -18 and -19 http://www.employees.org/~lonvick/sign-18-19.html The differences between -19 and -20 http://www.employees.org/~lonvick/sign-19-20.html The differences between -18 and -20 http://www.employees.org/~lonvick/sign-18-20.html Please review and send in your comments. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 13 03:35:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuPZ1-00008b-UV; Wed, 13 Dec 2006 03:34:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuPYz-00005c-Vi for syslog@lists.ietf.org; Wed, 13 Dec 2006 03:34:05 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuPYy-0001qB-Hh for syslog@lists.ietf.org; Wed, 13 Dec 2006 03:34:05 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3E1E927C013 for ; Wed, 13 Dec 2006 09:36:56 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12732-03 for ; Wed, 13 Dec 2006 09:36:56 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id DEE2D27C012 for ; Wed, 13 Dec 2006 09:36:55 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 09:33:49 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Dec 2006 09:33:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F88C3@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Framing in syslog-transport-tls Thread-Index: AccekWLftezytcn4QPqOs1hl5YMwhw== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 13 Dec 2006 08:33:49.0965 (UTC) FILETIME=[69EE13D0:01C71E91] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Syslog] Framing in syslog-transport-tls X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Miao, WG, I have partially implemented syslog-transport-tls in two different programs (MonitorWare Agent and rsyslog). My focus was the framing, not tls itself (I needed the new framing for some other functionality, but that is a separate story). I would like to share my experience during that implementation. This is *not* necessarily a request for change. I just though that might also come up during IETF last call, so I think the information is useful. FRAME-LEN is a variable length field. It specifies the length of the frame including the length of FRAME-LEN itself. This is no real problem for the receiver. On the sender side, however, it is a bit tricky. I need to obtain the length of the ASCII-encoded field including the (potentially changing) size of itself. Let's look at a sample. We have a message with 996 octets. Now I obtain the information that I need 4 octets to encode this ("996 "). I need to add that to the total message length, bringing me up to 1000 octets. Now, I need to re-check my buffer requirements. I now learn that I need a 5 octect encoding. This I need to add to the previous length of the message (996), resulting in a total frame length of 1001 octets. If we would just count the MSG part of the frame, there would be no such ambiguity, because I would set FRAME-LEN to whatever size I know the MSG part has. It would be 996 in this case. However, that would mean we have two different framing mechanisms inside the frame - octet stuffing (the SP) after the count and then octet counting for the rest of the message (I think http uses such a mechanism, but have not verified). On the other hand, I can easily implement the current specification with few lines of code. Here is a C sample of the code I actually use in rsyslog: iLenBuf =3D snprintf(szLenBuf, sizeof(szLenBuf)/sizeof(char), "%d ", = len); iLenBuf =3D snprintf(szLenBuf, sizeof(szLenBuf)/sizeof(char), "%d ", len = + iLenBuf); Where len is the length of SYSLOG-MSG and iLenBuf the total frame length. For context, see http://rsyslog.cvs.sourceforge.net/rsyslog/rsyslog/syslogd.c?revision=3D1= . 159&view=3Dmarkup and scroll down to line 1766. Initially, I was of the view that it would be advisable to think about changing -transport-tls so that the octet count is just the length of SYSLOG-MSG. After some thinking, I now believe that it is fine as it currently is specified. I suggest a sentence "warning to implementors" to point to the potential mis-implementation. On the other hand, a receiver must rely on the octet-stuffing in any case. Because it needs to find the SP in order to find the end of the octet count. That would be an argument to contain only the size of SYSLOG-MSG in the counter. Given the fact that -transport-tls is already submitted to the IESG AND there is no real problem with the current specification, I propose not to change it (except for adding a warning as outlined above). Sorry for the late catch, but these things seem to only appear when you actually implement...=20 I would appreciate comments on the issue. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 13 03:45:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuPjW-00067q-8x; Wed, 13 Dec 2006 03:44:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuPjU-00067f-S8 for syslog@lists.ietf.org; Wed, 13 Dec 2006 03:44:56 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuPjQ-00042t-Dv for syslog@lists.ietf.org; Wed, 13 Dec 2006 03:44:56 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 784EA5AD00; Wed, 13 Dec 2006 09:44:49 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09118-01; Wed, 13 Dec 2006 09:44:46 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 1F85559095; Wed, 13 Dec 2006 09:44:46 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 49CCA8F9771; Wed, 13 Dec 2006 09:44:43 +0100 (CET) Date: Wed, 13 Dec 2006 09:44:43 +0100 From: Juergen Schoenwaelder To: Rainer Gerhards Subject: Re: [Syslog] Framing in syslog-transport-tls Message-ID: <20061213084443.GA3110@boskop.local> References: <577465F99B41C842AAFBE9ED71E70ABA1F88C3@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F88C3@grfint2.intern.adiscon.com> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: syslog@lists.ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Wed, Dec 13, 2006 at 09:33:38AM +0100, Rainer Gerhards wrote: > FRAME-LEN is a variable length field. It specifies the length of the > frame including the length of FRAME-LEN itself. This is no real problem > for the receiver. On the sender side, however, it is a bit tricky. I > need to obtain the length of the ASCII-encoded field including the > (potentially changing) size of itself. Let's look at a sample. [...] > If we would just count the MSG part of the frame, there would be no such > ambiguity, because I would set FRAME-LEN to whatever size I know the MSG > part has. It would be 996 in this case. However, that would mean we have > two different framing mechanisms inside the frame - octet stuffing (the > SP) after the count and then octet counting for the rest of the message > (I think http uses such a mechanism, but have not verified). [...] > Initially, I was of the view that it would be advisable to think about > changing -transport-tls so that the octet count is just the length of > SYSLOG-MSG. After some thinking, I now believe that it is fine as it > currently is specified. I suggest a sentence "warning to implementors" > to point to the potential mis-implementation. On the other hand, a > receiver must rely on the octet-stuffing in any case. Because it needs > to find the SP in order to find the end of the octet count. That would > be an argument to contain only the size of SYSLOG-MSG in the counter. Unfortunately, I did not catch this when I reviewed this document. I believe not including the framing characters in the length value makes a lot of sense; in fact, FRAME-LEN should perhaps have been MSG-LEN to start with. Taking any process issues aside, I would be in favor of such a change. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 13 05:01:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuQuc-0005HQ-Ot; Wed, 13 Dec 2006 05:00:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuQua-0005GZ-W0 for syslog@lists.ietf.org; Wed, 13 Dec 2006 05:00:28 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuQuY-00065v-8Y for syslog@lists.ietf.org; Wed, 13 Dec 2006 05:00:28 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JA700ED3I6YHK@szxga01-in.huawei.com> for syslog@lists.ietf.org; Wed, 13 Dec 2006 17:54:34 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JA700HDBI6X4A@szxga01-in.huawei.com> for syslog@lists.ietf.org; Wed, 13 Dec 2006 17:54:34 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JA700CZ1I6TTJ@szxml04-in.huawei.com> for syslog@lists.ietf.org; Wed, 13 Dec 2006 17:54:33 +0800 (CST) Date: Wed, 13 Dec 2006 17:54:28 +0800 From: Miao Fuyou Subject: RE: [Syslog] Framing in syslog-transport-tls In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA1F88C3@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' , syslog@lists.ietf.org Message-id: <001c01c71e9c$ae5b50e0$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccekWLftezytcn4QPqOs1hl5YMwhwACNMgg X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, My co-workers in university also encountered this issue when implementing syslog-tls, and used a mechanism similiar to the one of Rainer to overcome it. As I am aware of, currently there are two syslog framing implementation and both the implementaters considered this boundary condition. So, my perception is careful implementater would have no problem, and a note for reminding is enough. Regards, Miao > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Wednesday, December 13, 2006 4:34 PM > To: syslog@lists.ietf.org > Subject: [Syslog] Framing in syslog-transport-tls > > Miao, WG, > > I have partially implemented syslog-transport-tls in two > different programs (MonitorWare Agent and rsyslog). My focus > was the framing, not tls itself (I needed the new framing for > some other functionality, but that is a separate story). I > would like to share my experience during that implementation. > This is *not* necessarily a request for change. I just though > that might also come up during IETF last call, so I think the > information is useful. > > FRAME-LEN is a variable length field. It specifies the length > of the frame including the length of FRAME-LEN itself. This > is no real problem for the receiver. On the sender side, > however, it is a bit tricky. I need to obtain the length of > the ASCII-encoded field including the (potentially changing) > size of itself. Let's look at a sample. > > We have a message with 996 octets. Now I obtain the > information that I need 4 octets to encode this ("996 "). I > need to add that to the total message length, bringing me up > to 1000 octets. Now, I need to re-check my buffer > requirements. I now learn that I need a 5 octect encoding. > This I need to add to the previous length of the message > (996), resulting in a total frame length of 1001 octets. > > If we would just count the MSG part of the frame, there would > be no such ambiguity, because I would set FRAME-LEN to > whatever size I know the MSG part has. It would be 996 in > this case. However, that would mean we have two different > framing mechanisms inside the frame - octet stuffing (the > SP) after the count and then octet counting for the rest of > the message (I think http uses such a mechanism, but have not > verified). > > On the other hand, I can easily implement the current > specification with few lines of code. Here is a C sample of > the code I actually use in > rsyslog: > > iLenBuf = snprintf(szLenBuf, sizeof(szLenBuf)/sizeof(char), > "%d ", len); iLenBuf = snprintf(szLenBuf, > sizeof(szLenBuf)/sizeof(char), "%d ", len + iLenBuf); > > Where len is the length of SYSLOG-MSG and iLenBuf the total > frame length. For context, see > > http://rsyslog.cvs.sourceforge.net/rsyslog/rsyslog/syslogd.c?r > evision=1. > 159&view=markup > > and scroll down to line 1766. > > Initially, I was of the view that it would be advisable to > think about changing -transport-tls so that the octet count > is just the length of SYSLOG-MSG. After some thinking, I now > believe that it is fine as it currently is specified. I > suggest a sentence "warning to implementors" > to point to the potential mis-implementation. On the other > hand, a receiver must rely on the octet-stuffing in any case. > Because it needs to find the SP in order to find the end of > the octet count. That would be an argument to contain only > the size of SYSLOG-MSG in the counter. > > Given the fact that -transport-tls is already submitted to > the IESG AND there is no real problem with the current > specification, I propose not to change it (except for adding > a warning as outlined above). > > Sorry for the late catch, but these things seem to only > appear when you actually implement... > > I would appreciate comments on the issue. > > Rainer > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 13 05:45:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuRbm-0001o4-2Z; Wed, 13 Dec 2006 05:45:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuRbk-0001lt-Tb for syslog@lists.ietf.org; Wed, 13 Dec 2006 05:45:04 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuRbi-00005s-Iy for syslog@lists.ietf.org; Wed, 13 Dec 2006 05:45:04 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id C9F555617A; Wed, 13 Dec 2006 11:45:01 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19900-06; Wed, 13 Dec 2006 11:44:58 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id C549E56281; Wed, 13 Dec 2006 11:44:58 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 219C98F98FD; Wed, 13 Dec 2006 11:44:56 +0100 (CET) Date: Wed, 13 Dec 2006 11:44:56 +0100 From: Juergen Schoenwaelder To: Miao Fuyou Subject: Re: [Syslog] Framing in syslog-transport-tls Message-ID: <20061213104456.GB3406@boskop.local> References: <577465F99B41C842AAFBE9ED71E70ABA1F88C3@grfint2.intern.adiscon.com> <001c01c71e9c$ae5b50e0$800c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001c01c71e9c$ae5b50e0$800c6f0a@china.huawei.com> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: syslog@lists.ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Wed, Dec 13, 2006 at 05:54:28PM +0800, Miao Fuyou wrote: > My co-workers in university also encountered this issue when implementing > syslog-tls, and used a mechanism similiar to the one of Rainer to overcome > it. As I am aware of, currently there are two syslog framing implementation > and both the implementaters considered this boundary condition. So, my > perception is careful implementater would have no problem, and a note for > reminding is enough. The fact that two implementars did already run into this is a good indication that perhaps the format should be changed to what implementors expect and find easier. We seem to have some evidence that the current format makes things more complex to get implemented than it needs to be and I have not seen yet a technical argument in favor of the current format. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 13 06:46:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuSYN-0003i4-S9; Wed, 13 Dec 2006 06:45:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuSYM-0003fN-8J for syslog@ietf.org; Wed, 13 Dec 2006 06:45:38 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuSYK-0005nH-8W for syslog@ietf.org; Wed, 13 Dec 2006 06:45:38 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBDBjHJW026257 for ; Wed, 13 Dec 2006 20:45:17 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBDBjGsN002015 for ; Wed, 13 Dec 2006 20:45:17 +0900 (JST) Message-ID: <457FE7CC.8050000@cysols.com> Date: Wed, 13 Dec 2006 20:45:16 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 References: <0d5401c71989$086d1910$0600a8c0@china.huawei.com> <457A5716.2070005@cysols.com> In-Reply-To: <457A5716.2070005@cysols.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I have pruned the list of comments and renumbered them. The following starts the discussion on the points raised in Dbh re-Review of -mib-11, part 2. Cheers Glenn +---------------------------------------------------------------+ 2.1 > > 5) is there a mismatch between transportaddresstype and > > syslEntCtlService? Is there a transportAddressType for this > > type of > > "address"? Not fixed. I think you are using an enumeration to identify the format of the value in the next object, and then using a format in the next object that does not match any of the enumerated choices. This is obviously wrong. Response: That is not what we are doing. syslogEntityControlTransportDomain maps onto a transport domain. e.g. transportDomainUdpIpv4 syslogEntityControlService maps onto a port number e.g. 512 Let me know if I got this wrong. 2.2 > > 6) syslEntCtlConfFileName - using lots of abbreviations in > > the name > > makes it hard for people to remember how the words were > > abbreviated. > > It would be better to use something like syslogEntCtlFilename. > > Why do > > we need Ent in the name? we never deal with anything other than > > entities, do we? syslogControlFile would be much easier to > > remember > > than syslEntCtlConfFileName. Fixed (mostly). Response: What is the remaining problem? 2.3 > > 9) syslEntCtlStorageType - is this definition exactly the > > same as the > > StorageType T-C? I am not sure this is the same semantics as StorageType T-C. Your text is somewhat unclear when it says "backed up by non-volatile (permanent)" Response: Will the following help: syslogEntityControlStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether the parameters defined in this row are kept in volatile storage and lost upon reboot or are backed up by non-volatile or permanent storage. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " That mimics the DESCRIPTION used in DISMAN-MIB e.g. smLaunchStorageType 2.4 > > 11) syslEntStarted and syslEntStopped - spell out MO. I don't > > understand the second sentence; how does the manager know what > > syslEntOpsIndex is used? Partially fixed. I still do not understand the second sentence. Can you reword this sentence? Response: When a trap is received, the NMS/Operator needs to figure out which syslog "entity" the trap is about. This is done by using the syslogEntityOperationsIndex instance identifier of the objects in the notification. Will the following help? "The syslog entity corresponding to the notification will be identified by the syslogEntityOperationsIndex instance identifier of the objects in the notification." 2.5 > > 13) why are notifications not mandatory for compliance? syslogFullCompliance2 says this means support for writable objects and notifications, but th enotification group has been left out of the manadatory-groups. If the intention is to leave out the notification, I would like to know why this is desirable. Response: The intention is to leave out the notification. syslogFullCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the SYSLOG-MIB with support for writable objects. Such an implementation can be both monitored and configured via SNMP. " MODULE -- this module MANDATORY-GROUPS { syslogDefaultGroup, syslogEntityOperationsGroup, syslogEntityControlGroup } ::= { syslogCompliances 2 } The reason is to retain the possibility of a compliant implementation that does not support notifications. 2.6 > > 14) The MIB module exposes some info from syslog, such as > > last error. > > The security considerations talk about securing snmp, but > > that does > > not make sense if you do not also secure the syslog transport. > > The > > security considerations should recommend securing syslog to > > match the > > snmp security. Not fixed. Response: To me that appeared to be out of scope. That seems to be a matter for the "security considerations" for syslog transport. No? Will something like the following suffice: "Under some circumstances securing SNMP will not make sense if the syslog transport is not secured. It is recommended that the syslog transport be secured to match the security level of SNMP." 2.7 > > 17) I suspect you are not usinng xml2rfc. If not, you need to > > make > > sure all the boilerplates are up-to-date. Please check the > > funding > > statement and the intellectual property clauses. Partially fixed. Needs updated boilerplates. Response: Updated the boilerplate for the Copyright notice. http://tools.ietf.org/tools/idnits/ shows zero errors now. Glenn M. Keeni wrote: > Dave, > Thanks for the detailed review. I count a total of > 13 + 7 + 4 = 24 issues raised in the three mails. Let > me go through these and try to figure out how to address > the issues, hopefully by 18/12/2006. > > Cheers > > Glenn > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 13 12:45:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuY9R-0004mC-JZ; Wed, 13 Dec 2006 12:44:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuY9P-0004m0-Px for syslog@lists.ietf.org; Wed, 13 Dec 2006 12:44:15 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuY9O-0002ey-3O for syslog@lists.ietf.org; Wed, 13 Dec 2006 12:44:15 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Dec 2006 09:44:14 -0800 X-IronPort-AV: i="4.12,164,1165219200"; d="scan'208"; a="48532083:sNHT55479564" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBDHiDao015521; Wed, 13 Dec 2006 12:44:13 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBDHiDYJ003720; Wed, 13 Dec 2006 12:44:13 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 12:44:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Framing in syslog-transport-tls Date: Wed, 13 Dec 2006 12:44:14 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122025109AC@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Framing in syslog-transport-tls Thread-Index: Acceo+Lmpd5YK6ReTsWD+CV1hy2dggAOiFeA From: "Anton Okmianski \(aokmians\)" To: , "Miao Fuyou" X-OriginalArrivalTime: 13 Dec 2006 17:44:13.0018 (UTC) FILETIME=[4D3413A0:01C71EDE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1592; t=1166031853; x=1166895853; 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=20Okmianski=20\(aokmians\)=22=20 |Subject:=20RE=3A=20[Syslog]=20Framing=20in=20syslog-transport-tls |Sender:=20 |To:=20, =20=22Miao=20Fuyou=22=20; bh=8+g8oGUyTl5D9Oqpb5IdrUrlywLQArVXQtjFiq2bpPE=; b=zcWiclsqEbF4LFZd3ZtIjtUghsiOPdx+3FmaQhSEiD07jiamU8kO8PvPRYkwVA9PqNgj2B9+ 3653e98+bDWCqyZnKwlnt5qn/lW394Vm0p4JlqOYjlEvtrWlCe9ICDlf; Authentication-Results: rtp-dkim-2; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: syslog@lists.ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I second Jeurgen's analysis. I'd like to understand a technical argument (if there is any) for requiring that extra bit of logic and creating a potential for errors.=20 Anton. =20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Wednesday, December 13, 2006 2:45 AM To: Miao Fuyou Cc: syslog@lists.ietf.org Subject: Re: [Syslog] Framing in syslog-transport-tls On Wed, Dec 13, 2006 at 05:54:28PM +0800, Miao Fuyou wrote: =20 > My co-workers in university also encountered this issue when=20 > implementing syslog-tls, and used a mechanism similiar to the one of=20 > Rainer to overcome it. As I am aware of, currently there are two=20 > syslog framing implementation and both the implementaters considered=20 > this boundary condition. So, my perception is careful implementater=20 > would have no problem, and a note for reminding is enough. The fact that two implementars did already run into this is a good indication that perhaps the format should be changed to what implementors expect and find easier. We seem to have some evidence that the current format makes things more complex to get implemented than it needs to be and I have not seen yet a technical argument in favor of the current format. /js --=20 Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 13 13:00:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuYOO-00059x-OF; Wed, 13 Dec 2006 12:59:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuYON-00059Z-Bu for syslog@ietf.org; Wed, 13 Dec 2006 12:59:43 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuYOK-0004mM-PS for syslog@ietf.org; Wed, 13 Dec 2006 12:59:43 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20061213175939b1200bu0tge>; Wed, 13 Dec 2006 17:59:39 +0000 From: "David Harrington" To: Date: Wed, 13 Dec 2006 12:56:30 -0500 Message-ID: <137d01c71ee0$077c9060$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccerGDD86Vp0ZFCSnO7HtXFHmsUfQALuTwQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <457FE7CC.8050000@cysols.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: Subject: [Syslog] Notification compliance X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Dbh> If the intention is to leave out the notification, I would like to know why this is desirable. Glenn> The reason is to retain the possibility of a compliant implementation that does not support notifications. This still does not explain why this is desirable. Who wants this feature? It may be desirable to implementers who have not chosen to implement notifications, so they can market their products as being IETF-compliant, but we are NOT here to help marketing departments claim compliance for their implementations by lowering the standards to match their implementations. The majority of snmp agents are based on either the commerical toolkit from SNMP research (or other commercial snmp toolkits), or the NET-SNMP (nee CMU-SNMP) toolkit. These already support notifications, and the objects carried in the notification are required for compliance, so I think it should be pretty simple to support the one notification. So I don't see a strong benefit for an implementer to not support the notification. I especially do not see the benefit of making this optional in the standard. Keep in mind that our job here is NOT to define a specification that allows as many incompatible implementations to claim compliance as possible. Our job here is to set some standards - a minimum level of support for a common set of features to provide multi-vendor and vendor-neutral interoperability. Having some implementations support notfications and others not support notifications negatively impacts interoperability. Non-interoperability is NOT a desirable feature. So I STRONGLY question the need for a compliance level to allow the lack of support for the notification. -- Let me approach the question from a different angle. Does the WG believe that this notification is so useless that most implementers will not implement it? Is this a nice-to-have but not really necessary feature in the standard? If so, then we should simply remove it from the standard. My personal opinion is that this would be a useful feature, and should not be optional. It should be part of the mandatory compliance, and an implementation without it should NOT be allowed to claim compliance to the standard. dbh > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Wednesday, December 13, 2006 6:45 AM > To: syslog@ietf.org > Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 > > Hi, > I have pruned the list of comments and renumbered them. > The following starts the discussion on the points raised > in Dbh re-Review of -mib-11, part 2. > > Cheers > > Glenn > > +---------------------------------------------------------------+ > 2.1 > > 5) is there a mismatch between transportaddresstype and > > > syslEntCtlService? Is there a transportAddressType for this > > > type of > > > "address"? > Not fixed. > I think you are using an enumeration to identify the > format of the > value in the next object, and then using a format in the > next object > that does not match any of the enumerated choices. This > is obviously > wrong. > > Response: > That is not what we are doing. > > syslogEntityControlTransportDomain maps onto a transport domain. > e.g. transportDomainUdpIpv4 > syslogEntityControlService maps onto a port number > e.g. 512 > > Let me know if I got this wrong. > > > 2.2 > > 6) syslEntCtlConfFileName - using lots of abbreviations in > > > the name > > > makes it hard for people to remember how the words were > > > abbreviated. > > > It would be better to use something like > syslogEntCtlFilename. > > > Why do > > > we need Ent in the name? we never deal with anything > other than > > > entities, do we? syslogControlFile would be much easier to > > > remember > > > than syslEntCtlConfFileName. > Fixed (mostly). > > Response: > What is the remaining problem? > > 2.3 > > 9) syslEntCtlStorageType - is this definition exactly the > > > same as the > > > StorageType T-C? > I am not sure this is the same semantics as StorageType T-C. > Your text is somewhat unclear when it says "backed up by > non-volatile (permanent)" > > Response: > Will the following help: > syslogEntityControlStorageType OBJECT-TYPE > SYNTAX StorageType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object defines whether the parameters defined in > this row are kept in volatile storage and lost upon > reboot or are backed up by non-volatile or permanent > storage. > Conceptual rows having the value 'permanent' need not > allow write-access to any columnar objects in the row. > " > > That mimics the DESCRIPTION used in DISMAN-MIB e.g. > smLaunchStorageType > > > 2.4 > > 11) syslEntStarted and syslEntStopped - spell out MO. I don't > > > understand the second sentence; how does the manager > know what > > > syslEntOpsIndex is used? > Partially fixed. I still do not understand the second > sentence. Can > you reword this sentence? > > Response: > When a trap is received, the NMS/Operator needs to > figure out which > syslog "entity" the trap is about. This is done by using the > syslogEntityOperationsIndex instance identifier of the objects in > the notification. > > Will the following help? > > "The syslog entity corresponding to the notification will be > identified by the syslogEntityOperationsIndex > instance identifier > of the objects in the notification." > > 2.5 > > 13) why are notifications not mandatory for compliance? > syslogFullCompliance2 says this means support for writable > objects and > notifications, but th enotification group has been left out > of the manadatory-groups. > > If the intention is to leave out the notification, I > would like to > know why this is desirable. > > Response: > The intention is to leave out the notification. > > syslogFullCompliance2 MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for SNMP entities which > implement the SYSLOG-MIB with support for writable > objects. Such an implementation can > be both monitored and configured via SNMP. > " > MODULE -- this module > MANDATORY-GROUPS { > syslogDefaultGroup, > syslogEntityOperationsGroup, > syslogEntityControlGroup > } > ::= { syslogCompliances 2 } > > The reason is to retain the possibility of a compliant > implementation that does not support notifications. > > 2.6 > > 14) The MIB module exposes some info from syslog, such as > > > last error. > > > The security considerations talk about securing snmp, but > > > that does > > > not make sense if you do not also secure the syslog > transport. > > > The > > > security considerations should recommend securing syslog to > > > match the > > > snmp security. > Not fixed. > > Response: > To me that appeared to be out of scope. That seems to be a matter > for the "security considerations" for syslog transport. No? > > Will something like the following suffice: > > "Under some circumstances securing SNMP will not make sense if > the syslog transport is not secured. It is > recommended that the > syslog transport be secured to match the security > level of SNMP." > > 2.7 > > 17) I suspect you are not usinng xml2rfc. If not, you need to > > > make > > > sure all the boilerplates are up-to-date. Please check the > > > funding > > > statement and the intellectual property clauses. > Partially fixed. Needs updated boilerplates. > > Response: > Updated the boilerplate for the Copyright notice. > http://tools.ietf.org/tools/idnits/ > shows zero errors now. > > > > > > Glenn M. Keeni wrote: > > Dave, > > Thanks for the detailed review. I count a total of > > 13 + 7 + 4 = 24 issues raised in the three mails. Let > > me go through these and try to figure out how to address > > the issues, hopefully by 18/12/2006. > > > > Cheers > > > > Glenn > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 13 19:43:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gueff-0002NM-90; Wed, 13 Dec 2006 19:41:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guefd-0002Kv-GD for syslog@lists.ietf.org; Wed, 13 Dec 2006 19:41:57 -0500 Received: from sinclair.provo.novell.com ([137.65.248.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guefb-0008Sf-3t for syslog@lists.ietf.org; Wed, 13 Dec 2006 19:41:57 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 13 Dec 2006 17:41:45 -0700 Message-Id: <45803B53.37FF.0081.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Wed, 13 Dec 2006 17:41:39 -0700 From: "John Calcote" To: "Miao Fuyou" , Subject: Re: [Syslog] Framing in syslog-transport-tls References: <577465F99B41C842AAFBE9ED71E70ABA1F88C3@grfint2.intern.adiscon.com> <001c01c71e9c$ae5b50e0$800c6f0a@china.huawei.com> <20061213104456.GB3406@boskop.local> In-Reply-To: <20061213104456.GB3406@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: syslog@lists.ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi all, I know I'm not very active on this list, but I do monitor all of the traffic. I'm totally in favor of the change. It makes sense, and the last thing we need is to publish a mistake at the last minute because we're not willing to make a small change so late in the game. Let's do it right the first time. --john >>> Juergen Schoenwaelder 12/13/06 3:44 AM >>> On Wed, Dec 13, 2006 at 05:54:28PM +0800, Miao Fuyou wrote: > My co-workers in university also encountered this issue when implementing > syslog-tls, and used a mechanism similiar to the one of Rainer to overcome > it. As I am aware of, currently there are two syslog framing implementation > and both the implementaters considered this boundary condition. So, my > perception is careful implementater would have no problem, and a note for > reminding is enough. The fact that two implementars did already run into this is a good indication that perhaps the format should be changed to what implementors expect and find easier. We seem to have some evidence that the current format makes things more complex to get implemented than it needs to be and I have not seen yet a technical argument in favor of the current format. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 06:16:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoZ8-0002ME-6W; Thu, 14 Dec 2006 06:15:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoZ7-0002M3-2o for syslog@ietf.org; Thu, 14 Dec 2006 06:15:53 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuoZ5-0007IR-32 for syslog@ietf.org; Thu, 14 Dec 2006 06:15:52 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBEBFlJW021512 for ; Thu, 14 Dec 2006 20:15:47 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBEBFgsN026022 for ; Thu, 14 Dec 2006 20:15:47 +0900 (JST) Message-ID: <4581325E.9000903@cysols.com> Date: Thu, 14 Dec 2006 20:15:42 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1 References: <0d5401c71989$086d1910$0600a8c0@china.huawei.com> <457A5716.2070005@cysols.com> <457FE7CC.8050000@cysols.com> In-Reply-To: <457FE7CC.8050000@cysols.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The following starts the discussion on the points raised in Dbh re-Review of -mib-11, part 1. There is a basic issue about terminology (points 1.1,1.2,1.3, 1.4) and another 1.9 about the nature and usage of indices on which the WG definitely needs to provide input. Cheers Glenn +---------------------------------------------------+ 1.1 > > 3) the terminology is not consistent with the other WG documents. Not fixed. Still a problem. The WG consensus was to use sender, receiver, relay, and collector. Other document were required to change to match this terminology. The MIB document uses entity, which is a term not found in the protocol draft. I find this change in terminology makes it difficult to interpret some objects in the mib module. Response: We have a single MIB module for all the roles of a syslog "entity" - sender, receiver, relay and collector. I do not see any problem with this generic nature of the MIB, as yet. Let me know about the specific objects that are difficult to interpret. We may try the following: Use the generic "syslog entity" when the discussion applies to all the roles Use the role(s) explicitly "syslog sender", "syslog receiver", etc. when the discussion does not apply to all the roles. Add a statement to that effect in the early part of the text. Any other suggestions? 1.2 > > 4) "roles a syslog entity maybe in" would be better as "roles of a > > syslog entity" (although then entity should be changed according to > > #3. See #3. Response: See #1. 1.3 > > 5) I concur with Bert that the citations in section 2 seem > > inappropriate. I suggest rewriting the introduction to use the same terminology as the protocol draft. See #3. Response: See #1. 1.4 > > 6) I find the references to SA-Li, RA-Rj confusing since these are not > > used in the diagram. Fixed, but replaced by "entity" which is a problem. See #3. Response: See #1. 1.5 > > 7) "The MIB comprises of four groups" would be better as > > "The MIB > > contains four groups" Fixed. However, "group" is a reserved keyword in SMIv2 referring to compliance, so it should be replaced by "subtree" where that is its meaning. Response. Done. 1.6 > > 11) in SyslogSeverity, I recommend removing the second sentnece > > in the > > description "The syslog protocol uses the values 0 (emergency) > > to 7 (debug)." since this is already spelled out in the SYNTAX > > clause,andshows that 99 (other) is also used. Why do we > > need 99? Are other > > values valid? Partially fixed. When is "other" used? Response. "other" will be used to count messages that do not have severity in the range 0-7. The syslog protocol specs (-19.txt) does not disallow such messages. 1.7 > > 12) SyslogService - can we make this just a service name. The > > port semantics are really ambiguous. How do distinguish a UDP > >port# from a TCP port#? Not fixed. Response. The syslogEntityControlTransportDomain specifies the transport e.g. transportDomainUdpIpv4. 1.8 > > 14) transportAddressType is designed to be used with specific > > types of > > transportAddress. The syslogDefaultTransport object should > > probably be > > syslogDefaultTransportType. A transportAddressType > > seems inappropriate > > for use with syslogDefaultService, which does not necessarily > > resolve > > to one of the enumerated options. We should have a > > syslogDefaultTransport that is a transport address. If we want a > > Default service, that should probably be a separate object. Partially fixed. How will the syslog/TLS transport address be specified in this object? Response. A syslog TLS transport domain will be defined. E.g. something like SyslogTLSTransportDomain. We will specify that as the syslogEntityControlTransportDomain. Thus, we will have something like: syslogEntityControlTransportDomain : SyslogTLSTransportDomain syslogEntityControlService: SyslogTLSPort 1.9 > > 20) In the SNMPv2 effort, we found that using integer indices > > made using the tabels more difficut for human readers. It would > > be much easier for a human to interpret the statistics here is > > it is easy to tell what the systlog entity is. So I recommend > > using an SnmpAdminString as the index. For systems that cannot, > > for whatever reason, determine a human-readable identifier for > > the index, theSnmpAdminString can always be "1", "2", etc. Not fixed. Response. The human readable identifier/description is there in syslogEntityControlDescr. I think that any NMS can easily handle this and make the table nicely "readable" to the user. I accept that the primitive snmpget/snmpwalk type applications which show OIDs will be difficult to "read". I will not recommend mixing indices and descriptions - that may lead to constraints on or, inappropriate usage of both indices and descriptions. If the working group wants descriptive indices, that is not a big deal. 1.10> > 21) what is the persistence of the index? If syslog entities > > happen to > > start in a different order, will the index# refer to the same > > entity > > after a reboot? If the MIB says they must be persistent across > > reboots, how difficult will that be for the OS that starts the > > applications? What value will the system keep to match up to the > > integer indicies to make sure they remain the same? Partially fixed. Is it important for interoperability to be able to correlate messages from before a system reboot and after a system reboot? If so, what object can be used to do this correlation since integer index can change across reboots? I suspect the ControlDescr object might be able to be used, but the description for ControlDescr does not specify the persistence of that object. All objects in the syslogEntityControlTable should probably persist across reboots if you want the syslog entity to be configured the same way across reboots. You have a problem, however. You are using an integer index that does not persist across reboots. How does the SNMP agent correlate the persistent configuration parameters with the appropriate application index after a reboot? How does a remote manager read this table and understand which row of configuration and monitoring info (like statistics) refers to which application? Response. The syslogEntityControlDescr will be used by the application/NMS to correlate the index and the target syslog application. It is the user/admin responsibility to use appropriate syslogEntityControlDescr. 1.11> > 23) syslEntOpsMsgsIgnored - where are the "allowed > > specifications" > > defined? We don't want a value that can be interpreted > > differently by > > different entities, because then the values canot be compared > > across > > systems, or have consistent baselines for comparison across > > products, > > etc. Objects shoud be defined to be interoperable and > > unambiguous. Partially fixed. This is still ambiguous, and could be interpreted in different ways by different implemnenters resulting in non-interoperability. This needs to be unambiguous as to what gets counted. This object counts things outside the "allowed specifications" - again I ask where are the allowed specfications defined so an implementer knows what they are? Response. The allowed specifications are in the protocol document. There are several MUST clauses. Some clauses explicitly mention that if the MUST condition is not met the message MAY be discarded, some don't. E.g. Sec. 6.1 Message length, Sec. 6.2 HEADER. 1.12> > 25) syslEntOpsLastError talks about "this process". Is this the > > syslog > > entity? This needs to be clear and unambiguous, and consistent > > with > > the terminology in the other WG documents. I'm confused. Is an entity an application, such as login, or is the entity the thing that sends syslog messages, such as a syslog daemon, that sends messages for multiple applications? Does the last error refer to the last error seen by the login process, or by the syslog sender process (e.g. daemon)? Since entity refers to all the different roles - senders, receivers, relays, and collectors, does that mean we are keeping "last error" info at the receiver as well as at the sender, and at the relays as well? Response. Let me try it this way. The MIB is about syslog entities- syslog senders, syslog receivers, syslog relays etc. We do not need to care whether the Sender is a syslog daemon or a mail application as long as it is sending and/or receiving syslog messages. Having said that, I agree that the description of the lastError is difficult to interpret. Will the following help? "A description of the last error related to sending, receiving or processing a syslog message that was encountered by this syslog entity. " 1.13> > 26) syslEntOpsLastError talks about the last error this process > > "encountered". The definition of encountered needs to be made > > unclear > > and unambiguous. Not fixed. What does "encountered" mean? Sent/received/relayed/collected? While we're at it, what exactly does error mean? How do I know when I am encountering an error? Can I encounter other things, like warnings? I see that Error is a type of severity. Is that what we ar ecounting? Do we also want to count criticals, and alerts, and emergencies, etc. Or is that not what you mean by "encounter an error". Response. see #12 above. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 09:26:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurX6-0007he-5Z; Thu, 14 Dec 2006 09:26:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurX4-0007hZ-4Q for syslog@ietf.org; Thu, 14 Dec 2006 09:25:58 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GurX1-0001AR-RI for syslog@ietf.org; Thu, 14 Dec 2006 09:25:58 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 8BB4327C013; Thu, 14 Dec 2006 15:28:48 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08658-10; Thu, 14 Dec 2006 15:28:48 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 4A26C27C012; Thu, 14 Dec 2006 15:28:48 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 15:25:48 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Dec 2006 15:25:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F88D6@grfint2.intern.adiscon.com> In-Reply-To: <4581325E.9000903@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Dbh re-Review of -mib-11, part 1 Thread-Index: AccfcWf9nAvIvZ6XSNi+z/M5y7A5JgAGedOw From: "Rainer Gerhards" To: "Glenn M. Keeni" , X-OriginalArrivalTime: 14 Dec 2006 14:25:48.0600 (UTC) FILETIME=[C007CB80:01C71F8B] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org So far, just one comment... > 1.6 > > 11) in SyslogSeverity, I recommend removing the=20 > second sentnece > > > in the > > > description "The syslog protocol uses the values 0=20 > (emergency) > > > to 7 (debug)." since this is already spelled out in=20 > the SYNTAX > > > clause,andshows that 99 (other) is also used. Why do we > > > need 99? Are other > > > values valid? > Partially fixed. When is "other" used? >=20 > Response. > "other" will be used to count messages that do not have=20 > severity in > the range 0-7. The syslog protocol specs (-19.txt) does=20 > not disallow > such messages. Actually, -syslog-protocol disallows this by the way the PRI value is specified (this was different in previous versions of the I-D). In short: PRI MOD 8 is severity. So if a severity greater than 7 would be given, it would actually modify the facility. See 6.2.1: -- The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. -- Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 09:52:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gurwc-0002vz-S0; Thu, 14 Dec 2006 09:52:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gurwb-0002vZ-7P for syslog@ietf.org; Thu, 14 Dec 2006 09:52:21 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GurwY-0003hF-OC for syslog@ietf.org; Thu, 14 Dec 2006 09:52:21 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3C24E27C013; Thu, 14 Dec 2006 15:55:17 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09837-09; Thu, 14 Dec 2006 15:55:17 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id E3F3E27C012; Thu, 14 Dec 2006 15:55:16 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 15:52:18 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Syslog-mib-11 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Dec 2006 15:52:23 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F88DA@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <124601c71e2d$2e77c030$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-mib-11 Thread-Index: AcceLKmfNw1SmUTjRsuOkJ+iGwewdgBYf8QA From: "Rainer Gerhards" To: "David Harrington" X-OriginalArrivalTime: 14 Dec 2006 14:52:18.0511 (UTC) FILETIME=[73B0F5F0:01C71F8F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David, Sorry for the late reply. In my experience: it depends... Under Linux/Unix, it is most common to have a single instance of the syslog process running. All other processes communicate with that process via local IPC, but the ultimate sender is the single instance of syslogd running. I have seen some deployments where multiple syslogd's run on a single machine. This is rare and, if so, almost always because of different security domains (e.g. have a different process listen to locally generated messages vs. Network received messages). >From a design perspective, it might be a choice to have multiple processes make up for the syslog subsystem. A real-world example is SDSC syslogd, which runs different stacks in different processes. Rsyslog also has the RFC 3195 receiver separated. AFAIK these processes do not share internal information. It is questionable if such can always be assumed. Under Windows, it is common to have different syslog sender processes, but typically only one receiver is running. This stems back to the fact that there is no syslog subsystem is available on Windows so every vendor brings in its own. The key difference to *nix is that here each program is itself a syslog sender, while under *nix each program formats the MSG part of the message, passes that to an API and the syslogd picks and sends it from there (effectively relaying the message). I hope this information is useful. Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Tuesday, December 12, 2006 9:36 PM > To: syslog@ietf.org > Subject: [Syslog] Syslog-mib-11 >=20 > Hi, >=20 > In my latest review of syslog-mib-11, I have started to believe that > Tom was right when he questioned the MIB module design, which models > multiple syslog entities in a table, so one SNMP engine deals with > multiple syslog senders, relays, and/or recievers on the same host.=20 >=20 > This adds complexity in the MIB design that I am not convinced is > necessary. As the terminology in the MIB document has gotten closer to > other WG documents, this has become somewhat clearer to me. >=20 > Tom recommended that the MIB module only model a single syslog entity. > Different instantations of the MIB module can be represented as > existing in different contexts (e.g. in different communities), so one > SNMP engine can still deal with multiple syslog senders, relays, > and/or receivers on the same host, but the MIB module itself becomes > simpler.=20 >=20 > We should be sure the MIB module reflects real world requirements. I > do not have much operational experience, so I need your input. >=20 > In real deployments, is it **typical** to have multiple syslog stacks > running on the same host, each with a different bind address and port > number and config file? or is it more common for most applications to > share one syslog process (e.g., daemon) that operates via one > address/port? >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 10:28:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GusUQ-0000Un-Tl; Thu, 14 Dec 2006 10:27:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GusUO-0000Uh-WC for syslog@ietf.org; Thu, 14 Dec 2006 10:27:17 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GusUN-00072B-Mo for syslog@ietf.org; Thu, 14 Dec 2006 10:27:16 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20061214152714b1300q91jse>; Thu, 14 Dec 2006 15:27:14 +0000 From: "David Harrington" To: Date: Thu, 14 Dec 2006 10:24:02 -0500 Message-ID: <146a01c71f93$e565b510$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccfcWf9nAvIvZ6XSNi+z/M5y7A5JgAGedOwAAGIl/A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F88D6@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [Syslog] severity X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I don't think -protocol- spelled out the restriction clearly that severity could only be 0-7. The document states that the 0-7 severities listed were not normative. Now that Rainer pointed this out, I do realize that an implementer of the PRI calculation code might recognize that the PRI calculation implies such a restriction. But syslog is often implemented as a system of independently-implemented pieces (daemon vs application, for example), and not all of them will need to implement the PRI calculation code, so it may not be obvious (just as it was not obvious to Gleen who has been working with this WG for a long time). Before we publish the spec as an RFC, is the WG satisfied with this restriction of severity to 0-7, and is the WG satisfied that this is clear and unambiguous in our spec? If the WG believes the 0-7 restriction is unacceotable, we will need to pull the draft back from the IESG and make changes to PRI. If the WG accepts the 0-7, but thinks the draft is not clear and unambiguous, then we could provide clarifying text as part of WGLC without pulling the draft back from the IESG. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Thursday, December 14, 2006 9:26 AM > To: Glenn M. Keeni; syslog@ietf.org > Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 1 > > So far, just one comment... > > > 1.6 > > 11) in SyslogSeverity, I recommend removing the > > second sentnece > > > > in the > > > > description "The syslog protocol uses the values 0 > > (emergency) > > > > to 7 (debug)." since this is already spelled out in > > the SYNTAX > > > > clause,andshows that 99 (other) is also used. Why do we > > > > need 99? Are other > > > > values valid? > > Partially fixed. When is "other" used? > > > > Response. > > "other" will be used to count messages that do not have > > severity in > > the range 0-7. The syslog protocol specs (-19.txt) does > > not disallow > > such messages. > > Actually, -syslog-protocol disallows this by the way the PRI value is > specified (this was different in previous versions of the I-D). In > short: PRI MOD 8 is severity. So if a severity greater than 7 would be > given, it would actually modify the facility. See 6.2.1: > > -- > The Priority value is calculated by first multiplying the Facility > number by 8 and then adding the numerical value of the Severity. > -- > > Rainer > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 10:31:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GusYc-0003RK-K2; Thu, 14 Dec 2006 10:31:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GusYb-0003QB-O9 for syslog@ietf.org; Thu, 14 Dec 2006 10:31:37 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GusYZ-0007UT-8b for syslog@ietf.org; Thu, 14 Dec 2006 10:31:37 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3EA8627C013; Thu, 14 Dec 2006 16:34:33 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10899-10; Thu, 14 Dec 2006 16:34:33 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id DD61A27C012; Thu, 14 Dec 2006 16:34:32 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 16:31:35 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] severity MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Dec 2006 16:31:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F88DB@grfint2.intern.adiscon.com> In-Reply-To: <146a01c71f93$e565b510$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] severity Thread-Index: AccfcWf9nAvIvZ6XSNi+z/M5y7A5JgAGedOwAAGIl/AAAMhrkA== From: "Rainer Gerhards" To: "David Harrington" , X-OriginalArrivalTime: 14 Dec 2006 15:31:35.0937 (UTC) FILETIME=[F0D39F10:01C71F94] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, December 14, 2006 4:24 PM > To: syslog@ietf.org > Subject: [Syslog] severity >=20 > Hi, >=20 > I don't think -protocol- spelled out the restriction clearly that > severity could only be 0-7. The document states that the 0-7 > severities listed were not normative.=20 >=20 > Now that Rainer pointed this out, I do realize that an implementer of > the PRI calculation code might recognize that the PRI calculation > implies such a restriction. But syslog is often implemented as a > system of independently-implemented pieces (daemon vs application, for > example), and not all of them will need to implement the PRI > calculation code, so it may not be obvious (just as it was not obvious > to Gleen who has been working with this WG for a long time). >=20 > Before we publish the spec as an RFC, is the WG satisfied with this > restriction of severity to 0-7, and is the WG satisfied that this is > clear and unambiguous in our spec? >=20 > If the WG believes the 0-7 restriction is unacceotable, we will need > to pull the draft back from the IESG and make changes to PRI. The last time a version was submitted (roughly a year ago), it was pulled back *because* PRI calculation was different from legacy syslog. This was the whole point in that discussion. And, yes, then there wasn't this restriction. IMHO we can not change that without going into a "deep-inconsistency-loop" of WG decisions. >=20 > If the WG accepts the 0-7, but thinks the draft is not clear and > unambiguous, then we could provide clarifying text as part of WGLC > without pulling the draft back from the IESG. This is what I'd recommend. A simple sentence like "severities MUST be in the range of 0 to 7" should do the job. Rainer >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > Sent: Thursday, December 14, 2006 9:26 AM > > To: Glenn M. Keeni; syslog@ietf.org > > Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 1 > >=20 > > So far, just one comment... > >=20 > > > 1.6 > > 11) in SyslogSeverity, I recommend removing the=20 > > > second sentnece > > > > > in the > > > > > description "The syslog protocol uses the values 0=20 > > > (emergency) > > > > > to 7 (debug)." since this is already spelled out in=20 > > > the SYNTAX > > > > > clause,andshows that 99 (other) is also used. Why do we > > > > > need 99? Are other > > > > > values valid? > > > Partially fixed. When is "other" used? > > >=20 > > > Response. > > > "other" will be used to count messages that do not have=20 > > > severity in > > > the range 0-7. The syslog protocol specs (-19.txt) does=20 > > > not disallow > > > such messages. > >=20 > > Actually, -syslog-protocol disallows this by the way the PRI value > is > > specified (this was different in previous versions of the I-D). In > > short: PRI MOD 8 is severity. So if a severity greater than 7 would > be > > given, it would actually modify the facility. See 6.2.1: > >=20 > > -- > > The Priority value is calculated by first multiplying the Facility > > number by 8 and then adding the numerical value of the Severity. > > -- > >=20 > > Rainer > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 12:22:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuuGp-0000o6-Ay; Thu, 14 Dec 2006 12:21:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuuGn-0000o1-TE for syslog@ietf.org; Thu, 14 Dec 2006 12:21:21 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuuGm-0003hn-Ga for syslog@ietf.org; Thu, 14 Dec 2006 12:21:21 -0500 Received: from pc6 (1Cust89.tnt109.lnd4.gbr.da.uu.net [62.188.172.89]) by astro.systems.pipex.net (Postfix) with SMTP id 9F5DFE000134; Thu, 14 Dec 2006 17:21:14 +0000 (GMT) Message-ID: <07f101c71f9b$d9ded5c0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <124601c71e2d$2e77c030$0600a8c0@china.huawei.com> Subject: Re: [Syslog] Syslog-mib-11 Date: Thu, 14 Dec 2006 17:19:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "David Harrington" To: Sent: Tuesday, December 12, 2006 9:36 PM Subject: [Syslog] Syslog-mib-11 > > In my latest review of syslog-mib-11, I have started to believe that > Tom was right when he questioned the MIB module design, which models > multiple syslog entities in a table, so one SNMP engine deals with > multiple syslog senders, relays, and/or recievers on the same host. > > This adds complexity in the MIB design that I am not convinced is > necessary. As the terminology in the MIB document has gotten closer to > other WG documents, this has become somewhat clearer to me. > > Tom recommended that the MIB module only model a single syslog entity. > Different instantations of the MIB module can be represented as > existing in different contexts (e.g. in different communities), so one > SNMP engine can still deal with multiple syslog senders, relays, > and/or receivers on the same host, but the MIB module itself becomes > simpler. > > We should be sure the MIB module reflects real world requirements. I > do not have much operational experience, so I need your input. > > In real deployments, is it **typical** to have multiple syslog stacks > running on the same host, each with a different bind address and port > number and config file? or is it more common for most applications to > share one syslog process (e.g., daemon) that operates via one > address/port? > My experience of syslog is on network devices - switch, router, firewall - and there I only see the single syslog stack; I would be surprised to see more. To quote from the manual of a large enterprise server, 'previous versions of the software allowed you to start two copies of syslogd with unpredictable results; there is now a check to prevent this' so even there, I only see scope for one syslogd. Must be an ....x thing. Tom Petch > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 16:38:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuyGx-0001D7-So; Thu, 14 Dec 2006 16:37:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuyGx-0001Cx-DX for syslog@ietf.org; Thu, 14 Dec 2006 16:37:47 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuyGw-0005UV-0d for syslog@ietf.org; Thu, 14 Dec 2006 16:37:47 -0500 Received: from pc6 (1Cust59.tnt24.lnd4.gbr.da.uu.net [62.188.151.59]) by astro.systems.pipex.net (Postfix) with SMTP id BD5CFE00027C; Thu, 14 Dec 2006 21:37:41 +0000 (GMT) Message-ID: <0a6d01c71fbf$ac489140$0601a8c0@pc6> From: "tom.petch" To: "Rainer Gerhards" , "David Harrington" , References: <577465F99B41C842AAFBE9ED71E70ABA1F88DB@grfint2.intern.adiscon.com> Subject: Re: [Syslog] severity Date: Thu, 14 Dec 2006 17:35:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Rainer Gerhards" To: "David Harrington" ; Sent: Thursday, December 14, 2006 4:31 PM Subject: RE: [Syslog] severity > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, December 14, 2006 4:24 PM > To: syslog@ietf.org > Subject: [Syslog] severity > > Hi, > > I don't think -protocol- spelled out the restriction clearly that > severity could only be 0-7. The document states that the 0-7 > severities listed were not normative. > > Now that Rainer pointed this out, I do realize that an implementer of > the PRI calculation code might recognize that the PRI calculation > implies such a restriction. But syslog is often implemented as a > system of independently-implemented pieces (daemon vs application, for > example), and not all of them will need to implement the PRI > calculation code, so it may not be obvious (just as it was not obvious > to Gleen who has been working with this WG for a long time). > > Before we publish the spec as an RFC, is the WG satisfied with this > restriction of severity to 0-7, and is the WG satisfied that this is > clear and unambiguous in our spec? > > If the WG believes the 0-7 restriction is unacceotable, we will need > to pull the draft back from the IESG and make changes to PRI. The last time a version was submitted (roughly a year ago), it was pulled back *because* PRI calculation was different from legacy syslog. This was the whole point in that discussion. And, yes, then there wasn't this restriction. IMHO we can not change that without going into a "deep-inconsistency-loop" of WG decisions. > > If the WG accepts the 0-7, but thinks the draft is not clear and > unambiguous, then we could provide clarifying text as part of WGLC > without pulling the draft back from the IESG. This is what I'd recommend. A simple sentence like "severities MUST be in the range of 0 to 7" should do the job. Rainer I agree with Rainer Tom Petch > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Thursday, December 14, 2006 9:26 AM > > To: Glenn M. Keeni; syslog@ietf.org > > Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 1 > > > > So far, just one comment... > > > > > 1.6 > > 11) in SyslogSeverity, I recommend removing the > > > second sentnece > > > > > in the > > > > > description "The syslog protocol uses the values 0 > > > (emergency) > > > > > to 7 (debug)." since this is already spelled out in > > > the SYNTAX > > > > > clause,andshows that 99 (other) is also used. Why do we > > > > > need 99? Are other > > > > > values valid? > > > Partially fixed. When is "other" used? > > > > > > Response. > > > "other" will be used to count messages that do not have > > > severity in > > > the range 0-7. The syslog protocol specs (-19.txt) does > > > not disallow > > > such messages. > > > > Actually, -syslog-protocol disallows this by the way the PRI value > is > > specified (this was different in previous versions of the I-D). In > > short: PRI MOD 8 is severity. So if a severity greater than 7 would > be > > given, it would actually modify the facility. See 6.2.1: > > > > -- > > The Priority value is calculated by first multiplying the Facility > > number by 8 and then adding the numerical value of the Severity. > > -- > > > > Rainer > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 16:45:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuyOQ-0005VO-0K; Thu, 14 Dec 2006 16:45:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuyOO-0005Uv-75 for syslog@ietf.org; Thu, 14 Dec 2006 16:45:28 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuyOL-0006Eh-TW for syslog@ietf.org; Thu, 14 Dec 2006 16:45:28 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061214214525b1100k6s9qe>; Thu, 14 Dec 2006 21:45:25 +0000 From: "David Harrington" To: "'Glenn M. Keeni'" , Date: Thu, 14 Dec 2006 16:41:56 -0500 Message-ID: <150401c71fc8$b9d4cdc0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccfcUyVjvq6AjM1Q9C3JlP0UvQN1gAHvwkg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <4581325E.9000903@cysols.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Subject: [Syslog] Mib terminology and MIB design X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [speaking as coc-ahir] We need WG input on this. Please look at mib-11 and decide whether "entity" is appropriate. Glenn has changed the terminology in many places to be more consistent than previous revisions. In the TLS document, Miao and Yuzhi tried to use a generic term for any role and WG consensus was to change the document to use the sender/receiever/relay/collector terminology. Does the same thing need to be done here? [co-chair end] [speaking as contributor (and MIB Doctor)] I have mixed feelings on this issue. I personally think not having a generic term makes it harder to write documents and design mib modules that can be applied to any of the roles. In SNMPv3, we deliberately moved away from different processing for different roles and toward a common "entity" that could act in different roles. When designing a MIB module to encompass multiple roles as one entity, it is very important to review the design from the perspective of each of the roles. For example, it may make sense to count messagesSent if you are implementing a sender or relay, but not if you are implementing a reciever or collector. It will be a poor MIB module design if it makes a great deal of sense for implementers to only implement some of the objects in a table that is mandatory-to-implement for compliance. Having objects that only make sense for certain roles and not others in one common table will encourage non-compliant implementations. On the other hand, defining the MIB module to contain four tables to model the sender configuration, and the receiver configuration, and the relay configuration, and the collector configuration, even though all four tables would contain identical information is simply ridiculous design. I do not like having one set of terminology in the protocol specifications, and a different set of terminology in the management interface, because it makes it harder for operators to interpret the data in the MIB module. The WG needs to review the MIB module design and determine what makes protocol sense. [contributor end] David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > +---------------------------------------------------+ > 1.1 > > 3) the terminology is not consistent with the > other WG documents. > Not fixed. Still a problem. The WG consensus was > to use sender, > receiver, relay, and collector. Other document were > required to change > to match this terminology. The MIB document uses entity, > which is a term not found in the protocol draft. > > I find this change in terminology makes it difficult > to interpret some objects in the mib module. > > Response: > We have a single MIB module for all the roles of a syslog > "entity" - sender, receiver, relay and collector. > I do not see any problem with this generic nature of the > MIB, as yet. > > Let me know about the specific objects that are difficult > to interpret. We may try the following: > Use the generic "syslog entity" when the discussion > applies to all the roles > Use the role(s) explicitly "syslog sender", "syslog > receiver", etc. when the discussion does not apply to > all the roles. > Add a statement to that effect in the early part of > the text. > > Any other suggestions? > > 1.2 > > 4) "roles a syslog entity maybe in" would be better > as "roles of a > > > syslog entity" (although then entity should be > changed according to > > > #3. > See #3. > Response: > See #1. > 1.3 > > 5) I concur with Bert that the citations in section 2 seem > > > inappropriate. > I suggest rewriting the introduction to use the same > terminology as > the protocol draft. See #3. > Response: > See #1. > > 1.4 > > 6) I find the references to SA-Li, RA-Rj confusing > since these are > not > > > used in the diagram. > Fixed, but replaced by "entity" which is a problem. See #3. > Response: > See #1. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 17:26:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guz1z-0004HM-7z; Thu, 14 Dec 2006 17:26:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guz1y-0004GZ-Fz for syslog@ietf.org; Thu, 14 Dec 2006 17:26:22 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guz1w-0001sT-4b for syslog@ietf.org; Thu, 14 Dec 2006 17:26:22 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061214222619b1100k48ete>; Thu, 14 Dec 2006 22:26:19 +0000 From: "David Harrington" To: "'Rainer Gerhards'" Subject: RE: [Syslog] Syslog-mib-11 Date: Thu, 14 Dec 2006 17:23:07 -0500 Message-ID: <150701c71fce$70a19470$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcceLKmfNw1SmUTjRsuOkJ+iGwewdgBYf8QAAA835ZA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F88DA@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [speaking as a contributor] Thank you Rainer for such a clear response. I recommend that text similar to Rainer's response be included in the DESCRIPTION clause for the syslogEntityControlTable, to explain why multiple syslog entities are modeled in the MIB module. I recommend capturing the discussion within the MIB module definition rather than in the document introductory sections, because MIB modules are often distributed already-extracted from the surrounding document, and NMS help screens are often fashioned from the DESCRIPTION clauses. So putting this info in the table description clause will get the explanation to the users. I would not object to **also** having it discussed in the introductory text sections. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Thursday, December 14, 2006 9:52 AM > To: David Harrington > Cc: syslog@ietf.org > Subject: RE: [Syslog] Syslog-mib-11 > > David, > > Sorry for the late reply. > > In my experience: it depends... > > Under Linux/Unix, it is most common to have a single instance of the > syslog process running. All other processes communicate with that > process via local IPC, but the ultimate sender is the single > instance of > syslogd running. I have seen some deployments where multiple syslogd's > run on a single machine. This is rare and, if so, almost > always because > of different security domains (e.g. have a different process listen to > locally generated messages vs. Network received messages). > > From a design perspective, it might be a choice to have multiple > processes make up for the syslog subsystem. A real-world > example is SDSC > syslogd, which runs different stacks in different processes. Rsyslog > also has the RFC 3195 receiver separated. AFAIK these processes do not > share internal information. It is questionable if such can always be > assumed. > > Under Windows, it is common to have different syslog sender processes, > but typically only one receiver is running. This stems back > to the fact > that there is no syslog subsystem is available on Windows so every > vendor brings in its own. The key difference to *nix is that here each > program is itself a syslog sender, while under *nix each > program formats > the MSG part of the message, passes that to an API and the > syslogd picks > and sends it from there (effectively relaying the message). > > I hope this information is useful. > > Rainer > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Tuesday, December 12, 2006 9:36 PM > > To: syslog@ietf.org > > Subject: [Syslog] Syslog-mib-11 > > > > Hi, > > > > In my latest review of syslog-mib-11, I have started to believe that > > Tom was right when he questioned the MIB module design, which models > > multiple syslog entities in a table, so one SNMP engine deals with > > multiple syslog senders, relays, and/or recievers on the same host. > > > > This adds complexity in the MIB design that I am not convinced is > > necessary. As the terminology in the MIB document has > gotten closer to > > other WG documents, this has become somewhat clearer to me. > > > > Tom recommended that the MIB module only model a single > syslog entity. > > Different instantations of the MIB module can be represented as > > existing in different contexts (e.g. in different > communities), so one > > SNMP engine can still deal with multiple syslog senders, relays, > > and/or receivers on the same host, but the MIB module itself becomes > > simpler. > > > > We should be sure the MIB module reflects real world requirements. I > > do not have much operational experience, so I need your input. > > > > In real deployments, is it **typical** to have multiple > syslog stacks > > running on the same host, each with a different bind > address and port > > number and config file? or is it more common for most > applications to > > share one syslog process (e.g., daemon) that operates via one > > address/port? > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 18:03:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuzbA-0002OE-9c; Thu, 14 Dec 2006 18:02:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guzb9-0002MU-GR for syslog@ietf.org; Thu, 14 Dec 2006 18:02:43 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guzb7-0007ca-8J for syslog@ietf.org; Thu, 14 Dec 2006 18:02:43 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20061214230239b1200bqifde>; Thu, 14 Dec 2006 23:02:39 +0000 From: "David Harrington" To: Date: Thu, 14 Dec 2006 17:59:22 -0500 Message-ID: <150b01c71fd3$84cb8780$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccfcUyVjvq6AjM1Q9C3JlP0UvQN1gAXM1Jg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <4581325E.9000903@cysols.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [Syslog] transportDomain and transportAddress X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Glenn, Maybe I misunderstand how transportDomain and transportAddress are supposed to work. I have consulted one of the authors of RFC3419 to make sure my understanding is correct. As I read RFC3419, it seems to me that transportDomain and transportAddress form a discriminated union; they form a corresponding pair. So your response to my concern did not answer the question. > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > > Response. > The syslogEntityControlTransportDomain specifies the > transport e.g. > transportDomainUdpIpv4. >From RFC3419: transportDomainUdpIpv4 OBJECT-IDENTITY STATUS current DESCRIPTION "The UDP over IPv4 transport domain. The corresponding transport address is of type TransportAddressIPv4 for global IPv4 addresses." ::= { transportDomains 1 } TransportAddressIPv4 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d:2d" STATUS current DESCRIPTION "Represents a transport address consisting of an IPv4 address and a port number (as used for example by UDP, TCP and SCTP): octets contents encoding 1-4 IPv4 address network-byte order 5-6 port number network-byte order This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair." SYNTAX OCTET STRING (SIZE (6)) When syslogEntityControlTransportDomain contains the value transportDomainUdpIpv4, into which object in the syslog mib does one put the corresponding transport address of type TransportAddressIPv4? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 18:35:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv06o-0006lO-Ek; Thu, 14 Dec 2006 18:35:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv06n-0006ko-VH for syslog@ietf.org; Thu, 14 Dec 2006 18:35:25 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guzzb-0002tq-Fz for syslog@ietf.org; Thu, 14 Dec 2006 18:28:00 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061214232758b1100k18h1e>; Thu, 14 Dec 2006 23:27:58 +0000 From: "David Harrington" To: Date: Thu, 14 Dec 2006 18:24:51 -0500 Message-ID: <150c01c71fd7$0e1d7630$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Accf1ulYvgq8cXT4TvOpTyuBgE8kxA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Syslog] TLS TransportDomain X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Glenn, How will the syslog/TLS transport address be specified in this object? Response. A syslog TLS transport domain will be defined. E.g. something like SyslogTLSTransportDomain. We will specify that as the syslogEntityControlTransportDomain. Thus, we will have something like: syslogEntityControlTransportDomain : SyslogTLSTransportDomain syslogEntityControlService: SyslogTLSPort Where and when will SyslogTLSTransportDomain be defined? Would it not make sense to define it in this mib module? I notice that RFC3419 uses the naming convention "transportDomain" So wouldn't it make sense to use transportDomainTLSIPv4? RFC3419 is meant to make transportDomains more generic than RFC3417, which is used to define snmp-specific transportDomains. I don't think we need to design syslog-specific transportDomains, but if so, then the naming convention from RFC3417 is Domain, such as snmpUDPDomain. With our byte-count header for syslog/TLS, a syslogTLSDomain might alert an application that there will be byte-counts in the stream. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 19:10:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv0eA-00044I-IX; Thu, 14 Dec 2006 19:09:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv0e9-00044D-Nt for syslog@ietf.org; Thu, 14 Dec 2006 19:09:53 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv0e8-0002Ol-G6 for syslog@ietf.org; Thu, 14 Dec 2006 19:09:53 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20061215000951b1300q8k7ie>; Fri, 15 Dec 2006 00:09:51 +0000 From: "David Harrington" To: "'Glenn M. Keeni'" , Date: Thu, 14 Dec 2006 19:06:12 -0500 Message-ID: <151801c71fdc$e7ba7050$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccfcUyVjvq6AjM1Q9C3JlP0UvQN1gAZcDPg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <4581325E.9000903@cysols.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Syslog] SyslogService X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Glenn, > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > > 1.7 > > 12) SyslogService - can we make this just a service name. The > > > port semantics are really ambiguous. How do distinguish a UDP > > >port# from a TCP port#? > Not fixed. > > Response. > The syslogEntityControlTransportDomain specifies the > transport e.g. > transportDomainUdpIpv4. > I am looking for an unambiguous format for the value of this field. SyslogService ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The service name or port number that will be used to send and/or receive messages. The service name must resolve to a port number on the local host. " SYNTAX OCTET STRING (SIZE (0..255)) A service name is presumably a string; a port number is a decimal value. When put into this object, MUST the port number be represented as an ASCII string? If so, the description does not say so. If a service name is specified, is this done as an ASCII string or a UTF-8 string? The description doesn't say. If it is not UTF-8, why not? If the service name must resolve to a port number on the local host, how will a remote NMS get that resolution from the local host? Wouldn't it be simpler to put only a port number in the managed object? If you restricted it to a port number, then implementers only need to provide memory for an unsigned32 value (4 octets) rather than 255 octets. dbh _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 19:30:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv0xd-0003Dk-Qe; Thu, 14 Dec 2006 19:30:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv0xc-0003DM-PS for syslog@ietf.org; Thu, 14 Dec 2006 19:30:00 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv0xb-0005WY-1T for syslog@ietf.org; Thu, 14 Dec 2006 19:30:00 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061215002958b1100k0pdbe>; Fri, 15 Dec 2006 00:29:58 +0000 From: "David Harrington" To: Date: Thu, 14 Dec 2006 19:26:51 -0500 Message-ID: <151901c71fdf$b7509c70$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccfcUyVjvq6AjM1Q9C3JlP0UvQN1gAbJfqQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <4581325E.9000903@cysols.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Syslog] allowed X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Glenn, > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > > 1.11> > 23) syslEntOpsMsgsIgnored - where are the "allowed > > > specifications" > > > defined? We don't want a value that can be interpreted > > > differently by > > > different entities, because then the values canot be compared > > > across > > > systems, or have consistent baselines for comparison across > > > products, > > > etc. Objects shoud be defined to be interoperable and > > > unambiguous. > Partially fixed. This is still ambiguous, and could be > interpreted > in different ways by different implemnenters resulting in > non-interoperability. This needs to be unambiguous as to > what gets > counted. > This object counts things outside the "allowed specifications" - > again > I ask where are the allowed specfications defined so an > implementer > knows what they are? > > Response. > The allowed specifications are in the protocol document. > There are > several MUST clauses. Some clauses explicitly mention that if the > MUST condition is not met the message MAY be discarded, > some don't. > E.g. Sec. 6.1 Message length, Sec. 6.2 HEADER. > We want to ensure consistency in what is counted; Will you please enumerate which conditions should be counted in this object. List which MUST clauses are relevant to this object, and which are not, and make it clear that ONLY these conditions should be counted. We should consider counting these conditions separately rather than counting them in an aggregated count. That way, a remote system could tell what the problem is, whereas "outside the allowed specifications" only says "there are one or more problems being encountered; we'll tell you how many problems have been encountered, but not which problems have been encountered." David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 19:41:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv17q-0007Xj-5n; Thu, 14 Dec 2006 19:40:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv17p-0007Xe-Kv for syslog@ietf.org; Thu, 14 Dec 2006 19:40:33 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv17o-0006gt-E4 for syslog@ietf.org; Thu, 14 Dec 2006 19:40:33 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061215004031b1100k2eose>; Fri, 15 Dec 2006 00:40:32 +0000 From: "David Harrington" To: Date: Thu, 14 Dec 2006 19:37:24 -0500 Message-ID: <151a01c71fe1$30c07390$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccerGDD86Vp0ZFCSnO7HtXFHmsUfQBM+ZgA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <457FE7CC.8050000@cysols.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Syslog] syslEntCtlConfFileName X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Wednesday, December 13, 2006 6:45 AM > To: syslog@ietf.org > Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 > > > 2.2 > > 6) syslEntCtlConfFileName - using lots of abbreviations in > > > the name > > > makes it hard for people to remember how the words were > > > abbreviated. > > > It would be better to use something like > syslogEntCtlFilename. > > > Why do > > > we need Ent in the name? we never deal with anything > other than > > > entities, do we? syslogControlFile would be much easier to > > > remember > > > than syslEntCtlConfFileName. > Fixed (mostly). > > Response: > What is the remaining problem? syslogEntityControlConfFileName uses an abbreviation for Configuration. The abbreviation could have been Conf or Config or Cfg. This makes it harder to remember. I can live with this. You can mark it as fixed. dbh _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 14 20:28:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv1rT-0000Zx-EU; Thu, 14 Dec 2006 20:27:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv1rS-0000Zb-Ej for syslog@ietf.org; Thu, 14 Dec 2006 20:27:42 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv1rQ-0005df-Vw for syslog@ietf.org; Thu, 14 Dec 2006 20:27:42 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20061215012739b1200bnqnfe>; Fri, 15 Dec 2006 01:27:40 +0000 From: "David Harrington" To: Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 Date: Thu, 14 Dec 2006 20:24:19 -0500 Message-ID: <152301c71fe7$c6910e10$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccerGDD86Vp0ZFCSnO7HtXFHmsUfQBNIfIw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <457FE7CC.8050000@cysols.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Wednesday, December 13, 2006 6:45 AM > To: syslog@ietf.org > Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3 > > Hi, > I have pruned the list of comments and renumbered them. > The following starts the discussion on the points raised > in Dbh re-Review of -mib-11, part 2. > > Cheers > > Glenn > > > 2.3 > > 9) syslEntCtlStorageType - is this definition exactly the > > > same as the > > > StorageType T-C? > I am not sure this is the same semantics as StorageType T-C. > Your text is somewhat unclear when it says "backed up by > non-volatile (permanent)" > > Response: > Will the following help: > syslogEntityControlStorageType OBJECT-TYPE > SYNTAX StorageType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object defines whether the parameters defined in > this row are kept in volatile storage and lost upon > reboot or are backed up by non-volatile or permanent > storage. > Conceptual rows having the value 'permanent' need not > allow write-access to any columnar objects in the row. > " > > That mimics the DESCRIPTION used in DISMAN-MIB e.g. > smLaunchStorageType > That will do, yes. > > 2.4 > > 11) syslEntStarted and syslEntStopped - spell out MO. I don't > > > understand the second sentence; how does the manager > know what > > > syslEntOpsIndex is used? > Partially fixed. I still do not understand the second > sentence. Can > you reword this sentence? > > Response: > When a trap is received, the NMS/Operator needs to > figure out which > syslog "entity" the trap is about. This is done by using the > syslogEntityOperationsIndex instance identifier of the objects in > the notification. > > Will the following help? > > "The syslog entity corresponding to the notification will be > identified by the syslogEntityOperationsIndex > instance identifier > of the objects in the notification." Yes. Thanks. > 2.6 > > 14) The MIB module exposes some info from syslog, such as > > > last error. > > > The security considerations talk about securing snmp, but > > > that does > > > not make sense if you do not also secure the syslog > transport. > > > The > > > security considerations should recommend securing syslog to > > > match the > > > snmp security. > Not fixed. > > Response: > To me that appeared to be out of scope. That seems to be a matter > for the "security considerations" for syslog transport. No? > > Will something like the following suffice: > > "Under some circumstances securing SNMP will not make sense if > the syslog transport is not secured. It is > recommended that the > syslog transport be secured to match the security > level of SNMP." Let me just withdraw my comment. If the IESG wants something here, they can request it. > > 2.7 > > 17) I suspect you are not usinng xml2rfc. If not, you need to > > > make > > > sure all the boilerplates are up-to-date. Please check the > > > funding > > > statement and the intellectual property clauses. > Partially fixed. Needs updated boilerplates. > > Response: > Updated the boilerplate for the Copyright notice. > http://tools.ietf.org/tools/idnits/ > shows zero errors now. > Good. > > > > > Glenn M. Keeni wrote: > > Dave, > > Thanks for the detailed review. I count a total of > > 13 + 7 + 4 = 24 issues raised in the three mails. Let > > me go through these and try to figure out how to address > > the issues, hopefully by 18/12/2006. > > > > Cheers > > > > Glenn > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 15 02:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv7M3-00009G-G0; Fri, 15 Dec 2006 02:19:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv7M1-000091-LI for syslog@ietf.org; Fri, 15 Dec 2006 02:19:37 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv7Lz-00020Q-5L for syslog@ietf.org; Fri, 15 Dec 2006 02:19:37 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id E062C27C013; Fri, 15 Dec 2006 08:22:30 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08845-03; Fri, 15 Dec 2006 08:22:30 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 9260F27C012; Fri, 15 Dec 2006 08:22:30 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 08:19:33 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] severity MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Dec 2006 08:19:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F88E0@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F88DB@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] severity Thread-Index: AccfcWf9nAvIvZ6XSNi+z/M5y7A5JgAGedOwAAGIl/AAAMhrkAAhHgBg From: "Rainer Gerhards" To: "David Harrington" , X-OriginalArrivalTime: 15 Dec 2006 07:19:33.0312 (UTC) FILETIME=[5E624C00:01C72019] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David, I went through my notes. Retaining PRI as is is actually a charter item: --- Reviews have shown that there are very few similarities between the message formats generated by heterogeneous systems. In fact, the only consistent commonality between messages is that all of them contain the at the start. Additional testing has shown that as long as the is present in a syslog message, all tested receivers will accept any generated message as a valid syslog message. In designing a standard syslog message format, this Working Group will retain the at the start of the message and will introduce protocol versioning.=20 --- So we can not change the PRI representation (and thus the representation of severity). >From what I see in my notes, we simply copied over the 3164 text on PRI without any further thinking after we had set on this charter. I think this is the primary reason that it was not better spelled out and be undetected until now. Rainer > > Before we publish the spec as an RFC, is the WG satisfied with this > > restriction of severity to 0-7, and is the WG satisfied that this is > > clear and unambiguous in our spec? > >=20 > > If the WG believes the 0-7 restriction is unacceotable, we will need > > to pull the draft back from the IESG and make changes to PRI. >=20 > The last time a version was submitted (roughly a year ago), it was > pulled back *because* PRI calculation was different from=20 > legacy syslog. > This was the whole point in that discussion. And, yes, then=20 > there wasn't > this restriction. IMHO we can not change that without going into a > "deep-inconsistency-loop" of WG decisions. > >=20 > > If the WG accepts the 0-7, but thinks the draft is not clear and > > unambiguous, then we could provide clarifying text as part of WGLC > > without pulling the draft back from the IESG. >=20 > This is what I'd recommend. A simple sentence like "severities MUST be > in the range of 0 to 7" should do the job. >=20 > Rainer > >=20 > > David Harrington > > dharrington@huawei.com=20 > > dbharrington@comcast.net > > ietfdbh@comcast.net > >=20 > >=20 > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > > > Sent: Thursday, December 14, 2006 9:26 AM > > > To: Glenn M. Keeni; syslog@ietf.org > > > Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 1 > > >=20 > > > So far, just one comment... > > >=20 > > > > 1.6 > > 11) in SyslogSeverity, I recommend removing the=20 > > > > second sentnece > > > > > > in the > > > > > > description "The syslog protocol uses the values 0=20 > > > > (emergency) > > > > > > to 7 (debug)." since this is already spelled out in=20 > > > > the SYNTAX > > > > > > clause,andshows that 99 (other) is also used. Why do we > > > > > > need 99? Are other > > > > > > values valid? > > > > Partially fixed. When is "other" used? > > > >=20 > > > > Response. > > > > "other" will be used to count messages that do not have=20 > > > > severity in > > > > the range 0-7. The syslog protocol specs (-19.txt) does=20 > > > > not disallow > > > > such messages. > > >=20 > > > Actually, -syslog-protocol disallows this by the way the PRI value > > is > > > specified (this was different in previous versions of the I-D). In > > > short: PRI MOD 8 is severity. So if a severity greater=20 > than 7 would > > be > > > given, it would actually modify the facility. See 6.2.1: > > >=20 > > > -- > > > The Priority value is calculated by first multiplying=20 > the Facility > > > number by 8 and then adding the numerical value of the Severity. > > > -- > > >=20 > > > Rainer > > >=20 > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 15 02:44:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv7kQ-0001T5-9o; Fri, 15 Dec 2006 02:44:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv7kP-0001RE-2l for syslog@ietf.org; Fri, 15 Dec 2006 02:44:49 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv7kN-0006Au-KT for syslog@ietf.org; Fri, 15 Dec 2006 02:44:49 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 390C7562C9; Fri, 15 Dec 2006 08:44:47 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20437-06; Fri, 15 Dec 2006 08:44:44 +0100 (CET) Received: from boskop.local (unknown [10.222.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E899F56095; Fri, 15 Dec 2006 08:44:43 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 8DDAE8FB97B; Fri, 15 Dec 2006 08:44:43 +0100 (CET) Date: Fri, 15 Dec 2006 08:44:43 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Syslog] TLS TransportDomain Message-ID: <20061215074443.GD7487@boskop.local> Mail-Followup-To: David Harrington , syslog@ietf.org References: <150c01c71fd7$0e1d7630$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150c01c71fd7$0e1d7630$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Thu, Dec 14, 2006 at 06:24:51PM -0500, David Harrington wrote: > Hi Glenn, > > How will the syslog/TLS transport address be specified in this > object? > > Response. > A syslog TLS transport domain will be defined. E.g. something > like > SyslogTLSTransportDomain. We will specify that as the > syslogEntityControlTransportDomain. > Thus, we will have something like: > syslogEntityControlTransportDomain : > SyslogTLSTransportDomain > syslogEntityControlService: SyslogTLSPort > > Where and when will SyslogTLSTransportDomain be defined? > Would it not make sense to define it in this mib module? > > I notice that RFC3419 uses the naming convention > "transportDomain" > So wouldn't it make sense to use transportDomainTLSIPv4? > > RFC3419 is meant to make transportDomains more generic than RFC3417, > which is used to define snmp-specific transportDomains. I don't think > we need to design syslog-specific transportDomains, but if so, then > the naming convention from RFC3417 is protocol>Domain, such as snmpUDPDomain. With our byte-count header for > syslog/TLS, a syslogTLSDomain might alert an application that there > will be byte-counts in the stream. There are two things here that should not be mixed together: (1) There is the transport layer endpoint you connect to in case of TLS which can be well represented by TransportDomain and TransportAddress pairs or perhaps even more handy using TransportType and TransportAddress pairs (if you do not expected vendor specific layer 4 endpoints). Alternatively, you can also use an (InetAddressType, InetAddress, InetPort) triple (and I have the feeling that the later has been kind of more popular so far). (2) There is the additional information that after connecting to the transport endpoint, you are talking TLS and you have to use the SYSLOG over TLS framing. This, I think, goes beyond what the Transport* TCs (or the Inet* TCs) try to represent. In SNMP land, the TAddress and TDomain carry this additional knowledge and hence we keep defining new TCs and OIDs for new SNMP transports. An alternative is to have a construction where you specify the transport endpoint in one of the ways explained under (1) and you have an additional object which defines the encapsulation method. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 15 09:25:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvDzv-0004TH-4V; Fri, 15 Dec 2006 09:25:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvDzt-0004TB-PZ for syslog@ietf.org; Fri, 15 Dec 2006 09:25:13 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvDzs-0002y8-9q for syslog@ietf.org; Fri, 15 Dec 2006 09:25:13 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 15 Dec 2006 06:25:12 -0800 X-IronPort-AV: i="4.12,175,1165219200"; d="scan'208"; a="352066100:sNHT49412530" 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 kBFEPBxe009599; Fri, 15 Dec 2006 06:25:11 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kBFEPAjT018860; Fri, 15 Dec 2006 06:25:11 -0800 (PST) Date: Fri, 15 Dec 2006 06:25:10 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] severity In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F88E0@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA1F88E0@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4494; t=1166192711; x=1167056711; 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]=20severity |Sender:=20; bh=G0A5yg3pUx4e2JzGhyv5XhK0RNWYsIow8HkewC/GupQ=; b=tu/E99obBoxxBsUFRZ9Emcfa+Ygv77szJhCkfExhPOgc/at9Ls749Umcg7aZxXk/CbcxeSAd tNet4FpjRu4+mTU/ZEAff5T5MboPq0NuY0wjDBnU17zJxiJGYlwqAMMQ; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Rainer has it right. I agree that a simple note as Rainer suggests will do it. Thanks, Chris On Fri, 15 Dec 2006, Rainer Gerhards wrote: > David, > > I went through my notes. Retaining PRI as is is actually a charter item: > > --- > Reviews have shown that there are very few similarities between the > message formats generated by heterogeneous systems. In fact, the only > consistent commonality between messages is that all of them contain > the at the start. Additional testing has shown that as long as > the is present in a syslog message, all tested receivers will > accept any generated message as a valid syslog message. In designing a > standard syslog message format, this Working Group will retain the > at the start of the message and will introduce protocol > versioning. > --- > > So we can not change the PRI representation (and thus the representation > of severity). > >> From what I see in my notes, we simply copied over the 3164 text on PRI > without any further thinking after we had set on this charter. I think > this is the primary reason that it was not better spelled out and be > undetected until now. > > Rainer > >>> Before we publish the spec as an RFC, is the WG satisfied with this >>> restriction of severity to 0-7, and is the WG satisfied that this is >>> clear and unambiguous in our spec? >>> >>> If the WG believes the 0-7 restriction is unacceotable, we will need >>> to pull the draft back from the IESG and make changes to PRI. >> >> The last time a version was submitted (roughly a year ago), it was >> pulled back *because* PRI calculation was different from >> legacy syslog. >> This was the whole point in that discussion. And, yes, then >> there wasn't >> this restriction. IMHO we can not change that without going into a >> "deep-inconsistency-loop" of WG decisions. >>> >>> If the WG accepts the 0-7, but thinks the draft is not clear and >>> unambiguous, then we could provide clarifying text as part of WGLC >>> without pulling the draft back from the IESG. >> >> This is what I'd recommend. A simple sentence like "severities MUST be >> in the range of 0 to 7" should do the job. >> >> Rainer >>> >>> David Harrington >>> dharrington@huawei.com >>> dbharrington@comcast.net >>> ietfdbh@comcast.net >>> >>> >>>> -----Original Message----- >>>> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] >>>> Sent: Thursday, December 14, 2006 9:26 AM >>>> To: Glenn M. Keeni; syslog@ietf.org >>>> Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 1 >>>> >>>> So far, just one comment... >>>> >>>>> 1.6 > > 11) in SyslogSeverity, I recommend removing the >>>>> second sentnece >>>>> >> in the >>>>> >> description "The syslog protocol uses the values 0 >>>>> (emergency) >>>>> >> to 7 (debug)." since this is already spelled out in >>>>> the SYNTAX >>>>> >> clause,andshows that 99 (other) is also used. Why do we >>>>> >> need 99? Are other >>>>> >> values valid? >>>>> Partially fixed. When is "other" used? >>>>> >>>>> Response. >>>>> "other" will be used to count messages that do not have >>>>> severity in >>>>> the range 0-7. The syslog protocol specs (-19.txt) does >>>>> not disallow >>>>> such messages. >>>> >>>> Actually, -syslog-protocol disallows this by the way the PRI value >>> is >>>> specified (this was different in previous versions of the I-D). In >>>> short: PRI MOD 8 is severity. So if a severity greater >> than 7 would >>> be >>>> given, it would actually modify the facility. See 6.2.1: >>>> >>>> -- >>>> The Priority value is calculated by first multiplying >> the Facility >>>> number by 8 and then adding the numerical value of the Severity. >>>> -- >>>> >>>> Rainer >>>> >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/syslog >>>> >>> >>> >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >>> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 15 10:41:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFBZ-0001kr-Kf; Fri, 15 Dec 2006 10:41:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFBY-0001kM-37 for syslog@ietf.org; Fri, 15 Dec 2006 10:41:20 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvFBW-0004iR-MB for syslog@ietf.org; Fri, 15 Dec 2006 10:41:20 -0500 Received: from pc6 (1Cust133.tnt29.lnd3.gbr.da.UU.NET [62.188.120.133]) by astro.systems.pipex.net (Postfix) with SMTP id 114A5E0004AC; Fri, 15 Dec 2006 15:41:16 +0000 (GMT) Message-ID: <065101c72057$0b9360c0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Rainer Gerhards'" References: <150701c71fce$70a19470$0600a8c0@china.huawei.com> Subject: Re: [Syslog] Syslog-mib-11 Date: Fri, 15 Dec 2006 15:34:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org mmmmmm Rainer's explanation shows me why I have not encountered this; it is only present in Windows servers and then only, if I read it aright, because Windows has not done a satisfactory implementation yet. The question then is, how much do we adapt to this behaviour of Windows? I find your remedy insufficient. Look at the diagram at the start of -mib and compare it with the diagram at the start of -protocol. Seeing those two diagrams convinced me that the two I-Ds came from different planets and that, until that was resolved - and only now, months later, do I begin to see a resolution - it was not worth expending much effort on -mib. I think this will be the reaction of others and that we MUST include the diagram in -mib that appears in all the others and then -mib must explain how the terms it chooses relates to those in the diagram and why. Simplying saying this I-D is different because we are on planet Microsoft is not sufficient for me. I agree that there must also be a brief explanation in the DESCRIPTION clause. Another problem I have with -mib is the statement that "The syslog entities may be on the same host or on different hosts." If on different hosts, what is the protocol used to communicate between the two hosts? If this is syslog, then how is the MIB information communicated from syslog sender to the entity with the SNMP agent? This is not a new question:-(. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'Rainer Gerhards'" Cc: Sent: Thursday, December 14, 2006 11:23 PM Subject: RE: [Syslog] Syslog-mib-11 > Hi, > > [speaking as a contributor] > > Thank you Rainer for such a clear response. > > I recommend that text similar to Rainer's response be included in the > DESCRIPTION clause for the syslogEntityControlTable, to explain why > multiple syslog entities are modeled in the MIB module. > > I recommend capturing the discussion within the MIB module definition > rather than in the document introductory sections, because MIB modules > are often distributed already-extracted from the surrounding document, > and NMS help screens are often fashioned from the DESCRIPTION clauses. > So putting this info in the table description clause will get the > explanation to the users. I would not object to **also** having it > discussed in the introductory text sections. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 15 10:41:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFBX-0001kC-VI; Fri, 15 Dec 2006 10:41:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFBW-0001jT-Ei for syslog@ietf.org; Fri, 15 Dec 2006 10:41:18 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvFBU-0004iE-VY for syslog@ietf.org; Fri, 15 Dec 2006 10:41:18 -0500 Received: from pc6 (1Cust133.tnt29.lnd3.gbr.da.UU.NET [62.188.120.133]) by astro.systems.pipex.net (Postfix) with SMTP id 417BAE00045E; Fri, 15 Dec 2006 15:41:11 +0000 (GMT) Message-ID: <065001c72057$0a4535e0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Glenn M. Keeni'" , References: <150401c71fc8$b9d4cdc0$0600a8c0@china.huawei.com> Subject: Re: [Syslog] Mib terminology and MIB design Date: Fri, 15 Dec 2006 15:17:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is also tied up with the scalar/table question. If we had a scalar MIB module, then much of my difficulty would vanish. If we keep the table, then it should not be of entities. As you point out, SNMPv3 has given the word 'entity' a specific meaning and I think it wrong to re-use the word to mean something different in a MIB module (it would be ok if this were SMTP or BGP); I find the use of 'managed entity' in DESCRIPTION clauses especially confusing. I like 'daemon' (not seeing that as being in any way limited to a particular role) or 'device', which is already in use in other syslog documents. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'Glenn M. Keeni'" ; Sent: Thursday, December 14, 2006 10:41 PM Subject: [Syslog] Mib terminology and MIB design > Hi, > > [speaking as coc-ahir] > We need WG input on this. > Please look at mib-11 and decide whether "entity" is appropriate. > Glenn has changed the terminology in many places to be more consistent > than previous revisions. > > In the TLS document, Miao and Yuzhi tried to use a generic term for > any role and WG consensus was to change the document to use the > sender/receiever/relay/collector terminology. Does the same thing need > to be done here? > [co-chair end] > > [speaking as contributor (and MIB Doctor)] > I have mixed feelings on this issue. > > I personally think not having a generic term makes it harder to write > documents and design mib modules that can be applied to any of the > roles. In SNMPv3, we deliberately moved away from different processing > for different roles and toward a common "entity" that could act in > different roles. > > When designing a MIB module to encompass multiple roles as one entity, > it is very important to review the design from the perspective of each > of the roles. For example, it may make sense to count messagesSent if > you are implementing a sender or relay, but not if you are > implementing a reciever or collector. It will be a poor MIB module > design if it makes a great deal of sense for implementers to only > implement some of the objects in a table that is > mandatory-to-implement for compliance. Having objects that only make > sense for certain roles and not others in one common table will > encourage non-compliant implementations. > > On the other hand, defining the MIB module to contain four tables to > model the sender configuration, and the receiver configuration, and > the relay configuration, and the collector configuration, even though > all four tables would contain identical information is simply > ridiculous design. > > I do not like having one set of terminology in the protocol > specifications, and a different set of terminology in the management > interface, because it makes it harder for operators to interpret the > data in the MIB module. > > The WG needs to review the MIB module design and determine what makes > protocol sense. > [contributor end] > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > +---------------------------------------------------+ > > 1.1 > > 3) the terminology is not consistent with the > > other WG documents. > > Not fixed. Still a problem. The WG consensus was > > to use sender, > > receiver, relay, and collector. Other document were > > required to change > > to match this terminology. The MIB document uses entity, > > which is a term not found in the protocol draft. > > > > I find this change in terminology makes it difficult > > to interpret some objects in the mib module. > > > > Response: > > We have a single MIB module for all the roles of a syslog > > "entity" - sender, receiver, relay and collector. > > I do not see any problem with this generic nature of the > > MIB, as yet. > > > > Let me know about the specific objects that are difficult > > to interpret. We may try the following: > > Use the generic "syslog entity" when the discussion > > applies to all the roles > > Use the role(s) explicitly "syslog sender", "syslog > > receiver", etc. when the discussion does not apply to > > all the roles. > > Add a statement to that effect in the early part of > > the text. > > > > Any other suggestions? > > > > 1.2 > > 4) "roles a syslog entity maybe in" would be better > > as "roles of a > > > > syslog entity" (although then entity should be > > changed according to > > > > #3. > > See #3. > > Response: > > See #1. > > 1.3 > > 5) I concur with Bert that the citations in section 2 seem > > > > inappropriate. > > I suggest rewriting the introduction to use the same > > terminology as > > the protocol draft. See #3. > > Response: > > See #1. > > > > 1.4 > > 6) I find the references to SA-Li, RA-Rj confusing > > since these are > > not > > > > used in the diagram. > > Fixed, but replaced by "entity" which is a problem. See #3. > > Response: > > See #1. > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 15 13:27:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvHlN-000106-HP; Fri, 15 Dec 2006 13:26:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvHlM-000101-W2 for syslog@ietf.org; Fri, 15 Dec 2006 13:26:28 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvHlM-0005Q3-DT for syslog@ietf.org; Fri, 15 Dec 2006 13:26:28 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20061215182625b1100k6b9me>; Fri, 15 Dec 2006 18:26:25 +0000 From: "David Harrington" To: Subject: RE: [Syslog] Mib terminology and MIB design Date: Fri, 15 Dec 2006 13:23:06 -0500 Message-ID: <155c01c72076$177323c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccgX3WUKfHv+nwtTcOKYu4PsWXaHgABu2Rg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <065001c72057$0a4535e0$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [posting as a contributor] Tom mentions that we should not use the term entity here, because it conflicts with the SNMP usage of that term. Since this is a MIB module designed for use in an SNMP environment, that is a really good point. It would hurt us to have conflicts between the terminology used to describe syslog things, and the terminology used to describe SNMP things in this mib module. Which raises an interesting question. Is the terminology used for syslog and the terminology used for SNMP compatible? Could we make them more compatible (without modifying any of the other syslog documents?) One approach to consider would be to use the RFC3411 "descriptive" architecture to describe the syslog architecture. The processes of preparing messages, dealing with message security, and sending messages via different transports are all services provided by the "engine": +-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +------------+ | | | | | Transport | | | | | | Subsystem | | | | | +------------+ | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Proxy | | | | | | Generator | | Receiver | | Forwarder | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Other | | | | | | Responder | | Originator | | | | | | | +-------------+ +--------------+ +--------------+ | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ One engine can support multiple "SNMP applications". SNMP applications are the things that define the roles, e.g. a notification originator (Cf: a syslog sender), a notification receiver (Cf: a syslog receiver), and a proxy forwarder (Cf: syslog relay). The RFC3411 architecture also supports command generator (that makes requests) and command responder (that processes requests and responds) that do not apply to syslog. The "SNMP applications" describe functionality that is combined with other functionality provided by software or devices; to put this in syslog terms, the facilities would utilize the "SNMP application" style functionality to generate, receive, or relay messages. Since this is a MIB document, we could provide an introductory section that maps from the syslog terminology to the RFC3411 terminology. Most users of the MIB will already have some knowledge of the SNMPv3 concepts. We could use the picture above. modified to describe the syslog architecure: +-------------------------------------------------------------------+ | Syslog entity | | | | +-------------------------------------------------------------+ | | | Syslog engine | | | | | | | | +------------+ | | | | | Transport | | | | | | Subsystem | | | | | +------------+ | | | | | | | | +------------+ +------------+ +-----------+ | | | | | Dispatcher | | Message | | Security | | | | | | | | Processing | | Subsystem | | | | | | | | Subsystem | | | | | | | +------------+ +------------+ +-----------+ | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Syslog | | Syslog | | Syslog | | | | | | Sender | | Receiver | | Relay | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ I think with the addition of entity and engine to the terminology, this picture does a good job of describing the syslog architecture, and would make it clearer what the "things" are that are modeled in the syslog mib module. It would however, only be clearer to a degree. The table in the mib document would likely model one or more *engines* (daemons that serve multiple applications) in a *NIX environment, but would model multiple *entities* in a Windows environment. And sometimes, the table would include multiple engines and multiple entities. We need to model the real world. As Tom points out, one way to avoid this is to develop a scalar mib module. Such a mib module would only model one engine at a time. It might be immaterial whether that engine services one or more applications. It could however be important to know that, so we might need to model the engine as a scalar, and supplement that with a table of applications (facilities?) serviced by the one engine, and statistics related to that usage. If a system had more than one syslog engine operating, a single SNMP engine could service them all, using different SNMP contexts to model them. But this brings us back to where we are now, with the reality that some engines are contained in complete entities, and some engines are not. I have a bias toward an approach using RFC3411. Not only am I one of the authors of RFC3411, I am trying to migrate SNMP, syslog, ipfix, and netconf to all use a common terminology, where possible, to describe their concepts and functionalities, so it is easier to compare, and possibly reuse, some design decisions. It might also be possible to reuse some specifications. All of these protocols are looking to utilize secure transports (e.g., SSH and TLS). It would be a good thing if they all used similar approaches, so operators only had to configure one secure transport protocol (e.g. TLS) in one consistent manner to secure all four NM protocols. All four protocols need data modleing capabilities, to different degrees, and if the IETF NM community could agree to all use, say XML for encoding, and XSD for modeling, it would be easier to reuse and/or correlate the data. Netconf is looking at a notification design that can carry syslog info and snmp info; if the syslog SDEs can be translated into XML, and MIB data can be translated into XML, and ipfix data can be transalted into XML, (e.g., via XSLT transform tools), then it might be much easier for operators to correlate the data of the four NM protocols. I am only suggesting here that we use a diagram and entity/engine terminology similar to RFC3411 terminology to make the MIB module easier to understand. Doing so would place no constraints on syslog designers, implementers, or users (except of course, the designers of this mib module). David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, December 15, 2006 9:18 AM > To: David Harrington; 'Glenn M. Keeni'; syslog@ietf.org > Subject: Re: [Syslog] Mib terminology and MIB design > > This is also tied up with the scalar/table question. If we > had a scalar MIB > module, then much of my difficulty would vanish. > > If we keep the table, then it should not be of entities. As > you point out, > SNMPv3 has given the word 'entity' a specific meaning and I > think it wrong to > re-use the word to mean something different in a MIB module > (it would be ok if > this were SMTP or BGP); I find the use of 'managed entity' in > DESCRIPTION > clauses especially confusing. I like 'daemon' (not seeing > that as being in any > way limited to a particular role) or 'device', which is > already in use in other > syslog documents. > > Tom Petch > > > ----- Original Message ----- > From: "David Harrington" > To: "'Glenn M. Keeni'" ; > Sent: Thursday, December 14, 2006 10:41 PM > Subject: [Syslog] Mib terminology and MIB design > > > > Hi, > > > > [speaking as coc-ahir] > > We need WG input on this. > > Please look at mib-11 and decide whether "entity" is appropriate. > > Glenn has changed the terminology in many places to be more > consistent > > than previous revisions. > > > > In the TLS document, Miao and Yuzhi tried to use a generic term for > > any role and WG consensus was to change the document to use the > > sender/receiever/relay/collector terminology. Does the same > thing need > > to be done here? > > [co-chair end] > > > > [speaking as contributor (and MIB Doctor)] > > I have mixed feelings on this issue. > > > > I personally think not having a generic term makes it > harder to write > > documents and design mib modules that can be applied to any of the > > roles. In SNMPv3, we deliberately moved away from different > processing > > for different roles and toward a common "entity" that could act in > > different roles. > > > > When designing a MIB module to encompass multiple roles as > one entity, > > it is very important to review the design from the > perspective of each > > of the roles. For example, it may make sense to count > messagesSent if > > you are implementing a sender or relay, but not if you are > > implementing a reciever or collector. It will be a poor MIB module > > design if it makes a great deal of sense for implementers to only > > implement some of the objects in a table that is > > mandatory-to-implement for compliance. Having objects that only make > > sense for certain roles and not others in one common table will > > encourage non-compliant implementations. > > > > On the other hand, defining the MIB module to contain four tables to > > model the sender configuration, and the receiver configuration, and > > the relay configuration, and the collector configuration, > even though > > all four tables would contain identical information is simply > > ridiculous design. > > > > I do not like having one set of terminology in the protocol > > specifications, and a different set of terminology in the management > > interface, because it makes it harder for operators to interpret the > > data in the MIB module. > > > > The WG needs to review the MIB module design and determine > what makes > > protocol sense. > > [contributor end] > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > > +---------------------------------------------------+ > > > 1.1 > > 3) the terminology is not consistent with the > > > other WG documents. > > > Not fixed. Still a problem. The WG consensus was > > > to use sender, > > > receiver, relay, and collector. Other document were > > > required to change > > > to match this terminology. The MIB document uses entity, > > > which is a term not found in the protocol draft. > > > > > > I find this change in terminology makes it difficult > > > to interpret some objects in the mib module. > > > > > > Response: > > > We have a single MIB module for all the roles of a syslog > > > "entity" - sender, receiver, relay and collector. > > > I do not see any problem with this generic nature of the > > > MIB, as yet. > > > > > > Let me know about the specific objects that are difficult > > > to interpret. We may try the following: > > > Use the generic "syslog entity" when the discussion > > > applies to all the roles > > > Use the role(s) explicitly "syslog sender", "syslog > > > receiver", etc. when the discussion does not apply to > > > all the roles. > > > Add a statement to that effect in the early part of > > > the text. > > > > > > Any other suggestions? > > > > > > 1.2 > > 4) "roles a syslog entity maybe in" would be better > > > as "roles of a > > > > > syslog entity" (although then entity should be > > > changed according to > > > > > #3. > > > See #3. > > > Response: > > > See #1. > > > 1.3 > > 5) I concur with Bert that the citations in section 2 seem > > > > > inappropriate. > > > I suggest rewriting the introduction to use the same > > > terminology as > > > the protocol draft. See #3. > > > Response: > > > See #1. > > > > > > 1.4 > > 6) I find the references to SA-Li, RA-Rj confusing > > > since these are > > > not > > > > > used in the diagram. > > > Fixed, but replaced by "entity" which is a problem. See #3. > > > Response: > > > See #1. > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Dec 16 14:16:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvf06-0001hW-GA; Sat, 16 Dec 2006 14:15:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvf05-0001hN-F6 for syslog@ietf.org; Sat, 16 Dec 2006 14:15:13 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvf04-0004w1-8W for syslog@ietf.org; Sat, 16 Dec 2006 14:15:13 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20061216191508b1300q86mae>; Sat, 16 Dec 2006 19:15:09 +0000 From: "David Harrington" To: "Glenn Mansfield Keeni" , Date: Sat, 16 Dec 2006 14:11:38 -0500 Message-ID: <168c01c72146$0fa1ae70$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcchRgLMOuX1mgoYQmqS700hgso2Sw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Syslog] Mib-12 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Glenn, Once you finish updating the document with the issues we agree on, can you publish a mib-12 so we narrow the discussion to the few remaining issues? Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Dec 17 10:09:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvxcq-0005B0-G5; Sun, 17 Dec 2006 10:08:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvxcp-0005Ar-Dv for syslog@ietf.org; Sun, 17 Dec 2006 10:08:27 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvxcm-0001t6-6D for syslog@ietf.org; Sun, 17 Dec 2006 10:08:26 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBHF8BJW024903 for ; Mon, 18 Dec 2006 00:08:11 +0900 (JST) Received: from [127.0.0.1] (kiras7.priv.cysol.co.jp [192.168.0.157]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBHF84sN011153 for ; Mon, 18 Dec 2006 00:08:10 +0900 (JST) Message-ID: <45855D54.2000606@cysols.com> Date: Mon, 18 Dec 2006 00:08:04 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The following starts the discussion on the points raised in Dbh re-Review of -mib-11, part 3. Cheers Glenn +-----------------------------------------------------+ 3.1 The idnits checker reports the use of the old copyright and disclaimer boilerplates rather than the new copyright and disclaimer boilerplates. These need to be updated. Response. Same as 2.7. Updated the boilerplate for the Copyright notice. http://tools.ietf.org/tools/idnits/ shows zero errors now. 3.2 syslogEntityOperationsReference uses a lower case "should". Is it nto important for interoperability that this be done? If so, then this should be a "SHOULD". If not for interoperability, why are we saying it "should" be done? Response. Changed should to SHOULD. 3.3 I still have difficulty understanding why default parameters are listed in the MIB module. What is the use case that requires these objects in the MIB module? Who decides what the default values should be? Since they are read-write objects, I assume the purpose is to allow an NMS to set the default values they want the sender to use. What happens if there are multiple NMSs talking to the same sender? Then who decides? If each NMS gets to decide, than you need a table in which each row is "owned" by a particular NMS. I still don't see why this would be needed however. If the sender decides, and the objects exist only so the receivers can check and see what the sender will use for defaults, then why are the objects read-write? Once an NMS checks the defaults, what are they supposed to do with this information? I question whether this deserves to be in the MIB module at all, but if it kept, then at least the MIB module should include a description of why it is there and how it should be used. Response. OK. I understand that there is a problem when several NMSs are talking to the system. I will make this read-only. These default values are set by some means at start up. In general the default values will be used ( IPv4, UDP, port 512 etc.) by syslog entities. In these cases it is not necessary to specify the (default) values for each row (representing a syslog entity) in the syslogEntityControlTable. The values will be specified when they are different from the defaults. Does that help ? 3.4 RFCPROT is a reference in syslogDefaultTransportDomain; it probably shoul dbe shown as [RFCPROT] or the RFC editor may overlook it. Response. Done. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Dec 17 13:32:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw0nO-0000Js-Uk; Sun, 17 Dec 2006 13:31:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw0nN-0000Go-1c for syslog@ietf.org; Sun, 17 Dec 2006 13:31:33 -0500 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw0nL-0003Pc-FU for syslog@ietf.org; Sun, 17 Dec 2006 13:31:33 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20061217183127b1300q740ve>; Sun, 17 Dec 2006 18:31:27 +0000 From: "David Harrington" To: "'Glenn M. Keeni'" , Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 3 Date: Sun, 17 Dec 2006 13:27:55 -0500 Message-ID: <170401c72209$1e61bb80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acch7U8EyimUX4gYQXiG8mJVWev5JgAE3vyQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <45855D54.2000606@cysols.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Glenn, > 3.3 I still have difficulty understanding why default parameters > are listed in the MIB module. What is the use case that > requires these objects in the MIB module? > > Who decides what the default values should be? Since they are > read-write objects, I assume the purpose is to allow an NMS to > set the default values they want the sender to use. What happens > if there are multiple NMSs talking to the same sender? Then who > decides? If each NMS gets to decide, than you need a table in > which each row is "owned" by a particular NMS. I still don't > see why this would be needed however. > > If the sender decides, and the objects exist only so the > receivers can check and see what the sender will use for > defaults, then why are the objects read-write? Once an NMS > checks the defaults, what are they supposed to do with this > information? > > I question whether this deserves to be in the MIB module at > all, but if it kept, then at least the MIB module should > include a description of why it is there and how it should > be used. > > Response. > OK. I understand that there is a problem when several NMSs > are talking to the system. I will make this read-only. > These default values are set by some means at start up. > In general the default values will be used ( IPv4, UDP, > port 512 etc.) by syslog entities. > In these cases it is not necessary to specify the (default) > values for each row (representing a syslog entity) in the > syslogEntityControlTable. The values will be specified when > they are different from the defaults. > > Does that help ? > Only to a degree. I think this reinforces some of my concerns (and Tom's). Why does this need to be made accessible in the MIB module? If it is read-write, you have the problem of multiple NMSs. If it is read-only, then no NMS can modify it. So all it does is reflect what default values are used. But if the table represents different engines (not different applications using a common engine), then those engines should probably operate on different ports, So it becomes a per-engine (per-entity) issue, not a global default issue. So it doesn't make sense as a scalar value, if it must be applied on a per-row basis. If the idea is to recommend what defaults should be used (IPv4,UDP,512), those can be specified as DEFVALS in the per-row managed objects (TransportDomain and syslogService) that can override such DEFVALs. You say that if the entity uses the defaults, it is not necessary to specify the values for each row. But the objects are defined a part of the row, and they are listed as mandatory-to-implement objects in the syslogEntityControlGroup. Why would we want to require implementers to implement these objects and then tell them they do not need to use them? (and when we go down that path, then I have some problems with "If no value is specified,..."). Different engines may have different ideas of what to use for defaults for severity and facility as well, so would it not make sense to have these defaults also specified on a per-row basis? If the engine and application are combined into a single entity, then surely that application has some idea of its own facility? But if I have a login facility and a ntp facility, why would I want the ability to use SNMP to set a default facility equal to uucp? It does not make sense to me to define these global defaults in a MIB module that supports multiple entities; or maybe I do not understand the use case, because you have lumped all sender/receiver/relay together as entities, and this is really only useful in certain situations. Are these designed to allow a receiver/collector to calculate and store a PRI for messages received from non-standard senders? Are these designed to allow a relay to calculate the PRI for messages received from non-standard senders, and to convert the message into a standard message format? Or are these designed for a standard sender to calculate the PRI for applications that don't specify their facility and severity when asking the sender to send a message? What are these defaults for? These defaults might make sense if the MIB represented one sender/engine and the table represented different applications (facilities) that utilized the message-sending capaibilities of the engine. Even there I would think the applications(facility) would be expected to identify its own facility category to a standards-compliant sender. If it is not a standards-compliant sender, then it is not our business to figure out how the application should talk to the sender, because that is not an on-the-wire issue. How a standards-compliant sender should deal with a non-standards-compliant facility that doesn't provide the facility and severity (e.g. refusing the request or substituting default values) is an implementation detail, not a standard detail. Note that I don't think there really is a non-standards-compliant application here, because we don't standardize implementation interfaces between an application and its sender/engine, but it seems pretty certain that if a sender needs to calculate a PRI, then it will need a facility and severity, and any application working with a standards-compliant sender would be expected to provide that info, so an application that doesn't provide them might be called non-standards-compliant, but that would really be stretching. It would probbaly b emore accurate to call the application non-standards-supporting. I do not understand the purpose of these defaults; I do not understand who uses them for what, and without understanding what the use case is, I **CANNOT** understand the implications of their designs, and why an implemneter is required to support them, or how an implementer is expected to utilize them. How can we possibly declare these to be part of an industry-wide standard? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 18 04:39:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwExC-0007xJ-EX; Mon, 18 Dec 2006 04:38:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwExB-0007wV-8X for syslog@ietf.org; Mon, 18 Dec 2006 04:38:37 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwExA-00083p-0F for syslog@ietf.org; Mon, 18 Dec 2006 04:38:37 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 1606C27C015; Mon, 18 Dec 2006 10:41:16 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20782-03; Mon, 18 Dec 2006 10:41:16 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id C6D2C27C013; Mon, 18 Dec 2006 10:41:15 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 10:38:27 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Dec 2006 10:38:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F88F8@grfint2.intern.adiscon.com> In-Reply-To: <45855D54.2000606@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Dbh re-Review of -mib-11, part 3 Thread-Index: Acch7Wyy2rbyFqxsROGnRfOFBlSKnwAmsOcA References: <45855D54.2000606@cysols.com> From: "Rainer Gerhards" To: "Glenn M. Keeni" , X-OriginalArrivalTime: 18 Dec 2006 09:38:27.0966 (UTC) FILETIME=[4576D1E0:01C72288] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Just one comment... > In general the default values will be used ( IPv4, UDP, > port 512 etc.) by syslog entities. 514 is the IANA assigned port for UPD syslog. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 18 04:57:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwFF9-0005FW-T8; Mon, 18 Dec 2006 04:57:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwFF8-0005FL-SQ for syslog@ietf.org; Mon, 18 Dec 2006 04:57:10 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwFF7-0001UK-9H for syslog@ietf.org; Mon, 18 Dec 2006 04:57:10 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBI9v0JW010019 for ; Mon, 18 Dec 2006 18:57:00 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBI9uxsN026407 for ; Mon, 18 Dec 2006 18:57:00 +0900 (JST) Message-ID: <458665EB.20605@cysols.com> Date: Mon, 18 Dec 2006 18:56:59 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 3 References: <45855D54.2000606@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA1F88F8@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F88F8@grfint2.intern.adiscon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Rainer Gerhards wrote: > Just one comment... > >> In general the default values will be used ( IPv4, UDP, >> port 512 etc.) by syslog entities. > > 514 is the IANA assigned port for UPD syslog. > > Rainer > Ooops. That was port 514/UDP. Thanks for pointing that out. Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 18 06:59:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwH9L-0002mK-7s; Mon, 18 Dec 2006 06:59:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwH9K-0002mF-7Y for syslog@ietf.org; Mon, 18 Dec 2006 06:59:18 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GwH9I-0002g2-BD for syslog@ietf.org; Mon, 18 Dec 2006 06:59:18 -0500 Received: from pc6 (1Cust93.tnt5.lnd4.gbr.da.uu.net [62.188.134.93]) by blaster.systems.pipex.net (Postfix) with SMTP id 35D62E000225; Mon, 18 Dec 2006 11:59:07 +0000 (GMT) Message-ID: <012301c72293$7f3d2900$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <155c01c72076$177323c0$0600a8c0@china.huawei.com> Subject: syslog architecture Re: [Syslog] Mib terminology and MIB design Date: Mon, 18 Dec 2006 11:50:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org An architecture is very useful for me as long as it captures the essence of the engineering being architected, and this I am becoming increasingly unclear about. My use case is masses of dumb devices that just about support syslog (with a struggle) feeding a small number of powerful servers. Others on the list talk of servers as senders while the existence of relays is highly plausible. I now know of the Windows case of multiple applications each as its own sender but you now seem to be extending that to a host (to use the IP term) with multiple syslog processes each of which can be sender/relay/collector; and that seems an over-complication which noone is asking for. We already have an architecture - sender, relay, collector - which allows for a combined collector/relay and sender/relay (as defined in -protocol). I think we need a good reason to move away from that. Note in passing that -protocol uses the terms 'application' and 'system' Tom Petch ----- Original Message ----- From: "David Harrington" To: Sent: Friday, December 15, 2006 7:23 PM Subject: RE: [Syslog] Mib terminology and MIB design > Hi, > > [posting as a contributor] > > Tom mentions that we should not use the term entity here, because it > conflicts with the SNMP usage of that term. Since this is a MIB module > designed for use in an SNMP environment, that is a really good point. > It would hurt us to have conflicts between the terminology used to > describe syslog things, and the terminology used to describe SNMP > things in this mib module. > > Which raises an interesting question. Is the terminology used for > syslog and the terminology used for SNMP compatible? Could we make > them more compatible (without modifying any of the other syslog > documents?) > > One approach to consider would be to use the RFC3411 "descriptive" > architecture to describe the syslog architecture. The processes of > preparing messages, dealing with message security, and sending > messages via different transports are all services provided by the > "engine": > > > > +-------------------------------------------------------------------+ > | SNMP entity > | > | > | > | +-------------------------------------------------------------+ > | > | | SNMP engine (identified by snmpEngineID) | > | > | | | > | > | | +------------+ | > | > | | | Transport | | > | > | | | Subsystem | | > | > | | +------------+ | > | > | | | > | > | | +------------+ +------------+ +-----------+ +-----------+ | > | > | | | Dispatcher | | Message | | Security | | Access | | > | > | | | | | Processing | | Subsystem | | Control | | > | > | | | | | Subsystem | | | | Subsystem | | > | > | | +------------+ +------------+ +-----------+ +-----------+ | > | > | +-------------------------------------------------------------+ > | > | > | > | +-------------------------------------------------------------+ > | > | | Application(s) | > | > | | | > | > | | +-------------+ +--------------+ +--------------+ | > | > | | | Command | | Notification | | Proxy | | > | > | | | Generator | | Receiver | | Forwarder | | > | > | | +-------------+ +--------------+ +--------------+ | > | > | | | > | > | | +-------------+ +--------------+ +--------------+ | > | > | | | Command | | Notification | | Other | | > | > | | | Responder | | Originator | | | | > | > | | +-------------+ +--------------+ +--------------+ | > | > | +-------------------------------------------------------------+ > | > | > | > > +-------------------------------------------------------------------+ > > > One engine can support multiple "SNMP applications". SNMP applications > are the things that define the roles, e.g. a notification originator > (Cf: a syslog sender), a notification receiver (Cf: a syslog > receiver), and a proxy forwarder (Cf: syslog relay). > > The RFC3411 architecture also supports command generator (that makes > requests) and command responder (that processes requests and responds) > that do not apply to syslog. > > The "SNMP applications" describe functionality that is combined with > other functionality provided by software or devices; to put this in > syslog terms, the facilities would utilize the "SNMP application" > style functionality to generate, receive, or relay messages. > > Since this is a MIB document, we could provide an introductory section > that maps from the syslog terminology to the RFC3411 terminology. Most > users of the MIB will already have some knowledge of the SNMPv3 > concepts. We could use the picture above. modified to describe the > syslog architecure: > > > > +-------------------------------------------------------------------+ > | Syslog entity > | > | > | > | +-------------------------------------------------------------+ > | > | | Syslog engine | > | > | | | > | > | | +------------+ | > | > | | | Transport | | > | > | | | Subsystem | | > | > | | +------------+ | > | > | | | > | > | | +------------+ +------------+ +-----------+ | > | > | | | Dispatcher | | Message | | Security | | > | > | | | | | Processing | | Subsystem | | > | > | | | | | Subsystem | | | | > | > | | +------------+ +------------+ +-----------+ | > | > | +-------------------------------------------------------------+ > | > | > | > | +-------------------------------------------------------------+ > | > | | Application(s) | > | > | | | > | > | | +-------------+ +--------------+ +--------------+ | > | > | | | Syslog | | Syslog | | Syslog | | > | > | | | Sender | | Receiver | | Relay | | > | > | | +-------------+ +--------------+ +--------------+ | > | > | | | > | > | +-------------------------------------------------------------+ > | > | > | > > +-------------------------------------------------------------------+ > > > I think with the addition of entity and engine to the terminology, > this picture does a good job of describing the syslog architecture, > and would make it clearer what the "things" are that are modeled in > the syslog mib module. > > It would however, only be clearer to a degree. The table in the mib > document would likely model one or more *engines* (daemons that serve > multiple applications) in a *NIX environment, but would model multiple > *entities* in a Windows environment. And sometimes, the table would > include multiple engines and multiple entities. We need to model the > real world. > > As Tom points out, one way to avoid this is to develop a scalar mib > module. Such a mib module would only model one engine at a time. It > might be immaterial whether that engine services one or more > applications. It could however be important to know that, so we might > need to model the engine as a scalar, and supplement that with a table > of applications (facilities?) serviced by the one engine, and > statistics related to that usage. > > If a system had more than one syslog engine operating, a single SNMP > engine could service them all, using different SNMP contexts to model > them. But this brings us back to where we are now, with the reality > that some engines are contained in complete entities, and some engines > are not. > > > I have a bias toward an approach using RFC3411. Not only am I one of > the authors of RFC3411, I am trying to migrate SNMP, syslog, ipfix, > and netconf to all use a common terminology, where possible, to > describe their concepts and functionalities, so it is easier to > compare, and possibly reuse, some design decisions. > > It might also be possible to reuse some specifications. All of these > protocols are looking to utilize secure transports (e.g., SSH and > TLS). It would be a good thing if they all used similar approaches, so > operators only had to configure one secure transport protocol (e.g. > TLS) in one consistent manner to secure all four NM protocols. > > All four protocols need data modleing capabilities, to different > degrees, and if the IETF NM community could agree to all use, say XML > for encoding, and XSD for modeling, it would be easier to reuse and/or > correlate the data. Netconf is looking at a notification design that > can carry syslog info and snmp info; if the syslog SDEs can be > translated into XML, and MIB data can be translated into XML, and > ipfix data can be transalted into XML, (e.g., via XSLT transform > tools), then it might be much easier for operators to correlate the > data of the four NM protocols. > > > I am only suggesting here that we use a diagram and entity/engine > terminology similar to RFC3411 terminology to make the MIB module > easier to understand. Doing so would place no constraints on syslog > designers, implementers, or users (except of course, the designers of > this mib module). > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Friday, December 15, 2006 9:18 AM > > To: David Harrington; 'Glenn M. Keeni'; syslog@ietf.org > > Subject: Re: [Syslog] Mib terminology and MIB design > > > > This is also tied up with the scalar/table question. If we > > had a scalar MIB > > module, then much of my difficulty would vanish. > > > > If we keep the table, then it should not be of entities. As > > you point out, > > SNMPv3 has given the word 'entity' a specific meaning and I > > think it wrong to > > re-use the word to mean something different in a MIB module > > (it would be ok if > > this were SMTP or BGP); I find the use of 'managed entity' in > > DESCRIPTION > > clauses especially confusing. I like 'daemon' (not seeing > > that as being in any > > way limited to a particular role) or 'device', which is > > already in use in other > > syslog documents. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "David Harrington" > > To: "'Glenn M. Keeni'" ; > > Sent: Thursday, December 14, 2006 10:41 PM > > Subject: [Syslog] Mib terminology and MIB design > > > > > > > Hi, > > > > > > [speaking as coc-ahir] > > > We need WG input on this. > > > Please look at mib-11 and decide whether "entity" is appropriate. > > > Glenn has changed the terminology in many places to be more > > consistent > > > than previous revisions. > > > > > > In the TLS document, Miao and Yuzhi tried to use a generic term > for > > > any role and WG consensus was to change the document to use the > > > sender/receiever/relay/collector terminology. Does the same > > thing need > > > to be done here? > > > [co-chair end] > > > > > > [speaking as contributor (and MIB Doctor)] > > > I have mixed feelings on this issue. > > > > > > I personally think not having a generic term makes it > > harder to write > > > documents and design mib modules that can be applied to any of the > > > roles. In SNMPv3, we deliberately moved away from different > > processing > > > for different roles and toward a common "entity" that could act in > > > different roles. > > > > > > When designing a MIB module to encompass multiple roles as > > one entity, > > > it is very important to review the design from the > > perspective of each > > > of the roles. For example, it may make sense to count > > messagesSent if > > > you are implementing a sender or relay, but not if you are > > > implementing a reciever or collector. It will be a poor MIB module > > > design if it makes a great deal of sense for implementers to only > > > implement some of the objects in a table that is > > > mandatory-to-implement for compliance. Having objects that only > make > > > sense for certain roles and not others in one common table will > > > encourage non-compliant implementations. > > > > > > On the other hand, defining the MIB module to contain four tables > to > > > model the sender configuration, and the receiver configuration, > and > > > the relay configuration, and the collector configuration, > > even though > > > all four tables would contain identical information is simply > > > ridiculous design. > > > > > > I do not like having one set of terminology in the protocol > > > specifications, and a different set of terminology in the > management > > > interface, because it makes it harder for operators to interpret > the > > > data in the MIB module. > > > > > > The WG needs to review the MIB module design and determine > > what makes > > > protocol sense. > > > [contributor end] > > > > > > David Harrington > > > dharrington@huawei.com > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > > > > > > > > +---------------------------------------------------+ > > > > 1.1 > > 3) the terminology is not consistent with the > > > > other WG documents. > > > > Not fixed. Still a problem. The WG consensus was > > > > to use sender, > > > > receiver, relay, and collector. Other document were > > > > required to change > > > > to match this terminology. The MIB document uses entity, > > > > which is a term not found in the protocol draft. > > > > > > > > I find this change in terminology makes it difficult > > > > to interpret some objects in the mib module. > > > > > > > > Response: > > > > We have a single MIB module for all the roles of a syslog > > > > "entity" - sender, receiver, relay and collector. > > > > I do not see any problem with this generic nature of the > > > > MIB, as yet. > > > > > > > > Let me know about the specific objects that are difficult > > > > to interpret. We may try the following: > > > > Use the generic "syslog entity" when the discussion > > > > applies to all the roles > > > > Use the role(s) explicitly "syslog sender", "syslog > > > > receiver", etc. when the discussion does not apply to > > > > all the roles. > > > > Add a statement to that effect in the early part of > > > > the text. > > > > > > > > Any other suggestions? > > > > > > > > 1.2 > > 4) "roles a syslog entity maybe in" would be better > > > > as "roles of a > > > > > > syslog entity" (although then entity should be > > > > changed according to > > > > > > #3. > > > > See #3. > > > > Response: > > > > See #1. > > > > 1.3 > > 5) I concur with Bert that the citations in section 2 > seem > > > > > > inappropriate. > > > > I suggest rewriting the introduction to use the same > > > > terminology as > > > > the protocol draft. See #3. > > > > Response: > > > > See #1. > > > > > > > > 1.4 > > 6) I find the references to SA-Li, RA-Rj confusing > > > > since these are > > > > not > > > > > > used in the diagram. > > > > Fixed, but replaced by "entity" which is a problem. See #3. > > > > Response: > > > > See #1. > > > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 18 11:50:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLgY-0004cw-1V; Mon, 18 Dec 2006 11:49:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLgW-0004cr-1M for syslog@ietf.org; Mon, 18 Dec 2006 11:49:52 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwLgQ-0007xR-16 for syslog@ietf.org; Mon, 18 Dec 2006 11:49:52 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JAH005DG9GU7H@usaga01-in.huawei.com> for syslog@ietf.org; Mon, 18 Dec 2006 08:22:06 -0800 (PST) Received: from Harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net [24.128.104.207]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JAH00AX29GMXR@usaga01-in.huawei.com> for syslog@ietf.org; Mon, 18 Dec 2006 08:22:06 -0800 (PST) Date: Mon, 18 Dec 2006 11:18:56 -0500 From: David Harrington In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA1F8906@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' , 'Chris Lonvick' , 'Miao Fuyou' , syslog@ietf.org Message-id: <176d01c722c0$3899feb0$0600a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccitIBOw1Hl0TJVTWKeOPHj3STThQAB3Hew X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Syslog] RE: Framing... X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The chairs believe there is consensus, and will ask Miao to change the -tls- document to say that FRAME-LEN is the count of the octets of the SYSLOG-MSG. dbh > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Monday, December 18, 2006 9:55 AM > To: Chris Lonvick; David Harrington; Miao Fuyou > Subject: Framing... > > Hi all, > > I just wonder if we have reached consensus to change the octet counter > to just cover the SYSLOG-MSG len. I have to admit that I am > hesitant to > release the open source software with the "wrong" framing. I know that > it is not appropriate to claim anything of an implementation > of a draft, > but as it looks we have consensus, I'd like to release what will most > probable become reality. Of course, I'll include big > disclaimers on that > functionality. But on the other hand, I would really like to get some > feedback from practice. I am also preparing a document that describes > why I have implemented the framing and why it is a big advantage over > traditional syslog/tcp. > > If we have a consensus, could we declare it? > > Rainer > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 18 11:58:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLoz-0000m0-8S; Mon, 18 Dec 2006 11:58:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLoy-0000lv-Nq for syslog@ietf.org; Mon, 18 Dec 2006 11:58:36 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwLot-00017t-Bw for syslog@ietf.org; Mon, 18 Dec 2006 11:58:36 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 72B9E56065; Mon, 18 Dec 2006 17:58:28 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31141-06; Mon, 18 Dec 2006 17:58:25 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 5A77755E92; Mon, 18 Dec 2006 17:58:25 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id BD6AD8FE135; Mon, 18 Dec 2006 17:58:22 +0100 (CET) Date: Mon, 18 Dec 2006 17:58:22 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Syslog] RE: Framing... Message-ID: <20061218165822.GA11624@boskop.local> Mail-Followup-To: David Harrington , 'Rainer Gerhards' , 'Chris Lonvick' , 'Miao Fuyou' , syslog@ietf.org References: <577465F99B41C842AAFBE9ED71E70ABA1F8906@grfint2.intern.adiscon.com> <176d01c722c0$3899feb0$0600a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <176d01c722c0$3899feb0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Mon, Dec 18, 2006 at 11:18:56AM -0500, David Harrington wrote: > The chairs believe there is consensus, and will ask Miao to change the > -tls- document to say that FRAME-LEN is the count of the octets of the > SYSLOG-MSG. Perhaps also consider to change FRAME-LEN to MSG-LEN to better reflect the purpose of the value. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 18 13:20:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwN5c-0001KY-4k; Mon, 18 Dec 2006 13:19:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwN5b-0001KG-0F for syslog@ietf.org; Mon, 18 Dec 2006 13:19:51 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwN5Z-0005Hz-LH for syslog@ietf.org; Mon, 18 Dec 2006 13:19:50 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 18 Dec 2006 10:19:49 -0800 X-IronPort-AV: i="4.12,185,1165219200"; d="scan'208"; a="451884307:sNHT46031736" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kBIIJnLH013268 for ; Mon, 18 Dec 2006 10:19:49 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kBIIJmjT013478 for ; Mon, 18 Dec 2006 10:19:48 -0800 (PST) Date: Mon, 18 Dec 2006 10:19:48 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3847; t=1166465989; x=1167329989; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20clonvick=20WGLC=20Review=20of=20draft-ietf-syslog-sign-20.txt |Sender:=20; bh=4IvjWwfv8D+kmfORevdqyr/qSBAk5ZXjw1Zo35cS7AA=; b=ARkvRakPOdrAnjnRuOGGMdWQY2mLSSk3gXg5aKQeDqLdZUJBGU5faWFNuzlovISMoozmPXNh I1N+QGsla4XaEEJa2I/eFnyigAuy+cF4X1YwKgTSM1qrgqu5glb4t4MV; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, In the following, [14] is syslog-protocol [15] is syslog-transport-udp [16] is syslog-transport-tls === Last paragraph in the Introduction This specification is independent of the actual transport protocol selected. The mechanism is especially suitable for use with the syslog protocol as defined in RFC xxxx [14] because it utilizes the STRUCTURED-DATA elements defined in that document. It may also be used with syslog packets over traditional UDP [4] as described in RFC 3164 [10]. It may also be used with the Reliable Delivery of syslog as described in RFC 3195 [11], and it may be used with other message delivery mechanisms. Designers of other efforts to define event notification mechanisms are encouraged to consider this specification in their design. Would it be better to RECOMMEND this mechanism be used with [14]? That would be consistent with the RECOMMENDation in Section 3. === Fourth paragraph in Section 3: When used in conjunction with RFC xxxx [14], the syslog messages defined in this document carry the signature and certificate data as STRUCTURED DATA, as defined, while the MSG part of the syslog messages is simply empty - the contents of the messages is not intended for interpretation by humans but by applications that use those messages to build an authenticated log. Would it be better to state that the MSG part of the message MUST be empty? It's suggested here but not explicitly stated. === >From Section 4.1 A Signature Block message that is compliant with RFC xxxx [14] MUST contain valid APP-NAME, PROCID, and MSGID fields. Specifically, as value for APP-NAME, "syslog" (without the double quotes) MUST be used. As value for MSG-ID, "sig" (without the double quotes) MUST be used. As value for the PRI field, 110 MUST be used, corresponding to facility 13 and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. Perhaps restructure that as: A Signature Block message that is compliant with RFC xxxx [14] MUST contain valid APP-NAME, PROCID, and MSGID fields. Specifically, the value for APP-NAME MUST be "syslog" (without the double quotes). The value for MSG-ID MUST be "sig" (without the double quotes). The value for the PRI field MSUT be 110, corresponding to facility 13 and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. Similar in Section 5.3.1. === Section 4.2.7 gives the definition of the syslog message that needs to be hashed: starting with the < of the PRI portion of the header part of the message and ending with the Unicode byte order mask, BOM. That needs to be changed as the BOM is not the end of the message. === The count for ssign is a maximum of 2-bytes and is a value of between 1 and 99. This will likely fit into a message with a length of 2048 octets as stated in Section 4.2.7 if the hashes are 160-bytes. Is this acceptable to the group? We started this with the idea that this mechanism would be run atop RFC 3164 with a maximum length of 1024 octets. However, would a greater efficiency be gained by increasing the length of the syslog-sign message and the length of the Count? === The word "monotonically increasing" is used in a few places. I think that we're actually trying to say "sequentially increasing". === The SD-ID values in Section 9 (IANA Considerations) need to be in tables so that the IANA can cut-n-paste. === Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 18 16:15:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPpX-0007tv-AD; Mon, 18 Dec 2006 16:15:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPpW-0007tG-KV for syslog@ietf.org; Mon, 18 Dec 2006 16:15:26 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwPpO-0001mg-SB for syslog@ietf.org; Mon, 18 Dec 2006 16:15:26 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 5865427C015; Mon, 18 Dec 2006 22:18:01 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10108-08; Mon, 18 Dec 2006 22:18:01 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id EE6BB27C013; Mon, 18 Dec 2006 22:18:00 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 22:15:13 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 18 Dec 2006 22:15:10 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8912@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Thread-Index: Acci0TRTrR9YeWNMRFKtzbN9foAdtQAFnzKg From: "Rainer Gerhards" To: "Chris Lonvick" , X-OriginalArrivalTime: 18 Dec 2006 21:15:13.0667 (UTC) FILETIME=[9B9A8D30:01C722E9] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, So far, I have not been able to do a full review. But this triggers my attention immediately...=20 > Perhaps restructure that as: >=20 > A Signature Block message that is compliant with RFC xxxx=20 > [14] MUST > contain valid APP-NAME, PROCID, and MSGID fields. =20 > Specifically, the > value for APP-NAME MUST be "syslog" (without the double quotes). > The value for MSG-ID MUST be "sig" (without the double=20 > quotes). The > value for the PRI field MSUT be 110, corresponding to facility 13 > and severity 6 (informational). The Signature Block is carried as > Structured Data within the Signature Block message, per the > definitions that follow in the next section. >=20 > Similar in Section 5.3.1. Syslog-protocol does not reserve any specific values for APP-NAME, PROCID and MSGID. So (at least theoretically), another implementor migth use the suggested values for any other case. As an implementor, I would probably like to consistenly use the same APP-NAME. For example, all messages in rsyslog will be logged as "rsyslogd". I have just quickly read the IANA section (9.1): there is no such registry like "APP-NAME". It might eventually be a good idea to create one, but I am not sure if it is worth the trouble. In any case, I think that must be spelled out in -protocol (else I can implement somthing compliant to -protocol but not -sign). Same goes for MSGID. My recommendation (without a full read of the document...) is to remove any dependencies on APP-NAME, PROCID and MSGID and use structured data fields for them. Otherwise, I foresee that I need a lot of hardcoded exception inside a syslog implementation to "mangle" this fields so that the happen to be right for -sign while they are invalid from the overall application point of view. -- Version field: I recommend renaming it to something like "Sig-Version" to avoid mistaking -protocol VERSION and -sign Version. -- I hope I will be able to do a full review by the end of the week. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 18 20:00:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwTKw-0002n7-8n; Mon, 18 Dec 2006 20:00:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwTKv-0002mz-OP for syslog@ietf.org; Mon, 18 Dec 2006 20:00:05 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwTKr-0005Jg-51 for syslog@ietf.org; Mon, 18 Dec 2006 20:00:05 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JAH005M5XEQCL@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 19 Dec 2006 08:59:14 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JAH00GFMXEQPT@szxga01-in.huawei.com> for syslog@ietf.org; Tue, 19 Dec 2006 08:59:14 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JAH006O5XEMWM@szxml03-in.huawei.com> for syslog@ietf.org; Tue, 19 Dec 2006 08:59:14 +0800 (CST) Date: Tue, 19 Dec 2006 08:59:09 +0800 From: Miao Fuyou Subject: RE: [Syslog] RE: Framing... In-reply-to: <20061218165822.GA11624@boskop.local> To: j.schoenwaelder@iu-bremen.de, 'David Harrington' Message-id: <01ab01c72308$e45f7480$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AccixcFI6EVBABDCSzia49zvZMzo2AAQwO8w X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Yes, exactly. Thanks, Miao > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, December 19, 2006 12:58 AM > To: David Harrington > Cc: 'Rainer Gerhards'; 'Chris Lonvick'; 'Miao Fuyou'; syslog@ietf.org > Subject: Re: [Syslog] RE: Framing... > > On Mon, Dec 18, 2006 at 11:18:56AM -0500, David Harrington wrote: > > > The chairs believe there is consensus, and will ask Miao to > change the > > -tls- document to say that FRAME-LEN is the count of the > octets of the > > SYSLOG-MSG. > > Perhaps also consider to change FRAME-LEN to MSG-LEN to > better reflect the purpose of the value. > > /js > > -- > Juergen Schoenwaelder {International|Jacobs} > University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Dec 19 16:18:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmLm-0004mp-4M; Tue, 19 Dec 2006 16:18:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmLl-0004ma-Ed for syslog@ietf.org; Tue, 19 Dec 2006 16:18:13 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwmLj-0005xz-3c for syslog@ietf.org; Tue, 19 Dec 2006 16:18:13 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 19 Dec 2006 13:18:10 -0800 X-IronPort-AV: i="4.12,188,1165219200"; d="scan'208"; a="452256912:sNHT46187544" 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 kBJLIAwa007762; Tue, 19 Dec 2006 13:18:10 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kBJLI9jT027453; Tue, 19 Dec 2006 13:18:10 -0800 (PST) Date: Tue, 19 Dec 2006 13:18:09 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8912@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA1F8912@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2955; t=1166563090; x=1167427090; 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]=20clonvick=20WGLC=20Review=20of=20draft-ietf -syslog-sign-20.txt |Sender:=20; bh=9xvcZke8QMfSQ55Xx22WPxf9u3qu/lLyQ9Sae6h1HCg=; b=mJHhDmoy32foizCQpsy8wU4Gu8ZzS07y4LXV3gbRSFZebw/Nc82Sj23USPHHVG5PonUce+WI o/OfQnVkn/PBAaLGVvj08ym18fAKtIFNz890QIdlZnU8yi3llK6hhu+O; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, On Mon, 18 Dec 2006, Rainer Gerhards wrote: > Hi, > > So far, I have not been able to do a full review. But this triggers my > attention immediately... > >> Perhaps restructure that as: >> >> A Signature Block message that is compliant with RFC xxxx >> [14] MUST >> contain valid APP-NAME, PROCID, and MSGID fields. >> Specifically, the >> value for APP-NAME MUST be "syslog" (without the double quotes). >> The value for MSG-ID MUST be "sig" (without the double >> quotes). The >> value for the PRI field MSUT be 110, corresponding to facility 13 >> and severity 6 (informational). The Signature Block is carried as >> Structured Data within the Signature Block message, per the >> definitions that follow in the next section. >> >> Similar in Section 5.3.1. > > Syslog-protocol does not reserve any specific values for APP-NAME, > PROCID and MSGID. So (at least theoretically), another implementor migth > use the suggested values for any other case. > > As an implementor, I would probably like to consistenly use the same > APP-NAME. For example, all messages in rsyslog will be logged as > "rsyslogd". > > I have just quickly read the IANA section (9.1): there is no such > registry like "APP-NAME". It might eventually be a good idea to create > one, but I am not sure if it is worth the trouble. In any case, I think > that must be spelled out in -protocol (else I can implement somthing > compliant to -protocol but not -sign). Same goes for MSGID. > > My recommendation (without a full read of the document...) is to remove > any dependencies on APP-NAME, PROCID and MSGID and use structured data > fields for them. Otherwise, I foresee that I need a lot of hardcoded > exception inside a syslog implementation to "mangle" this fields so that > the happen to be right for -sign while they are invalid from the overall > application point of view. We're going to have "ssign" and "ssign-cert" as the SD-IDs used for syslog-sign. I don't think that there are any dependencies on APP-NAME, PROCID and MSGID for the proper working of syslog-sign; they're just there to make sure that these messages are placed consistently into the right bins. The "ssign" and "ssign-cert" SD-IDs will be reserved for this. > > -- > > Version field: I recommend renaming it to something like "Sig-Version" > to avoid mistaking -protocol VERSION and -sign Version. There are actually two "Version" fields. The first is an SD-Param called "VER" in the SD-ID of ssign. The second is an SD-Param, also called "VER", in ssign-cert. This type of duplication is acceptable in the rules of syslog-protocol. I can't think of any way that it could be confused with the version number in the header of the syslog message. > > -- > > I hope I will be able to do a full review by the end of the week. Looking forward to it. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Dec 19 16:36:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwmdi-0003Bj-Qt; Tue, 19 Dec 2006 16:36:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwmdh-0003Be-Vo for syslog@ietf.org; Tue, 19 Dec 2006 16:36:45 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwmdg-0001Rl-Hy for syslog@ietf.org; Tue, 19 Dec 2006 16:36:45 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 8E45327C015; Tue, 19 Dec 2006 22:39:23 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19048-01; Tue, 19 Dec 2006 22:39:23 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 3FBF927C013; Tue, 19 Dec 2006 22:39:23 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 22:36:40 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt 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, 19 Dec 2006 22:35:56 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8935@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Thread-Index: AccjszhtlVkFiQsjRfCCBPNpOEadegAAYB4g From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 19 Dec 2006 21:36:40.0682 (UTC) FILETIME=[C52334A0:01C723B5] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris, > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Tuesday, December 19, 2006 10:18 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] clonvick WGLC Review of=20 > draft-ietf-syslog-sign-20.txt >=20 > Hi Rainer, >=20 > On Mon, 18 Dec 2006, Rainer Gerhards wrote: >=20 > > Hi, > > > > So far, I have not been able to do a full review. But this=20 > triggers my > > attention immediately... > > > >> Perhaps restructure that as: > >> > >> A Signature Block message that is compliant with RFC xxxx > >> [14] MUST > >> contain valid APP-NAME, PROCID, and MSGID fields. > >> Specifically, the > >> value for APP-NAME MUST be "syslog" (without the=20 > double quotes). > >> The value for MSG-ID MUST be "sig" (without the double > >> quotes). The > >> value for the PRI field MSUT be 110, corresponding to=20 > facility 13 > >> and severity 6 (informational). The Signature Block=20 > is carried as > >> Structured Data within the Signature Block message, per the > >> definitions that follow in the next section. > >> > >> Similar in Section 5.3.1. > > > > Syslog-protocol does not reserve any specific values for APP-NAME, > > PROCID and MSGID. So (at least theoretically), another=20 > implementor migth > > use the suggested values for any other case. > > > > As an implementor, I would probably like to consistenly use the same > > APP-NAME. For example, all messages in rsyslog will be logged as > > "rsyslogd". > > > > I have just quickly read the IANA section (9.1): there is no such > > registry like "APP-NAME". It might eventually be a good=20 > idea to create > > one, but I am not sure if it is worth the trouble. In any=20 > case, I think > > that must be spelled out in -protocol (else I can implement somthing > > compliant to -protocol but not -sign). Same goes for MSGID. > > > > My recommendation (without a full read of the document...)=20 > is to remove > > any dependencies on APP-NAME, PROCID and MSGID and use=20 > structured data > > fields for them. Otherwise, I foresee that I need a lot of hardcoded > > exception inside a syslog implementation to "mangle" this=20 > fields so that > > the happen to be right for -sign while they are invalid=20 > from the overall > > application point of view. >=20 > We're going to have "ssign" and "ssign-cert" as the SD-IDs used for=20 > syslog-sign. I don't think that there are any dependencies=20 > on APP-NAME,=20 > PROCID and MSGID for the proper working of syslog-sign;=20 >From the quoted text above: >> value for ####APP-NAME MUST be "syslog"#### (without the double quotes). >> The value for ####MSG-ID MUST be "sig"#### (without the double If APP-NAME and MSG-ID *MUST* contain something specific, I think there is a strong dependency. > they're just there=20 > to make sure that these messages are placed consistently into=20 > the right=20 > bins. The "ssign" and "ssign-cert" SD-IDs will be reserved for this. I do not see how this addresses the concerns I mentioned above. I can not implement it without interfering with my application design in a way that I do not find justified. How does mandating a specific APP-NAME and MSG-ID make sure that they are put into the right bins? Many stock syslogds can not even filter on these fields... Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 20 09:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2Yx-0008W6-4O; Wed, 20 Dec 2006 09:36:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2Yv-0008Qz-Pp for syslog@ietf.org; Wed, 20 Dec 2006 09:36:53 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx2Yt-00048g-BG for syslog@ietf.org; Wed, 20 Dec 2006 09:36:53 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 20 Dec 2006 06:36:50 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kBKEaoEM016051; Wed, 20 Dec 2006 06:36:50 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kBKEanA5021806; Wed, 20 Dec 2006 06:36:50 -0800 (PST) Date: Wed, 20 Dec 2006 06:36:49 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8935@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA1F8935@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4581; t=1166625410; x=1167489410; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20APP-NAME, =20PROCID=20and=20MSGID=20in=20syslog=20sign=20-=20w as=3A=20RE=3A=20[Syslog]=20clonvick=0A=20WGLC=20Review=20of=20draft-ietf-s yslog-sign-20.txt |Sender:=20; bh=GE7ZrIQnwRdXDRpXd7az4QPs6CmKCYBbZw6RiZ6eb2M=; b=CNrcbAkintNorur+VxTD2h6X+DdSV+oLYX1MhFKd2Xlc0XFFHJJqItowqobgTjz6zxg7oHi1 fUtjGEMSRLfbLHefa0h2bbRfTans4NZ18dkwCAuDEYH/SF7SRvMyGs5U; Authentication-Results: sj-dkim-8; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, Ahh.. I see your point now. (Sorry - being a little slow this week.) All: I'm tending to agree with Rainer's point that no value should be specified for APP-NAME. Does anyone think that the document should suggest something for fixed-function devices such as printers which might not have a syslogd? Currently syslog-protocol allows a NILVALUE if nothing better can be used. Similarly, PROCID may be NIVALUE in syslog-protocol if the device cannot produce it. I'm OK with that for syslog-sign as well. Finally, I'd still like to keep "sig" for the MSGID. This should allow for parsers (automated and manual searches) to find syslog-sign messages quickly. This won't be the only mechanism to identify a syslog-sign message. I believe that a syslog-sign message would have to: - be sent to PRI = 110 - have MSGID = "sig" - contain an SD-ID with the SD-PARAM of "ssign" or "ssign-cert" I don't think that we need a registry of MSGIDs for this. If anyone has issues with any of this, please speak up now. I'd like to get this settled so we can update and send this to the IESG when the WGLC ends. Thanks, Chis On Tue, 19 Dec 2006, Rainer Gerhards wrote: > Chris, > >> -----Original Message----- >> From: Chris Lonvick [mailto:clonvick@cisco.com] >> Sent: Tuesday, December 19, 2006 10:18 PM >> To: Rainer Gerhards >> Cc: syslog@ietf.org >> Subject: RE: [Syslog] clonvick WGLC Review of >> draft-ietf-syslog-sign-20.txt >> >> Hi Rainer, >> >> On Mon, 18 Dec 2006, Rainer Gerhards wrote: >> >>> Hi, >>> >>> So far, I have not been able to do a full review. But this >> triggers my >>> attention immediately... >>> >>>> Perhaps restructure that as: >>>> >>>> A Signature Block message that is compliant with RFC xxxx >>>> [14] MUST >>>> contain valid APP-NAME, PROCID, and MSGID fields. >>>> Specifically, the >>>> value for APP-NAME MUST be "syslog" (without the >> double quotes). >>>> The value for MSG-ID MUST be "sig" (without the double >>>> quotes). The >>>> value for the PRI field MSUT be 110, corresponding to >> facility 13 >>>> and severity 6 (informational). The Signature Block >> is carried as >>>> Structured Data within the Signature Block message, per the >>>> definitions that follow in the next section. >>>> >>>> Similar in Section 5.3.1. >>> >>> Syslog-protocol does not reserve any specific values for APP-NAME, >>> PROCID and MSGID. So (at least theoretically), another >> implementor migth >>> use the suggested values for any other case. >>> >>> As an implementor, I would probably like to consistenly use the same >>> APP-NAME. For example, all messages in rsyslog will be logged as >>> "rsyslogd". >>> >>> I have just quickly read the IANA section (9.1): there is no such >>> registry like "APP-NAME". It might eventually be a good >> idea to create >>> one, but I am not sure if it is worth the trouble. In any >> case, I think >>> that must be spelled out in -protocol (else I can implement somthing >>> compliant to -protocol but not -sign). Same goes for MSGID. >>> >>> My recommendation (without a full read of the document...) >> is to remove >>> any dependencies on APP-NAME, PROCID and MSGID and use >> structured data >>> fields for them. Otherwise, I foresee that I need a lot of hardcoded >>> exception inside a syslog implementation to "mangle" this >> fields so that >>> the happen to be right for -sign while they are invalid >> from the overall >>> application point of view. >> >> We're going to have "ssign" and "ssign-cert" as the SD-IDs used for >> syslog-sign. I don't think that there are any dependencies >> on APP-NAME, >> PROCID and MSGID for the proper working of syslog-sign; > > From the quoted text above: > >>> value for ####APP-NAME MUST be "syslog"#### (without the double > quotes). >>> The value for ####MSG-ID MUST be "sig"#### (without the double > > If APP-NAME and MSG-ID *MUST* contain something specific, I think there > is a strong dependency. > >> they're just there >> to make sure that these messages are placed consistently into >> the right >> bins. The "ssign" and "ssign-cert" SD-IDs will be reserved for this. > > I do not see how this addresses the concerns I mentioned above. I can > not implement it without interfering with my application design in a way > that I do not find justified. How does mandating a specific APP-NAME and > MSG-ID make sure that they are put into the right bins? Many stock > syslogds can not even filter on these fields... > > Rainer > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 20 09:51:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2n7-00084r-Mg; Wed, 20 Dec 2006 09:51:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2n6-00084m-Sd for syslog@ietf.org; Wed, 20 Dec 2006 09:51:32 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx2n4-0007AH-8X for syslog@ietf.org; Wed, 20 Dec 2006 09:51:32 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 20EC127C016; Wed, 20 Dec 2006 15:54:09 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16332-03; Wed, 20 Dec 2006 15:54:09 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id B5EEC27C013; Wed, 20 Dec 2006 15:54:08 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 15:51:28 +0100 Content-class: urn:content-classes:message Subject: RE: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Dec 2006 15:51:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8947@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Thread-Index: AcckRE9DxA8Eg+S7QIimXvtc41pWDgAAO7YA References: <577465F99B41C842AAFBE9ED71E70ABA1F8935@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 20 Dec 2006 14:51:28.0262 (UTC) FILETIME=[54381260:01C72446] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris, > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Wednesday, December 20, 2006 3:37 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] > clonvick WGLC Review of draft-ietf-syslog-sign-20.txt >=20 > Hi Rainer, >=20 > Ahh.. I see your point now. (Sorry - being a little slow this week.) >=20 > All: I'm tending to agree with Rainer's point that no value should be > specified for APP-NAME. Does anyone think that the document should > suggest something for fixed-function devices such as printers which > might > not have a syslogd? Currently syslog-protocol allows a NILVALUE if > nothing better can be used. I think they should use whatever the use with other messages. For example, they might use "router". Sure, this is not intelligent. But my point is that this should not be of concern for syslog-sign. >=20 > Similarly, PROCID may be NIVALUE in syslog-protocol if the device > cannot > produce it. I'm OK with that for syslog-sign as well. >=20 > Finally, I'd still like to keep "sig" for the MSGID. This should allow > for parsers (automated and manual searches) to find syslog-sign > messages > quickly. =20 I do not object it, as long as we caution implementors that a MSGID of "sig" does not necessarily indicate this is a syslog-sign message. We can not guarantee that, because we did not reserve any message ids at all. So it may be a clue, but it is nothing to rely on. Which brings me to the point: what is the advantage of an unreliable indicator? >This won't be the only mechanism to identify a syslog-sign > message. I believe that a syslog-sign message would have to: > - be sent to PRI =3D 110 > - have MSGID =3D "sig" > - contain an SD-ID with the SD-PARAM of "ssign" or "ssign-cert" > I don't think that we need a registry of MSGIDs for this. For me, the SD-ID is the only valid indicator that this is a syslog-sign message. We can not rely on PRI as operators like to reconfigure PRI. Even if we mandate a fixed PRI in the specification, real-world implementations will ignore that requirement and still allow the operator to override it (and this for a good reason). On the other hand, SD-IDs *are* under IANA control and the absolutely positively identify the element that they are contained in. This is what we designed them for. So why not use them for their design purpose? With RFC 3164 syslog, we obviously can not totally be assured that the SD-ID will be valid. But we should keep in mind that we most probably will try to obsolete 3164 either via -protocol or a follow-up RFC. I already questioned the point in supporting this (informational!) document in a new standard. Is this really a wise idea? Rainer >=20 > If anyone has issues with any of this, please speak up now. I'd like > to > get this settled so we can update and send this to the IESG when the > WGLC > ends. >=20 > Thanks, > Chis >=20 >=20 > On Tue, 19 Dec 2006, Rainer Gerhards wrote: >=20 > > Chris, > > > >> -----Original Message----- > >> From: Chris Lonvick [mailto:clonvick@cisco.com] > >> Sent: Tuesday, December 19, 2006 10:18 PM > >> To: Rainer Gerhards > >> Cc: syslog@ietf.org > >> Subject: RE: [Syslog] clonvick WGLC Review of > >> draft-ietf-syslog-sign-20.txt > >> > >> Hi Rainer, > >> > >> On Mon, 18 Dec 2006, Rainer Gerhards wrote: > >> > >>> Hi, > >>> > >>> So far, I have not been able to do a full review. But this > >> triggers my > >>> attention immediately... > >>> > >>>> Perhaps restructure that as: > >>>> > >>>> A Signature Block message that is compliant with RFC xxxx > >>>> [14] MUST > >>>> contain valid APP-NAME, PROCID, and MSGID fields. > >>>> Specifically, the > >>>> value for APP-NAME MUST be "syslog" (without the > >> double quotes). > >>>> The value for MSG-ID MUST be "sig" (without the double > >>>> quotes). The > >>>> value for the PRI field MSUT be 110, corresponding to > >> facility 13 > >>>> and severity 6 (informational). The Signature Block > >> is carried as > >>>> Structured Data within the Signature Block message, per the > >>>> definitions that follow in the next section. > >>>> > >>>> Similar in Section 5.3.1. > >>> > >>> Syslog-protocol does not reserve any specific values for APP-NAME, > >>> PROCID and MSGID. So (at least theoretically), another > >> implementor migth > >>> use the suggested values for any other case. > >>> > >>> As an implementor, I would probably like to consistenly use the > same > >>> APP-NAME. For example, all messages in rsyslog will be logged as > >>> "rsyslogd". > >>> > >>> I have just quickly read the IANA section (9.1): there is no such > >>> registry like "APP-NAME". It might eventually be a good > >> idea to create > >>> one, but I am not sure if it is worth the trouble. In any > >> case, I think > >>> that must be spelled out in -protocol (else I can implement > somthing > >>> compliant to -protocol but not -sign). Same goes for MSGID. > >>> > >>> My recommendation (without a full read of the document...) > >> is to remove > >>> any dependencies on APP-NAME, PROCID and MSGID and use > >> structured data > >>> fields for them. Otherwise, I foresee that I need a lot of > hardcoded > >>> exception inside a syslog implementation to "mangle" this > >> fields so that > >>> the happen to be right for -sign while they are invalid > >> from the overall > >>> application point of view. > >> > >> We're going to have "ssign" and "ssign-cert" as the SD-IDs used for > >> syslog-sign. I don't think that there are any dependencies > >> on APP-NAME, > >> PROCID and MSGID for the proper working of syslog-sign; > > > > From the quoted text above: > > > >>> value for ####APP-NAME MUST be "syslog"#### (without the double > > quotes). > >>> The value for ####MSG-ID MUST be "sig"#### (without the double > > > > If APP-NAME and MSG-ID *MUST* contain something specific, I think > there > > is a strong dependency. > > > >> they're just there > >> to make sure that these messages are placed consistently into > >> the right > >> bins. The "ssign" and "ssign-cert" SD-IDs will be reserved for > this. > > > > I do not see how this addresses the concerns I mentioned above. I can > > not implement it without interfering with my application design in a > way > > that I do not find justified. How does mandating a specific APP-NAME > and > > MSG-ID make sure that they are put into the right bins? Many stock > > syslogds can not even filter on these fields... > > > > Rainer > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 20 21:20:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxDXP-0006Z1-0z; Wed, 20 Dec 2006 21:20:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxDXN-0006Yw-I3 for syslog@ietf.org; Wed, 20 Dec 2006 21:20:01 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxDXM-0000gx-8X for syslog@ietf.org; Wed, 20 Dec 2006 21:20:01 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 20 Dec 2006 18:19:57 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kBL2JvgV001158 for ; Wed, 20 Dec 2006 18:19:57 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBL2JvSU006789 for ; Wed, 20 Dec 2006 18:19:57 -0800 (PST) Date: Wed, 20 Dec 2006 18:19:57 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1610; t=1166667597; x=1167531597; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20RFC=203164=20in=20syslog-sign? |Sender:=20; bh=9+QjICo4OnxehZaqpijDGnc2zQ/st5ZF47NRB0FCvSU=; b=gYDaX2E10wJyRNo7BqQZEU8W/YVZnROJfmmfj2tWwOYBguRx5Vpc3Gg4IMD/LBv2kr3j5Luo wGFbo5zifscI0qgcy6JyLdbQALgkZBKLvJKkspG/ZQexaAgkCFnSOML3; Authentication-Results: sj-dkim-5; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Syslog] RFC 3164 in syslog-sign? X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, We started syslog-sign before we had Structured Data, and the original author was creating a mechanism that could be used within the RFC 3164 framework. However, times have changed. We now have syslog-protocol with SDs. Does the WG feel that syslog-sign should contain normative information on how to utilize the syslog-sign mechanism in the RFC 3164 format? Answers can be: __ Yes - leave it, it forms a bridge for transition, __ No - take it out, we need to move the world along, __ Maybe - move it to a non-normative appendix Thanks, Chris ---------- Forwarded message ---------- Date: Wed, 20 Dec 2006 15:51:25 +0100 From: Rainer Gerhards To: Chris Lonvick Cc: syslog@ietf.org Subject: RE: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Chris, > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Wednesday, December 20, 2006 3:37 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] > clonvick WGLC Review of draft-ietf-syslog-sign-20.txt ---some elided for brevity--- With RFC 3164 syslog, we obviously can not totally be assured that the SD-ID will be valid. But we should keep in mind that we most probably will try to obsolete 3164 either via -protocol or a follow-up RFC. I already questioned the point in supporting this (informational!) document in a new standard. Is this really a wise idea? Rainer ---remainder elided for brevity--- _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 20 22:51:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxExY-000185-GH; Wed, 20 Dec 2006 22:51:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxExX-00017v-5z for syslog@ietf.org; Wed, 20 Dec 2006 22:51:07 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxExU-0004f9-GZ for syslog@ietf.org; Wed, 20 Dec 2006 22:51:07 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JAL00LBBUKEFH@szxga01-in.huawei.com> for syslog@ietf.org; Thu, 21 Dec 2006 11:48:14 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JAL00CQXUKD6S@szxga01-in.huawei.com> for syslog@ietf.org; Thu, 21 Dec 2006 11:48:13 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JAL00NIDUK907@szxml04-in.huawei.com> for syslog@ietf.org; Thu, 21 Dec 2006 11:48:13 +0800 (CST) Date: Thu, 21 Dec 2006 11:48:09 +0800 From: Miao Fuyou Subject: RE: [Syslog] RFC 3164 in syslog-sign? In-reply-to: To: 'Chris Lonvick' , syslog@ietf.org Message-id: <011501c724b2$d513c610$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acckp2QMT5UX3dqrTmydt/oqhJHYDQACdjKA X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Option 2 may be a better choice for a cohesive set of Syslog specifications. And, a seperated informational document can be included as work item when rechartering to address the 3164 signature issue. Is it possible? The drawback is the implementer has to do something different for -protocol and 3164. Thanks, Miao > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Thursday, December 21, 2006 10:20 AM > To: syslog@ietf.org > Subject: [Syslog] RFC 3164 in syslog-sign? > > Hi, > > We started syslog-sign before we had Structured Data, and the > original author was creating a mechanism that could be used > within the RFC 3164 framework. However, times have changed. > We now have syslog-protocol with SDs. > > Does the WG feel that syslog-sign should contain normative > information on how to utilize the syslog-sign mechanism in > the RFC 3164 format? > > Answers can be: > __ Yes - leave it, it forms a bridge for transition, __ No - > take it out, we need to move the world along, __ Maybe - move > it to a non-normative appendix > > Thanks, > Chris > > > > ---------- Forwarded message ---------- > Date: Wed, 20 Dec 2006 15:51:25 +0100 > From: Rainer Gerhards > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: RE: APP-NAME, > PROCID and MSGID in syslog sign - was: RE: [Syslog] > clonvick WGLC Review of > draft-ietf-syslog-sign-20.txt > > Chris, > > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Wednesday, December 20, 2006 3:37 PM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: APP-NAME, PROCID and MSGID in syslog sign - was: > RE: [Syslog] > > clonvick WGLC Review of draft-ietf-syslog-sign-20.txt > > ---some elided for brevity--- > > With RFC 3164 syslog, we obviously can not totally be assured > that the SD-ID will be valid. But we should keep in mind that > we most probably will try to obsolete 3164 either via > -protocol or a follow-up RFC. I already questioned the point > in supporting this (informational!) document in a new > standard. Is this really a wise idea? > > Rainer > ---remainder elided for brevity--- > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 21 02:02:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxHvo-00053g-Rk; Thu, 21 Dec 2006 02:01:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxHvn-00053W-Qs for syslog@ietf.org; Thu, 21 Dec 2006 02:01:31 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxHvm-0001oc-C1 for syslog@ietf.org; Thu, 21 Dec 2006 02:01:31 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 56A2227C016; Thu, 21 Dec 2006 08:04:05 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11085-10; Thu, 21 Dec 2006 08:04:05 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 110A727C013; Thu, 21 Dec 2006 08:04:04 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 08:01:26 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] RFC 3164 in syslog-sign? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 21 Dec 2006 08:01:18 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F894C@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] RFC 3164 in syslog-sign? Thread-Index: AcckprA5QPsh5qP+R8eQRs0aeiUzkgAJr7hg References: From: "Rainer Gerhards" To: "Chris Lonvick" , X-OriginalArrivalTime: 21 Dec 2006 07:01:26.0148 (UTC) FILETIME=[D4DCBC40:01C724CD] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris, I would prefer > __ No - take it out, we need to move the world along, as this removes a lot of complexity and guesswork. It will also be cleaner if rfc3164 is actually obsoleted by -syslog-protocol.=20 If that is not WG consensus, I would recommend > __ Maybe - move it to a non-normative appendix As a formal note, I am not sure if we can create normative text based on a non-normative document (rfc 3164). This sounds kind of wrong to me... Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Thursday, December 21, 2006 3:20 AM > To: syslog@ietf.org > Subject: [Syslog] RFC 3164 in syslog-sign? >=20 > Hi, >=20 > We started syslog-sign before we had Structured Data, and the original > author was creating a mechanism that could be used within the RFC 3164 > framework. However, times have changed. We now have syslog-protocol > with > SDs. >=20 > Does the WG feel that syslog-sign should contain normative information > on > how to utilize the syslog-sign mechanism in the RFC 3164 format? >=20 > Answers can be: > __ Yes - leave it, it forms a bridge for transition, > __ No - take it out, we need to move the world along, > __ Maybe - move it to a non-normative appendix >=20 > Thanks, > Chris >=20 >=20 >=20 > ---------- Forwarded message ---------- > Date: Wed, 20 Dec 2006 15:51:25 +0100 > From: Rainer Gerhards > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: RE: APP-NAME, > PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC > Review of > draft-ietf-syslog-sign-20.txt >=20 > Chris, >=20 > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Wednesday, December 20, 2006 3:37 PM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: > [Syslog] > > clonvick WGLC Review of draft-ietf-syslog-sign-20.txt >=20 > ---some elided for brevity--- >=20 > With RFC 3164 syslog, we obviously can not totally be assured that the > SD-ID will be valid. But we should keep in mind that we most probably > will try to obsolete 3164 either via -protocol or a follow-up RFC. I > already questioned the point in supporting this (informational!) > document in a new standard. Is this really a wise idea? >=20 > Rainer > ---remainder elided for brevity--- >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 21 02:13:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxI6x-00024U-Vf; Thu, 21 Dec 2006 02:13:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxI6x-00024P-7D for syslog@ietf.org; Thu, 21 Dec 2006 02:13:03 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxI6v-00052k-QX for syslog@ietf.org; Thu, 21 Dec 2006 02:13:03 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3694527C018 for ; Thu, 21 Dec 2006 08:15:39 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13802-07 for ; Thu, 21 Dec 2006 08:15:39 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id E6A1A27C013 for ; Thu, 21 Dec 2006 08:15:38 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 08:13:00 +0100 x-cr-puzzleid: {643F9C9D-ECC4-4AE9-9813-63C418A90123} MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Thu, 21 Dec 2006 08:12:35 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F894E@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AKo/ AMau AiLI BSER CJac CbpR C3P7 DD7E F41t Gd7V HSeu H4Uo ITF7 JbxJ Jck7 KYh+; 1; cwB5AHMAbABvAGcAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {643F9C9D-ECC4-4AE9-9813-63C418A90123}; cgBnAGUAcgBoAGEAcgBkAHMAQABoAHEALgBhAGQAaQBzAGMAbwBuAC4AYwBvAG0A; Thu, 21 Dec 2006 07:12:35 GMT; UgBGAEMAIAAzADEANgA0AA== Thread-Topic: RFC 3164 Thread-Index: Acckz2OY3NjOU31zRw6CNYbBI2H1nA== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 21 Dec 2006 07:13:00.0538 (UTC) FILETIME=[72C03DA0:01C724CF] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Syslog] RFC 3164 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi all, I just realized that the future of RFC 3164 is not yet publically discussed. RFC 3164 is a well-done work, but we have made much progress in the past 5 years since it was written. Most importantly, we discovered that actual syslog software uses a much different set of formats than expected by 3164. This was the source of much discussion inside the WG and we did a lot of testing to confirm the findings. The bottom line is that we now know that 3164 does *not* acurately describe what is observed in the wild. Nobody is to blame here - the breadth of information we created the past years was simply not available (nor were the ressources to do the testing) to the orginal authors of RFC 3164. Having said that, I think we must do something about the situation. In practice I see more and more vendors claim compliance to RFC 3164. This is kind of funny in itself, because 3164 is just an information document, so you can not be compliant to it ;) Anyhow, many vendors seem to have a wrong impression and use this in their advertising as well as tech support. I think we should do either one of the following: 1. create an updated RFC 3164bis 2. obsolete RFC 3164 I personally would tend to 1. - update the document with what we have gained on additional knowledge. I have been told that this would be somewhat unusual for the IETF, as 3164 is only informational and -transport-protocol will soon set a real standard. So updating information on "the past" seems not to be useful. However, I expect traditional syslog to stay around for at least another 5 to 10 years, if not longer. I would consider it a plus to have a RFC that accurately describes the format that we can expect from such a legacy syslog sender. Most importantly, it will remove any false secure feeling about format standardization where there is none. I would appreciate comments on this issue. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 21 03:09:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxIys-0006wU-0f; Thu, 21 Dec 2006 03:08:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxIyq-0006wK-5L for syslog@ietf.org; Thu, 21 Dec 2006 03:08:44 -0500 Received: from www.balabit.hu ([212.92.18.33] helo=lists.balabit.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxIyn-0006zX-SE for syslog@ietf.org; Thu, 21 Dec 2006 03:08:44 -0500 Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id 7D3A14C162 for ; Thu, 21 Dec 2006 09:08:34 +0100 (CET) Subject: Re: [Syslog] RFC 3164 in syslog-sign? From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: Content-Type: text/plain Date: Thu, 21 Dec 2006 09:08:23 +0100 Message-Id: <1166688503.5893.2.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Wed, 2006-12-20 at 18:19 -0800, Chris Lonvick wrote: > Hi, > > We started syslog-sign before we had Structured Data, and the original > author was creating a mechanism that could be used within the RFC 3164 > framework. However, times have changed. We now have syslog-protocol with > SDs. > > Does the WG feel that syslog-sign should contain normative information on > how to utilize the syslog-sign mechanism in the RFC 3164 format? > > Answers can be: > __ Yes - leave it, it forms a bridge for transition, > __ No - take it out, we need to move the world along, > __ Maybe - move it to a non-normative appendix No. We should give reasons to migrate to the new protocol, syslog-sign might be one of them, and I doubt there'd be real-world implementations of syslog-sign over RFC3164 -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 21 04:52:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxKaa-0004bq-UZ; Thu, 21 Dec 2006 04:51:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxKaY-0004ba-CK for syslog@ietf.org; Thu, 21 Dec 2006 04:51:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxKaV-0008SC-MQ for syslog@ietf.org; Thu, 21 Dec 2006 04:51:46 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 21 Dec 2006 01:51:43 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBL9phYG020935; Thu, 21 Dec 2006 01:51:43 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBL9pgZg002163; Thu, 21 Dec 2006 01:51:42 -0800 (PST) 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); Thu, 21 Dec 2006 01:51:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLCReview of draft-ietf-syslog-sign-20.txt Date: Thu, 21 Dec 2006 01:51:38 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB02CE905B@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLCReview of draft-ietf-syslog-sign-20.txt Thread-Index: AcckRE9DxA8Eg+S7QIimXvtc41pWDgAAO7YAACcPGTA= From: "Alexander Clemm \(alex\)" To: "Rainer Gerhards" , "Chris Lonvick \(clonvick\)" X-OriginalArrivalTime: 21 Dec 2006 09:51:40.0692 (UTC) FILETIME=[9D347540:01C724E5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9273; t=1166694703; x=1167558703; c=relaxed/simple; s=sjdkim1002; 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=20APP-NAME, PROCID=20and=20MSGID=20in=20syslog=20sign=20 -=20was=3A=20RE=3A=20[Syslog]=20clonvick=20WGLCReview=20of=20draft-ietf-sy slog-sign-20.txt |Sender:=20; bh=tYi3bFwm8hgUPtnsDm/rSWNeJXYdlBNXJ20E5Oh36ds=; b=epH5Xehr4UMR3GJI/s5o1KVLfA9+HrDUiOnZ5pCCdwVcKsWBKWeJ8XZIRkcavrxZHy6iV4VP teoXaAb87Ng6nybCl5rOe+wDVh6rxBEZaGrkQv7v6MGvx5cgtDAgBDmU; Authentication-Results: sj-dkim-1; header.From=alex@cisco.com; dkim=pass (si g from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Chris, Rainer, others from my perspective, I do believe it is important to be able to easily tell apart a syslog-sign message from another message. It is true and I agree with you that SD-ID can be legitimately used for that purpose, although I do consider it a bit of an "overloading" of what it is that SD-ID identifies. I think per se it is fine to do this, but this does mean that syslog-sign should be used only in conjunction with syslog-protocol - this route practically precludes use in conjunction with RFC 3164, because I don't think we should require looking into the message body to distinguish a syslog-sign message. =20 Now (and this goes more to the other message thread), as to whether or not to support RFC 3164, technically there is nothing that would prevent it from being supported in addition to syslog protocol (as it is currently specified) so in a sense it doesn't hurt to specify it that way. Of course, to force migration to syslog protocol is a valid argument to preclude it. On the other hand, I would not be surprised if there are cases who would like to use the ability to sign _without_ having to change the entire protocol in the process - basically, that would like to have the signing capability but that do not want to incur the additional cost of having to switch. I am also thinking of scenarios where you are in essence "bolting on" a separate signing capability outside the actual sender of the syslog messages (which might be a legacy sender doing RFC 3164), that simply injects additional syslog messages into the message stream. =20 If this is not a concern, I am fine to go with the suggestions that were made. In that case, the choice of PRI may not matter either, although if one is chosen, 110 is the one that IMHO makes the most sense. In terms of wording, would we want to leave completely open what implementations choose as APP-NAME and simply leave specification of it out, or still make a suggestion in terms of "SHOULD"? =20 Best regards --- Alex -----Original Message----- From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 Sent: Wednesday, December 20, 2006 6:51 AM To: Chris Lonvick (clonvick) Cc: syslog@ietf.org Subject: RE: APP-NAME,PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLCReview of draft-ietf-syslog-sign-20.txt Chris, > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Wednesday, December 20, 2006 3:37 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] > clonvick WGLC Review of draft-ietf-syslog-sign-20.txt >=20 > Hi Rainer, >=20 > Ahh.. I see your point now. (Sorry - being a little slow this week.) >=20 > All: I'm tending to agree with Rainer's point that no value should be > specified for APP-NAME. Does anyone think that the document should=20 > suggest something for fixed-function devices such as printers which=20 > might not have a syslogd? Currently syslog-protocol allows a NILVALUE > if nothing better can be used. I think they should use whatever the use with other messages. For example, they might use "router". Sure, this is not intelligent. But my point is that this should not be of concern for syslog-sign. >=20 > Similarly, PROCID may be NIVALUE in syslog-protocol if the device=20 > cannot produce it. I'm OK with that for syslog-sign as well. >=20 > Finally, I'd still like to keep "sig" for the MSGID. This should allow > for parsers (automated and manual searches) to find syslog-sign=20 > messages quickly. I do not object it, as long as we caution implementors that a MSGID of "sig" does not necessarily indicate this is a syslog-sign message. We can not guarantee that, because we did not reserve any message ids at all. So it may be a clue, but it is nothing to rely on. Which brings me to the point: what is the advantage of an unreliable indicator? >This won't be the only mechanism to identify a syslog-sign message. I >believe that a syslog-sign message would have to: > - be sent to PRI =3D 110 > - have MSGID =3D "sig" > - contain an SD-ID with the SD-PARAM of "ssign" or "ssign-cert" > I don't think that we need a registry of MSGIDs for this. For me, the SD-ID is the only valid indicator that this is a syslog-sign message. We can not rely on PRI as operators like to reconfigure PRI. Even if we mandate a fixed PRI in the specification, real-world implementations will ignore that requirement and still allow the operator to override it (and this for a good reason). On the other hand, SD-IDs *are* under IANA control and the absolutely positively identify the element that they are contained in. This is what we designed them for. So why not use them for their design purpose? With RFC 3164 syslog, we obviously can not totally be assured that the SD-ID will be valid. But we should keep in mind that we most probably will try to obsolete 3164 either via -protocol or a follow-up RFC. I already questioned the point in supporting this (informational!) document in a new standard. Is this really a wise idea? Rainer >=20 > If anyone has issues with any of this, please speak up now. I'd like=20 > to get this settled so we can update and send this to the IESG when=20 > the WGLC ends. >=20 > Thanks, > Chis >=20 >=20 > On Tue, 19 Dec 2006, Rainer Gerhards wrote: >=20 > > Chris, > > > >> -----Original Message----- > >> From: Chris Lonvick [mailto:clonvick@cisco.com] > >> Sent: Tuesday, December 19, 2006 10:18 PM > >> To: Rainer Gerhards > >> Cc: syslog@ietf.org > >> Subject: RE: [Syslog] clonvick WGLC Review of=20 > >> draft-ietf-syslog-sign-20.txt > >> > >> Hi Rainer, > >> > >> On Mon, 18 Dec 2006, Rainer Gerhards wrote: > >> > >>> Hi, > >>> > >>> So far, I have not been able to do a full review. But this > >> triggers my > >>> attention immediately... > >>> > >>>> Perhaps restructure that as: > >>>> > >>>> A Signature Block message that is compliant with RFC xxxx=20 > >>>> [14] MUST > >>>> contain valid APP-NAME, PROCID, and MSGID fields. > >>>> Specifically, the > >>>> value for APP-NAME MUST be "syslog" (without the > >> double quotes). > >>>> The value for MSG-ID MUST be "sig" (without the double=20 > >>>> quotes). The > >>>> value for the PRI field MSUT be 110, corresponding to > >> facility 13 > >>>> and severity 6 (informational). The Signature Block > >> is carried as > >>>> Structured Data within the Signature Block message, per the > >>>> definitions that follow in the next section. > >>>> > >>>> Similar in Section 5.3.1. > >>> > >>> Syslog-protocol does not reserve any specific values for APP-NAME, > >>> PROCID and MSGID. So (at least theoretically), another > >> implementor migth > >>> use the suggested values for any other case. > >>> > >>> As an implementor, I would probably like to consistenly use the > same > >>> APP-NAME. For example, all messages in rsyslog will be logged as=20 > >>> "rsyslogd". > >>> > >>> I have just quickly read the IANA section (9.1): there is no such=20 > >>> registry like "APP-NAME". It might eventually be a good > >> idea to create > >>> one, but I am not sure if it is worth the trouble. In any > >> case, I think > >>> that must be spelled out in -protocol (else I can implement > somthing > >>> compliant to -protocol but not -sign). Same goes for MSGID. > >>> > >>> My recommendation (without a full read of the document...) > >> is to remove > >>> any dependencies on APP-NAME, PROCID and MSGID and use > >> structured data > >>> fields for them. Otherwise, I foresee that I need a lot of > hardcoded > >>> exception inside a syslog implementation to "mangle" this > >> fields so that > >>> the happen to be right for -sign while they are invalid > >> from the overall > >>> application point of view. > >> > >> We're going to have "ssign" and "ssign-cert" as the SD-IDs used for > >> syslog-sign. I don't think that there are any dependencies on=20 > >> APP-NAME, PROCID and MSGID for the proper working of syslog-sign; > > > > From the quoted text above: > > > >>> value for ####APP-NAME MUST be "syslog"#### (without the double > > quotes). > >>> The value for ####MSG-ID MUST be "sig"#### (without the double > > > > If APP-NAME and MSG-ID *MUST* contain something specific, I think > there > > is a strong dependency. > > > >> they're just there > >> to make sure that these messages are placed consistently into the=20 > >> right bins. The "ssign" and "ssign-cert" SD-IDs will be reserved=20 > >> for > this. > > > > I do not see how this addresses the concerns I mentioned above. I can > > not implement it without interfering with my application design in a > way > > that I do not find justified. How does mandating a specific APP-NAME > and > > MSG-ID make sure that they are put into the right bins? Many stock=20 > > syslogds can not even filter on these fields... > > > > Rainer > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 21 05:22:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxL3x-0003U7-31; Thu, 21 Dec 2006 05:22:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxL3v-0003Tw-PV for syslog@ietf.org; Thu, 21 Dec 2006 05:22:07 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GxL3s-0005GC-PW for syslog@ietf.org; Thu, 21 Dec 2006 05:22:07 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 362C927C013; Thu, 21 Dec 2006 11:24:41 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19745-07; Thu, 21 Dec 2006 11:24:41 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id B025227C012; Thu, 21 Dec 2006 11:24:40 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 11:22:02 +0100 Content-class: urn:content-classes:message Subject: RE: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLCReview of draft-ietf-syslog-sign-20.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Dec 2006 11:21:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8957@grfint2.intern.adiscon.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB02CE905B@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLCReview of draft-ietf-syslog-sign-20.txt Thread-Index: AcckRE9DxA8Eg+S7QIimXvtc41pWDgAAO7YAACcPGTAAAZtQYA== References: <85B2F271FDF6B949B3672BA5A7BB62FB02CE905B@xmb-sjc-236.amer.cisco.com> From: "Rainer Gerhards" To: "Alexander Clemm (alex)" , "Chris Lonvick (clonvick)" X-OriginalArrivalTime: 21 Dec 2006 10:22:02.0667 (UTC) FILETIME=[DB2FC7B0:01C724E9] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Alex, thanks for your well thought-out reply. I am just commenting on one sentence (below), because this is IMHO the key issue... > -----Original Message----- > From: Alexander Clemm (alex) [mailto:alex@cisco.com] > Sent: Thursday, December 21, 2006 10:52 AM > To: Rainer Gerhards; Chris Lonvick (clonvick) > Cc: syslog@ietf.org > Subject: RE: APP-NAME,PROCID and MSGID in syslog sign - was: RE: > [Syslog] clonvick WGLCReview of draft-ietf-syslog-sign-20.txt >=20 > Hi Chris, Rainer, others >=20 > from my perspective, I do believe it is important to be able to easily > tell apart a syslog-sign message from another message. It is true and > I > agree with you that SD-ID can be legitimately used for that purpose, > although I do consider it a bit of an "overloading" of what it is that > SD-ID identifies. I think per se it is fine to do this, but this does > mean that syslog-sign should be used only in conjunction with > syslog-protocol - this route practically precludes use in conjunction > with RFC 3164, because I don't think we should require looking into the > message body to distinguish a syslog-sign message. >=20 > Now (and this goes more to the other message thread), as to whether or > not to support RFC 3164, technically there is nothing that would > prevent > it from being supported in addition to syslog protocol (as it is > currently specified) so in a sense it doesn't hurt to specify it that > way. Of course, to force migration to syslog protocol is a valid > argument to preclude it. On the other hand, I would not be surprised > if > there are cases who would like to use the ability to sign _without_ > having to change the entire protocol in the process - basically, that > would like to have the signing capability but that do not want to incur > the additional cost of having to switch. I am also thinking of > scenarios where you are in essence "bolting on" a separate signing > capability outside the actual sender of the syslog messages (which > might > be a legacy sender doing RFC 3164), that simply injects additional > syslog messages into the message stream. >=20 > If this is not a concern, I am fine to go with the suggestions that > were > made. In that case, the choice of PRI may not matter either, although > if one is chosen, 110 is the one that IMHO makes the most sense. In > terms of wording, would we want to leave completely open what > implementations choose as APP-NAME and simply leave specification of it > out, or still make a suggestion in terms of "SHOULD"? I can life with "SHOULD". But I would prefer to leave it out. The reason is the definition of APP-NAME (syslog-protocol, section 6.2.5): --- The APP-NAME field SHOULD identify the device or application that generated the message.=20 --- Of course, one can argue that syslog-sign is the "application" that generated the message. However, this is not in the spirit of syslog-protocol. The discussion was focussed about software programs being an application. So typical value would be "syslogd", "postfix", "kernel", "mySuperApp", ... It is not safe to mandate (or expect) that APP-NAME "syslog" will only be used by syslog-sign. There is nothing we can make a reservation for it. Forcing my to use "syslog" as app-name causes grief in my application design, because the APP-NAME is something that is already well defined and *independent* of the message content. I would prefer not to introduce a dependency between the message content and the APP-NAME. -- more from the same section -- It is a string without further semantics. --- That means in plain words: you can put whatever you like into APP-NAME. It is NOT a semantical object. The same goes for MSGID and PROCID. Please note that all fields MAY be operator-assigend. When discussing compatibility with RFC 3164, we should keep in mind that 3164 does NOT reflect what is used in the majority of cases (this is the main argument to updating it, see the other thread). So it is already a very slippery slope to define field usage on top of 3164. [side note: this discussion and reminder is one of the reasons I think we need to update 3164 quite soon - the arguments need to be re-iterated ever and ever again and we all sometimes forget about them (me included ;))]. Rainer >=20 > Best regards > --- Alex >=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Wednesday, December 20, 2006 6:51 AM > To: Chris Lonvick (clonvick) > Cc: syslog@ietf.org > Subject: RE: APP-NAME,PROCID and MSGID in syslog sign - was: RE: > [Syslog] clonvick WGLCReview of draft-ietf-syslog-sign-20.txt >=20 > Chris, >=20 > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Wednesday, December 20, 2006 3:37 PM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: > [Syslog] >=20 > > clonvick WGLC Review of draft-ietf-syslog-sign-20.txt > > > > Hi Rainer, > > > > Ahh.. I see your point now. (Sorry - being a little slow this > week.) > > > > All: I'm tending to agree with Rainer's point that no value should > be >=20 > > specified for APP-NAME. Does anyone think that the document should > > suggest something for fixed-function devices such as printers which > > might not have a syslogd? Currently syslog-protocol allows a > NILVALUE >=20 > > if nothing better can be used. >=20 > I think they should use whatever the use with other messages. For > example, they might use "router". Sure, this is not intelligent. But my > point is that this should not be of concern for syslog-sign. >=20 > > > > Similarly, PROCID may be NIVALUE in syslog-protocol if the device > > cannot produce it. I'm OK with that for syslog-sign as well. > > > > Finally, I'd still like to keep "sig" for the MSGID. This should > allow > > for parsers (automated and manual searches) to find syslog-sign > > messages quickly. >=20 > I do not object it, as long as we caution implementors that a MSGID of > "sig" does not necessarily indicate this is a syslog-sign message. We > can not guarantee that, because we did not reserve any message ids at > all. So it may be a clue, but it is nothing to rely on. Which brings me > to the point: what is the advantage of an unreliable indicator? >=20 > >This won't be the only mechanism to identify a syslog-sign message. > I >=20 > >believe that a syslog-sign message would have to: > > - be sent to PRI =3D 110 > > - have MSGID =3D "sig" > > - contain an SD-ID with the SD-PARAM of "ssign" or "ssign-cert" > > I don't think that we need a registry of MSGIDs for this. >=20 > For me, the SD-ID is the only valid indicator that this is a syslog- > sign > message. We can not rely on PRI as operators like to reconfigure PRI. > Even if we mandate a fixed PRI in the specification, real-world > implementations will ignore that requirement and still allow the > operator to override it (and this for a good reason). On the other > hand, > SD-IDs *are* under IANA control and the absolutely positively identify > the element that they are contained in. This is what we designed them > for. So why not use them for their design purpose? >=20 > With RFC 3164 syslog, we obviously can not totally be assured that the > SD-ID will be valid. But we should keep in mind that we most probably > will try to obsolete 3164 either via -protocol or a follow-up RFC. I > already questioned the point in supporting this (informational!) > document in a new standard. Is this really a wise idea? >=20 > Rainer > > > > If anyone has issues with any of this, please speak up now. I'd like > > to get this settled so we can update and send this to the IESG when > > the WGLC ends. > > > > Thanks, > > Chis > > > > > > On Tue, 19 Dec 2006, Rainer Gerhards wrote: > > > > > Chris, > > > > > >> -----Original Message----- > > >> From: Chris Lonvick [mailto:clonvick@cisco.com] > > >> Sent: Tuesday, December 19, 2006 10:18 PM > > >> To: Rainer Gerhards > > >> Cc: syslog@ietf.org > > >> Subject: RE: [Syslog] clonvick WGLC Review of > > >> draft-ietf-syslog-sign-20.txt > > >> > > >> Hi Rainer, > > >> > > >> On Mon, 18 Dec 2006, Rainer Gerhards wrote: > > >> > > >>> Hi, > > >>> > > >>> So far, I have not been able to do a full review. But this > > >> triggers my > > >>> attention immediately... > > >>> > > >>>> Perhaps restructure that as: > > >>>> > > >>>> A Signature Block message that is compliant with RFC xxxx > > >>>> [14] MUST > > >>>> contain valid APP-NAME, PROCID, and MSGID fields. > > >>>> Specifically, the > > >>>> value for APP-NAME MUST be "syslog" (without the > > >> double quotes). > > >>>> The value for MSG-ID MUST be "sig" (without the double > > >>>> quotes). The > > >>>> value for the PRI field MSUT be 110, corresponding to > > >> facility 13 > > >>>> and severity 6 (informational). The Signature Block > > >> is carried as > > >>>> Structured Data within the Signature Block message, per the > > >>>> definitions that follow in the next section. > > >>>> > > >>>> Similar in Section 5.3.1. > > >>> > > >>> Syslog-protocol does not reserve any specific values for APP- > NAME, >=20 > > >>> PROCID and MSGID. So (at least theoretically), another > > >> implementor migth > > >>> use the suggested values for any other case. > > >>> > > >>> As an implementor, I would probably like to consistenly use the > > same > > >>> APP-NAME. For example, all messages in rsyslog will be logged as > > >>> "rsyslogd". > > >>> > > >>> I have just quickly read the IANA section (9.1): there is no such > > >>> registry like "APP-NAME". It might eventually be a good > > >> idea to create > > >>> one, but I am not sure if it is worth the trouble. In any > > >> case, I think > > >>> that must be spelled out in -protocol (else I can implement > > somthing > > >>> compliant to -protocol but not -sign). Same goes for MSGID. > > >>> > > >>> My recommendation (without a full read of the document...) > > >> is to remove > > >>> any dependencies on APP-NAME, PROCID and MSGID and use > > >> structured data > > >>> fields for them. Otherwise, I foresee that I need a lot of > > hardcoded > > >>> exception inside a syslog implementation to "mangle" this > > >> fields so that > > >>> the happen to be right for -sign while they are invalid > > >> from the overall > > >>> application point of view. > > >> > > >> We're going to have "ssign" and "ssign-cert" as the SD-IDs used > for >=20 > > >> syslog-sign. I don't think that there are any dependencies on > > >> APP-NAME, PROCID and MSGID for the proper working of syslog-sign; > > > > > > From the quoted text above: > > > > > >>> value for ####APP-NAME MUST be "syslog"#### (without the > double > > > quotes). > > >>> The value for ####MSG-ID MUST be "sig"#### (without the > double > > > > > > If APP-NAME and MSG-ID *MUST* contain something specific, I think > > there > > > is a strong dependency. > > > > > >> they're just there > > >> to make sure that these messages are placed consistently into the > > >> right bins. The "ssign" and "ssign-cert" SD-IDs will be reserved > > >> for > > this. > > > > > > I do not see how this addresses the concerns I mentioned above. I > can > > > not implement it without interfering with my application design in > a > > way > > > that I do not find justified. How does mandating a specific APP- > NAME > > and > > > MSG-ID make sure that they are put into the right bins? Many stock > > > syslogds can not even filter on these fields... > > > > > > Rainer > > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 21 08:33:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxO1w-00054p-Db; Thu, 21 Dec 2006 08:32:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxO1v-00054Z-H9 for syslog@ietf.org; Thu, 21 Dec 2006 08:32:15 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxO1t-0007sB-S0 for syslog@ietf.org; Thu, 21 Dec 2006 08:32:15 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 2D27327C013 for ; Thu, 21 Dec 2006 14:34:46 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26478-05 for ; Thu, 21 Dec 2006 14:34:46 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id B8F1727C012 for ; Thu, 21 Dec 2006 14:34:45 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 14:32:08 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 21 Dec 2006 14:32:30 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F895C@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC -sign-20 rgerhards review Thread-Index: AcclBHa0HcfN0/ASSY+yZLIBvwpcUw== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 21 Dec 2006 13:32:08.0414 (UTC) FILETIME=[698AA7E0:01C72504] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: Subject: [Syslog] WGLC -sign-20 rgerhards review X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi all, finally, I have managed to do a thourough review. I have not excessively commented on issues that are already being discussed on list. All in all, the document is fine work and in good shape. My issues are mostly small nits and many of them connected to support for 3164 and 3195 (oh yes, we've almost forgotten about it...). I have one more substential comment (actually a suggestion) at the end of the review. While I reviewed the document I also thought how I would actually implement syslog-sign in the two (quite different) syslog products that I influence. I would like to express that section 7 is very helpful in understanding the overall concept and its implications. This is an excellent description. From the implementor's point of view, I think the document clearly conveys what needs to be done to implement the protocol. After reviewing, I have a clear understanding of where and what I need to modify in our software's design to implement -sign. Of course, there are probably some caveats that I will only detect if we actually implement it, but that should be no major issues. Now on to the details. ---- abstract ---- "defined in RFC 3164," 3164 is informational, so it is "described" at most =20 [same comment for section 1. and section 3. (first paragraph)] ---- section 3. ---- ## receiving renders the mechanism useless. For this reason, syslog sender and receiver implementations implementing this specification MUST support messages of up to and including 2048 octets in length, ## I didn't catch it when it was brought up on list before. I was thinking too much of syslog-protocol. However, we must stick with a max size of 1024 because neither RFC 3164 NOR RFC 3195 allow for more. In regard to 3195 this is somewhat debatable, but arguments that more is supported are on slippery ground. ---- section 4.1 ---- ## There is a need to distinguish the Signature Block itself from the syslog message that is used to carry a Signature Block Signature Blocks MUST be encompassed within completely formed syslog messages. ## I think there is a period missing "Signature Block###.### Signature Blocks MUST ...". -- No additional comment on APP-NAME, MSG-ID - see already existing thread ## Similarly, when used with traditional syslog [10], the Signature Block message MUST contain a valid TAG field. The TAG field MUST have the value of "syslog" (without the double quotes) to signify that this message was generated by the syslog process. ## I think "... was generated by the syslog process." implies a specific software architecture (which is beyond the scope of the IETF). I would recommend something along the lines of "that this message is an administrative message inside the syslog protocol". --- section 4.2. --- The term "bytes" is used. I was advised some time ago that "octets" is more appropriate inside the IETF. The sample is missing the quotes around SD-PARAMs. It should read as follows: "[ssign VER=3D"xxx" RSID=3D"xxx" SG=3D"xxx" SPRI=3D"xxx" GBC=3D"xxx" = FMN=3D"xxx" CNT=3D"xxx" HB=3D"xxx" SIGN=3D"xxx"]" ---- section 4.2.1 ---- " The Signature Block version field is 4 characters in length." We must be careful. Syslog-protocol now mandates UTF-8 in this field. So a character is not equal to an octet. I guess octet is meant. If I read on, the term "byte" reappears. I suggest using a unified term. This comment also applies to the sections following after 4.2.1. --- section 4.2.3 --- This is not something overly important... but might it be possible to allow 999 sig groups when SG is '3'? I agree it is unlikely to have more than 192 groups, but does it hurt to support it in (rare) cases where it might be needed? ---- section 4.2.4 ---- I do not understand why the global block counter works across different signature groups. Wouldn't it be more useful if it were on a per-signature-group basis? I would appreciate if you could elaborate a little on the reasoning. ---- section 4.2.5 ---- What happens if the (first) message number latches at 9999999999? What is the "message number"? I did not find it defined anywhere. Of course, I think I can guess (number of messages "sent over" this signature group since reboot?) what it means, but it should be defined. ---- section 4.2.7 ---- size needs to be changed back to 1024 (see above for reasons) ---- section 5.2 ---- -- Bullet Point "b": I recommend to refer the timestamp from syslog-protocol (instead of RFC 3339) because code to handle that is already present in syslog applications. ---- section 5.3. ---- size needs to be changed back to 1024 (see above for reasons) ---- section 5.3.2.1. ---- Quotes need to be added to sample: "[ssign-cert VER=3D"xxx" RSID=3D"xxx" SG=3D"xxx" SPRI=3D"xxx" = TBPL=3D"xxx" INDEX=3D"xxx" FLEN=3D"xxx" FRAG=3D"xxx" SIGN=3D"xxx"]" --- section 5.3.2.6. --- - This comment is just in case that we will (for whatever reason) stick with messages sizes above 1024: then, the fragment length must be 4 octets. This comment does not apply if we change back to 1024. - registry names must be suggested to IANA ---- section 7.1 ---- bullet point "d": ## The resulting authenticated log file contains all messages that have been authenticated and implicitly indicates (by missing message numbers) all gaps in the authenticated messages. ## I think it should be pointed out that "missing" messages are not necessary actually missing. They might just have never been sent to this collector. See 4.2.3: ## One reasonable way to configure some installations is to have only one signature group, ... ## The same can apply in relay chains where interim relay may not relay all messages to the (same) final destination. ---- section 9. ---- [just for completeness - see other thread] There are no IANA registries for APP-NAME and MSGID. ---- section 12. ---- Is Reference [4] actually necessary? references 8, 9, 11, 13, 14, 15, 16 need to be moved to "Normative references". Reference [12] can be dropped if my comment above is followed. ---- GENERAL ---- - must "Note to RFC Editor" not be a separate section? -- use of MUST -- I am not sure if "MUST" is often enough used. For example, section 4.2.1 says=20 ## As such, the version, hash algorithm and signature scheme defined in this document may be represented as "0111" (without the quote marks). ## This text to me implies that another Version may be used for this document. That, however, poses a problem on the receiver side. Should we say it MUST be "0111" if it is to be interpreted according to this document. Similar comments apply to other places (e.g. 4.2.3.) where I am missing a MUST.=20 -- RFC 3195 -- Is it intentional to just support RAW profile? If so, why? -- original syslog messages -- There is no indication or alteration to the original syslog records (those that are signed). This is perfectly fine for SG modes 0, 1 and 2. For SG 3 it would be useful to have an optional SD-ID for the original messages themselves specifying the signature group. This could be something like [signed SG=3D"3" SPRI=3D"xxx"]. This would be very = helpful in conveying which group the message belongs to. The sender knows this information, because it needs to build the signature blocks and thus must know which hash to go into which group. So there is no extra effort here. I came to this point while I was thinking how to implement syslog-sign. Let me quickly explain, it might help grasp the idea behind my suggestion. In rsyslog, I have multiple filters that can be applied to messages. Among them is PRI, of course, but also things like expressions inside the MSG text itself. From the design perspective, each "forward syslog" action is a sender in itself. I would model it so that each of these actions will use its own signature group. So I need mode 3. The question now is: how can the receiver tell which message belongs to which group? The Draft intentionally does provide any guidance here. I think, however, that stems back to the days where it was modelled for 3164 and 3195 exclusively. With -protocol, it is easy to convey that information within STRUCTURED-DATA. It makes life on the reciever side much simpler. I know this does not work for 3164 and 3195, but in the long term we will have most messages formatted in -protocol format. Besides that, if we add it as optional nothing will be hurt in all of the cases. Does that make sense? Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 21 08:54:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOMs-0000Nh-Ro; Thu, 21 Dec 2006 08:53:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxGob-0002bU-EM; Thu, 21 Dec 2006 00:50:01 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxGoY-0002GA-E2; Thu, 21 Dec 2006 00:50:01 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBL5nuJW000207; Thu, 21 Dec 2006 14:49:56 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBL5nqsN020714; Thu, 21 Dec 2006 14:49:55 +0900 (JST) Message-ID: <458A2081.1060800@cysols.com> Date: Thu, 21 Dec 2006 14:49:53 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Internet-Drafts Administrator , syslog@ietf.org Content-Type: multipart/mixed; boundary="------------060707020700000907060700" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f73473b57594bedd5915b8213d0195a X-Mailman-Approved-At: Thu, 21 Dec 2006 08:53:52 -0500 Cc: Subject: [Syslog] Submission of draft-ietf-syslog-device-mib-12.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------060707020700000907060700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Attached please find the updated ID draft-ietf-syslog-device-mib-12.txt This is a work of the ietf-syslog-wg. I will appreciate it very much if you can post this to the archives. Thanks. Glenn --------------060707020700000907060700 Content-Type: text/plain; name="draft-ietf-syslog-device-mib-12.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-syslog-device-mib-12.txt" Syslog Working Group Glenn Mansfield Keeni INTERNET-DRAFT Cyber Solutions Inc. Intended Status: Proposed Standard Expires: June 17, 2007 December 18, 2006 Syslog Management Information Base Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a product of the syslog Working Group. Comments should be addressed to the authors or the mailing list at syslog@ietf.org This Internet-Draft will expire on June 17, 2007. Copyright Notice Copyright (C) The IETF Trust (2006). Glenn M. Keeni. Expires: June 17, 2007 [Page 1] Internet Draft syslogMIB December 2006 Abstract This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog entities. Table of Contents 1. The Internet-Standard Management Framework .... 3 2. Background .................................... 3 3. The MIB Design ................................ 4 4. The Syslog MIB ................................ 6 5. Security Considerations ....................... 32 6. IANA Considerations ........................... 34 7. References .................................... 34 8 Acknowledgments ............................... 35 9. Author's Addresses ............................ 36 10. Full Copyright Statement ...................... 37 Appendix ...................................... 39 Glenn M. Keeni. Expires: June 17, 2007 [Page 2] Internet Draft syslogMIB December 2006 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Background Operating systems, processes and applications, collectively termed "facilities" in the following, generate messages indicating their own status or the occurrence of events. These messages are handled by what has come to be known as the syslog application[RFCPROT] or device [RFC3164]. In this document we refer to a syslog application or device as a syslog entity. A syslog entity sends and/or receives syslog messages. The reader is referred to [RFCPROT] for a description of the various roles of a syslog entity viz. "sender", "receiver", "relay" and "collector". The discussion in this document in general refers to a syslog entity. For exceptional cases the specific role of the syslog application will be mentioned. [RFCUDPX] describes the UDP transport for the syslog protocol. This document defines a set of managed objects (MOs) that can be used to monitor a group of syslog entities. The SYSLOG-MIB can be used in conjunction with other MIB modules - in particular the Host Resources MIB[RFC2790]. The generic process related matters e.g. control and monitoring for status, resource usage etc. can be serviced by the corresponding entries in the Host Resources MIB. Glenn M. Keeni. Expires: June 17, 2007 [Page 3] Internet Draft syslogMIB December 2006 +------+ | Ent1 | /+------+ Facility-1-->| / -->| / +------+ / Facility-N-->|+---| Ent2 |------> Ent4 -->| \ +------+ \ SyslogHost-N-->| \ \+------+ / | Ent3 |------> Ent5 +------+ \ \ facility-i: Facility originating the message (locally) Ent1,..,Ent5: Syslog entity The syslog entities may be on the same host or on different hosts. Fig.1 Syslog Application Model The group of syslog entities modeled by the SYSLOG-MIB is shown in Fig.1. One or more syslog entities which may be on the same host receive syslog messages from local facilities and from other syslog entities which may be on other hosts. The syslog entity receives the message and processes it. The processing will depend on internal configuration and may involve relaying the message to a syslog entity which may be on another host. 3. The MIB Design. The purpose of the SYSLOG-MIB is to allow the monitoring of a group of syslog entities. This requires managed objects representing the following elements. o The default configuration parameters for the group of syslog entities e.g. maximum message size, type of transport, port numbers on which the entity will listen for messages, etc. o The configuration and status related details of each syslog entity. o The statistics on syslog messages received, processed locally, relayed by each syslog entity. Glenn M. Keeni. Expires: June 17, 2007 [Page 4] Internet Draft syslogMIB December 2006 The MIB contains four subtrees. o The syslogSystem subtree services the default configuration parameters. o The syslogEntity subtree consists of the following tables. - SyslogEntityControlTable deals with the configuration and control information for a syslog entity. - SyslogEntityOperationsTable deals with operations and statistical information about messages processed by a syslog entity. o The syslogNotifications subtree defines the set of notifications that will be used to asynchronously report the status of a syslog entity. o The conformance subtree defines the compliance statements. The SYSLOG-MIB module uses textual conventions defined in INET- ADDRESS-MIB[RFC4001], TRANSPORT-ADDRESS-MIB[RFC3419] and SNMP- FRAMEWORK-MIB[RFC3411]. Glenn M. Keeni. Expires: June 17, 2007 [Page 5] Internet Draft syslogMIB December 2006 4. The Syslog MIB SYSLOG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter32, Integer32, mib-2, zeroDotZero, NOTIFICATION-TYPE FROM SNMPv2-SMI RowStatus, StorageType, TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC InetAddressType, InetAddress FROM INET-ADDRESS-MIB transportDomainUdpIpv4, TransportDomain FROM TRANSPORT-ADDRESS-MIB MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; syslogMIB MODULE-IDENTITY LAST-UPDATED "200610230000Z" -- 23th October, 2006 ORGANIZATION "IETF Syslog Working Group" CONTACT-INFO " Glenn Mansfield Keeni Postal: Cyber Solutions Inc. 6-6-3, Minami Yoshinari Aoba-ku, Sendai, Japan 989-3204. Tel: +81-22-303-4012 Fax: +81-22-303-4015 E-mail: glenn@cysols.com Support Group E-mail: syslog@ietf.org " DESCRIPTION "The MIB module for monitoring syslog entities. In this MIB we refer to a syslog application or device as a syslog entity. A syslog entity sends and/or receives syslog messages. The reader is referred to [RFCPROT] for a description of the various roles of a syslog entity viz. ''sender'', ''receiver'', Glenn M. Keeni. Expires: June 17, 2007 [Page 6] Internet Draft syslogMIB December 2006 ''relay'' and ''collector''. The discussion in this document in general refers to a syslog entity. For exceptional cases the specific role of the syslog application will be mentioned. Copyright (C) The Internet Trust (2006). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices. " -- RFC Ed.: replace XXXX with the actual RFC number & remove this -- note REVISION "200610230000Z" -- 23rd October, 2006 DESCRIPTION "The initial version, published as RFC XXXX." -- RFC Ed.: replace XXXX with the actual RFC number & remove this -- note ::= { mib-2 YYYY } -- Will be assigned by IANA -- IANA Reg.: Please assign a value for "YYYY" under the -- 'mib-2' subtree and record the assignment in the SMI -- Numbers registry. -- RFC Ed.: When the above assignment has been made, please -- remove the above note -- replace "YYYY" here with the assigned value and -- remove this note. -- ------------------------------------------------------------- -- Textual Conventions -- ------------------------------------------------------------- Glenn M. Keeni. Expires: June 17, 2007 [Page 7] Internet Draft syslogMIB December 2006 SyslogFacility ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention enumerates the facilities that originate syslog messages. The value noMap(99) indicates that the appropriate facility will be provided by the application on the managed entity. If this option is not available on a particular entity, attempts to set the facility to this value will fail with an error-status of wrongValue. " REFERENCE "The Syslog Protocol [RFCPROT] sec. 6.2.1 (Table 1). " SYNTAX INTEGER { kernel (0), -- kernel messages user (1), -- user-level messages mail (2), -- mail system messages daemon (3), -- system daemons' messages auth1 (4), -- security/authorization messages syslog (5), -- messages generated internally by -- syslogd lpr (6), -- line printer subsystem messages news (7), -- network news subsystem messages uucp (8), -- UUCP subsystem messages cron1 (9), -- clock daemon messages auth2 (10),-- security/authorization messages ftp (11),-- ftp daemon messages ntp (12),-- NTP subsystem messages logAudit (13),-- log audit messages logAlert (14),-- log alert messages cron2 (15),-- clock daemon messages local0 (16), local1 (17), local2 (18), local3 (19), local4 (20), local5 (21), local6 (22), local7 (23), noMap (99) } Glenn M. Keeni. Expires: June 17, 2007 [Page 8] Internet Draft syslogMIB December 2006 SyslogSeverity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention enumerates the severity levels of syslog messages. " REFERENCE "The Syslog Protocol RFCPROT sec. 6.2.1 (Table 2) " SYNTAX INTEGER { emergency (0), -- system is unusable alert (1), -- action must be taken immediately critical (2), -- critical condition error (3), -- error condition warning (4), -- warning condition notice (5), -- normal but significant condition info (6), -- informational message debug (7) -- debug-level messages } SyslogService ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The service name or port number that will be used to send and/or receive messages. The service name must resolve to a port number on the local host. " SYNTAX OCTET STRING (SIZE (0..255)) -- ------------------------------------------------------------- -- syslogMIB - the main groups -- ------------------------------------------------------------- syslogNotifications OBJECT IDENTIFIER ::= { syslogMIB 0 } syslogObjects OBJECT IDENTIFIER ::= { syslogMIB 1 } syslogConformance OBJECT IDENTIFIER ::= { syslogMIB 3 } Glenn M. Keeni. Expires: June 17, 2007 [Page 9] Internet Draft syslogMIB December 2006 syslogSystem OBJECT IDENTIFIER ::= { syslogObjects 1 } syslogEntity OBJECT IDENTIFIER ::= { syslogObjects 2 } -- ------------------------------------------------------------- -- syslogSystem -- ------------------------------------------------------------- -- The default parameters syslogDefaultTransportDomain OBJECT-TYPE SYNTAX TransportDomain MAX-ACCESS read-write STATUS current DESCRIPTION "The default transportDomain for the address which the syslog entity will use to receive and transmit messages. Typical values will be one of (not all inclusive) list: transportDomainUdpIpv4 (from TRANSPORT-ADDRESS-MIB) transportDomainUdpIpv6 (from TRANSPORT-ADDRESS-MIB) The default transport that a syslog entity will use to send syslog messages. The value of this object SHOULD remain unchanged across reboots of the managed entity. " REFERENCE "The Syslog Protocol [RFCPROT] Sec. 5. " DEFVAL {transportDomainUdpIpv4} ::= { syslogSystem 1 } Glenn M. Keeni. Expires: June 17, 2007 [Page 10] Internet Draft syslogMIB December 2006 syslogDefaultService OBJECT-TYPE SYNTAX SyslogService MAX-ACCESS read-write STATUS current DESCRIPTION "The default service name or port number that a syslog entity will use to send syslog messages. The value of this object SHOULD remain unchanged across reboots of the managed entity. " REFERENCE "Transmission of syslog messages over UDP RFCUDPX Sec. 3.3. " DEFVAL { "514" } ::= { syslogSystem 2 } syslogDefaultFacility OBJECT-TYPE SYNTAX SyslogFacility MAX-ACCESS read-write STATUS current DESCRIPTION "The default syslog facility will be used to compute the syslog priority that will be added to syslog messages when the message needs to be relayed and does not have facility specified. The value of this object SHOULD remain unchanged across reboots of the managed entity. " ::= { syslogSystem 3 } syslogDefaultSeverity OBJECT-TYPE SYNTAX SyslogSeverity MAX-ACCESS read-write STATUS current DESCRIPTION "The default syslog severity will be used to compute the syslog priority that will be added to syslog messages when the message needs to be relayed and does not have priority specified. The value of this object SHOULD remain unchanged across reboots of the managed entity. Glenn M. Keeni. Expires: June 17, 2007 [Page 11] Internet Draft syslogMIB December 2006 " ::= { syslogSystem 4 } -- ------------------------------------------------------------- -- syslog entity configuration info table -- ------------------------------------------------------------- syslogEntityControlTable OBJECT-TYPE SYNTAX SEQUENCE OF SyslogEntityControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing the configuration parameters pertaining to the syslog entities serviced by an SNMP agent. " ::= { syslogEntity 1 } syslogEntityControlEntry OBJECT-TYPE SYNTAX SyslogEntityControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The configuration parameters pertaining to a syslog entity. " INDEX { syslogEntityControlIndex } ::= { syslogEntityControlTable 1 } Glenn M. Keeni. Expires: June 17, 2007 [Page 12] Internet Draft syslogMIB December 2006 SyslogEntityControlEntry ::= SEQUENCE { syslogEntityControlIndex Unsigned32, syslogEntityControlDescr SnmpAdminString, syslogEntityControlBindAddrType InetAddressType, syslogEntityControlBindAddr InetAddress, syslogEntityControlTransportDomain TransportDomain, syslogEntityControlService SyslogService, syslogEntityControlMaxMessageSize Unsigned32, syslogEntityControlConfFileName SnmpAdminString, syslogEntityControlStatus INTEGER, syslogEntityControlStorageType StorageType, syslogEntityControlRowStatus RowStatus } syslogEntityControlIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Index that uniquely identifies the syslog entity in the syslogEntityControlTable. The value of the index for a syslog entity may not be the same across system reboots. Users and Applications will need to determine the index of a syslog entity after system reboots. " ::= { syslogEntityControlEntry 1 } Glenn M. Keeni. Expires: June 17, 2007 [Page 13] Internet Draft syslogMIB December 2006 syslogEntityControlDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A user definable description of the syslog entity. This description could be used by syslog management applications e.g. in reports or in user interfaces. " ::= { syslogEntityControlEntry 2 } syslogEntityControlBindAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address which follows in syslogEntityControlBindAddr. " ::= { syslogEntityControlEntry 3 } syslogEntityControlBindAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The specific address the syslog entity will bind to. The format of the address is specified by the corresponding syslogEntityControlBindAddrType object. If the address is specified in the DNS domain name format [syslogEntityControlBindAddrType = 'dns'], the corresponding IPv4 or IPv6 address obtained at the time of the binding operation by the syslog entity, will be used. " ::= { syslogEntityControlEntry 4 } syslogEntityControlTransportDomain OBJECT-TYPE SYNTAX TransportDomain MAX-ACCESS read-create STATUS current DESCRIPTION "The transport that a syslog entity will use to send syslog messages. Glenn M. Keeni. Expires: June 17, 2007 [Page 14] Internet Draft syslogMIB December 2006 The value 'zeroDotZero' indicates the syslog entity will use the transport specified in syslogDefaultTransportDomain. " DEFVAL {zeroDotZero} ::= { syslogEntityControlEntry 5 } syslogEntityControlService OBJECT-TYPE SYNTAX SyslogService MAX-ACCESS read-create STATUS current DESCRIPTION "The service name or port number that this syslog entity will use to send syslog messages. If no value is specified, the syslog entity will use the service name or port number specified in syslogDefaultService. " ::= { syslogEntityControlEntry 6 } syslogEntityControlMaxMessageSize OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum size of the syslog messages in bytes for this syslog entity. A syslog entity may reject or truncate messages larger than the specified maximum syslog message size. " ::= { syslogEntityControlEntry 7 } Glenn M. Keeni. Expires: June 17, 2007 [Page 15] Internet Draft syslogMIB December 2006 syslogEntityControlConfFileName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The fullpath name of the configuration file where the syslog entity's message selection and corresponding action rules will be read from. If the system does not support the specification of a configuration file, this field will be a zero-length string. " DEFVAL { "/etc/syslog.conf" } ::= { syslogEntityControlEntry 8 } syslogEntityControlStatus OBJECT-TYPE SYNTAX INTEGER { unknown (1), started (2), suspended(3), stopped (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the syslog entity. " DEFVAL { unknown } ::= { syslogEntityControlEntry 9 } Glenn M. Keeni. Expires: June 17, 2007 [Page 16] Internet Draft syslogMIB December 2006 syslogEntityControlStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether the parameters defined in this row are kept in volatile storage and lost upon reboot or are backed up by non-volatile or permanent storage. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { syslogEntityControlEntry 10 } syslogEntityControlRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create, modify and delete rows in the syslogEntityControlTable. The value of syslogEntityControlDescr can be changed when this object is in state ''active'' or in ''notInService''. The other objects in a row can be modified only when the value of this object in the corresponding conceptual row is not ''active''. Thus to modify one or more of the objects in this conceptual row, a. change the row status to ''notInService'', b. change the values of the row c. change the row status to ''active'' The syslogEntityControlRowStatus may be changed to ''active'' if all the managed objects in the conceptual row have been assigned valid values. " ::= { syslogEntityControlEntry 11 } Glenn M. Keeni. Expires: June 17, 2007 [Page 17] Internet Draft syslogMIB December 2006 -- ------------------------------------------------------------- -- syslogEntityOperations -- ------------------------------------------------------------- syslogEntityOperationsTable OBJECT-TYPE SYNTAX SEQUENCE OF SyslogEntityOperationsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing operations information about the syslog entities serviced by an SNMP agent. This table complements the (configuration) information in syslogEntityControlTable . " ::= { syslogEntity 2 } syslogEntityOperationsEntry OBJECT-TYPE SYNTAX SyslogEntityOperationsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The operations information pertaining to a syslog entity. " AUGMENTS { syslogEntityControlEntry } ::= { syslogEntityOperationsTable 1 } Glenn M. Keeni. Expires: June 17, 2007 [Page 18] Internet Draft syslogMIB December 2006 SyslogEntityOperationsEntry ::= SEQUENCE { syslogEntityOperationsMsgsReceived Counter32, syslogEntityOperationsMsgsRelayed Counter32, syslogEntityOperationsMsgsDropped Counter32, syslogEntityOperationsMsgsIllFormed Counter32, syslogEntityOperationsMsgsIgnored Counter32, syslogEntityOperationsLastMsgRecdTime TimeStamp, syslogEntityOperationsLastMsgTransmittedTime TimeStamp, syslogEntityOperationsStartTime TimeStamp, syslogEntityOperationsLastError SnmpAdminString, syslogEntityOperationsLastErrorTime TimeStamp, syslogEntityOperationsReference Integer32, syslogEntityOperationsCounterDiscontinuityTime TimeStamp } syslogEntityOperationsMsgsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages received by the syslog entity. This includes messages that were ignored. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of syslogEntityOperationsCounterDiscontinuityTime. " ::= { syslogEntityOperationsEntry 1 } Glenn M. Keeni. Expires: June 17, 2007 [Page 19] Internet Draft syslogMIB December 2006 syslogEntityOperationsMsgsRelayed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages relayed by the syslog entity to other syslog entities. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of syslogEntityOperationsCounterDiscontinuityTime. " ::= { syslogEntityOperationsEntry 2 } syslogEntityOperationsMsgsDropped OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that could not be queued for transmission by the syslog entity. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of syslogEntityOperationsCounterDiscontinuityTime. " ::= { syslogEntityOperationsEntry 3 } syslogEntityOperationsMsgsIllFormed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that were rejected by the syslog entity because these were not well-formed. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of syslogEntityOperationsCounterDiscontinuityTime. " ::= { syslogEntityOperationsEntry 4 } Glenn M. Keeni. Expires: June 17, 2007 [Page 20] Internet Draft syslogMIB December 2006 syslogEntityOperationsMsgsIgnored OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages that were not processed by the syslog entity because the messages did not meet the allowed specifications. This will include messages that are not accepted as the message size was greater than the system's maximum message size and will exclude messages that are rejected because they are malformed. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of syslogEntityOperationsCounterDiscontinuityTime. " ::= { syslogEntityOperationsEntry 5 } syslogEntityOperationsLastMsgRecdTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The local time when the last message was received by the syslog entity locally or from a remote syslog entity. " ::= { syslogEntityOperationsEntry 6 } syslogEntityOperationsLastMsgTransmittedTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The local time when the last message was transmitted by the syslog entity. " ::= { syslogEntityOperationsEntry 7 } Glenn M. Keeni. Expires: June 17, 2007 [Page 21] Internet Draft syslogMIB December 2006 syslogEntityOperationsStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The local time when this entity was started. " ::= { syslogEntityOperationsEntry 8 } syslogEntityOperationsLastError OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A description of the last error related to sending, receiving or processing a syslog message that was encountered by this syslog entity. " ::= { syslogEntityOperationsEntry 9 } syslogEntityOperationsLastErrorTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The local time when the last error was encountered. " ::= { syslogEntityOperationsEntry 10 } syslogEntityOperationsReference OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "If the Host resource MIB is instantiated on the host then this entry will have the value of the hrSWRunIndex of the corresponding entry in the hrSWRunTable. Note that the hrSWRunIndex is not persistent across system reboots or software restarts. The value of syslogEntityOperationsReference SHOULD reference the latest value of the hrSWRunIndex of the corresponding entry in the hrSWRunTable. The special value of zero indicates that the Host Glenn M. Keeni. Expires: June 17, 2007 [Page 22] Internet Draft syslogMIB December 2006 resource MIB is not instantiated. " ::= { syslogEntityOperationsEntry 11 } syslogEntityOperationsCounterDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this syslog entity's counters, viz., counters with OID prefix 'syslogEntityOperationsMsgsReceived' or 'syslogEntityOperationsMsgsRelayed' or 'syslogEntityOperationsMsgsDropped' or 'syslogEntityOperationsMsgsIllFormed' or 'syslogEntityOperationsMsgsIgnored' suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object will have a zero value. " ::= { syslogEntityOperationsEntry 12 } Glenn M. Keeni. Expires: June 17, 2007 [Page 23] Internet Draft syslogMIB December 2006 syslogEntityStatusChanged NOTIFICATION-TYPE OBJECTS { syslogEntityControlStatus, syslogEntityControlDescr, syslogEntityControlBindAddrType, syslogEntityControlBindAddr, syslogEntityControlTransportDomain, syslogEntityControlService, syslogEntityControlConfFileName } STATUS current DESCRIPTION "This notification is sent when a syslog entity changes state. For example when the syslog entity starts [syslogEntityControlStatus is ''started'' ] or the syslog entity stops [syslogEntityControlStatus is ''suspended'' or ''stopped'']. The syslog entity corresponding to the notification will be identified by the syslogEntityOperationsIndex instance identifier of the objects in the notification. " ::= { syslogNotifications 1 } -- ------------------------------------------------------------- -- Conformance Information -- ------------------------------------------------------------- syslogGroups OBJECT IDENTIFIER ::= { syslogConformance 1 } syslogCompliances OBJECT IDENTIFIER ::= { syslogConformance 2 } Glenn M. Keeni. Expires: June 17, 2007 [Page 24] Internet Draft syslogMIB December 2006 -- ------------------------------------------------------------- -- units of conformance -- ------------------------------------------------------------- syslogDefaultGroup OBJECT-GROUP OBJECTS { syslogDefaultTransportDomain, syslogDefaultService, syslogDefaultFacility, syslogDefaultSeverity } STATUS current DESCRIPTION "A collection of objects providing default parameters for syslog entities " ::= { syslogGroups 1} syslogEntityOperationsGroup OBJECT-GROUP OBJECTS { -- syslogEntityOperationsIndex, syslogEntityOperationsMsgsReceived, syslogEntityOperationsMsgsRelayed, syslogEntityOperationsMsgsDropped, syslogEntityOperationsMsgsIllFormed, syslogEntityOperationsMsgsIgnored, syslogEntityOperationsLastMsgRecdTime, syslogEntityOperationsLastMsgTransmittedTime, syslogEntityOperationsStartTime, syslogEntityOperationsLastError, syslogEntityOperationsLastErrorTime, syslogEntityOperationsReference, syslogEntityOperationsCounterDiscontinuityTime } STATUS current DESCRIPTION "A collection of objects providing message related statistics." ::= { syslogGroups 2} Glenn M. Keeni. Expires: June 17, 2007 [Page 25] Internet Draft syslogMIB December 2006 syslogEntityControlGroup OBJECT-GROUP OBJECTS { syslogEntityControlDescr, syslogEntityControlBindAddrType, syslogEntityControlBindAddr, syslogEntityControlTransportDomain, syslogEntityControlService, syslogEntityControlMaxMessageSize, syslogEntityControlConfFileName, syslogEntityControlStatus, syslogEntityControlStorageType, syslogEntityControlRowStatus } STATUS current DESCRIPTION "A collection of objects representing the run time parameters for the syslog entities. " ::= { syslogGroups 3} syslogNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { syslogEntityStatusChanged } STATUS current DESCRIPTION "A collection of notifications about the operational state of a syslog entity. " ::= { syslogGroups 4} Glenn M. Keeni. Expires: June 17, 2007 [Page 26] Internet Draft syslogMIB December 2006 -- ------------------------------------------------------------- -- compliance statements -- ------------------------------------------------------------- syslogFullCompliance1 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the SYSLOG-MIB with support for writable objects and notifications. Such an implementation can be both monitored and configured via SNMP. It can also send notifications about change in the operational status of the syslog entity. " MODULE -- this module MANDATORY-GROUPS { syslogNotificationGroup, syslogDefaultGroup, syslogEntityOperationsGroup, syslogEntityControlGroup } ::= { syslogCompliances 1 } syslogFullCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the SYSLOG-MIB with support for writable objects. Such an implementation can be both monitored and configured via SNMP. " MODULE -- this module MANDATORY-GROUPS { syslogDefaultGroup, syslogEntityOperationsGroup, syslogEntityControlGroup } ::= { syslogCompliances 2 } Glenn M. Keeni. Expires: June 17, 2007 [Page 27] Internet Draft syslogMIB December 2006 syslogReadOnlyCompliance1 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the syslog MIB without support for read-write (i.e. in read-only mode). It can also send notifications about change in the operational status of the syslog entity. " MODULE -- this module MANDATORY-GROUPS { syslogNotificationGroup, syslogDefaultGroup, syslogEntityOperationsGroup, syslogEntityControlGroup } OBJECT syslogEntityControlDescr MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlBindAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlBindAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlTransportDomain MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlService MIN-ACCESS read-only DESCRIPTION "Write access is not required. " Glenn M. Keeni. Expires: June 17, 2007 [Page 28] Internet Draft syslogMIB December 2006 OBJECT syslogEntityControlMaxMessageSize MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlConfFileName MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. " ::= { syslogCompliances 3 } syslogReadOnlyCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the syslog MIB without support for read-write (i.e. in read-only mode). " MODULE -- this module MANDATORY-GROUPS { syslogDefaultGroup, syslogEntityOperationsGroup, syslogEntityControlGroup } OBJECT syslogEntityControlDescr MIN-ACCESS read-only DESCRIPTION "Write access is not required. " Glenn M. Keeni. Expires: June 17, 2007 [Page 29] Internet Draft syslogMIB December 2006 OBJECT syslogEntityControlBindAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlBindAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlTransportDomain MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlService MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlMaxMessageSize MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlConfFileName MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT syslogEntityControlRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. " ::= { syslogCompliances 4 } Glenn M. Keeni. Expires: June 17, 2007 [Page 30] Internet Draft syslogMIB December 2006 syslogNotificationCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the SYSLOG-MIB and support only notifications about change in the operational status of a syslog entity. " MODULE -- this module MANDATORY-GROUPS { syslogNotificationGroup } ::= { syslogCompliances 5 } END Glenn M. Keeni. Expires: June 17, 2007 [Page 31] Internet Draft syslogMIB December 2006 5. Security Considerations Syslog plays a very important role in the computer and network security of an organization. SYSLOG-MIB defines several managed objects that may be used to monitor, configure and control syslog entities. As such improper manipulation of the objects represented by this MIB may lead to an attack on an important component of the computer and network security infrastructure. The objects in syslogEntityControlTable may be misconfigured to cause syslog messages to be diverted or lost. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o syslogEntityControlTable: The objects in this table describe the configuration of the syslog entities. It may be misconfigured to start up a very large number of syslog entities (processes) and deny the system of its resources. o syslogEntityControlBindAddr: This object may be misconfigured to bind syslog entity to the wrong address. This will cause messages to be lost. o syslogEntityControlTransportDomain : This object may be misconfigured to specify a wrong transport for the syslog entity. This will cause messages to be lost. o syslogEntityControlService : This object may be misconfigured to bind syslog entity to the wrong service (port). This will cause messages to be lost. o syslogEntityControlMaxMessageSize: This message may be misconfigured to set the wrong MaxMessageSize for the syslog entity. It may cause syslog messages to be lost. o syslogEntityControlConfFileName: This object may be misconfigured to start the syslog entity with the wrong (rogue) configuration. o syslogEntityControlStorageType: This object may be misconfigured to set the wrong storage type. That may cause confusion, operational errors and/or loss of information. Glenn M. Keeni. Expires: June 17, 2007 [Page 32] Internet Draft syslogMIB December 2006 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o syslogEntityOperationsTable: Objects in this table carry sensitive information. The counters may reveal information about the deployment and effectiveness of the relevant security systems. The counters may be analyzed to tell whether the security systems are able to detect an event or not. o syslogEntityOperationsLastError: This object may contain sensitive information e.g. user-id, password etc. depending on the implementation of the syslog entity. It may reveal details about the syslog implementation itself, e.g. version, OS etc. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Glenn M. Keeni. Expires: June 17, 2007 [Page 33] Internet Draft syslogMIB December 2006 6. IANA Considerations The MIB modules in this document use the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- syslogMIB { mib-2 YYYY } IANA Reg.: Please assign a value under the 'mib-2' subtree for the 'syslogMIB' MODULE-IDENTITY and record the assignment in the SMI Numbers registry. RFC Ed.: When the above assignments have been made, please - remove the above note - replace "YYYY" here with the assigned values and - remove this note. 7. References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. Glenn M. Keeni. Expires: June 17, 2007 [Page 34] Internet Draft syslogMIB December 2006 [RFC3419] Daniele, M., and Schoenwaelder, J., "Textual Conventions for Transport Addresses", RFC 3419, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and Schoenwaelder, J., "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFCPROT] Gerhards, R., "The syslog Protocol", draft-ietf-syslog-protocol-17.txt, work in progress, June, 2006. [RFCUDPX] Okmianski, A., "Transmission of syslog messages over UDP", draft-ietf-syslog-transport-udp-07.txt work in progress, May, 2006. 7.2 Informative References [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for the Internet-Standard Management Framework", RFC 3410, December 2002. [RFC2790] Waldbusser, S., and Grillo, P., "Host Resources MIB", RFC 2790, March 2000. 8. Acknowledgments The initial draft of this document was authored by Bruno Pape. The authors would like to thank David Harrington, Mark Ellison, Mike MacFaden, Dave T Perkins and members of the WIDE-netman group for their comments and suggestions. Glenn M. Keeni. Expires: June 17, 2007 [Page 35] Internet Draft syslogMIB December 2006 9. Author's Addresses Glenn Mansfield Keeni Cyber Solutions Inc. 6-6-3 Minami Yoshinari Aoba-ku, Sendai 989-3204 Japan Phone: +81-22-303-4012 EMail: glenn@cysols.com Glenn M. Keeni. Expires: June 17, 2007 [Page 36] Internet Draft syslogMIB December 2006 10. Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Glenn M. Keeni. Expires: June 17, 2007 [Page 37] Internet Draft syslogMIB December 2006 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Glenn M. Keeni. Expires: June 17, 2007 [Page 38] Internet Draft syslogMIB December 2006 APPENDIX This section documents the development of the draft. It will be deleted when the draft becomes an RFC. Revision History: Changes from draft-ietf-syslog-device-mib-11.txt to draft-ietf-syslog-device-mib-12.txt 1. Added text in introduction and in the DESCRIPTION of the MIB module to explain the terminology used in the document. Ref. Comment 1.1, 1.2, 1.3, 1.4. 2. Changed "group" to "subtree" in Section 3 (The MIB Design). Ref. Comment 1.5 3. Removed enumeration "other" from the enumeration for SyslogSeverity. This case does not arise. Ref. Comment 1.6 4. Revised DESCRIPTION of syslogEntityControlStorageType Ref. comment 2.3 5. Revised DESCRIPTION of syslogEntityStatusChanged Ref. Comment 2.4 6. Updated the boilerplate for the Copyright notice. Ref. Comment 2.7 7. Changed "should" to "SHOULD" in DESCRIPTION of syslogEntityOperationsReference Ref. Comment 3.2 8. Changed RFCPROT to "[RFCPROT]" in REFERENCE of syslogDefaultTransportDomain Changes from draft-ietf-syslog-device-mib-9.txt to draft-ietf-syslog-device-mib-11.txt [Note: The changes to the mib-9.txt and mib-10.txt are consolidated below.] 1. Namings changed: Page-8. changed the duplicate instances of auth and cron to auth1, auth2, cron1, cron2 changed: SyslDevOpsEntry -> SyslogEntityOperationsEntry syslEntOpsEntry -> syslogEntityOperationsEntry SyslDevCtlEntry -> SyslogEntityControlEntry syslEntCtlEntry -> syslogEntityControlEntry syslEntOpsTable -> syslogEntityOperationsTable Glenn M. Keeni. Expires: June 17, 2007 [Page 39] Internet Draft syslogMIB December 2006 syslogDevice -> syslogDevice syslEntCtlProcDescr -> syslogEntityControlDescr syslEntOpsLastMsgDeliveredTime -> syslogEntityOperationsLastMsgTransmittedTime. syslDevOpsGroup -> syslogEntityOperationsGroup 2. Added TRANSPORT-ADDRESS-MIB[RFC3419] to the text on section 3 (and 7.1 Normative References). 3. MIB. Fixed MIB nits. 4. Added text about the expected persistency behaviour of the read-write objects in the corresponding DESCRIPTION clauses. syslogDefaultTransport syslogDefaultService syslogDefaultFacility syslogDefaultSeverity 5. Replaced syslogDefaultTransport OBJECT-TYPE SYNTAX TransportAddressType and syslEntCtlTransport OBJECT-TYPE SYNTAX TransportAddressType by syslogDefaultTransportDomain OBJECT-TYPE SYNTAX TransportDomain syslogEntityControlTransportDomain OBJECT-TYPE SYNTAX TransportDomain 6. Changed the ordering of syslEntOpsTable ::= { syslogDevice 1 } syslEntCtlTable ::= { syslogDevice 2 } to syslogEntityControlTable ::= { syslogEntity 1 } syslogEntityOperationsTable ::= { syslogEntity 2 } 7. The tree structure is changed from syslogSystem OBJECT IDENTIFIER ::= { syslogMIB 1 } Glenn M. Keeni. Expires: June 17, 2007 [Page 40] Internet Draft syslogMIB December 2006 syslogDevice OBJECT IDENTIFIER ::= { syslogMIB 2 } to, syslogObjects OBJECT IDENTIFIER ::= { syslogMIB 1 } syslogSystem OBJECT IDENTIFIER ::= { syslogObjects 1 } syslogEntity OBJECT IDENTIFIER ::= { syslogObjects 2 } 8. syslogEntityOperationsEntry AUGMENTS { syslogEntityControlEntry } 9. Added syslogEntityOperationsCounterDiscontinuityTime OBJECT-TYPE to indicate whether 'syslogEntityOperationsMsgsReceived' or 'syslogEntityOperationsMsgsRelayed' or 'syslogEntityOperationsMsgsDropped' or 'syslogEntityOperationsMsgsIllFormed' or 'syslogEntityOperationsMsgsIgnored' suffered a discontinuity. Revised the DESCRIPTION of the above Objects. 10. Changed all references of "syslog process", "syslog device" to "syslog entity". 11. Changed syntax of syslogEntityOperationsReference from syslEntOpsReference OBJECT-TYPE SYNTAX Integer32 to syslogEntityOperationsReference OBJECT-TYPE SYNTAX Integer32 (0..2147483647) 12. Revised the DESCRIPTION clauses of syslogEntityControlTable syslogEntityOperationsReference syslogEntityControlBindAddrType syslogEntityControlBindAddr syslogEntityControlTransportDomain syslogEntityControlService syslogEntityControlConfFileName Glenn M. Keeni. Expires: June 17, 2007 [Page 41] Internet Draft syslogMIB December 2006 syslogEntityControlStatus syslogEntityControlRowStatus syslogEntityOperationsTable syslogEntityControlTable syslogEntityOperationsMsgsDropped syslogEntityOperationsReference syslogEntityControlEntry 13. Added DEFVAL { nonVolatile } to syslogEntityControlStorageType 14. Merged the NOTIFICATIONs syslEntStarted syslEntStopped into syslogEntityStatusChanged 15. Overhauled the syslogCompliance tree 16. idnits fixed. 17. IANA considerations section revised. 17. Labels and Captions in figure 1 are revised. 18. Revised DESCRIPTION clauses of SyslogSeverity syslogDefaultFacility syslogDefaultSeverity 19. syslogDefaultMaxMessageSize is deleted revised the DESCRIPTION of syslogEntityControlMaxMessageSize 20. editorial fixes The changes upto draft-ietf-syslog-device-mib-9.txt are documented below in the form of MIB Revision clauses. REVISION "200609040000Z" -- 9th September 2006 DESCRIPTION " o The draft has been aligned with the current standards track documents syslog-protocol-17.txt and syslog-transport-udp-07.txt: the REFERNCE clauses have changed. o The TEXTUAL-CONVENTION SyslogTransport has been replaced by the TransportAddressType. Glenn M. Keeni. Expires: June 17, 2007 [Page 42] Internet Draft syslogMIB December 2006 o The TEXTUAL-CONVENTION SyslogFacility and SyslogSeverity have been aligned with syslog-protocol-17.txt o A paragraph has been added to list the related MIBs from which MOS and TEXTUAL-CONVENTIONs have been imported. o The target of this MIB is now called a syslog entity. [ Earlier it was referred to as a syslog device.] The prefix syslDev has been changed to syslEnt o The DEFVALS have been aligned with the reference documents. o The REFERENCE section has been updated. o The OID for syslogConformance has been changed from 4 to 3. " REVISION "200607250000Z" -- 25th July 2006 DESCRIPTION "the internet draft's version number has been changed (7->8). " REVISION "200511250000Z" -- 25th November 2005 DESCRIPTION "A near complete overhaul of the MIB and the document. The BSD-syslog flavor has been abandoned in favor of a more generic syslog-protocol document that is under preparation. TBD. The reference clauses need to be redone once the new syslog document is ready. List of authors changed. Original draft author Bruno Pape is acknowledged in the Acknowledgments section. Editorial nits fixed. " REVISION "200406160000Z" -- Mon Feb 16 00:00 GMT 2004 DESCRIPTION "Major change. The configuration parts have been removed. Updated the description clauses. Glenn M. Keeni. Expires: June 17, 2007 [Page 43] Internet Draft syslogMIB December 2006 Editorial nits fixed. " REVISION "200306250000Z" -- Wed June 25 00:00 GMT 2003 DESCRIPTION "Changed the type of syslogProcLastError SnmpAdminString, from Integer32. DEFVAL { 0 ] is added to syslogAllowedHostsMaskLen MO name changed from syslogCtlSelectionHostname to syslogCtlSelectionHostName Updated the description clauses. Fixed nits pointed out in Bert's mails of 20030319 and revised the document wrt the guidelines in draft-ietf-ops-mib-review-guidelines-01.txt Editorial nits fixed. " REVISION "200303030000Z" -- Mon March 03 00:00 GMT 2003 DESCRIPTION "Fixing of nits in descriptions, addition of references, addition of the following MOs syslogProcMsgsIllFormed Counter32, syslogProcStartTime TimeStamp, syslogProcLastError Integer32, syslogProcLastErrorTime TimeStamp, syslDevCtlStorageType StorageType, syslogCtlFwdActionSrcAddrType InetAddressType, syslogCtlFwdActionSrcAddr InetAddress, added enumeration ''suspended(2)'' to syslDevCtlStatus. " REVISION "200212252343Z" -- Wed December 25 23:43 GMT 2002 DESCRIPTION "Radical revision of the MIB structure and design." REVISION "200206061841Z" -- Thu Jun 6 18:41 GMT 2002 DESCRIPTION "The initial version of this MIB module." Glenn M. Keeni. Expires: June 17, 2007 [Page 44] Internet Draft syslogMIB December 2006 Glenn M. Keeni. Expires: June 17, 2007 [Page 45] --------------060707020700000907060700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --------------060707020700000907060700-- From syslog-bounces@lists.ietf.org Thu Dec 21 09:39:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxP3w-0008MZ-31; Thu, 21 Dec 2006 09:38:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxP3v-0008MQ-64 for syslog@ietf.org; Thu, 21 Dec 2006 09:38:23 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxP3s-0004cQ-Oy for syslog@ietf.org; Thu, 21 Dec 2006 09:38:23 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 98CA159711; Thu, 21 Dec 2006 15:38:13 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13158-10; Thu, 21 Dec 2006 15:38:10 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id AA57D56183; Thu, 21 Dec 2006 15:38:08 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 5CECE903017; Thu, 21 Dec 2006 15:38:08 +0100 (CET) Date: Thu, 21 Dec 2006 15:38:08 +0100 From: Juergen Schoenwaelder To: "Glenn M. Keeni" Subject: Re: [Syslog] Submission of draft-ietf-syslog-device-mib-12.txt Message-ID: <20061221143808.GC2166@boskop.local> Mail-Followup-To: "Glenn M. Keeni" , syslog@ietf.org References: <458A2081.1060800@cysols.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <458A2081.1060800@cysols.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Thu, Dec 21, 2006 at 02:49:53PM +0900, Glenn M. Keeni wrote: > Attached please find the updated ID > draft-ietf-syslog-device-mib-12.txt The combination of syslogEntityControlBindAddrType InetAddressType syslogEntityControlBindAddr InetAddress syslogEntityControlTransportDomain TransportDomain syslogEntityControlService SyslogService looks a bit crazy to me. - Why have both InetAddressType and TransportDomain? - Why not simply use (InetAddressType,InetAddress,InetPortNumber) or (TansportAddressType,TransportAddress)? - What is the value of saying the service name is "xyz", which has only local significance? - How do I find out which encapsulations are supported (plain, beep, tls, ...)? /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 21 12:43:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRwo-0000a0-Ko; Thu, 21 Dec 2006 12:43:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRwn-0000Zt-Np for syslog@ietf.org; Thu, 21 Dec 2006 12:43:13 -0500 Received: from ext-ch1gw-2.online-age.net ([216.34.191.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxRwh-0001xh-Qh for syslog@ietf.org; Thu, 21 Dec 2006 12:43:13 -0500 Received: from int-ch1gw-4.online-age.net (int-ch1gw-4 [3.159.232.68]) by ext-ch1gw-2.online-age.net (8.13.6/8.13.6/20051111-SVVS-TLS-DNSBL) with ESMTP id kBLHh41r011451 for ; Thu, 21 Dec 2006 12:43:05 -0500 (EST) Received: from cinmlef06.e2k.ad.ge.com (int-ch1gw-4 [3.159.232.68]) by int-ch1gw-4.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP id kBLHgekS019072 for ; Thu, 21 Dec 2006 12:42:40 -0500 (EST) Received: from ALPMLVEM07.e2k.ad.ge.com ([3.159.17.66]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 21 Dec 2006 12:43:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] WGLC -sign-20 rgerhards review Date: Thu, 21 Dec 2006 12:43:02 -0500 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F895C@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] WGLC -sign-20 rgerhards review Thread-Index: AcclBHa0HcfN0/ASSY+yZLIBvwpcUwAIhqDg From: "Moehrke, John \(GE Healthcare\)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 21 Dec 2006 17:43:03.0932 (UTC) FILETIME=[775463C0:01C72527] X-Spam-Score: 0.6 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I would like to plea with the group to figure out ways to stop using the legacy MTU as a reason to constrain new standards. I would rather see syslog-sign not support 3164 than for it to be constrained to 1024 bytes because of some belief that it needs to support a non-normative RFC. My recommendation is to NOT support 3164, Fix 3195 (remove the MTU), and don't constrain the MTU unless there is a good reason (non-normative legacy is not a good reason).=20 John Moehrke GE Healthcare > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Thursday, December 21, 2006 7:33 AM > To: syslog@ietf.org > Subject: [Syslog] WGLC -sign-20 rgerhards review >=20 > Hi all, >=20 > finally, I have managed to do a thourough review. I have not=20 > excessively > commented on issues that are already being discussed on list. >=20 > All in all, the document is fine work and in good shape. My issues are > mostly small nits and many of them connected to support for 3164 and > 3195 (oh yes, we've almost forgotten about it...). I have one more > substential comment (actually a suggestion) at the end of the review. >=20 > While I reviewed the document I also thought how I would actually > implement syslog-sign in the two (quite different) syslog=20 > products that > I influence. I would like to express that section 7 is very helpful in > understanding the overall concept and its implications. This is an > excellent description. From the implementor's point of view,=20 > I think the > document clearly conveys what needs to be done to implement the > protocol. After reviewing, I have a clear understanding of where and > what I need to modify in our software's design to implement -sign. Of > course, there are probably some caveats that I will only detect if we > actually implement it, but that should be no major issues. >=20 > Now on to the details. >=20 > ---- abstract ---- > "defined in RFC 3164," >=20 > 3164 is informational, so it is "described" at most > =20 > [same comment for section 1. and section 3. (first paragraph)] >=20 > ---- section 3. ---- > ## > receiving renders the mechanism useless. For this reason, syslog > sender and receiver implementations implementing this specification > MUST support messages of up to and including 2048 octets in length, > ## >=20 > I didn't catch it when it was brought up on list before. I=20 > was thinking > too much of syslog-protocol. However, we must stick with a max size of > 1024 because neither RFC 3164 NOR RFC 3195 allow for more. In=20 > regard to > 3195 this is somewhat debatable, but arguments that more is supported > are on slippery ground. >=20 > ---- section 4.1 ---- > ## > There is a need to distinguish the Signature Block itself from the > syslog message that is used to carry a Signature Block Signature > Blocks MUST be encompassed within completely formed syslog=20 > messages. > ## >=20 > I think there is a period missing "Signature Block###.### Signature > Blocks MUST ...". >=20 > -- > No additional comment on APP-NAME, MSG-ID - see already=20 > existing thread >=20 > ## > Similarly, when used with traditional syslog [10], the Signature > Block message MUST contain a valid TAG field. The TAG field MUST > have the value of "syslog" (without the double quotes) to signify > that this message was generated by the syslog process. > ## >=20 > I think "... was generated by the syslog process." implies a specific > software architecture (which is beyond the scope of the IETF). I would > recommend something along the lines of "that this message is an > administrative message inside the syslog protocol". >=20 > --- section 4.2. --- > The term "bytes" is used. I was advised some time ago that "octets" is > more appropriate inside the IETF. >=20 > The sample is missing the quotes around SD-PARAMs. It should read as > follows: >=20 > "[ssign VER=3D"xxx" RSID=3D"xxx" SG=3D"xxx" SPRI=3D"xxx" GBC=3D"xxx" = FMN=3D"xxx" > CNT=3D"xxx" > HB=3D"xxx" SIGN=3D"xxx"]" >=20 > ---- section 4.2.1 ---- > " The Signature Block version field is 4 characters in length." > We must be careful. Syslog-protocol now mandates UTF-8 in=20 > this field. So > a character is not equal to an octet. I guess octet is meant.=20 > If I read > on, the term "byte" reappears. I suggest using a unified term. This > comment also applies to the sections following after 4.2.1. >=20 >=20 > --- section 4.2.3 --- > This is not something overly important... but might it be possible to > allow 999 sig groups when SG is '3'? I agree it is unlikely=20 > to have more > than 192 groups, but does it hurt to support it in (rare)=20 > cases where it > might be needed? >=20 > ---- section 4.2.4 ---- > I do not understand why the global block counter works across=20 > different > signature groups. Wouldn't it be more useful if it were on a > per-signature-group basis? I would appreciate if you could elaborate a > little on the reasoning. >=20 > ---- section 4.2.5 ---- > What happens if the (first) message number latches at 9999999999? What > is the "message number"? I did not find it defined anywhere.=20 > Of course, > I think I can guess (number of messages "sent over" this=20 > signature group > since reboot?) what it means, but it should be defined. >=20 > ---- section 4.2.7 ---- > size needs to be changed back to 1024 (see above for reasons) >=20 > ---- section 5.2 ---- >=20 > -- Bullet Point "b": >=20 > I recommend to refer the timestamp from syslog-protocol=20 > (instead of RFC > 3339) because code to handle that is already present in syslog > applications. >=20 > ---- section 5.3. ---- > size needs to be changed back to 1024 (see above for reasons) >=20 > ---- section 5.3.2.1. ---- > Quotes need to be added to sample: >=20 > "[ssign-cert VER=3D"xxx" RSID=3D"xxx" SG=3D"xxx" SPRI=3D"xxx" = TBPL=3D"xxx" > INDEX=3D"xxx" > FLEN=3D"xxx" FRAG=3D"xxx" SIGN=3D"xxx"]" >=20 >=20 > --- section 5.3.2.6. --- > - This comment is just in case that we will (for whatever=20 > reason) stick > with messages sizes above 1024: then, the fragment length must be 4 > octets. This comment does not apply if we change back to 1024. >=20 > - registry names must be suggested to IANA >=20 > ---- section 7.1 ---- > bullet point "d": > ## > The resulting authenticated log file contains all messages that > have been authenticated and implicitly indicates (by missing > message numbers) all gaps in the authenticated messages. > ## > I think it should be pointed out that "missing" messages are not > necessary actually missing. They might just have never been=20 > sent to this > collector. >=20 > See 4.2.3: > ## > One reasonable way to configure some installations is to have only > one signature group, ... > ## >=20 > The same can apply in relay chains where interim relay may=20 > not relay all > messages to the (same) final destination. >=20 > ---- section 9. ---- > [just for completeness - see other thread] > There are no IANA registries for APP-NAME and MSGID. >=20 > ---- section 12. ---- > Is Reference [4] actually necessary? >=20 > references 8, 9, 11, 13, 14, 15, 16 need to be moved to "Normative > references". Reference [12] can be dropped if my comment above is > followed. >=20 > ---- GENERAL ---- >=20 > - must "Note to RFC Editor" not be a separate section? >=20 > -- use of MUST -- > I am not sure if "MUST" is often enough used. For example,=20 > section 4.2.1 > says=20 >=20 > ## > As such, the version, hash algorithm and signature scheme defined in > this document may be represented as "0111" (without the=20 > quote marks). > ## > This text to me implies that another Version may be used for this > document. That, however, poses a problem on the receiver=20 > side. Should we > say it MUST be "0111" if it is to be interpreted according to this > document. >=20 > Similar comments apply to other places (e.g. 4.2.3.) where I=20 > am missing > a MUST.=20 >=20 > -- RFC 3195 -- >=20 > Is it intentional to just support RAW profile? If so, why? >=20 > -- original syslog messages -- > There is no indication or alteration to the original syslog records > (those that are signed). This is perfectly fine for SG modes=20 > 0, 1 and 2. > For SG 3 it would be useful to have an optional SD-ID for the original > messages themselves specifying the signature group. This could be > something like [signed SG=3D"3" SPRI=3D"xxx"]. This would be very=20 > helpful in > conveying which group the message belongs to. The sender knows this > information, because it needs to build the signature blocks and thus > must know which hash to go into which group. So there is no=20 > extra effort > here. >=20 > I came to this point while I was thinking how to implement=20 > syslog-sign. > Let me quickly explain, it might help grasp the idea behind my > suggestion. >=20 > In rsyslog, I have multiple filters that can be applied to messages. > Among them is PRI, of course, but also things like expressions inside > the MSG text itself. From the design perspective, each=20 > "forward syslog" > action is a sender in itself. I would model it so that each of these > actions will use its own signature group. So I need mode 3.=20 > The question > now is: how can the receiver tell which message belongs to=20 > which group? > The Draft intentionally does provide any guidance here. I think, > however, that stems back to the days where it was modelled=20 > for 3164 and > 3195 exclusively. With -protocol, it is easy to convey that=20 > information > within STRUCTURED-DATA. It makes life on the reciever side=20 > much simpler. > I know this does not work for 3164 and 3195, but in the long term we > will have most messages formatted in -protocol format.=20 > Besides that, if > we add it as optional nothing will be hurt in all of the cases. >=20 > Does that make sense? >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 21 13:13:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSPO-00010D-0q; Thu, 21 Dec 2006 13:12:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSPM-0000z6-Ku for syslog@ietf.org; Thu, 21 Dec 2006 13:12:44 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxSPJ-0006oc-7y for syslog@ietf.org; Thu, 21 Dec 2006 13:12:44 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Dec 2006 13:12:41 -0500 X-IronPort-AV: i="4.12,200,1165208400"; d="scan'208"; a="110052855:sNHT48945128" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBLICfvA022137; Thu, 21 Dec 2006 13:12:41 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBLICeG9027447; Thu, 21 Dec 2006 13:12:40 -0500 (EST) 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); Thu, 21 Dec 2006 13:12:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] RFC 3164 Date: Thu, 21 Dec 2006 13:12:42 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B731220256E9BB@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] RFC 3164 Thread-Index: Acckz2OY3NjOU31zRw6CNYbBI2H1nAAXAM/A From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , X-OriginalArrivalTime: 21 Dec 2006 18:12:40.0595 (UTC) FILETIME=[9A4DA630:01C7252B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2718; t=1166724761; x=1167588761; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=20=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:=20RE=3A=20[Syslog]=20RFC=203164 |Sender:=20 |To:=20=22Rainer=20Gerhards=22=20, =20; bh=d7BsngWLlbWQfZH2+OeSgEHSt8jK1a1JNLb3PTM4esY=; b=ePh9bhDLUtgaFnf65mUb0rmsOKoX6j8uX0gVE6Cdef4GUQ9deksqLBoRsUSBkq2IgEoypJnY arIzv2b6xN4aFgFbH5iEZshNqi23OdZ3PhBHIesEWR0287NCR93gKWM9; Authentication-Results: rtp-dkim-1; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Rainer: I think it should be marked as obsoleted by the new RFC, which I believe is commonly done. Why bother updating an obsoleted document? How much common will you find in the wild aside from PRI? =20 Thanks, Anton. =20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Wednesday, December 20, 2006 11:13 PM > To: syslog@ietf.org > Subject: [Syslog] RFC 3164 >=20 > Hi all, >=20 > I just realized that the future of RFC 3164 is not yet=20 > publically discussed. >=20 > RFC 3164 is a well-done work, but we have made much progress=20 > in the past > 5 years since it was written. Most importantly, we discovered=20 > that actual syslog software uses a much different set of=20 > formats than expected by 3164. This was the source of much=20 > discussion inside the WG and we did a lot of testing to=20 > confirm the findings. The bottom line is that we now know=20 > that 3164 does *not* acurately describe what is observed in=20 > the wild. Nobody is to blame here - the breadth of=20 > information we created the past years was simply not=20 > available (nor were the ressources to do the testing) to the=20 > orginal authors of RFC 3164. >=20 > Having said that, I think we must do something about the=20 > situation. In practice I see more and more vendors claim=20 > compliance to RFC 3164. This is kind of funny in itself,=20 > because 3164 is just an information document, so you can not=20 > be compliant to it ;) Anyhow, many vendors seem to have a=20 > wrong impression and use this in their advertising as well as=20 > tech support. >=20 > I think we should do either one of the following: >=20 > 1. create an updated RFC 3164bis > 2. obsolete RFC 3164 >=20 > I personally would tend to 1. - update the document with what=20 > we have gained on additional knowledge. I have been told that=20 > this would be somewhat unusual for the IETF, as 3164 is only=20 > informational and -transport-protocol will soon set a real=20 > standard. So updating information on "the past" seems not to=20 > be useful. However, I expect traditional syslog to stay=20 > around for at least another 5 to 10 years, if not longer. I=20 > would consider it a plus to have a RFC that accurately=20 > describes the format that we can expect from such a legacy=20 > syslog sender. Most importantly, it will remove any false=20 > secure feeling about format standardization where there is none. >=20 > I would appreciate comments on this issue. >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 21 15:51:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUsC-0002oo-I0; Thu, 21 Dec 2006 15:50:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUs4-0002ig-PD; Thu, 21 Dec 2006 15:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GxUs4-0004Ud-EI; Thu, 21 Dec 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 29DA717626; Thu, 21 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GxUrZ-00042i-Nk; Thu, 21 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 21 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-device-mib-12.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Syslog Management Information Base Author(s) : G. Keeni Filename : draft-ietf-syslog-device-mib-12.txt Pages : 45 Date : 2006-12-21 This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-device-mib-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-device-mib-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-21132052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-device-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-device-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-21132052.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Thu Dec 21 20:51:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxZYd-00014G-Uh; Thu, 21 Dec 2006 20:50:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxZYc-00014B-QD for syslog@ietf.org; Thu, 21 Dec 2006 20:50:46 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxZYb-0008So-4b for syslog@ietf.org; Thu, 21 Dec 2006 20:50:46 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBM1ocJW019319; Fri, 22 Dec 2006 10:50:38 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBM1oVsN008158; Fri, 22 Dec 2006 10:50:38 +0900 (JST) Message-ID: <458B39E7.9040406@cysols.com> Date: Fri, 22 Dec 2006 10:50:31 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org References: <168c01c72146$0fa1ae70$0600a8c0@china.huawei.com> In-Reply-To: <168c01c72146$0fa1ae70$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: "Wijnen, Bert \(Bert\)" Subject: [Syslog] Re: Mib-12 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, draft-ietf-syslog-device-mib-12.txt has been posted. The current status wrt the sets of comments in Dbh re-Review of -mib-11, part 1,2,3 given below. There are three areas of work: a. terminology. (1.1, 1.2, 1.3, 1.4) We need to arrive at a consensus b. TransportDomain matter: I have to do some work on this TransportDomain matter (1.7, 1.8, 2.1) c. The enumeration of the error cases (1.11) I have to do some work on this. The other matters are either resolved or waiting on further comments. I have attempted to explain or provide possible workarounds. If there are no comments I will mark those as resolved. Glenn 1.1 TBD. Waiting for consensus to emerge on terminology 1.2 Same as 1.1 1.3 Same as 1.1 1.4 Same as 1.1 1.5 Changed "group" to "subtree" in Section 3 (The MIB Design). 1.6 Removed enumeration "other" from the enumeration for SyslogSeverity. This case does not arise. 1.7 TBD. TransportDomain matter. Waiting for confirmation/ clarification. 1.8 TBD. Related to 1.7 1.9 Waiting for feedback from WG on index usage 1.10 TBD. Waiting for confirmation from WG. 1.11 TBD [enumeration of the error cases=> Glenn] 1.12 Waiting for confirmation from WG. 1.13 Same as 1.12 2.1 TBD TransportDomain matter. Related to 1.7 2.2 Withdrawn 2.3 Resolved Revised DESCRIPTION of syslogEntityControlStorageType 2.4 Resolved Revised DESCRIPTION of syslogEntityStatusChanged 2.5 TBD. Do we want to make notifications Optional ? Waiting on Working Group feedback 2.6 Withdrawn 2.7 Resolved Updated the boilerplate for the Copyright notice. http://tools.ietf.org/tools/idnits/ shows zero errors. 3.1 Resolved Updated the boilerplate for the Copyright notice. http://tools.ietf.org/tools/idnits/ shows zero errors. 3.2 Resolved. Changed "should" to "SHOULD" in DESCRIPTION of syslogEntityOperationsReference 3.3 TBD. Waiting on WG confirmation 3.4 Resolved. Changed RFCPROT to "[RFCPROT]" in REFERENCE of syslogDefaultTransportDomain David Harrington wrote: > Hi Glenn, > > Once you finish updating the document with the issues we agree on, can > you publish a mib-12 so we narrow the discussion to the few remaining > issues? > > Thanks, > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 21 21:24:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxa52-0000Ac-Ty; Thu, 21 Dec 2006 21:24:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxa51-0000AX-Ua for syslog@ietf.org; Thu, 21 Dec 2006 21:24:15 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxa50-000774-AK for syslog@ietf.org; Thu, 21 Dec 2006 21:24:15 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBM2OCJW020673; Fri, 22 Dec 2006 11:24:12 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBM2OAsN008541; Fri, 22 Dec 2006 11:24:12 +0900 (JST) Message-ID: <458B41CA.1050108@cysols.com> Date: Fri, 22 Dec 2006 11:24:10 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: TransportDomain. Was: Re: [Syslog] Submission of draft-ietf-syslog-device-mib-12.txt References: <458A2081.1060800@cysols.com> <20061221143808.GC2166@boskop.local> In-Reply-To: <20061221143808.GC2166@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Wijnen, Bert \(Bert\)" X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Juergen, Juergen Schoenwaelder wrote: > On Thu, Dec 21, 2006 at 02:49:53PM +0900, Glenn M. Keeni wrote: > >> Attached please find the updated ID >> draft-ietf-syslog-device-mib-12.txt > > The combination of > > syslogEntityControlBindAddrType InetAddressType > syslogEntityControlBindAddr InetAddress > syslogEntityControlTransportDomain TransportDomain > syslogEntityControlService SyslogService > > looks a bit crazy to me. I seemed to have missed something here. It will help if you can tell me where I am going wrong in the following: > > - Why have both InetAddressType and TransportDomain? We will not have this. > > - Why not simply use (InetAddressType,InetAddress,InetPortNumber) or > (TansportAddressType,TransportAddress)? We got started with InetAddressType,InetAddress,InetPortNumber. But then we realized that we will have problems representing transport over TLS etc. We can not use TransportAddressType,TransportAddress as there is no transport type specified for (syslog) Transport over TLS > - What is the value of saying the service name is "xyz", which has > only local significance? Is this referring to syslogEntityControlService? We will probably not need this. > > - How do I find out which encapsulations are supported (plain, beep, > tls, ...)? That is the problem we are trying to solve. Can that be done by defining appropriate domains for syslog transport over TLS syslog transport over beep etc. ? Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 02:40:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxf0I-0005g0-6f; Fri, 22 Dec 2006 02:39:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxf0H-0005fs-1u for syslog@ietf.org; Fri, 22 Dec 2006 02:39:41 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxf0F-0000TI-Fh for syslog@ietf.org; Fri, 22 Dec 2006 02:39:41 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id C83B327C013; Fri, 22 Dec 2006 08:42:07 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22912-02; Fri, 22 Dec 2006 08:42:07 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 6BB3F27C012; Fri, 22 Dec 2006 08:42:07 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 08:39:31 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] RFC 3164 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Dec 2006 08:39:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8968@grfint2.intern.adiscon.com> In-Reply-To: <000b01c7254a$63bc7050$d901a8c0@KiwiAndrew> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] RFC 3164 Thread-Index: AcclS1k7ytuhuD71Q4mvL6HItKScpAAT5lKQ References: <23037230.1166685385663.JavaMail.root@m35> <000b01c7254a$63bc7050$d901a8c0@KiwiAndrew> From: "Rainer Gerhards" To: X-OriginalArrivalTime: 22 Dec 2006 07:39:31.0286 (UTC) FILETIME=[5152DF60:01C7259C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Andrew, Anton, I am using Andrew's message to reply to both. I concur with Andrew, please see below... > -----Original Message----- > From: Andrew Ross [mailto:andrew@kiwisyslog.com] > Sent: Thursday, December 21, 2006 10:53 PM > To: Rainer Gerhards > Subject: RE: [Syslog] RFC 3164 >=20 >=20 > Hi Rainer, >=20 > Merry Christmas! >=20 > Sorry I've been out of the discussion loop for so long, things have > been > pretty hectic over here. I know that the new protocols are in good > hands > though. >=20 > With regard to 3164. I would prefer to obsolete 3164 with a document > that > details what is actually seen in real life on the wire. This would just > mean > adding some extra text to the 3164 document and adding in some examples > of > what is seen by different OS senders. Pretty much the research you > presented > to the list a while ago. This new document would then obsolete 3164. That would actually be my prefferred way to handle things. Other than Andrew, I think we should remove/change most of the text, as indeed only PRI is available on an universal basis. Samples of different message formats can be used to convey that information. > We get asked so often by customers if we are 3164 compliant. We used to > explain that 3164 is not really valid, but that didn't satisfy them, so > we > just said "yes, we are compliant" to keep them happy. Now to the question "why do that?". Andrew has a very valid point here. We experience the same quite often. We even added an option "use RFC 3164 compatible format" to our product and guess what - it is turned off most of the time because RFC 3164 does not describe what receivers and senders typically do ;). Even if we obsolete 3164 with -protocol, I know a lot of folks will come and ask "Hey, do you support the old standard that most of my other devices use?". They simply will not care about it being obsoleted by something different. However, if we go ahead and crate 3164bis (another informational document), the situation will IMHO change. Now there is a newer "standard" (as people perceive it) for the "old" syslog. And if that says "You can not trust anything but PRI" I can "sell" that. Plus, I have a very good point in argumenting why syslog-protocol is superior. I know I am not talking hard technical facts here. I am talking real life. Most people do not care if a RFC is informational or standards track. If it is a RFC, it must be something products comply too. I agree that implementors should understand the difference. They (hopefully/probably) do. But do implementors actually decide what to implement? No - not in my experience. The marketing department tells them what to do. And customers tell the marketing department. And guess what? These customers are the informed masses that do *not* know the inner workings of the IETF (aka "a RFC is a RFC is a RFC..."). Even in a technical context like the IETF I think a little bit of real-world politics can be considered. It is the key to acceptance of new standards. Rainer >=20 > Cheers >=20 > Andrew >=20 >=20 >=20 >=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Thursday, 21 December 2006 8:13 p.m. > To: syslog@ietf.org > Subject: [Syslog] RFC 3164 >=20 >=20 > Hi all, >=20 > I just realized that the future of RFC 3164 is not yet publically > discussed. >=20 > RFC 3164 is a well-done work, but we have made much progress in the > past > 5 years since it was written. Most importantly, we discovered that > actual syslog software uses a much different set of formats than > expected by 3164. This was the source of much discussion inside the WG > and we did a lot of testing to confirm the findings. The bottom line is > that we now know that 3164 does *not* acurately describe what is > observed in the wild. Nobody is to blame here - the breadth of > information we created the past years was simply not available (nor > were > the ressources to do the testing) to the orginal authors of RFC 3164. >=20 > Having said that, I think we must do something about the situation. In > practice I see more and more vendors claim compliance to RFC 3164. This > is kind of funny in itself, because 3164 is just an information > document, so you can not be compliant to it ;) Anyhow, many vendors > seem > to have a wrong impression and use this in their advertising as well as > tech support. >=20 > I think we should do either one of the following: >=20 > 1. create an updated RFC 3164bis > 2. obsolete RFC 3164 >=20 > I personally would tend to 1. - update the document with what we have > gained on additional knowledge. I have been told that this would be > somewhat unusual for the IETF, as 3164 is only informational and > -transport-protocol will soon set a real standard. So updating > information on "the past" seems not to be useful. However, I expect > traditional syslog to stay around for at least another 5 to 10 years, > if > not longer. I would consider it a plus to have a RFC that accurately > describes the format that we can expect from such a legacy syslog > sender. Most importantly, it will remove any false secure feeling about > format standardization where there is none. >=20 > I would appreciate comments on this issue. >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 04:34:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxgnH-00054w-5F; Fri, 22 Dec 2006 04:34:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxgnF-00054r-QT for syslog@ietf.org; Fri, 22 Dec 2006 04:34:21 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxgnD-0001w0-BN for syslog@ietf.org; Fri, 22 Dec 2006 04:34:21 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 660C35AD1F; Fri, 22 Dec 2006 10:34:16 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 16652-03; Fri, 22 Dec 2006 10:34:13 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 069505AD2E; Fri, 22 Dec 2006 10:34:12 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 38934904DD8; Fri, 22 Dec 2006 10:34:09 +0100 (CET) Date: Fri, 22 Dec 2006 10:34:09 +0100 From: Juergen Schoenwaelder To: "Glenn M. Keeni" Subject: Re: TransportDomain. Was: Re: [Syslog] Submission of draft-ietf-syslog-device-mib-12.txt Message-ID: <20061222093409.GA4476@boskop.local> Mail-Followup-To: "Glenn M. Keeni" , syslog@ietf.org, "Wijnen, Bert (Bert)" References: <458A2081.1060800@cysols.com> <20061221143808.GC2166@boskop.local> <458B41CA.1050108@cysols.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <458B41CA.1050108@cysols.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Wijnen, Bert \(Bert\)" , syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Fri, Dec 22, 2006 at 11:24:10AM +0900, Glenn M. Keeni wrote: > >- How do I find out which encapsulations are supported (plain, beep, > > tls, ...)? > That is the problem we are trying to solve. > Can that be done by defining appropriate domains for > syslog transport over TLS > syslog transport over beep etc. ? Option a): You use a four tuple consisting of: (InetAddressType, InetAddress, InetPortNumer, SyslogEncapsulation) Option b): You use a three tuple consisting of: (TransportAddressType, TransportAddress, SyslogEncapsulation) In both cases, you need to define a TC SyslogEncapsulation which enumerates the syslog encapsulations (or transport mappings) such as { other(0), plain(1), tls(2), beep(3), ... }. InetAddress identifies Internet network layer endpoints while TransportAddress identifies Internet transport layer endpoints, no more no less. If you want to move to a two tuple, the only option in principle is: Option c): You use a two tuple consisting of (SyslogAddressType, SyslogAddress) where SyslogAddressType combines the address type with the encapsulation (this is essentially what a TDomain does for SNMP) /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 08:06:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxk5s-0008WA-MO; Fri, 22 Dec 2006 08:05:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxk5r-0008US-6a for syslog@ietf.org; Fri, 22 Dec 2006 08:05:47 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxk5p-0003Ng-UZ for syslog@ietf.org; Fri, 22 Dec 2006 08:05:47 -0500 Received: from pc6 (1Cust85.tnt106.lnd4.gbr.da.uu.net [213.116.60.85]) by ranger.systems.pipex.net (Postfix) with SMTP id 5A9DDE000395; Fri, 22 Dec 2006 13:05:44 +0000 (GMT) Message-ID: <01e901c725c1$741b23c0$0601a8c0@pc6> From: "tom.petch" To: "Anton Okmianski (aokmians)" , "Rainer Gerhards" , References: <98AE08B66FAD1742BED6CB9522B731220256E9BB@xmb-rtp-20d.amer.cisco.com> Subject: Re: [Syslog] RFC 3164 Date: Fri, 22 Dec 2006 12:59:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I agree; make it obsolete, acknowledging the role it has had in moving syslog along. Tom Petch ----- Original Message ----- From: "Anton Okmianski (aokmians)" To: "Rainer Gerhards" ; Sent: Thursday, December 21, 2006 7:12 PM Subject: RE: [Syslog] RFC 3164 Rainer: I think it should be marked as obsoleted by the new RFC, which I believe is commonly done. Why bother updating an obsoleted document? How much common will you find in the wild aside from PRI? Thanks, Anton. > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Wednesday, December 20, 2006 11:13 PM > To: syslog@ietf.org > Subject: [Syslog] RFC 3164 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 08:51:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxknJ-0006Lo-6A; Fri, 22 Dec 2006 08:50:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxknI-0006Lh-2F for syslog@ietf.org; Fri, 22 Dec 2006 08:50:40 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxknF-0002qt-PA for syslog@ietf.org; Fri, 22 Dec 2006 08:50:40 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 22 Dec 2006 05:50:37 -0800 X-IronPort-AV: i="4.12,204,1165219200"; d="scan'208"; a="453039013:sNHT38819000" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kBMDoa4Y011083 for ; Fri, 22 Dec 2006 05:50:36 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kBMDoand028377 for ; Fri, 22 Dec 2006 05:50:36 -0800 (PST) Date: Fri, 22 Dec 2006 05:50:36 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Subject: Consensus - was: Re: [Syslog] RFC 3164 in syslog-sign? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=419; t=1166795437; x=1167659437; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Consensus=20-=20was=3A=20Re=3A=20[Syslog]=20RFC=203164=20in=2 0syslog-sign?=20(fwd) |Sender:=20; bh=4R5I8hycpBz0jpiAd1M1zeijy3cU/6J9ZCLQQPoqkbk=; b=OjfOS5UpqSEsCxKG6IOYZt6hjZGzssJXgR/u/P+/fuJx66UJxOZGCOs23z+KYJOlPbLA0tJb 4iF4bOv/BEbFbqyE6OlK7Hk+1e9+t57iz+RGq0I13NZyfQ6zv9/fqpqC; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Overwhelming consensus is that references to 3164 will be removed from syslog-sign. Alex, Please start working on this but don't submit any changes until after WGLC is complete on 28 Dec. All: Please continue to review the document and let's get this out the door. Thanks, Chris P.S. - Seasons Greetings to All and my very best wishes to everyone for a happy and prosperous New Year. :-) _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 09:01:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxkxR-0004UA-2A; Fri, 22 Dec 2006 09:01:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxkxQ-0004Qb-6w for syslog@ietf.org; Fri, 22 Dec 2006 09:01:08 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxkxO-0004in-JR for syslog@ietf.org; Fri, 22 Dec 2006 09:01:08 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Dec 2006 06:01:06 -0800 X-IronPort-AV: i="4.12,204,1165219200"; d="scan'208"; a="94168561:sNHT94031802" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kBME131D020257; Fri, 22 Dec 2006 06:01:03 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBME0t4h006535; Fri, 22 Dec 2006 06:00:55 -0800 (PST) Date: Fri, 22 Dec 2006 06:00:54 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] RFC 3164 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8968@grfint2.intern.adiscon.com> Message-ID: References: <23037230.1166685385663.JavaMail.root@m35> <000b01c7254a$63bc7050$d901a8c0@KiwiAndrew> <577465F99B41C842AAFBE9ED71E70ABA1F8968@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6316; t=1166796063; x=1167660063; 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]=20RFC=203164 |Sender:=20; bh=3PfxTQwFyqbGWuTWECvhkLZbPuIinTWEQcu6JCldK7o=; b=RSi8vtm+WWr0HvYI6wFGCqC9c047i/lQNkfVXRXx6Q6k7NwGP8qPgP1AZ5jGOmJzpHP44GMx eUAKUDtInSfFqev4QFhSdURaEvVcCH+bSZ5Tsc3Eeh82UkFy/koHKpPn; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: andrew@kiwisyslog.com, syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The Chairs have spoken to the author of RFC 3164. The author agrees that it should be OBSOLETED. ;-) I did discuss this with someone who has been trying to de-cruft a lot of ancient RFCs. It is not usual to OBSOLETE an INFORMATIONAL RFC but there's nothing that says that we can't do it. When syslog-protocol gets into the RFC Editors queue, I will tell them to OBSOLETE RFC 3164 with that document. Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: > Andrew, Anton, > > I am using Andrew's message to reply to both. I concur with Andrew, > please see below... > >> -----Original Message----- >> From: Andrew Ross [mailto:andrew@kiwisyslog.com] >> Sent: Thursday, December 21, 2006 10:53 PM >> To: Rainer Gerhards >> Subject: RE: [Syslog] RFC 3164 >> >> >> Hi Rainer, >> >> Merry Christmas! >> >> Sorry I've been out of the discussion loop for so long, things have >> been >> pretty hectic over here. I know that the new protocols are in good >> hands >> though. >> >> With regard to 3164. I would prefer to obsolete 3164 with a document >> that >> details what is actually seen in real life on the wire. This would > just >> mean >> adding some extra text to the 3164 document and adding in some > examples >> of >> what is seen by different OS senders. Pretty much the research you >> presented >> to the list a while ago. This new document would then obsolete 3164. > > That would actually be my prefferred way to handle things. Other than > Andrew, I think we should remove/change most of the text, as indeed only > PRI is available on an universal basis. Samples of different message > formats can be used to convey that information. > >> We get asked so often by customers if we are 3164 compliant. We used > to >> explain that 3164 is not really valid, but that didn't satisfy them, > so >> we >> just said "yes, we are compliant" to keep them happy. > > Now to the question "why do that?". Andrew has a very valid point here. > We experience the same quite often. We even added an option "use RFC > 3164 compatible format" to our product and guess what - it is turned off > most of the time because RFC 3164 does not describe what receivers and > senders typically do ;). Even if we obsolete 3164 with -protocol, I know > a lot of folks will come and ask "Hey, do you support the old standard > that most of my other devices use?". They simply will not care about it > being obsoleted by something different. However, if we go ahead and > crate 3164bis (another informational document), the situation will IMHO > change. Now there is a newer "standard" (as people perceive it) for the > "old" syslog. And if that says "You can not trust anything but PRI" I > can "sell" that. Plus, I have a very good point in argumenting why > syslog-protocol is superior. > > I know I am not talking hard technical facts here. I am talking real > life. Most people do not care if a RFC is informational or standards > track. If it is a RFC, it must be something products comply too. I agree > that implementors should understand the difference. They > (hopefully/probably) do. But do implementors actually decide what to > implement? No - not in my experience. The marketing department tells > them what to do. And customers tell the marketing department. And guess > what? These customers are the informed masses that do *not* know the > inner workings of the IETF (aka "a RFC is a RFC is a RFC..."). > > Even in a technical context like the IETF I think a little bit of > real-world politics can be considered. It is the key to acceptance of > new standards. > > Rainer >> >> Cheers >> >> Andrew >> >> >> >> >> -----Original Message----- >> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] >> Sent: Thursday, 21 December 2006 8:13 p.m. >> To: syslog@ietf.org >> Subject: [Syslog] RFC 3164 >> >> >> Hi all, >> >> I just realized that the future of RFC 3164 is not yet publically >> discussed. >> >> RFC 3164 is a well-done work, but we have made much progress in the >> past >> 5 years since it was written. Most importantly, we discovered that >> actual syslog software uses a much different set of formats than >> expected by 3164. This was the source of much discussion inside the WG >> and we did a lot of testing to confirm the findings. The bottom line > is >> that we now know that 3164 does *not* acurately describe what is >> observed in the wild. Nobody is to blame here - the breadth of >> information we created the past years was simply not available (nor >> were >> the ressources to do the testing) to the orginal authors of RFC 3164. >> >> Having said that, I think we must do something about the situation. In >> practice I see more and more vendors claim compliance to RFC 3164. > This >> is kind of funny in itself, because 3164 is just an information >> document, so you can not be compliant to it ;) Anyhow, many vendors >> seem >> to have a wrong impression and use this in their advertising as well > as >> tech support. >> >> I think we should do either one of the following: >> >> 1. create an updated RFC 3164bis >> 2. obsolete RFC 3164 >> >> I personally would tend to 1. - update the document with what we have >> gained on additional knowledge. I have been told that this would be >> somewhat unusual for the IETF, as 3164 is only informational and >> -transport-protocol will soon set a real standard. So updating >> information on "the past" seems not to be useful. However, I expect >> traditional syslog to stay around for at least another 5 to 10 years, >> if >> not longer. I would consider it a plus to have a RFC that accurately >> describes the format that we can expect from such a legacy syslog >> sender. Most importantly, it will remove any false secure feeling > about >> format standardization where there is none. >> >> I would appreciate comments on this issue. >> >> Rainer >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 09:56:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxloT-0008R7-Va; Fri, 22 Dec 2006 09:55:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxloS-0008R1-O6 for syslog@ietf.org; Fri, 22 Dec 2006 09:55:56 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxloR-0004Kr-Ew for syslog@ietf.org; Fri, 22 Dec 2006 09:55:56 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3FC0327C013 for ; Fri, 22 Dec 2006 15:58:28 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04710-03 for ; Fri, 22 Dec 2006 15:58:28 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 0039227C012 for ; Fri, 22 Dec 2006 15:58:27 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 15:55:51 +0100 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: Fri, 22 Dec 2006 15:55:50 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8987@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3195bis? Thread-Index: Accl2UVC6+n6h0DISSyD/XttUEI5Ig== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 22 Dec 2006 14:55:51.0245 (UTC) FILETIME=[45CB97D0:01C725D9] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Syslog] RFC 3195bis? X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi all, now that we obsolete RFC 3164 by -syslog-protocol, the only remaining RFC that is not compatible to the "new syslog series" is RFC 3195. The questions is now how to proceed here? I am raising this issue because it has some effect on syslog-sign. I would love to see 2k as limit for sign-generated messages, but that means we need to talk about 3195 (which not explicitely supports messages over 1k). IMHO, we should do a 3195bis that updates 3195 to work as a transport mapping with syslog-protocol. After we've done that, we have finally unified all syslog RFCs and do not have any more issues with incompatibilities between them. I think this is something we should do soon. Comments? Rainer PS: I, too, would like to express my seasons greetings to all folks on the list! May you have a great and peaceful xmas time and a good start into the new year. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 10:31:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxmM4-0001j3-6i; Fri, 22 Dec 2006 10:30:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxmM2-0001iw-OM for syslog@ietf.org; Fri, 22 Dec 2006 10:30:38 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxmM1-0001AI-E8 for syslog@ietf.org; Fri, 22 Dec 2006 10:30:38 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 22 Dec 2006 07:30:36 -0800 X-IronPort-AV: i="4.12,205,1165219200"; d="scan'208"; a="757310623:sNHT73080780" 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 kBMFUZOD019068; Fri, 22 Dec 2006 07:30:35 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kBMFUYnd015165; Fri, 22 Dec 2006 07:30:34 -0800 (PST) Date: Fri, 22 Dec 2006 07:30:34 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: Re: [Syslog] RFC 3195bis? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8987@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA1F8987@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1666; t=1166801435; x=1167665435; 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]=20RFC=203195bis? |Sender:=20; bh=Cjm2uxQ6FbirSzb1xEnafxH3DlkW+KxejYqooYPXPPM=; b=svGSg08LKhMTw5Ww/ShlCEE7+fV91bUcAs7zT9+KCRKxiftyRP+6If/LiFkcE1VKpl4ppq8p 7m7I5cWq9dSmC7+dZmiYA3Qazj8fJUElQASxd4frFM4Av1jjaeiHuKB4; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The Chairs have been discussing this already. We have a candidate to write the update. The length limit in RFC 3195 was constrained by RFC 3164 and we have moved beyond that with the transport IDs which identify realistic maximum lengths. Updating RFC 3195 to have a greater length should not be a problem. HOWEVER... We need to focus on syslog-sign and syslog-device-mib BEFORE doing this. Once we get the shepherding documents for those IDs sent to the IESG _THEN_ we can discuss 3195bis. Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: > Hi all, > > now that we obsolete RFC 3164 by -syslog-protocol, the only remaining > RFC that is not compatible to the "new syslog series" is RFC 3195. The > questions is now how to proceed here? I am raising this issue because it > has some effect on syslog-sign. I would love to see 2k as limit for > sign-generated messages, but that means we need to talk about 3195 > (which not explicitely supports messages over 1k). > > IMHO, we should do a 3195bis that updates 3195 to work as a transport > mapping with syslog-protocol. After we've done that, we have finally > unified all syslog RFCs and do not have any more issues with > incompatibilities between them. I think this is something we should do > soon. > > Comments? > > Rainer > PS: I, too, would like to express my seasons greetings to all folks on > the list! May you have a great and peaceful xmas time and a good start > into the new year. > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 11:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxn0D-000672-Kk; Fri, 22 Dec 2006 11:12:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxn0C-00063m-0D for syslog@ietf.org; Fri, 22 Dec 2006 11:12:08 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxn09-0001oN-Gm for syslog@ietf.org; Fri, 22 Dec 2006 11:12:07 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 28A6B27C013; Fri, 22 Dec 2006 17:14:38 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06306-08; Fri, 22 Dec 2006 17:14:38 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id C797027C012; Fri, 22 Dec 2006 17:14:37 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 17:12:03 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] RFC 3195bis? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Dec 2006 17:11:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8989@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] RFC 3195bis? Thread-Index: Accl3in+YWG/JeMSRpC09qVYi10pFwAA5hfw References: <577465F99B41C842AAFBE9ED71E70ABA1F8987@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 22 Dec 2006 16:12:03.0233 (UTC) FILETIME=[EAE99910:01C725E3] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > The Chairs have been discussing this already. We have a candidate to > write the update. The length limit in RFC 3195 was constrained by RFC > 3164 and we have moved beyond that with the transport IDs which > identify > realistic maximum lengths. Updating RFC 3195 to have a greater length > should not be a problem. >=20 > HOWEVER... We need to focus on syslog-sign and syslog-device-mib > BEFORE > doing this. Once we get the shepherding documents for those IDs sent > to > the IESG _THEN_ we can discuss 3195bis. The problem is that -sign is related (even depending) on 3195. This is why I brought up that issue. Let me explain. syslog-sign recommends 2k for signature and payload blocks. It does so, because it assumes (rightly for the new series) that 2k can be handled by almost every receiver, so there is no problem in using that length. However, if we require that -sign works together with 3195, we must lower this limit to 1k. I would not like to see this happen because 2k makes much sense and is much more efficient. 3195 does not seem as important: - it is due for update - there has only been an extremely limited set of implementations - none of the major vendors has implemented it - there is no (not "virtually no"!) customer demand for it at the=20 time being (I know this because I have implemented RFC 3195) - the only customer demand comes from IHE, but for IHE it is not usable because it still contains a too-rigid length constraint In short: the current RFC 3195 is not really in use. An updated version may. I think we should not sacrifice the 2k limit for something that is not being used. So my propsal is: we should remove RFC 3195 from syslog-sign as well. It should simply reference -syslog-protocol and its transport mappings. RFC 3195bis will most likely be a transport mapping. Thus, -sign can cover it without specifically mentioning it. This works exactly as the new series is designed. Transports are below -protocol and sign is in the layer above it. So there should be no dependencies between -sign and the actual transports used. If we take that route, we only lose the ability to use -sign *reliably* with RFC 3195 as it is today. Given the fact that nobody is actually using 3195, this is not a huge loss ;). It also finally de-couples -sign from any other transport RFCs - and this was a major intention about the whole effort of the new syslog series. I suggest we all have a look at this slide from 2004: http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html Rainer > Thanks, > Chris >=20 > On Fri, 22 Dec 2006, Rainer Gerhards wrote: >=20 > > Hi all, > > > > now that we obsolete RFC 3164 by -syslog-protocol, the only remaining > > RFC that is not compatible to the "new syslog series" is RFC 3195. > The > > questions is now how to proceed here? I am raising this issue because > it > > has some effect on syslog-sign. I would love to see 2k as limit for > > sign-generated messages, but that means we need to talk about 3195 > > (which not explicitely supports messages over 1k). > > > > IMHO, we should do a 3195bis that updates 3195 to work as a transport > > mapping with syslog-protocol. After we've done that, we have finally > > unified all syslog RFCs and do not have any more issues with > > incompatibilities between them. I think this is something we should > do > > soon. > > > > Comments? > > > > Rainer > > PS: I, too, would like to express my seasons greetings to all folks > on > > the list! May you have a great and peaceful xmas time and a good > start > > into the new year. > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 11:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxnAb-0003AR-CM; Fri, 22 Dec 2006 11:22:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxnAZ-0003AI-Kj for syslog@ietf.org; Fri, 22 Dec 2006 11:22:51 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxnAV-00044T-5M for syslog@ietf.org; Fri, 22 Dec 2006 11:22:51 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Dec 2006 08:22:46 -0800 X-IronPort-AV: i="4.12,205,1165219200"; d="scan'208"; a="94217456:sNHT45946170" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBMGMkhV023220; Fri, 22 Dec 2006 08:22:46 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBMGMkPo016417; Fri, 22 Dec 2006 08:22:46 -0800 (PST) Date: Fri, 22 Dec 2006 08:22:45 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] RFC 3195bis? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8989@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA1F8987@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA1F8989@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4379; t=1166804566; x=1167668566; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20RE=3A=20[Syslog]=20RFC=203195bis? |Sender:=20; bh=iycOUMsMFUp5hpkFem5XVWy4uFRo2fg2TKRxr3/lyrY=; b=XVDw4/CDRmH9fML1da/d1WnEYqj5nPOcmNNLcDH5EldZk6eR5Ih7VG9BMglWE9GWMOCZbi1S LdZQ9Atq01aLYnmeU/ltIsTXq3KSaZfQLPjXlgFX8xyM9qGAnLCZFZx4; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I'm OK removing references to RFC 3195 from syslog-sign for the points you mention. I'd welcome other opinions. I agree that RFC 3195 is due for an update but I disagree with most of your other points. A major vendor has found customers requesting it and has implemented it. http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a00807883c3.html Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: >> The Chairs have been discussing this already. We have a candidate to >> write the update. The length limit in RFC 3195 was constrained by RFC >> 3164 and we have moved beyond that with the transport IDs which >> identify >> realistic maximum lengths. Updating RFC 3195 to have a greater length >> should not be a problem. >> >> HOWEVER... We need to focus on syslog-sign and syslog-device-mib >> BEFORE >> doing this. Once we get the shepherding documents for those IDs sent >> to >> the IESG _THEN_ we can discuss 3195bis. > > The problem is that -sign is related (even depending) on 3195. This is > why I brought up that issue. > > Let me explain. syslog-sign recommends 2k for signature and payload > blocks. It does so, because it assumes (rightly for the new series) that > 2k can be handled by almost every receiver, so there is no problem in > using that length. However, if we require that -sign works together with > 3195, we must lower this limit to 1k. I would not like to see this > happen because 2k makes much sense and is much more efficient. 3195 does > not seem as important: > > - it is due for update > - there has only been an extremely limited set of implementations > - none of the major vendors has implemented it > - there is no (not "virtually no"!) customer demand for it at the > time being (I know this because I have implemented RFC 3195) > - the only customer demand comes from IHE, but for IHE it is not > usable because it still contains a too-rigid length constraint > > In short: the current RFC 3195 is not really in use. An updated version > may. I think we should not sacrifice the 2k limit for something that is > not being used. > > So my propsal is: we should remove RFC 3195 from syslog-sign as well. It > should simply reference -syslog-protocol and its transport mappings. RFC > 3195bis will most likely be a transport mapping. Thus, -sign can cover > it without specifically mentioning it. This works exactly as the new > series is designed. Transports are below -protocol and sign is in the > layer above it. So there should be no dependencies between -sign and the > actual transports used. > > If we take that route, we only lose the ability to use -sign *reliably* > with RFC 3195 as it is today. Given the fact that nobody is actually > using 3195, this is not a huge loss ;). It also finally de-couples -sign > from any other transport RFCs - and this was a major intention about the > whole effort of the new syslog series. > > I suggest we all have a look at this slide from 2004: > > http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html > > Rainer > > >> Thanks, >> Chris >> >> On Fri, 22 Dec 2006, Rainer Gerhards wrote: >> >>> Hi all, >>> >>> now that we obsolete RFC 3164 by -syslog-protocol, the only > remaining >>> RFC that is not compatible to the "new syslog series" is RFC 3195. >> The >>> questions is now how to proceed here? I am raising this issue > because >> it >>> has some effect on syslog-sign. I would love to see 2k as limit for >>> sign-generated messages, but that means we need to talk about 3195 >>> (which not explicitely supports messages over 1k). >>> >>> IMHO, we should do a 3195bis that updates 3195 to work as a > transport >>> mapping with syslog-protocol. After we've done that, we have finally >>> unified all syslog RFCs and do not have any more issues with >>> incompatibilities between them. I think this is something we should >> do >>> soon. >>> >>> Comments? >>> >>> Rainer >>> PS: I, too, would like to express my seasons greetings to all folks >> on >>> the list! May you have a great and peaceful xmas time and a good >> start >>> into the new year. >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >>> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 11:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxnP4-0002RA-Te; Fri, 22 Dec 2006 11:37:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxnP3-0002R5-S9 for syslog@ietf.org; Fri, 22 Dec 2006 11:37:49 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxnP2-00074V-8A for syslog@ietf.org; Fri, 22 Dec 2006 11:37:49 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3605427C013; Fri, 22 Dec 2006 17:40:21 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07630-06; Fri, 22 Dec 2006 17:40:21 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D2C4A27C012; Fri, 22 Dec 2006 17:40:20 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 17:37:45 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] RFC 3195bis? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Dec 2006 17:37:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F898A@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] RFC 3195bis? Thread-Index: Accl5W8+aG/BNlsZQhea/Pd6SX/oRwAAb9Gw References: <577465F99B41C842AAFBE9ED71E70ABA1F8987@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA1F8989@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 22 Dec 2006 16:37:45.0858 (UTC) FILETIME=[82637E20:01C725E7] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Ah... interesting. I knew that Cisco had something brewing, but I never heared that it was released. I still agree with you that 3195 should not specifically be mentioned by -sign. I assume that implementing 3195bis (when available) is probably not hard if you implemented 3195. Rainer=20 > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, December 22, 2006 5:23 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: RE: [Syslog] RFC 3195bis? >=20 > Hi, >=20 > I'm OK removing references to RFC 3195 from syslog-sign for the points > you > mention. I'd welcome other opinions. >=20 > I agree that RFC 3195 is due for an update but I disagree with most of > your other points. A major vendor has found customers requesting it > and > has implemented it. > http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a > 00807883c3.html >=20 > Thanks, > Chris >=20 >=20 > On Fri, 22 Dec 2006, Rainer Gerhards wrote: >=20 > >> The Chairs have been discussing this already. We have a candidate > to > >> write the update. The length limit in RFC 3195 was constrained by > RFC > >> 3164 and we have moved beyond that with the transport IDs which > >> identify > >> realistic maximum lengths. Updating RFC 3195 to have a greater > length > >> should not be a problem. > >> > >> HOWEVER... We need to focus on syslog-sign and syslog-device-mib > >> BEFORE > >> doing this. Once we get the shepherding documents for those IDs > sent > >> to > >> the IESG _THEN_ we can discuss 3195bis. > > > > The problem is that -sign is related (even depending) on 3195. This > is > > why I brought up that issue. > > > > Let me explain. syslog-sign recommends 2k for signature and payload > > blocks. It does so, because it assumes (rightly for the new series) > that > > 2k can be handled by almost every receiver, so there is no problem in > > using that length. However, if we require that -sign works together > with > > 3195, we must lower this limit to 1k. I would not like to see this > > happen because 2k makes much sense and is much more efficient. 3195 > does > > not seem as important: > > > > - it is due for update > > - there has only been an extremely limited set of implementations > > - none of the major vendors has implemented it > > - there is no (not "virtually no"!) customer demand for it at the > > time being (I know this because I have implemented RFC 3195) > > - the only customer demand comes from IHE, but for IHE it is not > > usable because it still contains a too-rigid length constraint > > > > In short: the current RFC 3195 is not really in use. An updated > version > > may. I think we should not sacrifice the 2k limit for something that > is > > not being used. > > > > So my propsal is: we should remove RFC 3195 from syslog-sign as well. > It > > should simply reference -syslog-protocol and its transport mappings. > RFC > > 3195bis will most likely be a transport mapping. Thus, -sign can > cover > > it without specifically mentioning it. This works exactly as the new > > series is designed. Transports are below -protocol and sign is in the > > layer above it. So there should be no dependencies between -sign and > the > > actual transports used. > > > > If we take that route, we only lose the ability to use -sign > *reliably* > > with RFC 3195 as it is today. Given the fact that nobody is actually > > using 3195, this is not a huge loss ;). It also finally de-couples - > sign > > from any other transport RFCs - and this was a major intention about > the > > whole effort of the new syslog series. > > > > I suggest we all have a look at this slide from 2004: > > > > http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html > > > > Rainer > > > > > >> Thanks, > >> Chris > >> > >> On Fri, 22 Dec 2006, Rainer Gerhards wrote: > >> > >>> Hi all, > >>> > >>> now that we obsolete RFC 3164 by -syslog-protocol, the only > > remaining > >>> RFC that is not compatible to the "new syslog series" is RFC 3195. > >> The > >>> questions is now how to proceed here? I am raising this issue > > because > >> it > >>> has some effect on syslog-sign. I would love to see 2k as limit for > >>> sign-generated messages, but that means we need to talk about 3195 > >>> (which not explicitely supports messages over 1k). > >>> > >>> IMHO, we should do a 3195bis that updates 3195 to work as a > > transport > >>> mapping with syslog-protocol. After we've done that, we have > finally > >>> unified all syslog RFCs and do not have any more issues with > >>> incompatibilities between them. I think this is something we should > >> do > >>> soon. > >>> > >>> Comments? > >>> > >>> Rainer > >>> PS: I, too, would like to express my seasons greetings to all folks > >> on > >>> the list! May you have a great and peaceful xmas time and a good > >> start > >>> into the new year. > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >>> > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 12:22:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxo64-0007mr-Pi; Fri, 22 Dec 2006 12:22:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxo63-0007mf-UY for syslog@ietf.org; Fri, 22 Dec 2006 12:22:15 -0500 Received: from ext-ch1gw-2.online-age.net ([216.34.191.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxo5u-0004wY-UI for syslog@ietf.org; Fri, 22 Dec 2006 12:22:15 -0500 Received: from int-ch1gw-2.online-age.net (int-ch1gw-2 [3.159.232.66]) by ext-ch1gw-2.online-age.net (8.13.6/8.13.6/20051111-SVVS-TLS-DNSBL) with ESMTP id kBMHLvBl026073 for ; Fri, 22 Dec 2006 12:22:03 -0500 (EST) Received: from cinmlef08.e2k.ad.ge.com (int-ch1gw-2 [3.159.232.66]) by int-ch1gw-2.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP id kBMHJ30m029886 for ; Fri, 22 Dec 2006 12:19:04 -0500 (EST) Received: from ALPMLVEM07.e2k.ad.ge.com ([3.159.17.66]) by cinmlef08.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 22 Dec 2006 12:21:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] RFC 3195bis? Date: Fri, 22 Dec 2006 12:21:52 -0500 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F898A@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] RFC 3195bis? Thread-Index: Accl5W8+aG/BNlsZQhea/Pd6SX/oRwAAb9GwAACsnxA= From: "Moehrke, John \(GE Healthcare\)" To: "Rainer Gerhards" , "Chris Lonvick" X-OriginalArrivalTime: 22 Dec 2006 17:21:56.0801 (UTC) FILETIME=[AE794B10:01C725ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Much of the reason 3195 is specified is because there is no good alternative. Healthcare has been asking for a stable standard that gets implemented for 4 years now. It is getting hard to justify this allegiance to the syslog community. There are many in the healthcare community that want to define their own transport for security audit events using Web-Services. Please stop the over-analysis, get the standards you have in the queue out, and please get them implemented. John Moehrke GE Healthcare And major contributor to IHE-ATNA, DICOM-Supplement-95, RFC-3881, and BS ISO 27789. http://wiki.ihe.net/index.php?title=3DATNA_Profile_FAQ =20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Friday, December 22, 2006 10:38 AM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: RE: [Syslog] RFC 3195bis? >=20 > Ah... interesting. I knew that Cisco had something brewing,=20 > but I never > heared that it was released. I still agree with you that 3195=20 > should not > specifically be mentioned by -sign. I assume that implementing 3195bis > (when available) is probably not hard if you implemented 3195. >=20 > Rainer=20 >=20 > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Friday, December 22, 2006 5:23 PM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] RFC 3195bis? > >=20 > > Hi, > >=20 > > I'm OK removing references to RFC 3195 from syslog-sign for=20 > the points > > you > > mention. I'd welcome other opinions. > >=20 > > I agree that RFC 3195 is due for an update but I disagree=20 > with most of > > your other points. A major vendor has found customers requesting it > > and > > has implemented it. > > > http://www.cisco.com/en/US/products/ps6441/products_feature_gu > ide09186a > > 00807883c3.html > >=20 > > Thanks, > > Chris > >=20 > >=20 > > On Fri, 22 Dec 2006, Rainer Gerhards wrote: > >=20 > > >> The Chairs have been discussing this already. We have a=20 > candidate > > to > > >> write the update. The length limit in RFC 3195 was=20 > constrained by > > RFC > > >> 3164 and we have moved beyond that with the transport IDs which > > >> identify > > >> realistic maximum lengths. Updating RFC 3195 to have a greater > > length > > >> should not be a problem. > > >> > > >> HOWEVER... We need to focus on syslog-sign and syslog-device-mib > > >> BEFORE > > >> doing this. Once we get the shepherding documents for those IDs > > sent > > >> to > > >> the IESG _THEN_ we can discuss 3195bis. > > > > > > The problem is that -sign is related (even depending) on=20 > 3195. This > > is > > > why I brought up that issue. > > > > > > Let me explain. syslog-sign recommends 2k for signature=20 > and payload > > > blocks. It does so, because it assumes (rightly for the=20 > new series) > > that > > > 2k can be handled by almost every receiver, so there is no problem > in > > > using that length. However, if we require that -sign=20 > works together > > with > > > 3195, we must lower this limit to 1k. I would not like to see this > > > happen because 2k makes much sense and is much more=20 > efficient. 3195 > > does > > > not seem as important: > > > > > > - it is due for update > > > - there has only been an extremely limited set of implementations > > > - none of the major vendors has implemented it > > > - there is no (not "virtually no"!) customer demand for it at the > > > time being (I know this because I have implemented RFC 3195) > > > - the only customer demand comes from IHE, but for IHE it is not > > > usable because it still contains a too-rigid length constraint > > > > > > In short: the current RFC 3195 is not really in use. An updated > > version > > > may. I think we should not sacrifice the 2k limit for=20 > something that > > is > > > not being used. > > > > > > So my propsal is: we should remove RFC 3195 from syslog-sign as > well. > > It > > > should simply reference -syslog-protocol and its=20 > transport mappings. > > RFC > > > 3195bis will most likely be a transport mapping. Thus, -sign can > > cover > > > it without specifically mentioning it. This works exactly=20 > as the new > > > series is designed. Transports are below -protocol and sign is in > the > > > layer above it. So there should be no dependencies=20 > between -sign and > > the > > > actual transports used. > > > > > > If we take that route, we only lose the ability to use -sign > > *reliably* > > > with RFC 3195 as it is today. Given the fact that nobody=20 > is actually > > > using 3195, this is not a huge loss ;). It also finally=20 > de-couples - > > sign > > > from any other transport RFCs - and this was a major=20 > intention about > > the > > > whole effort of the new syslog series. > > > > > > I suggest we all have a look at this slide from 2004: > > > > > > http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html > > > > > > Rainer > > > > > > > > >> Thanks, > > >> Chris > > >> > > >> On Fri, 22 Dec 2006, Rainer Gerhards wrote: > > >> > > >>> Hi all, > > >>> > > >>> now that we obsolete RFC 3164 by -syslog-protocol, the only > > > remaining > > >>> RFC that is not compatible to the "new syslog series"=20 > is RFC 3195. > > >> The > > >>> questions is now how to proceed here? I am raising this issue > > > because > > >> it > > >>> has some effect on syslog-sign. I would love to see 2k as limit > for > > >>> sign-generated messages, but that means we need to talk=20 > about 3195 > > >>> (which not explicitely supports messages over 1k). > > >>> > > >>> IMHO, we should do a 3195bis that updates 3195 to work as a > > > transport > > >>> mapping with syslog-protocol. After we've done that, we have > > finally > > >>> unified all syslog RFCs and do not have any more issues with > > >>> incompatibilities between them. I think this is something we > should > > >> do > > >>> soon. > > >>> > > >>> Comments? > > >>> > > >>> Rainer > > >>> PS: I, too, would like to express my seasons greetings to all > folks > > >> on > > >>> the list! May you have a great and peaceful xmas time and a good > > >> start > > >>> into the new year. > > >>> > > >>> _______________________________________________ > > >>> Syslog mailing list > > >>> Syslog@lists.ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/syslog > > >>> > > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 14:22:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxpxu-0007cO-2W; Fri, 22 Dec 2006 14:21:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxpxr-0007c7-UU for syslog@ietf.org; Fri, 22 Dec 2006 14:21:55 -0500 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxpxp-00072D-Ge for syslog@ietf.org; Fri, 22 Dec 2006 14:21:55 -0500 Received: from pc6 (1Cust149.tnt108.lnd4.gbr.da.uu.net [62.188.170.149]) by galaxy.systems.pipex.net (Postfix) with SMTP id 103CEE0003D3; Fri, 22 Dec 2006 19:21:44 +0000 (GMT) Message-ID: <052401c725f5$fedd9c20$0601a8c0@pc6> From: "tom.petch" To: , "Glenn M. Keeni" References: <458A2081.1060800@cysols.com> <20061221143808.GC2166@boskop.local><458B41CA.1050108@cysols.com> <20061222093409.GA4476@boskop.local> Subject: Re: TransportDomain. Was: Re: [Syslog] Submission ofdraft-ietf-syslog-device-mib-12.txt Date: Fri, 22 Dec 2006 19:17:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "Wijnen, Bert \(Bert\)" , syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I am not convinced that the proposed solutions match the underlying problem. Syslog: - can be -protocol or RFC3164 (or RFC3164bis or ...) - may be signed. - may be secured with TLS (or SSH or DTLS or ...) - could run over UDP or TCP (or SCTP or ..) What we have then done is to bind -protocol to TLS to TCP in a package and asked IANA for a port number less that 1024 for that combination So I think that trying to analyse it in terms of, eg, InetAddressType, InetAddress, InetPortNumber and SyslogEncapsulation won't work. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Glenn M. Keeni" Cc: "Wijnen, Bert (Bert)" ; Sent: Friday, December 22, 2006 10:34 AM Subject: Re: TransportDomain. Was: Re: [Syslog] Submission ofdraft-ietf-syslog-device-mib-12.txt > On Fri, Dec 22, 2006 at 11:24:10AM +0900, Glenn M. Keeni wrote: > > > >- How do I find out which encapsulations are supported (plain, beep, > > > tls, ...)? > > That is the problem we are trying to solve. > > Can that be done by defining appropriate domains for > > syslog transport over TLS > > syslog transport over beep etc. ? > > Option a): > > You use a four tuple consisting of: > > (InetAddressType, InetAddress, InetPortNumer, SyslogEncapsulation) > > Option b): > > You use a three tuple consisting of: > > (TransportAddressType, TransportAddress, SyslogEncapsulation) > > In both cases, you need to define a TC SyslogEncapsulation which > enumerates the syslog encapsulations (or transport mappings) such as { > other(0), plain(1), tls(2), beep(3), ... }. > > InetAddress identifies Internet network layer endpoints while > TransportAddress identifies Internet transport layer endpoints, no > more no less. If you want to move to a two tuple, the only option in > principle is: > > Option c): > > You use a two tuple consisting of > > (SyslogAddressType, SyslogAddress) > > where SyslogAddressType combines the address type with the > encapsulation (this is essentially what a TDomain does for SNMP) > > /js > > -- > Juergen Schoenwaelder {International|Jacobs} University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 22 14:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxqJt-0001UW-EO; Fri, 22 Dec 2006 14:44:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxqJr-0001UO-Lw for syslog@ietf.org; Fri, 22 Dec 2006 14:44:39 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxqJp-0002X3-MF for syslog@ietf.org; Fri, 22 Dec 2006 14:44:39 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id ACFD85ACF3; Fri, 22 Dec 2006 20:44:34 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29656-03; Fri, 22 Dec 2006 20:44:31 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 829DB5AAC9; Fri, 22 Dec 2006 20:44:31 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 0610B9054D7; Fri, 22 Dec 2006 20:44:29 +0100 (CET) Date: Fri, 22 Dec 2006 20:44:29 +0100 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: TransportDomain. Was: Re: [Syslog] Submission ofdraft-ietf-syslog-device-mib-12.txt Message-ID: <20061222194429.GA5315@boskop.local> Mail-Followup-To: "tom.petch" , "Glenn M. Keeni" , syslog@ietf.org References: <458A2081.1060800@cysols.com> <20061222093409.GA4476@boskop.local> <052401c725f5$fedd9c20$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <052401c725f5$fedd9c20$0601a8c0@pc6> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Fri, Dec 22, 2006 at 07:17:18PM +0100, tom.petch wrote: > I am not convinced that the proposed solutions match the underlying problem. > > Syslog: > - can be -protocol or RFC3164 (or RFC3164bis or ...) > - may be signed. > - may be secured with TLS (or SSH or DTLS or ...) > - could run over UDP or TCP (or SCTP or ..) > > What we have then done is to bind -protocol to TLS to TCP in a > package and asked IANA for a port number less that 1024 for that > combination > > So I think that trying to analyse it in terms of, eg, InetAddressType, > InetAddress, InetPortNumber and SyslogEncapsulation won't work. I don't get your message - can you enlighten us please? /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Dec 24 15:15:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyZjH-0003KR-6G; Sun, 24 Dec 2006 15:13:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyZjF-0003Jz-7p for syslog@ietf.org; Sun, 24 Dec 2006 15:13:53 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyZjA-0007Sg-8T for syslog@ietf.org; Sun, 24 Dec 2006 15:13:53 -0500 Received: from pc6 (1Cust82.tnt108.lnd4.gbr.da.uu.net [62.188.170.82]) by ranger.systems.pipex.net (Postfix) with SMTP id C3C06E00033A; Sun, 24 Dec 2006 20:13:39 +0000 (GMT) Message-ID: <000901c7278f$90c53b80$0601a8c0@pc6> From: "tom.petch" To: References: <458A2081.1060800@cysols.com> <20061222093409.GA4476@boskop.local> <052401c725f5$fedd9c20$0601a8c0@pc6> <20061222194429.GA5315@boskop.local> Subject: Re: TransportDomain. Was: Re: [Syslog] Submission ofdraft-ietf-syslog-device-mib-12.txt Date: Sun, 24 Dec 2006 20:08:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "Glenn M. Keeni" ; Sent: Friday, December 22, 2006 8:44 PM Subject: Re: TransportDomain. Was: Re: [Syslog] Submission ofdraft-ietf-syslog-device-mib-12.txt > On Fri, Dec 22, 2006 at 07:17:18PM +0100, tom.petch wrote: > > > I am not convinced that the proposed solutions match the underlying problem. > > > > Syslog: > > - can be -protocol or RFC3164 (or RFC3164bis or ...) > > - may be signed. > > - may be secured with TLS (or SSH or DTLS or ...) > > - could run over UDP or TCP (or SCTP or ..) > > > > What we have then done is to bind -protocol to TLS to TCP in a > > package and asked IANA for a port number less that 1024 for that > > combination > > > > So I think that trying to analyse it in terms of, eg, InetAddressType, > > InetAddress, InetPortNumber and SyslogEncapsulation won't work. > > I don't get your message - can you enlighten us please? > My pleasure :-) My sense is that your analysis of the protocols is syslog encapsulation transport somewhat RFC3411-like so we might have an enumeration for encapsulation, one (or more) for transport and problem solved. I am saying that the structure (architecture/layers) is not like that (no dbh:-), that we have 'tls/tcp/IANA port' all tied up in a bundle together, take it or leave it. Were we ever to do anything different in future, most likely it would be a another package, perhaps SSH/TCP/different IANA port or TCP per se, so the decomposition you imply does not make sense to me. Also, there is more than one flavour of syslog (-protocol, RFC3164) and perhaps we need that specifying more than we need to specify what lies underneath. So option c) is the closest but may not be enough. Tom Petch > /js > > -- > Juergen Schoenwaelder {International|Jacobs} University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 27 06:41:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzX8r-000399-12; Wed, 27 Dec 2006 06:40:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzX8p-00038Y-00 for syslog@ietf.org; Wed, 27 Dec 2006 06:40:15 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzX8k-0001gd-JL for syslog@ietf.org; Wed, 27 Dec 2006 06:40:14 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 40AD655E43; Wed, 27 Dec 2006 12:40:03 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08483-07; Wed, 27 Dec 2006 12:40:00 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 354CA55E1A; Wed, 27 Dec 2006 12:40:00 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 411249084D3; Wed, 27 Dec 2006 12:40:00 +0100 (CET) Date: Wed, 27 Dec 2006 12:40:00 +0100 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: TransportDomain. Was: Re: [Syslog] Submission ofdraft-ietf-syslog-device-mib-12.txt Message-ID: <20061227114000.GB12516@boskop.local> Mail-Followup-To: "tom.petch" , "Glenn M. Keeni" , syslog@ietf.org References: <458A2081.1060800@cysols.com> <20061222093409.GA4476@boskop.local> <052401c725f5$fedd9c20$0601a8c0@pc6> <20061222194429.GA5315@boskop.local> <000901c7278f$90c53b80$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000901c7278f$90c53b80$0601a8c0@pc6> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Sun, Dec 24, 2006 at 08:08:12PM +0100, tom.petch wrote: > > My sense is that your analysis of the protocols is > syslog > encapsulation > transport > somewhat RFC3411-like so we might have an enumeration for > encapsulation, one (or more) for transport and problem solved. I am > saying that the structure (architecture/layers) is not like that (no > dbh:-), that we have 'tls/tcp/IANA port' all tied up in a bundle > together, take it or leave it. I tried to clarify in a constructive way the purpose of InetAddress and friends and TransportAddress and friends. You seem to suggest to use some syslog specific SyslogDomain/SyslogAddress (but you don't spell things out so you leave me guessing). > Were we ever to do anything different in future, most likely it > would be a another package, perhaps SSH/TCP/different IANA port or > TCP per se, so the decomposition you imply does not make sense to > me. There is a transport endpoint involved in SSH/TCP and some sort of encapsulation - so I do not really see what breaks. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 27 16:53:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzghS-0004Sj-TX; Wed, 27 Dec 2006 16:52:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzghR-0004Se-H3 for syslog@ietf.org; Wed, 27 Dec 2006 16:52:37 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzghP-00046W-24 for syslog@ietf.org; Wed, 27 Dec 2006 16:52:37 -0500 Received: from harrington73653 (ip67-155-163-250.z163-155-67.customer.algx.net[67.155.163.250]) by comcast.net (alnrmhc11) with SMTP id <20061227215233b1100j4d1he>; Wed, 27 Dec 2006 21:52:34 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog] RFC 3164 Date: Wed, 27 Dec 2006 16:49:14 -0500 Message-ID: <1e1a01c72a00$e1be4c20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcclS1k7ytuhuD71Q4mvL6HItKScpAAT5lKQARlIs+A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8968@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org If members of the syslog community want to provide updated information about observed on-the-wire syslog messages, they should feel free to write such an informational document and have it published by the IETF. However, that is not part of the charter of our work, and should not be a WG item, but an individual draft. There is some question of whether providing such an update might conflict with the IETF efforts to standardize syslog, so the IESG may choose to prevent the publication of such a document within the IETF. Declaring RFC3164 obsolete (or historic) is within the scope of what we are authorized to do as a WG, and that step can be fully independent of an effort to provide updated information about historic/obsolete implementations. dbh > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Friday, December 22, 2006 2:39 AM > To: andrew@kiwisyslog.com > Cc: syslog@ietf.org > Subject: RE: [Syslog] RFC 3164 > > Andrew, Anton, > > I am using Andrew's message to reply to both. I concur with Andrew, > please see below... > > > -----Original Message----- > > From: Andrew Ross [mailto:andrew@kiwisyslog.com] > > Sent: Thursday, December 21, 2006 10:53 PM > > To: Rainer Gerhards > > Subject: RE: [Syslog] RFC 3164 > > > > > > Hi Rainer, > > > > Merry Christmas! > > > > Sorry I've been out of the discussion loop for so long, things have > > been > > pretty hectic over here. I know that the new protocols are in good > > hands > > though. > > > > With regard to 3164. I would prefer to obsolete 3164 with a document > > that > > details what is actually seen in real life on the wire. This would > just > > mean > > adding some extra text to the 3164 document and adding in some > examples > > of > > what is seen by different OS senders. Pretty much the research you > > presented > > to the list a while ago. This new document would then obsolete 3164. > > That would actually be my prefferred way to handle things. Other than > Andrew, I think we should remove/change most of the text, as > indeed only > PRI is available on an universal basis. Samples of different message > formats can be used to convey that information. > > > We get asked so often by customers if we are 3164 compliant. We used > to > > explain that 3164 is not really valid, but that didn't satisfy them, > so > > we > > just said "yes, we are compliant" to keep them happy. > > Now to the question "why do that?". Andrew has a very valid > point here. > We experience the same quite often. We even added an option "use RFC > 3164 compatible format" to our product and guess what - it is > turned off > most of the time because RFC 3164 does not describe what receivers and > senders typically do ;). Even if we obsolete 3164 with > -protocol, I know > a lot of folks will come and ask "Hey, do you support the old standard > that most of my other devices use?". They simply will not > care about it > being obsoleted by something different. However, if we go ahead and > crate 3164bis (another informational document), the situation > will IMHO > change. Now there is a newer "standard" (as people perceive > it) for the > "old" syslog. And if that says "You can not trust anything but PRI" I > can "sell" that. Plus, I have a very good point in argumenting why > syslog-protocol is superior. > > I know I am not talking hard technical facts here. I am talking real > life. Most people do not care if a RFC is informational or standards > track. If it is a RFC, it must be something products comply > too. I agree > that implementors should understand the difference. They > (hopefully/probably) do. But do implementors actually decide what to > implement? No - not in my experience. The marketing department tells > them what to do. And customers tell the marketing department. > And guess > what? These customers are the informed masses that do *not* know the > inner workings of the IETF (aka "a RFC is a RFC is a RFC..."). > > Even in a technical context like the IETF I think a little bit of > real-world politics can be considered. It is the key to acceptance of > new standards. > > Rainer > > > > Cheers > > > > Andrew > > > > > > > > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Thursday, 21 December 2006 8:13 p.m. > > To: syslog@ietf.org > > Subject: [Syslog] RFC 3164 > > > > > > Hi all, > > > > I just realized that the future of RFC 3164 is not yet publically > > discussed. > > > > RFC 3164 is a well-done work, but we have made much progress in the > > past > > 5 years since it was written. Most importantly, we discovered that > > actual syslog software uses a much different set of formats than > > expected by 3164. This was the source of much discussion > inside the WG > > and we did a lot of testing to confirm the findings. The bottom line > is > > that we now know that 3164 does *not* acurately describe what is > > observed in the wild. Nobody is to blame here - the breadth of > > information we created the past years was simply not available (nor > > were > > the ressources to do the testing) to the orginal authors of > RFC 3164. > > > > Having said that, I think we must do something about the > situation. In > > practice I see more and more vendors claim compliance to RFC 3164. > This > > is kind of funny in itself, because 3164 is just an information > > document, so you can not be compliant to it ;) Anyhow, many vendors > > seem > > to have a wrong impression and use this in their advertising as well > as > > tech support. > > > > I think we should do either one of the following: > > > > 1. create an updated RFC 3164bis > > 2. obsolete RFC 3164 > > > > I personally would tend to 1. - update the document with > what we have > > gained on additional knowledge. I have been told that this would be > > somewhat unusual for the IETF, as 3164 is only informational and > > -transport-protocol will soon set a real standard. So updating > > information on "the past" seems not to be useful. However, I expect > > traditional syslog to stay around for at least another 5 to > 10 years, > > if > > not longer. I would consider it a plus to have a RFC that accurately > > describes the format that we can expect from such a legacy syslog > > sender. Most importantly, it will remove any false secure feeling > about > > format standardization where there is none. > > > > I would appreciate comments on this issue. > > > > Rainer > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 27 18:30:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GziDk-0007HB-FV; Wed, 27 Dec 2006 18:30:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GziDj-0007H5-Ek for syslog@ietf.org; Wed, 27 Dec 2006 18:30:03 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GziDe-0008J5-UO for syslog@ietf.org; Wed, 27 Dec 2006 18:30:03 -0500 Received: from harrington73653 (ip67-155-163-250.z163-155-67.customer.algx.net[67.155.163.250]) by comcast.net (alnrmhc11) with SMTP id <20061227232957b1100j474ne>; Wed, 27 Dec 2006 23:29:58 +0000 From: "David Harrington" To: "'tom.petch'" , Date: Wed, 27 Dec 2006 18:26:30 -0500 Message-ID: <1e1b01c72a0e$7d2676d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccnmEkzkxE80/hQSmGbApv4t7uhYwCaoPxg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <000901c7278f$90c53b80$0601a8c0@pc6> X-Spam-Score: 1.8 (+) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: syslog@ietf.org Subject: [Syslog] RE: TransportDomain X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Tom, Juergen's explanation has nothing to do with RFC3411. The fact that syslog can be 3164 or -protocol or signed is really immaterial to this discussion, since these happen above the addressing level. This discussion has to do with choosing from three standard mechanisms for representing addresses in SMIv2 MIB modules. There are advantages and disadvantages to each of the three standard approaches to representing address formats, and these should be understood to make the proper choice. (Juergen is well versed in the intracacies of the advantages and disadvantages, and is trying to provide some advice). The three standards are: 1) TDomain (RFC3417) - which defines a mechanism to represent snmp-specific addresses (at layer7). This was defined explicitly for use in the MIB modules that are part of SNMPv3, and are designed only for managing SNMP, and the addresses defined (e.g. SnmpUDPDomain/SnmpUDPAddress) can not be easily reused to represent addresses used by other protocols. snmpUDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over UDP over IPv4 transport domain. The corresponding transport address is of type SnmpUDPAddress." ::= { snmpDomains 1 } SnmpUDPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d" STATUS current DESCRIPTION "Represents a UDP over IPv4 address: octets contents encoding 1-4 IP-address network-byte order 5-6 UDP-port network-byte order " SYNTAX OCTET STRING (SIZE (6)) Tdomain includes definitions for snmp-specific addresses. For syslog to use TDomain will require us to develop hardcoded OID assignments for a syslogUDPDomain and syslogUDPAddress, syslogTCPDomain, syslogTCPAddress, syslogTLSDomain, syslogTLSAddress, and so on. Those hardcoded values can then be used in TDomain/TAddress fields in MIB modules. To provide an SSH transport extension would require publishing a new MIB module to define the new hardcoded values syslogSSHDomain, syslogSSHAddress. The SNMP community realized it is really undesirable to have to write a whole new MIB module just to say what the address domain would be and what the address would look like. The suggestion that a syslog address is always syslog/tls/tcp/IANAport might lead one to select the TDomain approach, but this is not really required. One ting to point out is that IANA assigns a requested "default" port, but operators can often change what port is actually used. 2) TransportDomain - which defines a mechanism that represents (layer4) transport addresses, independent of the application. This better permitted showing the transport addresses of non-snmp-things in MIB modules. transportDomainUdpIpv4 OBJECT-IDENTITY STATUS current DESCRIPTION "The UDP over IPv4 transport domain. The corresponding transport address is of type TransportAddressIPv4 for global IPv4 addresses." ::= { transportDomains 1 } TransportAddressIPv4 ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d:2d" STATUS current DESCRIPTION "Represents a transport address consisting of an IPv4 address and a port number (as used for example by UDP, TCP and SCTP): octets contents encoding 1-4 IPv4 address network-byte order 5-6 port number network-byte order This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair." SYNTAX OCTET STRING (SIZE (6)) To use this in a MIB module, you define a pair of fields: a transportDomain field identifies the type of address being used, and a corresponding field of transportAddress with the actual address value. The corresponding address value MUST be of the type defined in TransportDomain. Syslog could use this approach, BUT - there are no existing definitions for a TLS/TCP transport address, so if we want to use this, we need to define such a transportDomain and corresponding transportAddress. The current syslog mib document does not provide such an update. There is an additional complication. RFC3419 provides an enumeration to select a transportDomain; this is done so a transportDomain can be used as a field in an index without having the whole OID of a transportDomain be part of the INDEX; you can use an integer identifier. In order to add a new transportDomain therefore requires updating RFC3419 to keep the enumeration in sync with the possible values of transportDomain. So while using trasportDomain would require us to make fewer hardcoded defintiions than Tdomain, the IETF process involved in doing the updates to support TLS is harder. 3) InetAddressType (RFC4001) defines a mechanism that represents internet (layer 3) addresses, and can supplement that with a PortNumber. This address is independent of the application using it, and is suitable for showing layer 3 addresses in MIB modules. It was motivated by the need to represent IP addresses in MIB modules so that either an IPv4 or an IPv6 or a DNS address could be used in the same managed object. Juergen, if I got any of this wrong, please feel free to correct me. -- Now to the problem at hand: The syslog MIB module uses a combination of types, without explanation for why each type is used where it is. The transportDomain is used without discussing how/where/when a TLS transportDomain will be defined so the syslog/TLS transport can be represented. Some current usages in the syslog mib appear to be incorrect. You need to think of these domain/address pairings as being discriminated unions - the first field identifies the format of the second field; you cannot use one part of the pair without the other. In the syslog mib module, the type field declares what the format of the next field is, but the address value field then describes a format that is NOT one of the address formats supported. This problem is exarcerbated by mib module decriptions that are unclear, partly because the WG members are not reviewing this document and helping the author write clear descriptions. This problem is also exacerbated by replies from the author that do not answer **the questions being asked** by the MIB experts so they can provide advice. For example: Question from Juergen: > syslogEntityControlBindAddrType InetAddressType > syslogEntityControlBindAddr InetAddress > syslogEntityControlTransportDomain TransportDomain > syslogEntityControlService SyslogService > > looks a bit crazy to me. > - Why have both InetAddressType and TransportDomain? Answer from Glenn: > We will not have this. We ALREADY have this; We are using both InetAddress and TransportDomain standards for representing addresses in the syslog mib module. Why do we need to use BOTH standards rather than using ONE standard to represent addresses? dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Sunday, December 24, 2006 2:08 PM > To: j.schoenwaelder@iu-bremen.de > Cc: syslog@ietf.org > Subject: Re: TransportDomain. Was: Re: [Syslog] > Submissionofdraft-ietf-syslog-device-mib-12.txt > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "tom.petch" > Cc: "Glenn M. Keeni" ; > Sent: Friday, December 22, 2006 8:44 PM > Subject: Re: TransportDomain. Was: Re: [Syslog] Submission > ofdraft-ietf-syslog-device-mib-12.txt > > > On Fri, Dec 22, 2006 at 07:17:18PM +0100, tom.petch wrote: > > > > > I am not convinced that the proposed solutions match the > underlying problem. > > > > > > Syslog: > > > - can be -protocol or RFC3164 (or RFC3164bis or ...) > > > - may be signed. > > > - may be secured with TLS (or SSH or DTLS or ...) > > > - could run over UDP or TCP (or SCTP or ..) > > > > > > What we have then done is to bind -protocol to TLS to TCP in a > > > package and asked IANA for a port number less that 1024 for that > > > combination > > > > > > So I think that trying to analyse it in terms of, eg, > InetAddressType, > > > InetAddress, InetPortNumber and SyslogEncapsulation won't work. > > > > I don't get your message - can you enlighten us please? > > > My pleasure :-) > > My sense is that your analysis of the protocols is > syslog > encapsulation > transport > somewhat RFC3411-like so we might have an enumeration for > encapsulation, one (or > more) for transport and problem solved. I am saying that the > structure > (architecture/layers) is not like that (no dbh:-), that we > have 'tls/tcp/IANA port' all tied up in a bundle together, > take it or leave it. > Were we ever to do anything different in future, most likely > it would be a > another package, perhaps SSH/TCP/different IANA port or TCP > per se, so the > decomposition you imply does not make sense to me. > > Also, there is more than one flavour of syslog (-protocol, > RFC3164) and perhaps > we need that specifying more than we need to specify what > lies underneath. So > option c) is the closest but may not be enough. > > Tom Petch > > /js > > > > -- > > Juergen Schoenwaelder {International|Jacobs} University Bremen > > P.O. Box 750 561, 28725 > Bremen, Germany > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 28 04:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzrvE-00037Z-LD; Thu, 28 Dec 2006 04:51:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzrvD-00036O-17 for syslog@ietf.org; Thu, 28 Dec 2006 04:51:35 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzrvB-0006Nb-HW for syslog@ietf.org; Thu, 28 Dec 2006 04:51:35 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id C308055E43; Thu, 28 Dec 2006 10:51:32 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 06982-08; Thu, 28 Dec 2006 10:51:29 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 689A255DA0; Thu, 28 Dec 2006 10:51:29 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 0B9C490930C; Thu, 28 Dec 2006 10:51:27 +0100 (CET) Date: Thu, 28 Dec 2006 10:51:27 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20061228095127.GB13941@boskop.local> Mail-Followup-To: David Harrington , "'tom.petch'" , syslog@ietf.org References: <000901c7278f$90c53b80$0601a8c0@pc6> <1e1b01c72a0e$7d2676d0$0600a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1e1b01c72a0e$7d2676d0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: syslog@ietf.org Subject: [Syslog] Re: TransportDomain X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Wed, Dec 27, 2006 at 06:26:30PM -0500, David Harrington wrote: > 2) TransportDomain - which defines a mechanism that represents > (layer4) transport addresses, independent of the application. This > better permitted showing the transport addresses of non-snmp-things in > MIB modules. > > transportDomainUdpIpv4 OBJECT-IDENTITY > STATUS current > DESCRIPTION > "The UDP over IPv4 transport domain. The corresponding > transport address is of type TransportAddressIPv4 for > global IPv4 addresses." > ::= { transportDomains 1 } > > TransportAddressIPv4 ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1d.1d.1d.1d:2d" > STATUS current > DESCRIPTION > "Represents a transport address consisting of an IPv4 > address and a port number (as used for example by UDP, > TCP and SCTP): > > octets contents encoding > 1-4 IPv4 address network-byte order > 5-6 port number network-byte order > > This textual convention SHOULD NOT be used directly in object > definitions since it restricts addresses to a specific > format. > However, if it is used, it MAY be used either on its own or > in conjunction with TransportAddressType or TransportDomain > as a pair." > SYNTAX OCTET STRING (SIZE (6)) > > > To use this in a MIB module, you define a pair of fields: a > transportDomain field identifies the type of address being used, and a > corresponding field of transportAddress with the actual address value. > The corresponding address value MUST be of the type defined in > TransportDomain. > > Syslog could use this approach, BUT - there are no existing > definitions for a TLS/TCP transport address, so if we want to use > this, we need to define such a transportDomain and corresponding > transportAddress. The current syslog mib document does not provide > such an update. And I would say that TLS/TCP is actually out of scope for RFC 3419. > There is an additional complication. RFC3419 provides an enumeration > to select a transportDomain; this is done so a transportDomain can be > used as a field in an index without having the whole OID of a > transportDomain be part of the INDEX; you can use an integer > identifier. > > In order to add a new transportDomain therefore requires updating > RFC3419 to keep the enumeration in sync with the possible values of > transportDomain. > > So while using trasportDomain would require us to make fewer hardcoded > defintiions than Tdomain, the IETF process involved in doing the > updates to support TLS is harder. RFC 3419 was born since we figured out that we need IPv6 definitions for SNMP but also other protocols that represent transport layer endpoints in MIB modules. So we tried a general approach to such transport layer endpoints. > 3) InetAddressType (RFC4001) defines a mechanism that represents > internet (layer 3) addresses, and can supplement that with a > PortNumber. This address is independent of the application using it, > and is suitable for showing layer 3 addresses in MIB modules. It was > motivated by the need to represent IP addresses in MIB modules so that > either an IPv4 or an IPv6 or a DNS address could be used in the same > managed object. Yes. Other definitions (among them InetPortNumber) were later added since MIB modules needed such definitions and the INET-ADDRESS-MIB was a convenient place to put them. /js PS: I am using transport layer in this message in the more traditional and restrictive sense. I know that sometimes application protocols consider soemthing they run over as a transport layer (e.g. BEEP, TLS, SSH, ...) but I am not using this definition here. -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 28 07:45:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzubw-00037M-0w; Thu, 28 Dec 2006 07:43:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzubu-00035M-2H for syslog@ietf.org; Thu, 28 Dec 2006 07:43:50 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gzuaw-0007qe-8k for syslog@ietf.org; Thu, 28 Dec 2006 07:42:54 -0500 Received: from pc6 (1Cust231.tnt108.lnd4.gbr.da.uu.net [62.188.170.231]) by blaster.systems.pipex.net (Postfix) with SMTP id 40972E0005B5; Thu, 28 Dec 2006 12:42:45 +0000 (GMT) Message-ID: <005f01c72a75$39cfac00$0601a8c0@pc6> From: "tom.petch" To: References: <458A2081.1060800@cysols.com> <20061222093409.GA4476@boskop.local> <052401c725f5$fedd9c20$0601a8c0@pc6> <20061222194429.GA5315@boskop.local> <000901c7278f$90c53b80$0601a8c0@pc6> <20061227114000.GB12516@boskop.local> Subject: Re: TransportDomain. Was: Re: [Syslog] Submission ofdraft-ietf-syslog-device-mib-12.txt Date: Thu, 28 Dec 2006 12:39:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "Glenn M. Keeni" ; Sent: Wednesday, December 27, 2006 12:40 PM Subject: Re: TransportDomain. Was: Re: [Syslog] Submission ofdraft-ietf-syslog-device-mib-12.txt > On Sun, Dec 24, 2006 at 08:08:12PM +0100, tom.petch wrote: > > > > My sense is that your analysis of the protocols is > > syslog > > encapsulation > > transport > > somewhat RFC3411-like so we might have an enumeration for > > encapsulation, one (or more) for transport and problem solved. I am > > saying that the structure (architecture/layers) is not like that (no > > dbh:-), that we have 'tls/tcp/IANA port' all tied up in a bundle > > together, take it or leave it. > > I tried to clarify in a constructive way the purpose of InetAddress > and friends and TransportAddress and friends. You seem to suggest to > use some syslog specific SyslogDomain/SyslogAddress (but you don't > spell things out so you leave me guessing). > You did indeed clarify the purpose of InetAddress and TransportAddress and that leaves me thinking that they do not fit very well here:-( Rather we have a choice of RFC3164 over UDP -protocol over UDP -protocol over TLS/TCP RFC3195 over BEEP (some of which can be signed) to enumerate Tom Petch > > Were we ever to do anything different in future, most likely it > > would be a another package, perhaps SSH/TCP/different IANA port or > > TCP per se, so the decomposition you imply does not make sense to > > me. > > There is a transport endpoint involved in SSH/TCP and some sort of > encapsulation - so I do not really see what breaks. > > /js > > -- > Juergen Schoenwaelder {International|Jacobs} University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 28 08:56:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzvjz-0008Sh-0m; Thu, 28 Dec 2006 08:56:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzvjy-0008Sc-7L for syslog@ietf.org; Thu, 28 Dec 2006 08:56:14 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gzvjv-0000uK-T4 for syslog@ietf.org; Thu, 28 Dec 2006 08:56:14 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1FD5B55E43; Thu, 28 Dec 2006 14:56:11 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19894-10; Thu, 28 Dec 2006 14:56:08 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id F042155DAD; Thu, 28 Dec 2006 14:56:07 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 28D099095C2; Thu, 28 Dec 2006 14:56:05 +0100 (CET) Date: Thu, 28 Dec 2006 14:56:05 +0100 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: TransportDomain. Was: Re: [Syslog] Submission ofdraft-ietf-syslog-device-mib-12.txt Message-ID: <20061228135605.GA14580@boskop.local> Mail-Followup-To: "tom.petch" , "Glenn M. Keeni" , syslog@ietf.org References: <458A2081.1060800@cysols.com> <20061222093409.GA4476@boskop.local> <052401c725f5$fedd9c20$0601a8c0@pc6> <20061222194429.GA5315@boskop.local> <000901c7278f$90c53b80$0601a8c0@pc6> <20061227114000.GB12516@boskop.local> <005f01c72a75$39cfac00$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005f01c72a75$39cfac00$0601a8c0@pc6> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Thu, Dec 28, 2006 at 12:39:50PM +0100, tom.petch wrote: > You did indeed clarify the purpose of InetAddress and > TransportAddress and that leaves me thinking that they do not fit > very well here:-( Rather we have a choice of > RFC3164 over UDP > -protocol over UDP > -protocol over TLS/TCP > RFC3195 over BEEP > (some of which can be signed) to enumerate This is nothing new. It would help us more if you could tell us _how_ you think this should be done and why your approach will be superior to those already put on the table here. Thanks, /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 28 11:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzyT8-0006rZ-4I; Thu, 28 Dec 2006 11:51:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzyT6-0006rS-F9 for syslog@ietf.org; Thu, 28 Dec 2006 11:51:00 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzyT5-0007Uo-6I for syslog@ietf.org; Thu, 28 Dec 2006 11:51:00 -0500 Received: from pc6 (1Cust148.tnt27.lnd4.gbr.da.uu.net [62.188.154.148]) by blaster.systems.pipex.net (Postfix) with SMTP id 967B3E000245; Thu, 28 Dec 2006 16:50:50 +0000 (GMT) Message-ID: <02a001c72a97$e2bb4320$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <1e1b01c72a0e$7d2676d0$0600a8c0@china.huawei.com> Date: Thu, 28 Dec 2006 16:43:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: syslog@ietf.org Subject: [Syslog] Re: TransportDomain X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Dbh Yes, another lucid explanation of a tricky subject. The issue I wish I had never raised :-) was a response to Juergen saying > The combination of > syslogEntityControlBindAddr InetAddress > syslogEntityControlTransportDomain TransportDomain > syslogEntityControlService SyslogService > > looks a bit crazy to me. > > - Why have both InetAddressType and TransportDomain? > > - Why not simply use (InetAddressType,InetAddress,InetPortNumber) or > (TansportAddressType,TransportAddress)? > > - What is the value of saying the service name is "xyz", which has > only local significance? > > - How do I find out which encapsulations are supported (plain, beep, tls, ...)? > > /js which mostly I agree with. But I think that there is no answer to finding out which encapsulations are supported because I do not think that the way in which syslog is put together has the concept of encapsulation; rather we have packages, bundles, like RFC3164/-sign/UDP RFC3195/BEEP RAW/TCP -protocol/TLS/TCP So by all means ask the editor of -mib to change it to use InetAddressType/InetAddress/InetPortNumber but I do not expect to see an answer there as to which encapsulations are supported. Tom Petch. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 28 12:17:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzysM-000763-9s; Thu, 28 Dec 2006 12:17:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzysL-00075f-DC for syslog@ietf.org; Thu, 28 Dec 2006 12:17:05 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gzuat-0007qE-W1 for syslog@ietf.org; Thu, 28 Dec 2006 07:42:49 -0500 Received: from pc6 (1Cust231.tnt108.lnd4.gbr.da.uu.net [62.188.170.231]) by blaster.systems.pipex.net (Postfix) with SMTP id D3CB9E0001A9; Thu, 28 Dec 2006 12:42:43 +0000 (GMT) Message-ID: <005e01c72a75$36f64d40$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] tpetch WGLC Review of draft-ietf-syslog-sign-20.txt Date: Thu, 28 Dec 2006 12:39:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I think that there are a number of places where the language is not quite English and could do with editing. There are also several places where I am unclear about the meaning. Taking the more significant ones and trying not to overlap with previous comments It would be easier for the RFC Editor (and me) if the three references were to proposed RFC were to xxxx, yyyy, zzzz as opposed to all being xxxx 3 'it is imperative .. ' seem unnecessary when it is followed by 'MUST NOT' 'Signature Group' seems as much a special term as Signature Block or Certificate Block and so should be capitalised. I find the mix of byte, decimal and character confusing. As already commented, I think octet should replace byte and, in most places, character. For me, saying a field is decimal is imprecise; I would like you to specify that in ABNF as Rainer does. Also, I you should give guidance on leading zeroes (omit them!). 4.2.2 "between 0 and 9999999999" I assume that this is an inclusive range, ie 0 and 9999999999 are valid values. "If the value latches at 9999999999" I am unclear about this and other uses of 'latches'. I expect a specification to say whether or not a value latches at its maximum value (and so needs to be reset by special action eg manual intervention). Saying 'if it latches' confuses me; is this at the choice of the implementor?. 4.2.3 "how to divide up the processing //of/ syslog messages " "The ability to /to// associate" "with flexibility /to/in/ that regard." 4.2.4 "In the case in which the reboot session ID is in fact 0 and persisting of reboot session IDs is not supported, when the global block counter latches, it resumes at 0 also in this case but the reboot session ID MUST NOT be incremented and remains at 0." I struggle to parse this. Is it more like "When the reboot session ID is 0 ( ie persistent reboot session IDs are not supported) and the global block counter reaches its maximum value, then the global block counter is reset to 0 and the reboot session ID MUST remain at 0." 4.2.7 How is the message padded? 5.2 "each reboot session has only one Payload Block" I get confused in this section; my sense is, and I struggle for the right wording, that the contents of the Payload Block are fixed for a reboot session (regardless of whether or not persistent session IDs are supported) but that the Payload Block may appear as many times as the sender thinks fit. 5.3 "refe/re//rred to as a Certificate Block" Should a Certificate Block have a minimum length? is it valid to send a large number of such blocks with zero length (DOS attack)? 6 I would like to see suggested values for this customisation. Given the number of comments from Chris and Rainer, I would like to see a reissue and the chance to read it again before this goes to the IESG. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 28 12:53:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzzQf-0002F0-8Y; Thu, 28 Dec 2006 12:52:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzzQe-0002Ev-Pz for syslog@ietf.org; Thu, 28 Dec 2006 12:52:32 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzzQc-0008It-6v for syslog@ietf.org; Thu, 28 Dec 2006 12:52:32 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20061228175229b1200brlsbe>; Thu, 28 Dec 2006 17:52:29 +0000 From: "David Harrington" To: "'tom.petch'" , "'Rainer Gerhards'" Date: Thu, 28 Dec 2006 12:49:14 -0500 Message-ID: <1e5a01c72aa8$83837010$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccgX3bFy0moKH4ZT+iOL4SCsDDcNgKPFAFQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <065101c72057$0b9360c0$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: syslog@ietf.org Subject: [Syslog] Syslog-mib-12 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [speaking as co-chair] I think these comments from Tom have not been addressed in mib-12. Does the WG agree that Figure 1 and discussion of facilities and hosts and so on should be removed in mib-xx? Does the WG agree that Diagram 1 from protocol-19 should be duplicated in mib-xx, as a way to bring the language used in the mib module closer to the "standard terminology" proposed by this WG? Does the WG agree that Diagram 1 represents all likely deployment scenarios (most notably those encountered on dumb-device, *NIX and Windows environments)? Would it be adequate to simply **reference** Diagram 1 in [RFCPROT], and the Terminology of Section 3 of [RFCPROT], and then explain how the terminology in the mib module relates to the [RFCPROT] terminology and diagram? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, December 15, 2006 9:35 AM > To: David Harrington; 'Rainer Gerhards' > Cc: syslog@ietf.org > Subject: Re: [Syslog] Syslog-mib-11 > > mmmmmm > > Rainer's explanation shows me why I have not encountered > this; it is only > present in Windows servers and then only, if I read it > aright, because Windows > has not done a satisfactory implementation yet. The question > then is, how much > do we adapt to this behaviour of Windows? > > I find your remedy insufficient. Look at the diagram at the > start of -mib and > compare it with the diagram at the start of -protocol. > Seeing those two > diagrams convinced me that the two I-Ds came from different > planets and that, > until that was resolved - and only now, months later, do I > begin to see a > resolution - it was not worth expending much effort on -mib. > > I think this will be the reaction of others and that we MUST > include the diagram > in -mib that appears in all the others and then -mib must > explain how the terms > it chooses relates to those in the diagram and why. > Simplying saying this I-D > is different because we are on planet Microsoft is not > sufficient for me. > > I agree that there must also be a brief explanation in the > DESCRIPTION clause. > > Another problem I have with -mib is the statement that > "The syslog entities may be on the same host or on different hosts." > If on different hosts, what is the protocol used to > communicate between the two > hosts? If this is syslog, then how is the MIB information > communicated from > syslog sender to the entity with the SNMP agent? This is not a new > question:-(. > > > Tom Petch > > > ----- Original Message ----- > From: "David Harrington" > To: "'Rainer Gerhards'" > Cc: > Sent: Thursday, December 14, 2006 11:23 PM > Subject: RE: [Syslog] Syslog-mib-11 > > > > Hi, > > > > [speaking as a contributor] > > > > Thank you Rainer for such a clear response. > > > > I recommend that text similar to Rainer's response be > included in the > > DESCRIPTION clause for the syslogEntityControlTable, to explain why > > multiple syslog entities are modeled in the MIB module. > > > > I recommend capturing the discussion within the MIB module > definition > > rather than in the document introductory sections, because > MIB modules > > are often distributed already-extracted from the > surrounding document, > > and NMS help screens are often fashioned from the > DESCRIPTION clauses. > > So putting this info in the table description clause will get the > > explanation to the users. I would not object to **also** having it > > discussed in the introductory text sections. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 28 13:45:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H00G8-00036e-UM; Thu, 28 Dec 2006 13:45:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H00G7-00035B-AZ for syslog@ietf.org; Thu, 28 Dec 2006 13:45:43 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H00G5-00035a-9u for syslog@ietf.org; Thu, 28 Dec 2006 13:45:42 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBSIjWJW024371; Fri, 29 Dec 2006 03:45:32 +0900 (JST) Received: from [127.0.0.1] (kiras1.priv.cysol.co.jp [192.168.0.151]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBSIjJsN028597; Fri, 29 Dec 2006 03:45:29 +0900 (JST) Message-ID: <459410BE.1040706@cysols.com> Date: Fri, 29 Dec 2006 03:45:18 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: TransportDomain. Was: Re: [Syslog] Submission of draft-ietf-syslog-device-mib-12.txt References: <458A2081.1060800@cysols.com> <20061221143808.GC2166@boskop.local> <458B41CA.1050108@cysols.com> <20061222093409.GA4476@boskop.local> In-Reply-To: <20061222093409.GA4476@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Wijnen, Bert \(Bert\)" X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Juergen, Thanks. That was helpful. I think that things do fall into place now. I will choose option (a) below. I will be ready to reconsider if there are some cases that cannot be handled with this. Glenn Juergen Schoenwaelder wrote: > On Fri, Dec 22, 2006 at 11:24:10AM +0900, Glenn M. Keeni wrote: > >>> - How do I find out which encapsulations are supported (plain, beep, >>> tls, ...)? >> That is the problem we are trying to solve. >> Can that be done by defining appropriate domains for >> syslog transport over TLS >> syslog transport over beep etc. ? > > Option a): > > You use a four tuple consisting of: > > (InetAddressType, InetAddress, InetPortNumer, SyslogEncapsulation) > > Option b): > > You use a three tuple consisting of: > > (TransportAddressType, TransportAddress, SyslogEncapsulation) > > In both cases, you need to define a TC SyslogEncapsulation which > enumerates the syslog encapsulations (or transport mappings) such as { > other(0), plain(1), tls(2), beep(3), ... }. > > InetAddress identifies Internet network layer endpoints while > TransportAddress identifies Internet transport layer endpoints, no > more no less. If you want to move to a two tuple, the only option in > principle is: > > Option c): > > You use a two tuple consisting of > > (SyslogAddressType, SyslogAddress) > > where SyslogAddressType combines the address type with the > encapsulation (this is essentially what a TDomain does for SNMP) > > /js > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 28 13:51:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H00Lh-0004h0-JA; Thu, 28 Dec 2006 13:51:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H00Lg-0004gZ-8g for syslog@ietf.org; Thu, 28 Dec 2006 13:51:28 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H00Le-0004OH-JZ for syslog@ietf.org; Thu, 28 Dec 2006 13:51:28 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBSIpPJW024414; Fri, 29 Dec 2006 03:51:25 +0900 (JST) Received: from [127.0.0.1] (kiras1.priv.cysol.co.jp [192.168.0.151]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBSIpHsN028645; Fri, 29 Dec 2006 03:51:23 +0900 (JST) Message-ID: <45941222.3060901@cysols.com> Date: Fri, 29 Dec 2006 03:51:14 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org, "Wijnen, Bert (Bert)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Subject: [Syslog] TransportDomain issue X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, After some discussion on the list and explanations from Juergen I porpose the following MIB description of the syslog transport. Let me have your comments. Cheers Glenn +-----------------------------------------------------------+ SyslogEncapsulation ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention enumerates the encapsulations of the syslog message that is used between syslog application endpoints. " REFERENCE "TBD. " SYNTAX INTEGER { other (0), none (1), -- RFCUDPX (no encapsulation) tls (2), -- RFCTLS beep (3), -- RFCBEEP sign (4) -- RFCSIGN } syslogDefaultEncapsulation OBJECT-TYPE SYNTAX SyslogEncapsulation MAX-ACCESS read-write STATUS current DESCRIPTION "The default encapsulation that the syslog entity will use to send syslog messages. The value of this object SHOULD remain unchanged across reboots of the managed entity. " REFERENCE "RFCUDPX, RFCTLS, RFCBEEP, RFCSIGN " DEFVAL { "1" } ::= { syslogSystem 5 } SyslogEntityControlEntry ::= SEQUENCE { ----- ----- syslogEntityControlBindAddrType InetAddressType, syslogEntityControlBindAddr InetAddress, syslogEntityControlService SyslogService, syslogEntityControlEncapsulation SyslogEncapsulation, ----- ----- } syslogEntityControlBindAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address which follows in syslogEntityControlBindAddr. If this syslog entity is not a syslog receiver, the value of this object will be 'unknown' (0)." " ::= { syslogEntityControlEntry 3 } .ne 10 syslogEntityControlBindAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The specific address the syslog receiver will bind to. The format of the address is specified by the corresponding syslogEntityControlBindAddrType object. If the address is specified in the DNS domain name format [syslogEntityControlBindAddrType = 'dns'], the corresponding IPv4 or IPv6 address obtained at the time of the binding operation by the syslog entity, will be used. If this syslog entity is not a syslog receiver, the value of this object will be a zero-length string." " ::= { syslogEntityControlEntry 4 } syslogEntityControlService OBJECT-TYPE SYNTAX SyslogService MAX-ACCESS read-create STATUS current DESCRIPTION "The service name or port number that this syslog receiver will be listening on for syslog messages. If this syslog entity is not a syslog receiver the value of this object will be zero. If no value is specified, the syslog receiver will use the service name or port number specified in syslogDefaultService. " ::= { syslogEntityControlEntry 6 } syslogEntityControlEncapsulation OBJECT-TYPE SYNTAX SyslogEncapsulation, MAX-ACCESS read-create STATUS current DESCRIPTION "The encapsulation that will be used for syslog messages. If no value is specified, the syslog entity will use the encapsulation specified in syslogDefaultEncapsulation. " ::= { syslogEntityControlEntry 7 } _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 28 15:30:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01st-0002Q4-Ue; Thu, 28 Dec 2006 15:29:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01ss-0002Pv-JO for syslog@ietf.org; Thu, 28 Dec 2006 15:29:51 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H01so-0007qn-03 for syslog@ietf.org; Thu, 28 Dec 2006 15:29:50 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 10E8355E45; Thu, 28 Dec 2006 21:29:41 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08035-05; Thu, 28 Dec 2006 21:29:37 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 7E5AC55DA0; Thu, 28 Dec 2006 21:29:37 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id D1CDB909C06; Thu, 28 Dec 2006 21:29:36 +0100 (CET) Date: Thu, 28 Dec 2006 21:29:36 +0100 From: Juergen Schoenwaelder To: "Glenn M. Keeni" Subject: Re: [Syslog] TransportDomain issue Message-ID: <20061228202936.GB15113@boskop.local> Mail-Followup-To: "Glenn M. Keeni" , syslog@ietf.org, "Wijnen, Bert (Bert)" References: <45941222.3060901@cysols.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45941222.3060901@cysols.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: "Wijnen, Bert \(Bert\)" , syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Fri, Dec 29, 2006 at 03:51:14AM +0900, Glenn M. Keeni wrote: > After some discussion on the list and explanations > from Juergen I porpose the following MIB description > of the syslog transport. Let me have your comments. > > Cheers > > Glenn > > +-----------------------------------------------------------+ > > SyslogEncapsulation ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This textual convention enumerates the encapsulations > of the syslog message that is used between syslog > application endpoints. > " > REFERENCE > "TBD. > " > SYNTAX INTEGER > { > other (0), > none (1), -- RFCUDPX (no encapsulation) > tls (2), -- RFCTLS > beep (3), -- RFCBEEP > sign (4) -- RFCSIGN > } My understanding is that signed syslog messages can be shipped over different transports. The signed syslog ID says: This specification is independent of the actual transport protocol selected. The mechanism is especially suitable for use with the syslog protocol as defined in RFC xxxx [14] because it utilizes the STRUCTURED-DATA elements defined in that document. It may also be used with syslog packets over traditional UDP [4] as described in RFC 3164 [10]. It may also be used with the Reliable Delivery of syslog as described in RFC 3195 [11], and it may be used with other message delivery mechanisms. Designers of other efforts to define event notification mechanisms are encouraged to consider this specification in their design. In other words, I think sign(4) does not make sense as an encapsulation mechanism. > syslogDefaultEncapsulation OBJECT-TYPE > SYNTAX SyslogEncapsulation > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The default encapsulation that the syslog > entity will use to send syslog messages. > > The value of this object SHOULD remain unchanged > across reboots of the managed entity. > " > REFERENCE > "RFCUDPX, RFCTLS, RFCBEEP, RFCSIGN > " > DEFVAL { "1" } This object talks about "sending" messages. (Note that the DEFVAL is syntactically wrong.) > ::= { syslogSystem 5 } > > > SyslogEntityControlEntry ::= > SEQUENCE { > ----- > ----- > syslogEntityControlBindAddrType > InetAddressType, > syslogEntityControlBindAddr > InetAddress, > syslogEntityControlService > SyslogService, > syslogEntityControlEncapsulation > SyslogEncapsulation, > ----- > ----- > } > > syslogEntityControlBindAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The type of Internet address which follows > in syslogEntityControlBindAddr. > If this syslog entity is not a syslog receiver, > the value of this object will be 'unknown' (0)." > " > ::= { syslogEntityControlEntry 3 } > > .ne 10 > syslogEntityControlBindAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The specific address the syslog receiver will bind to. > The format of the address is specified by the > corresponding syslogEntityControlBindAddrType object. > If the address is specified in the DNS domain name format > [syslogEntityControlBindAddrType = 'dns'], the > corresponding IPv4 or IPv6 address obtained at the time > of the binding operation by the syslog entity, will be > used. > If this syslog entity is not a syslog receiver, the value > of this object will be a zero-length string." > " > ::= { syslogEntityControlEntry 4 } > syslogEntityControlService OBJECT-TYPE > SYNTAX SyslogService > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The service name or port number that this syslog receiver > will be listening on for syslog messages. > > If this syslog entity is not a syslog receiver the value > of this object will be zero. > > If no value is specified, the syslog receiver will use the > service name or port number specified in > syslogDefaultService. > " > ::= { syslogEntityControlEntry 6 } These three objects are for the syslog receiver endpoint. I still question the usefulness of the service name (since it has local significance) and suggest to use an InetPortNumber instead and to rename this to syslogEntityControlBindPort. > syslogEntityControlEncapsulation OBJECT-TYPE > SYNTAX SyslogEncapsulation, > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The encapsulation that will be used for syslog messages. > > If no value is specified, the syslog entity will use the > encapsulation specified in syslogDefaultEncapsulation. > " > ::= { syslogEntityControlEntry 7 } This object now again talks about sending syslog messages. I am still confused. Before we beat this further, it might be useful to agree what the purpose and usage of these objects is going to be. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 28 15:46:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H028j-0007VC-2w; Thu, 28 Dec 2006 15:46:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H028i-0007V6-3U for syslog@ietf.org; Thu, 28 Dec 2006 15:46:12 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H028g-00018U-T3 for syslog@ietf.org; Thu, 28 Dec 2006 15:46:12 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20061228204610b1300q9t8ge>; Thu, 28 Dec 2006 20:46:10 +0000 From: "David Harrington" To: Date: Thu, 28 Dec 2006 15:42:55 -0500 Message-ID: <1e5e01c72ac0$c6883090$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccqwG7iaNi7a7yCTVuamyGqvYHTaw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Syslog] Rfc3164 and mib X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The consensus of the WG is to obsolete rfc3164. Therefore, it should not be referenced in the MIB document. The MIB document only references it in the introduction, so this has no effect. Glenn, please remove all reference to RFC3164 from the mib document. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 28 16:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H02x6-0001MU-CR; Thu, 28 Dec 2006 16:38:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H02x5-0001MM-51 for syslog@ietf.org; Thu, 28 Dec 2006 16:38:15 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H02x3-00031j-MH for syslog@ietf.org; Thu, 28 Dec 2006 16:38:15 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20061228213812b1400mhkshe>; Thu, 28 Dec 2006 21:38:13 +0000 From: "David Harrington" To: , "'Glenn M. Keeni'" Subject: RE: [Syslog] TransportDomain issue Date: Thu, 28 Dec 2006 16:34:45 -0500 Message-ID: <1ec301c72ac8$0af5dfa0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccqvwQky58yQ+FwTleGcDzWLSum4gAAtT4g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <20061228202936.GB15113@boskop.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: "'Wijnen, Bert \(Bert\)'" , syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi [speaking as co-chair] As this discussion continues, and based on the updated description clauses, it appears more and more obvious that some objects are only important for receivers or for senders or for relays: syslogEntityControlBindAddrType = receiver syslogEntityControlBindAddr = receiver syslogEntityControlBind(Port) = receiver syslogEntityControlService = receiver syslogEntityControlMaxMessageSize = receiver syslogEntityOperationsMsgsIgnored = receiver (exceeds max message size) syslogEntityOperationsMsgsReceived = reciever syslogEntityOperationsMsgsIllFormed = receiver syslogEntityOperationsLastMsgRecdTime = receiver (or for internal debugging?) syslogEntityControlEncapsulation = sender syslogEntityOperationsMsgsDropped = sender (internal debugging information?) syslogEntityOperationsLastMsgRecdTime = sender (internal debugging?) syslogEntityOperationsLastMsgTransmittedTime = sender, relay syslogDefaultFacility = relay syslogDefaultSeverity = relay syslogEntityOperationsMsgsRelayed = relay syslogEntityOperationsLastMsgTransmittedTime = sender, relay syslogEntityControlConfFileName = entity So let's take the tables, break them out according to role and document what is needed for each role. After that exercise, we may reach the conclusion that much of the info could be modeled for a generic syslog entity, but at this point I am far from convinced that is true. So far, the members of this WG have stayed out of the mib discussions, so the overall design (scalar versus tabular) comes down to Tom versus Glenn, and that does not denote consensus. We have seen one approach, but not the other, so let's design an alternate mib that has the information broken out by sender/receiver/relay, and is scalar with different instances represented in different SNMP contexts. This may simplify the design considerably and help us to understand what needs to be in the official mib module. Who wants to design an alternate mib module for the WG? It doesn't have to be perfect from a MIB standpoint; it needs to do a reasonably good job of showing what needs to be modeled for 1) a syslog receiver, 2) a syslog sender, and 3) a syslog relay. Glenn? Tom? Others? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Thursday, December 28, 2006 3:30 PM > To: Glenn M. Keeni > Cc: Wijnen, Bert (Bert); syslog@ietf.org > Subject: Re: [Syslog] TransportDomain issue > > On Fri, Dec 29, 2006 at 03:51:14AM +0900, Glenn M. Keeni wrote: > > > After some discussion on the list and explanations > > from Juergen I porpose the following MIB description > > of the syslog transport. Let me have your comments. > > > > Cheers > > > > Glenn > > > > +-----------------------------------------------------------+ > > > > SyslogEncapsulation ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "This textual convention enumerates the encapsulations > > of the syslog message that is used between syslog > > application endpoints. > > " > > REFERENCE > > "TBD. > > " > > SYNTAX INTEGER > > { > > other (0), > > none (1), -- RFCUDPX (no encapsulation) > > tls (2), -- RFCTLS > > beep (3), -- RFCBEEP > > sign (4) -- RFCSIGN > > } > > My understanding is that signed syslog messages can be shipped over > different transports. The signed syslog ID says: > > This specification is independent of the actual transport protocol > selected. The mechanism is especially suitable for use with the > syslog protocol as defined in RFC xxxx [14] because it utilizes the > STRUCTURED-DATA elements defined in that document. It may also be > used with syslog packets over traditional UDP [4] as > described in RFC > 3164 [10]. It may also be used with the Reliable Delivery > of syslog > as described in RFC 3195 [11], and it may be used with > other message > delivery mechanisms. Designers of other efforts to define event > notification mechanisms are encouraged to consider this > specification > in their design. > > In other words, I think sign(4) does not make sense as an > encapsulation mechanism. > > > syslogDefaultEncapsulation OBJECT-TYPE > > SYNTAX SyslogEncapsulation > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The default encapsulation that the syslog > > entity will use to send syslog messages. > > > > The value of this object SHOULD remain unchanged > > across reboots of the managed entity. > > " > > REFERENCE > > "RFCUDPX, RFCTLS, RFCBEEP, RFCSIGN > > " > > DEFVAL { "1" } > > This object talks about "sending" messages. (Note that the DEFVAL is > syntactically wrong.) > > > ::= { syslogSystem 5 } > > > > > > SyslogEntityControlEntry ::= > > SEQUENCE { > > ----- > > ----- > > syslogEntityControlBindAddrType > > InetAddressType, > > syslogEntityControlBindAddr > > InetAddress, > > syslogEntityControlService > > SyslogService, > > syslogEntityControlEncapsulation > > SyslogEncapsulation, > > ----- > > ----- > > } > > > > syslogEntityControlBindAddrType OBJECT-TYPE > > SYNTAX InetAddressType > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The type of Internet address which follows > > in syslogEntityControlBindAddr. > > If this syslog entity is not a syslog receiver, > > the value of this object will be 'unknown' (0)." > > " > > ::= { syslogEntityControlEntry 3 } > > > > .ne 10 > > syslogEntityControlBindAddr OBJECT-TYPE > > SYNTAX InetAddress > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The specific address the syslog receiver will bind to. > > The format of the address is specified by the > > corresponding syslogEntityControlBindAddrType object. > > If the address is specified in the DNS domain name format > > [syslogEntityControlBindAddrType = 'dns'], the > > corresponding IPv4 or IPv6 address obtained at the time > > of the binding operation by the syslog entity, will be > > used. > > If this syslog entity is not a syslog receiver, the value > > of this object will be a zero-length string." > > " > > ::= { syslogEntityControlEntry 4 } > > syslogEntityControlService OBJECT-TYPE > > SYNTAX SyslogService > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The service name or port number that this syslog receiver > > will be listening on for syslog messages. > > > > If this syslog entity is not a syslog receiver the value > > of this object will be zero. > > > > If no value is specified, the syslog receiver will use the > > service name or port number specified in > > syslogDefaultService. > > " > > ::= { syslogEntityControlEntry 6 } > > These three objects are for the syslog receiver endpoint. I still > question the usefulness of the service name (since it has local > significance) and suggest to use an InetPortNumber instead and to > rename this to syslogEntityControlBindPort. > > > syslogEntityControlEncapsulation OBJECT-TYPE > > SYNTAX SyslogEncapsulation, > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The encapsulation that will be used for syslog messages. > > > > If no value is specified, the syslog entity will use the > > encapsulation specified in syslogDefaultEncapsulation. > > " > > ::= { syslogEntityControlEntry 7 } > > This object now again talks about sending syslog messages. I am still > confused. Before we beat this further, it might be useful to agree > what the purpose and usage of these objects is going to be. > > /js > > -- > Juergen Schoenwaelder {International|Jacobs} > University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 29 06:35:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0G0W-0002XT-5I; Fri, 29 Dec 2006 06:34:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0G0U-0002XB-TU for syslog@ietf.org; Fri, 29 Dec 2006 06:34:38 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0G0T-0007JK-Gm for syslog@ietf.org; Fri, 29 Dec 2006 06:34:38 -0500 Received: from pc6 (1Cust53.tnt6.lnd4.gbr.da.uu.net [62.188.135.53]) by ranger.systems.pipex.net (Postfix) with SMTP id 2D30AE000487; Fri, 29 Dec 2006 11:34:23 +0000 (GMT) Message-ID: <025501c72b34$da1ee4e0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Glenn M. Keeni'" References: <1ec301c72ac8$0af5dfa0$0600a8c0@china.huawei.com> Date: Fri, 29 Dec 2006 11:32:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: syslog@ietf.org Subject: [Syslog] Mib structure issue wasTransportDomain issue X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "David Harrington" To: ; "'Glenn M. Keeni'" Cc: "'Wijnen, Bert (Bert)'" ; Sent: Thursday, December 28, 2006 10:34 PM Subject: RE: [Syslog] TransportDomain issue > [speaking as co-chair] > > As this discussion continues, and based on the updated description > clauses, it appears more and more obvious that some objects are only > important for receivers or for senders or for relays: Agreed although I disagree with some of your characterisations. More fundamentally, who is going to implement a MIB module where? Not I (sadly) but the one I want to see is in the managed network device, the sender, not relay/collector/receiver ( hosts which are likely to have plenty of non-MIB ways of doing things) so that is my prejudice. But for this work to have value, someone needs to be likely to implement this and I do not know who that might be; it is their views that I think matter most and I do not know what those views are - it may be that all potential implementors only want to implement on Windows platforms:-) which would in turn affect what should be in a MIB module. Whatever, my list of desirable objects is slightly different, as follows (I have shortened the object names to make them easier to read and write, the additional words can always go back later). Also, I see a relay as a sender+receiver so with one exception, I see no object as particular to a relay. syslogAddrType / syslogAddr / syslogPort endpoint on which a receiver (relay) listens endpoint to which a sender (relay) sends syslogService do not understand this except as a port, for which use syslogPort syslogMaxMessageSize maximum message size a receiver (relay) will accept syslogMsgsTooLarge messages received and discarded as too large by receiver (relay) syslogMsgsReceived total messages received valid and invalid by receiver (relay) syslogMsgsIllFormed messages received and discarded incorrect format by receiver (relay) syslogMsgsLastRecdTime sysUpTime of last message received by receiver (relay) syslogEncapsulation receiver (relay) formats supported (BEEP RAW, BEEP COOKED, TLS, SIGN ...) sender (relay) formats supported syslogMsgsSent total messages sent successfully by sender (relay) syslogMsgsDropped messages that could not be sent by sender (relay) syslogMsgsLastSentTime sysUpTime of last message sent by sender (relay) syslogCapability sending, receiving (probably as enumerated bits so both = relay) syslogDefaultSeverity unclear of the role of this syslogMsgsRelayed messages received and relayed (excludes messages originating in this process) syslogConfFileName configuration file - all plus perhaps, at least for sender, syslogHostname syslogAppName syslogProcId Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 29 08:13:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0HX1-0005dy-BJ; Fri, 29 Dec 2006 08:12:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0HWz-0005dr-Gz for syslog@ietf.org; Fri, 29 Dec 2006 08:12:17 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0HWx-0000vz-HR for syslog@ietf.org; Fri, 29 Dec 2006 08:12:17 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBTDCDJW009969; Fri, 29 Dec 2006 22:12:13 +0900 (JST) Received: from [127.0.0.1] (kiras1.priv.cysol.co.jp [192.168.0.151]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id kBTDC4sN007032; Fri, 29 Dec 2006 22:12:11 +0900 (JST) Message-ID: <45951421.9060108@cysols.com> Date: Fri, 29 Dec 2006 22:12:01 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org, "Wijnen, Bert (Bert)" Subject: Re: [Syslog] TransportDomain issue References: <45941222.3060901@cysols.com> <20061228202936.GB15113@boskop.local> In-Reply-To: <20061228202936.GB15113@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, > This object now again talks about sending syslog messages. I am still > confused. Before we beat this further, it might be useful to agree > what the purpose and usage of these objects is going to be. > The objects are for monitoring. The Manager/NMS will be able to find the configuration of the syslog receiver(s) on a host. E.g. there may be a syslog-tls receiver, and multiple syslog-udp receivers on a host. In one scenario the table will look like Type Address Port Encapsulation MsgsReceived MsgsDropped V4 1.1.1.1 11 TLS R1 D1 v6 v6address 22 None R2 D2 v4 3.3.3.3 33 None R3 D3 Now, I am not sure whether the same receiver can have multiple endpoints. The present MIB does not allow for multiple end-points. Glenn Juergen Schoenwaelder wrote: > On Fri, Dec 29, 2006 at 03:51:14AM +0900, Glenn M. Keeni wrote: > >> After some discussion on the list and explanations >> from Juergen I porpose the following MIB description >> of the syslog transport. Let me have your comments. >> >> Cheers >> >> Glenn >> >> +-----------------------------------------------------------+ >> >> SyslogEncapsulation ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "This textual convention enumerates the encapsulations >> of the syslog message that is used between syslog >> application endpoints. >> " >> REFERENCE >> "TBD. >> " >> SYNTAX INTEGER >> { >> other (0), >> none (1), -- RFCUDPX (no encapsulation) >> tls (2), -- RFCTLS >> beep (3), -- RFCBEEP >> sign (4) -- RFCSIGN >> } > > My understanding is that signed syslog messages can be shipped over > different transports. The signed syslog ID says: > > This specification is independent of the actual transport protocol > selected. The mechanism is especially suitable for use with the > syslog protocol as defined in RFC xxxx [14] because it utilizes the > STRUCTURED-DATA elements defined in that document. It may also be > used with syslog packets over traditional UDP [4] as described in RFC > 3164 [10]. It may also be used with the Reliable Delivery of syslog > as described in RFC 3195 [11], and it may be used with other message > delivery mechanisms. Designers of other efforts to define event > notification mechanisms are encouraged to consider this specification > in their design. > > In other words, I think sign(4) does not make sense as an > encapsulation mechanism. > >> syslogDefaultEncapsulation OBJECT-TYPE >> SYNTAX SyslogEncapsulation >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "The default encapsulation that the syslog >> entity will use to send syslog messages. >> >> The value of this object SHOULD remain unchanged >> across reboots of the managed entity. >> " >> REFERENCE >> "RFCUDPX, RFCTLS, RFCBEEP, RFCSIGN >> " >> DEFVAL { "1" } > > This object talks about "sending" messages. (Note that the DEFVAL is > syntactically wrong.) > >> ::= { syslogSystem 5 } >> >> >> SyslogEntityControlEntry ::= >> SEQUENCE { >> ----- >> ----- >> syslogEntityControlBindAddrType >> InetAddressType, >> syslogEntityControlBindAddr >> InetAddress, >> syslogEntityControlService >> SyslogService, >> syslogEntityControlEncapsulation >> SyslogEncapsulation, >> ----- >> ----- >> } >> >> syslogEntityControlBindAddrType OBJECT-TYPE >> SYNTAX InetAddressType >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "The type of Internet address which follows >> in syslogEntityControlBindAddr. >> If this syslog entity is not a syslog receiver, >> the value of this object will be 'unknown' (0)." >> " >> ::= { syslogEntityControlEntry 3 } >> >> .ne 10 >> syslogEntityControlBindAddr OBJECT-TYPE >> SYNTAX InetAddress >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "The specific address the syslog receiver will bind to. >> The format of the address is specified by the >> corresponding syslogEntityControlBindAddrType object. >> If the address is specified in the DNS domain name format >> [syslogEntityControlBindAddrType = 'dns'], the >> corresponding IPv4 or IPv6 address obtained at the time >> of the binding operation by the syslog entity, will be >> used. >> If this syslog entity is not a syslog receiver, the value >> of this object will be a zero-length string." >> " >> ::= { syslogEntityControlEntry 4 } >> syslogEntityControlService OBJECT-TYPE >> SYNTAX SyslogService >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "The service name or port number that this syslog receiver >> will be listening on for syslog messages. >> >> If this syslog entity is not a syslog receiver the value >> of this object will be zero. >> >> If no value is specified, the syslog receiver will use the >> service name or port number specified in >> syslogDefaultService. >> " >> ::= { syslogEntityControlEntry 6 } > > These three objects are for the syslog receiver endpoint. I still > question the usefulness of the service name (since it has local > significance) and suggest to use an InetPortNumber instead and to > rename this to syslogEntityControlBindPort. > >> syslogEntityControlEncapsulation OBJECT-TYPE >> SYNTAX SyslogEncapsulation, >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "The encapsulation that will be used for syslog messages. >> >> If no value is specified, the syslog entity will use the >> encapsulation specified in syslogDefaultEncapsulation. >> " >> ::= { syslogEntityControlEntry 7 } > > This object now again talks about sending syslog messages. I am still > confused. Before we beat this further, it might be useful to agree > what the purpose and usage of these objects is going to be. > > /js > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Dec 30 12:47:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0iIP-0007mR-Dk; Sat, 30 Dec 2006 12:47:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0J1G-0006u5-Eh for syslog@ietf.org; Fri, 29 Dec 2006 09:47:38 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0J1E-00014U-Jo for syslog@ietf.org; Fri, 29 Dec 2006 09:47:37 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kBTElQvk005472; Fri, 29 Dec 2006 08:47:27 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 08:47:26 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 15:47:24 +0100 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: Fri, 29 Dec 2006 15:47:24 +0100 Message-ID: In-Reply-To: <45941222.3060901@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TransportDomain issue Thread-Index: AccqsTHYaTOD9rLvTFC/N4B2cxxrnAAoglJw From: "Wijnen, Bert \(Bert\)" To: "Glenn M. Keeni" , X-OriginalArrivalTime: 29 Dec 2006 14:47:24.0741 (UTC) FILETIME=[40C97750:01C72B58] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab X-Mailman-Approved-At: Sat, 30 Dec 2006 12:47:01 -0500 Cc: Subject: [Syslog] RE: TransportDomain issue X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Quick comment: I thought/think that the MIB doctors in general advise/prefer to start enumartions at 1 and not at zero. Bert=20 > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com]=20 > Sent: donderdag 28 december 2006 19:51 > To: syslog@ietf.org; Wijnen, Bert (Bert) > Subject: TransportDomain issue >=20 > Hi, > After some discussion on the list and explanations from=20 > Juergen I porpose the following MIB description of the syslog=20 > transport. Let me have your comments. >=20 > Cheers >=20 > Glenn >=20 > +-----------------------------------------------------------+ >=20 > SyslogEncapsulation ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This textual convention enumerates the encapsulations > of the syslog message that is used between syslog > application endpoints. > " > REFERENCE > "TBD. > " > SYNTAX INTEGER > { > other (0), > none (1), -- RFCUDPX (no encapsulation) > tls (2), -- RFCTLS > beep (3), -- RFCBEEP > sign (4) -- RFCSIGN > } >=20 > syslogDefaultEncapsulation OBJECT-TYPE > SYNTAX SyslogEncapsulation > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The default encapsulation that the syslog > entity will use to send syslog messages. >=20 > The value of this object SHOULD remain unchanged > across reboots of the managed entity. > " > REFERENCE > "RFCUDPX, RFCTLS, RFCBEEP, RFCSIGN > " > DEFVAL { "1" } > ::=3D { syslogSystem 5 } >=20 >=20 > SyslogEntityControlEntry ::=3D > SEQUENCE { > ----- > ----- > syslogEntityControlBindAddrType > InetAddressType, > syslogEntityControlBindAddr > InetAddress, > syslogEntityControlService > SyslogService, > syslogEntityControlEncapsulation > SyslogEncapsulation, > ----- > ----- > } >=20 > syslogEntityControlBindAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The type of Internet address which follows > in syslogEntityControlBindAddr. > If this syslog entity is not a syslog receiver, > the value of this object will be 'unknown' (0)." > " > ::=3D { syslogEntityControlEntry 3 } >=20 > .ne 10 > syslogEntityControlBindAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The specific address the syslog receiver will bind to. > The format of the address is specified by the > corresponding syslogEntityControlBindAddrType object. > If the address is specified in the DNS domain name format > [syslogEntityControlBindAddrType =3D 'dns'], the > corresponding IPv4 or IPv6 address obtained at the time > of the binding operation by the syslog entity, will be > used. > If this syslog entity is not a syslog receiver, the value > of this object will be a zero-length string." > " > ::=3D { syslogEntityControlEntry 4 } > syslogEntityControlService OBJECT-TYPE > SYNTAX SyslogService > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The service name or port number that this syslog receiver > will be listening on for syslog messages. >=20 > If this syslog entity is not a syslog receiver the value > of this object will be zero. >=20 > If no value is specified, the syslog receiver will use the > service name or port number specified in > syslogDefaultService. > " > ::=3D { syslogEntityControlEntry 6 } >=20 > syslogEntityControlEncapsulation OBJECT-TYPE > SYNTAX SyslogEncapsulation, > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The encapsulation that will be used for syslog messages. >=20 > If no value is specified, the syslog entity will use the > encapsulation specified in syslogDefaultEncapsulation. > " > ::=3D { syslogEntityControlEntry 7 } >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Dec 31 14:26:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H16Ip-0005GD-0f; Sun, 31 Dec 2006 14:25:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H16Io-0005G7-1E for syslog@ietf.org; Sun, 31 Dec 2006 14:25:02 -0500 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H16Ik-0005M6-GJ for syslog@ietf.org; Sun, 31 Dec 2006 14:25:02 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20061231192455b1200bqc5ve>; Sun, 31 Dec 2006 19:24:55 +0000 From: "David Harrington" To: Date: Sun, 31 Dec 2006 14:21:36 -0500 Message-ID: <209f01c72d10$ea16adf0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iACkS6mUBSSxIGQA/mUC4A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Syslog] Conclusion of Working Group Last Call: syslog-sign-20 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, This message officially concludes the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-20.txt The chairs and the editor will review the comments and determine which actions should be taken. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog