RE: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt

"Rainer Gerhards" <rgerhards@hq.adiscon.com> Tue, 20 June 2006 10:48 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdmc-0006ue-4d; Tue, 20 Jun 2006 06:48:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdma-0006uZ-NR for syslog@ietf.org; Tue, 20 Jun 2006 06:48:32 -0400
Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsdma-0001cW-68 for syslog@ietf.org; Tue, 20 Jun 2006 06:48:32 -0400
Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 028A627C065; Tue, 20 Jun 2006 12:45:11 +0200 (CEST)
Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13212-08; Tue, 20 Jun 2006 12:45:10 +0200 (CEST)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 9DEA327C061; Tue, 20 Jun 2006 12:45:10 +0200 (CEST)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 12:48:30 +0200
Content-class: urn:content-classes:message
Subject: RE: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt
Date: Tue, 20 Jun 2006 12:48:11 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17496E@grfint2.intern.adiscon.com>
In-Reply-To: <027c01c69410$656456a0$e8726e0a@china.huawei.com>
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt
Thread-Index: AcaRJsvDvqeDRu+GRBiGp7K0XeJxhwC5c/cQABJdi8A=
From: Rainer Gerhards <rgerhards@hq.adiscon.com>
To: Miao Fuyou <miaofy@huawei.com>, Tom Petch <nwnetworks@dial.pipex.com>
X-OriginalArrivalTime: 20 Jun 2006 10:48:30.0363 (UTC) FILETIME=[1184F6B0:01C69457]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
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 <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Miao,

the idea of describing syslog over tcp is not to use this as an actual
transport, but to provide this as an interim for other stream transport,
e.g. for use by ssh. The more I think about it, the more logical it
sounds to define how syslog framing works over a stream (not necessarily
tcp). Then, other transports can build on this. As a software engineer,
this is also like I would use layers in my application. So it sounds
quite natural and extensibel.

A current practical good reason for this is the patent claim. An
interim-layer enables us to drop TLS with relative ease if we decide to
do so. 

I've begun to put together some thoughts on stream framing.

Rainer

> -----Original Message-----
> From: Miao Fuyou [mailto:miaofy@huawei.com] 
> Sent: Tuesday, June 20, 2006 4:23 AM
> To: 'Tom Petch'
> Cc: syslog@ietf.org
> Subject: RE: [Syslog] stream 
> transportwasdraft-ietf-syslog-transport-tls-01.txt
> 

> Yes, maybe it is favorable to have Syslog over TCP and Syslog 
> over DTLS for
> Syslog working group. But, there will be several transport 
> documents for the
> working group:
> 1, Syslog over UDP, already there and favorable for implementers
> 2, Syslog over TCP, what is the benefit? 
> 3, Syslog over TLS
> 4, Syslog over DTLS, I reckon implementer would like it, but does IESG
> satisfy to this transport? 
> With so many transport, implementer will be puzzled. Which is 
> recommended by
> the working group? The current ones are option 1 and 3.
> 
> 
> > -----Original Message-----
> > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] 
> > Sent: Friday, June 16, 2006 4:13 PM
> > To: syslog@ietf.org
> > Subject: Re: [Syslog] stream transport 
> > wasdraft-ietf-syslog-transport-tls-01.txt
> > 
> > I think that this document has some way to go.  It has 
> > introduced, and woven together, both TLS and TCP transport, 
> > which I think wrong.  Ideally, I think that we should have 
> > two separate documents, one dealing with TLS, the other with 
> > TCP issues; given that both would be short, it is probably 
> > sensible to have only the one, but I still see the need for 
> > separation within the document.  After all, DTLS exists: an 
> > outsider could, should, think that syslog is UDP-based, DTLS 
> > provides UDP security so DTLS is the obvious choice, what on 
> > earth is this document talking about?  We need a section on 
> > DTLS (if only justifying why it is not for further 
> > consideration).  And, for me, that alone justifies teasing 
> > out the TLS issues from the TCP issues; is FRAME-LEN needed 
> > over DTLS?.
> > 
> > That said, I do not think that this document adequately 
> > covers the TCP issues, ones that have surfaced on the list before.
> > 
> > TLSoTCP can deliver one syslog message, many syslog messages, 
> > part of a syslog message or a combination thereof - it is in 
> > the nature of a stream protocol.
> > This needs spelling out.
> > 
> > A TCP connection takes time to set up, TLSoTCP longer.  This 
> > needs spelling out; if timely delivery is a concern, then the 
> > connection should be established in advance.
> > 
> > The section on TCP termination is too weak.  If we are 
> > recommending a timeout, then we should recommend a value, 
> > even specifying that it should be configurable over a range.  
> > And if we cannot agree on such values, I do not think we 
> > should be specifying a timeout.
> > 
> > TCP perforce introduces flow control.  This will slow down 
> > and rate limit messages; what is the impact of this on the 
> > application?
> > 
> > TCP failures can terminate the connection!  Again, this has 
> > an impact on the application with the time taken to become 
> > aware that the connection has failed.
> > 
> > Tom Petch
> > 
> > ----- Original Message -----
> > From: "David B Harrington" <dbharrington@comcast.net>
> > To: <syslog@ietf.org>
> > Sent: Tuesday, May 09, 2006 4:26 PM
> > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt
> > 
> > 
> > Hi,
> > 
> > A new revision of the syslog/TLS draft is available.
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01
> > .txt
> > 
> > We need reviewers.
> > Can we get
> > 1) a person to check the grammar?
> > 2) a person to check the syslog technical parts?
> > 3) a person to check compatibility with the other WG documents?
> > 4) a person to check the TLS technical parts?
> > 
> > We also need general reviews of the document by multiple people.
> > 
> > Thanks,
> > David Harrington
> > co-chair, Syslog WG
> > 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
> > 
> 
> 
> 
> _______________________________________________
> 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