From ietfdbh@comcast.net Tue Jan 19 12:56:29 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04703A695E for ; Tue, 19 Jan 2010 12:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZySkWsM38dXw for ; Tue, 19 Jan 2010 12:56:29 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id D054E3A690E for ; Tue, 19 Jan 2010 12:56:28 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta10.westchester.pa.mail.comcast.net with comcast id XVFY1d00C1GhbT85AYwSww; Tue, 19 Jan 2010 20:56:26 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta07.westchester.pa.mail.comcast.net with comcast id XYwR1d008284sdk3TYwR2U; Tue, 19 Jan 2010 20:56:26 +0000 From: "David Harrington" To: Date: Tue, 19 Jan 2010 15:56:24 -0500 Message-ID: <00b601ca9949$dcd661a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcqZSdyHzOdjWf9eQLq2XtquJFEDgg== Subject: [Syslog] ietf77 - no syslog meeting X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 20:56:29 -0000 Hi, Chris and I see no reason to hold a syslog WG meeting at ietf77. If you feel there is something that requires a face-to-face meeting, please let us know. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From clonvick@cisco.com Tue Jan 26 10:24:47 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF183A6823 for ; Tue, 26 Jan 2010 10:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3DWC-j03S50 for ; Tue, 26 Jan 2010 10:24:46 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 55E733A6804 for ; Tue, 26 Jan 2010 10:24:46 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEANPBXkurRN+K/2dsb2JhbACQCwGzZZcihDkE X-IronPort-AV: E=Sophos;i="4.49,347,1262563200"; d="scan'208";a="140282938" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 26 Jan 2010 18:24:57 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0QIOvT6014866 for ; Tue, 26 Jan 2010 18:24:57 GMT Date: Tue, 26 Jan 2010 10:24: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 Subject: [Syslog] Review comments on draft-gerhards-syslog-plain-tcp-01.txt X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:24:47 -0000 Hi Folks, David provided a great review of -00 and we've updated it. http://tools.ietf.org/html/draft-gerhards-syslog-plain-tcp-01 Just one more time, this is not a product of the syslog WG. If you have some time, we would appreciate reviews. Here are our replies to David's review. 1) Is there such a thing as an RFC3164 message? Isn't rfc3164 just a description of a bunch of implementations, each of which has its own message format? CML> I've changed the wording. 3164 describes the original syntax that Eric Allman intended. It then backpeddles because there are so many divergences from that. 2) In the intro, the last sentence mentions syslog transport receivers and legacy syslog senders. Is this text consistent with the RFC5424 terminology? CML> I've changed that wording and added a clarification. 3) I suggest a small diagram showing the stack-oriented approach of rf5424 and its transport models, with an arrow showing that this document discusses interactions between the sender and receiver transport implementations. CML> New diagram 1. 4) Diagram 2 is labelled Diagram 1 CML> It's easier to reference when all diagrams are labelled the same. ....umm, OK, we removed the state diagrams as they were incomplete and would require a lot of work to get a correct basic understanding. 5) octet-counting and octet-stuffing are not described before the discussion of MUST/MAY is addressed. It would help to point to the sections that define these (i.e. provide a forward reference). CML> Now described in the Intro. 6) the discussion of MUST/MAY and REQUIRED/RECOMMENDED is redundant. You only need the sentence with REQUIRED/RECOMMENDED (which also discusses why) CML> OK 7) Is ABNF a figure? Do you need both diagrams and figures? CML> No longer a figure. 8) I'm not an expert on ABNF. Will this ABNF parse in standard parsers with APP-DEFINED not specified? CML> It would parse but I've modified it to be more complete. 9) " A transport receiver MUST accept that the TRAILER character is a USASCII LF." sounds like the receiver is talking with a shrink ;-) How about "A transport receiver MUST accept USASCII LF as a TRAILER character."? CML> Changed. 10) s/octect/octet/g CML> My bad. 11) 3.3.1 is NOT RECOMMENDED; 3.3.2 is RECOMMENDED. I would reverse their order CML> OK 12) 3.3.1 is NOT RECOMMENDED; 3.3.2 is RECOMMENDED. But if I read 3.3, they are MAY/MUST and RECOMMENDED/REQUIRED. There is inconsistency of RECOMMENDED vs MAY vs NOT RECOMMENDED for stuffing, and of MUST vs REQUIRED vs RECOMMENDED for counting. CML> Described later. It's so that the receiver can accept both types of legacy formats. 13) " It is recommended and current practice that a transport receiver assumes that octet counted framing is used if a syslog frame starts with a digit." You are defining a standard; make this a MUST for compliance to this standard. CML> OK 14) " SYSLOG-MSG is defined in [RFC5424]. Most senders use the format described in [RFC3164] as an alternate format." This sounds like an implicit recommendation to use the rfc3164 format, since that's what most senders use. Again, you are defining a standard; I think you should at least RECOMMEND the rfc5424 format for compliance with this TCP transport standard. CML> You misinterpreted that. It's saying that most legacy syslogs are using the format described in 3164. Nonetheless, I don't see that the paragraph is needed so it's been removed. 15) section 3.4 says to discard the TRAILER. How will this work with syslog sign? Should the hash be calculated before the TRAILER is added? And for octet counting, is the hash calculated before the count is prepended? CML> Yeah, not enough clarity there. I've reworked it to be consistent with 5424. 16) section 3.5 says "It then initiates a TCP session closure." Not being knowledgeable about TCP details, I thught this meant it would start a closure conversation with the peer. Would this be clearer if it said "It then initiates a local TCP session closure."? Obviously, the text that follows clarifies this, but it was distracting. CML> Sounds good to me. :-) 17) Some people prefer that non-normative sections be handled as appendices. Would it be good to move section for to an appendix? CML> Yes - I've moved all of that to an appendix. 18) section 4 uses terms "encouraged" and "should". This is not consistent with RFC2119. CML> Revisions made. 19) section 4 - same coments as in 13) CML> OK 20) section 4.1 - is this advice consistent with earlier statements about having to close and re-init the connection? If the difference is that the earlier discussed requirements for compliance ("conservative in what you send"), and this talks about "liberal in what you receive", I recommend you discuss it in those terms. (Is that Postel's law, or something like that?) 21) 4.2 and 4.3 mention what is REQUIRED; but section 4 is non-normative and only informational. The REQUIRED seems out of place here. I think a discussion of interoperability with legacy devices (ala Postel) might be called for in both sections, rather than RFC2119 required/may discussions. 22) "In that" is unnecessary and makes the sentence harder to parse. 23) "In this legacy implementation" - should this be "In some legacy implementations"? That whole paragragh could use cleanup. 24) octet-counting and octet-stuffing sections should be ordered consistently with 11) CML> I made changes throughout. Please take a look. 25) section 5.1 "representing itself as another machine" it is not clear who is doing the misrepresenting in this sentence - the sender or the receiver. Needs wordsmithing. CML> It was good enough for RFC 5426. Please look again to see if it's cleared up with these edits. 26) "indeed" is seldom necessary CML> Indeed. 27) 5.6 "cannot always know" - does it ever know? The transport sender doesn't, and TCP won't either. If you fail to get an ACK, does that mean that it was or wasn't delivered? CML> Cleaned up. 28) You should have a "Note to the RFC Editor" to discuss replacing the in the text associated with the port assignment requested in section 7. (Oh, I found it in secton 9; why not just put it into section 7?) CML> Cleaned up. 29) I think the acknowledgement of xml2rfc is not needed. Acknowledgements are for technical contributors. If you wrote the draft using MS-Word or Notepad or Emacs, would you acknowledge them? CML> OK 30) You don't need to have section 6; xml2rfc automatically generates a section (unnumbered per RFC editor rules) for Authors' Addresses. CML> OK === Thanks, Rainer & Chris From cfinss@dial.pipex.com Wed Jan 27 10:19:16 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D6D3A67CC for ; Wed, 27 Jan 2010 10:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LgYh-qvPeie for ; Wed, 27 Jan 2010 10:19:16 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id BD7043A67D3 for ; Wed, 27 Jan 2010 10:19:15 -0800 (PST) X-Trace: 177019762/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.54/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.54 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8GAOUSYEs+vBE2/2dsb2JhbACCLYVOiQfIYgqELwQ X-IronPort-AV: E=Sophos;i="4.49,355,1262563200"; d="scan'208";a="177019762" X-IP-Direction: IN Received: from 1cust54.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.54]) by smtp.pipex.tiscali.co.uk with SMTP; 27 Jan 2010 18:19:28 +0000 Message-ID: <007301ca9f74$d7dba800$0601a8c0@allison> From: "tom.petch" To: "Chris Lonvick" , References: Date: Wed, 27 Jan 2010 16:53:59 +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 Subject: Re: [Syslog] Review comments on draft-gerhards-syslog-plain-tcp-01.txt X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 18:19:16 -0000 Review comments on tcp-01 (as the subject line says:-) What is the intended status? The I-D does not say; I would aim for Standards Track. s.3 "Traditional TCP implementations do not use any backchannel mechanism " suggest "Traditional implementations of syslog over TCP do not use any backchannel mechanism " "abilities of TCP" suggest "capabilities of TCP" s3.3 I think that the ABNF rules should be amended so that the rule with = comes before the rule with =/ Add at the end " SYSLOG-MSG is defined in the syslog protocol [RFC5424]." A.2 %d10 is LF not NL; I do not know which you mean. And, perhaps the most important, somewhere I think you should cover the nature of TCP; give it a message and it will buffer it, may be for days, and then lose it because the connection is taken down. Should you recommend the use of PSH for all messages? Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Tuesday, January 26, 2010 7:24 PM Subject: [Syslog] Review comments on draft-gerhards-syslog-plain-tcp-01.txt > Hi Folks, > From wwwrun@core3.amsl.com Thu Jan 28 07:46:00 2010 Return-Path: X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id EFE803A688B; Thu, 28 Jan 2010 07:46:00 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100128154600.EFE803A688B@core3.amsl.com> Date: Thu, 28 Jan 2010 07:46:00 -0800 (PST) Cc: syslog mailing list , Internet Architecture Board , syslog chair , RFC Editor Subject: [Syslog] Protocol Action: 'Signed syslog Messages' to Proposed Standard X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 15:46:01 -0000 The IESG has approved the following document: - 'Signed syslog Messages ' as a Proposed Standard This document is the product of the Security Issues in Network Event Logging Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-29.txt Technical Summary This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". Working Group Summary The consensus of the working group was to publish this as a standards-track document. Protocol Quality It is possible that there are implementations of this document in various stages of completion at this time. Some equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. Personnel The document shepherd is David Harrington, and the responsible area director is Pasi Eronen. RFC Editor Note In Section 5.2.2, item (b), change both instances of "specifying" to "configuring". In Sections 9.x, change all occurrences of "IETF Consensus" to "IETF Review". Insert a new paragraph in Section 1, just before the last paragraph: "The process of signing works as long as the collector accepts the syslog messages, the Certificate Blocks and the Signature Blocks. Once that is done, the process is complete. After that, anyone can go back, find the key material, and validate the received messages using the information in the Signature Blocks. Finding the key material is very easily done with Key Blob Types C, P, and K (see Section 5.2.1) since the public key is in the Payload Block. If Key Blob Types N or U are used, some poking around may be required to find the key material. The only way to have a vendor-specific implementation is through N or U; however, also in that case the key material will have to be available in some form which could be used by implementations of other vendors." From ietfdbh@comcast.net Thu Jan 28 10:27:08 2010 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2908C3A6838 for ; Thu, 28 Jan 2010 10:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVPbR2uP+q8i for ; Thu, 28 Jan 2010 10:27:07 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by core3.amsl.com (Postfix) with ESMTP id DAC143A6834 for ; Thu, 28 Jan 2010 10:27:06 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id b59v1d0051c6gX85C6TSg0; Thu, 28 Jan 2010 18:27:26 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta23.westchester.pa.mail.comcast.net with comcast id b6U71d00E284sdk3j6U7Tf; Thu, 28 Jan 2010 18:28:08 +0000 From: "David Harrington" To: Date: Thu, 28 Jan 2010 13:27:24 -0500 Message-ID: <069901caa047$8a02ec50$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcqgMQrjUySh9PyvRN6iSJGbT1+p8AAFlVHA Subject: [Syslog] Protocol Action: 'Signed syslog Messages' to Proposed Standard X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 18:27:08 -0000 Syslog-sign has now been approved as a Proposed Standard. Congratulations to all involved. Chris and David -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Thursday, January 28, 2010 10:46 AM To: IETF-Announce Cc: Internet Architecture Board; RFC Editor; syslog mailing list; syslog chair Subject: Protocol Action: 'Signed syslog Messages' to Proposed Standard The IESG has approved the following document: - 'Signed syslog Messages ' as a Proposed Standard This document is the product of the Security Issues in Network Event Logging Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-29.txt Technical Summary This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". Working Group Summary The consensus of the working group was to publish this as a standards-track document. Protocol Quality It is possible that there are implementations of this document in various stages of completion at this time. Some equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. Personnel The document shepherd is David Harrington, and the responsible area director is Pasi Eronen. RFC Editor Note In Section 5.2.2, item (b), change both instances of "specifying" to "configuring". In Sections 9.x, change all occurrences of "IETF Consensus" to "IETF Review". Insert a new paragraph in Section 1, just before the last paragraph: "The process of signing works as long as the collector accepts the syslog messages, the Certificate Blocks and the Signature Blocks. Once that is done, the process is complete. After that, anyone can go back, find the key material, and validate the received messages using the information in the Signature Blocks. Finding the key material is very easily done with Key Blob Types C, P, and K (see Section 5.2.1) since the public key is in the Payload Block. If Key Blob Types N or U are used, some poking around may be required to find the key material. The only way to have a vendor-specific implementation is through N or U; however, also in that case the key material will have to be available in some form which could be used by implementations of other vendors."