Re: [Syslog] New Version Notification fordraft-gerhards-syslog-plain-tcp-05 (fwd)
"David Harrington" <ietfdbh@comcast.net> Tue, 02 November 2010 05:52 UTC
Return-Path: <ietfdbh@comcast.net>
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 134763A67EC for <syslog@core3.amsl.com>; Mon, 1 Nov 2010 22:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.258
X-Spam-Level:
X-Spam-Status: No, score=-102.258 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100]
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 tIuUqe0YFnWH for <syslog@core3.amsl.com>; Mon, 1 Nov 2010 22:52:33 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id C29AB3A67E4 for <syslog@ietf.org>; Mon, 1 Nov 2010 22:52:24 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA11.westchester.pa.mail.comcast.net with comcast id S5q21f0011vXlb85B5sPEu; Tue, 02 Nov 2010 05:52:23 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta17.westchester.pa.mail.comcast.net with comcast id S5sP1f0072JQnJT3d5sPLw; Tue, 02 Nov 2010 05:52:23 +0000
From: David Harrington <ietfdbh@comcast.net>
To: "'t.petch'" <ietfc@btconnect.com>, 'Chris Lonvick' <clonvick@cisco.com>, syslog@ietf.org
Date: Tue, 02 Nov 2010 13:52:28 +0800
Message-ID: <82F9FF37AFF94FB8AC90606D1124D63A@23FX1C1>
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.5994
Thread-Index: Act57y9sNoDu5xDVRhWhEqoAXQpm7gAXvs9AAABhayA=
Subject: Re: [Syslog] New Version Notification fordraft-gerhards-syslog-plain-tcp-05 (fwd)
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/syslog>
List-Post: <mailto:syslog@ietf.org>
List-Help: <mailto:syslog-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Nov 2010 05:52:41 -0000
Hi, Many of the changes were made at my request. I believe the document as written would not have made it through IESG approval. 1) the IETF has defined a standard syslog; how to make your legacy proprietary version work is not an IETF problem. 2) the syslog WG was created to develop a secure syslog solution with secure transport and signing capability. How to make your legacy proprietary version work over non-secure transport is not an IETF problem. 3) Publishing this as a proposed standard seems to violate BCP 61. syslog/tls already provides "strong security" over tcp, so syslog/tcp is not needed to meet IETF goals. Under what circumstances is it **desirable** to use this specification (with no strong security available) in the Internet? Why not use the syslog/TLS specification, with the security features administratively turned off within secure environments? You cannot justify implementing this by saying things like "syslog/TLS is required and this is optional", and not explain WHY this additional non-bcp61-compliant specification is needed. 4) The aim of this IETF specification should be to document "how TCP MAY be used as a transport for standardized syslog", when the standard secure transport may not apply. (But I expect serious pushback from the IESG on this; see #3) Because this might have to work with legacy deployments, we also include as an appendix "how to correlate the legacy and standard usages." 5) RFC3164 is just a survey, not a specification. 6) RFC2119 language needed to be cleaned up. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of t.petch > Sent: Tuesday, November 02, 2010 1:02 AM > To: Chris Lonvick; syslog@ietf.org > Subject: Re: [Syslog] New Version Notification > fordraft-gerhards-syslog-plain-tcp-05 (fwd) > > Chris > > I had not noticed before but this seems to have changed > direction during the > summer; Informational not Standards Track, and stressing > byte-counting more, > byte-stuffing less. > > I do find it less clear. I think that the Introduction needs > more work in the > light of the changes to the rest of the document. I read > "This specification includes descriptions of both > format options in an attempt to ensure that standardized syslog > transport receivers can receive and properly interpret > messages sent > from legacy syslog senders." > got to the end of the document and thought 'oh no it does > not!' and then > realised that this is now an Appendix whereas before it was > in the main body. > Of course, if you never knew it was in the body, you might > not be as confused as > I. > > But really, the emphasis on standardised and legacy syslog > seems misplaced. The > carriage over TCP is the same whether the carried is > SYSLOG-3164 or SYSLOG-MSG > so the distinction seems spurious. And SYSLOG-3164 does not > appear in any RFC > or I-D I can find. > > Rather, you have two forms of adaptation to carry a message, > and what that > message is is mostly academic. > > Separately, I think that more is needed on Security. It is > easier to sabotage > TCP than it is UDP; spurious FIN, RST etc. > > And I think more is needed on closing the session. The > transport receiver > detects a format error (well, the transport sender is not > going to) sends FIN, > gets FIN-ACK and .... the transport sender carries merrily > on. I think that > there should be a recommendation that the transport sender > closes the connection > and reopens it if it wants to. > > Tom Petch > ----- Original Message ----- > From: "Chris Lonvick" <clonvick@cisco.com> > To: <syslog@ietf.org> > Sent: Friday, October 01, 2010 9:16 PM > Subject: [Syslog] New Version Notification for > draft-gerhards-syslog-plain-tcp-05 (fwd) > > > > Hi Folks, > > > > While this is a non-WG item, there are some people interested. I've > > updated the syslog/tcp draft and I'll invite reviews and comments. > > > > Thanks, > > Chris > > > > ---------- Forwarded message ---------- > > Date: Thu, 30 Sep 2010 09:04:15 -0700 (PDT) > > From: IETF I-D Submission Tool <idsubmission@ietf.org> > > To: clonvick@cisco.com > > Cc: rgerhards@adiscon.com > > Subject: New Version Notification for > draft-gerhards-syslog-plain-tcp-05 > > > > > > A new version of I-D, > draft-gerhards-syslog-plain-tcp-05.txt has been > successfully submitted by Chris Lonvick and posted to the > IETF repository. > > > > Filename: draft-gerhards-syslog-plain-tcp > > Revision: 05 > > Title: Transmission of Syslog Messages over TCP > > Creation_date: 2010-09-30 > > WG ID: Independent Submission > > Number_of_pages: 14 > > > > Abstract: > > There have been many implementations and deployments of > legacy syslog > > over TCP for many years. That protocol has evolved without being > > standardized and has proven to be quite interoperable in practice. > > > > The aim of this specification is to document three things: how to > > transmit standardized syslog over TCP, how TCP has been used as a > > transport for legacy syslog, and how to correlate these usages. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog
- Re: [Syslog] New Version Notification fordraft-ge… David Harrington