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, 2 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