[Syslog] stream transport

"David Harrington" <ietfdbh@comcast.net> Wed, 21 June 2006 17:54 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6tz-0000mT-99; Wed, 21 Jun 2006 13:54:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6ty-0000mO-C4 for syslog@ietf.org; Wed, 21 Jun 2006 13:54:06 -0400
Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6tw-0007Wk-Ri for syslog@ietf.org; Wed, 21 Jun 2006 13:54:06 -0400
Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc12) with SMTP id <20060621175403m12008v7dpe>; Wed, 21 Jun 2006 17:54:03 +0000
From: David Harrington <ietfdbh@comcast.net>
To: syslog@ietf.org
Date: Wed, 21 Jun 2006 13:52:51 -0400
Message-ID: <146f01c6955b$842d1f30$0400a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA17496E@grfint2.intern.adiscon.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-index: AcaRJsvDvqeDRu+GRBiGp7K0XeJxhwC5c/cQABJdi8AAQOr+8A==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1
Cc:
Subject: [Syslog] stream transport
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

Hi,

[Posting as a contributor]
 
Let me tell you that in ISMS we have written an equivalent abstraction
layer. 

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-isms-tmsm
-02.txt discusses how to handle generic session-based security rather
than datagram-based security, transport connection reuse, and other
issues that came up because we now use a streaming protocol. Then we
wrote a protocol-specific proposal in
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-isms-secs
hell-03.txt. This separation into an abstract and protocol-specific
layers has been a large task, partly because it is difficult to
eliminate unnecessary repetition between documents, it is difficult to
keep the two documents in sync on terminology, and so on (and I'm the
author for both drafts). 

Having also authored RFC3411 which defines an abstracted modular
architecture for SNMP frameworks, I can also tell you that going in
that direction can end up constraining future development a great
deal. The SMIng WG and the EOS WG suffered a great deal from having to
try to remain compatible with the RFC3411 abstractions.

I am a believer in specifying architectures or frameworks to guide
modular development, but they also need to be taken with a grain of
salt. That is much easier to do in a product development environment
than it is in a standards development environment, so caveat emptor
(and whatever latin phrase suits this best).

I worked for years at Cabletron helping to develop internal standards
for software OS-portability. There was a wonderful quote from somebody
who led the industry effort to standardize some portion of X-Windows
or Xmake. I don't remember the quote, the technology, or who said it,
but I remember the gist of it - Do not try to abstract the concepts
from one instance or implementation of a technology; there should
always be at least two to draw from, and preferably more.

I think that trying to develop an abstraction layer at this point
would be a distraction. I think that this WG has a history of being
easily distracted. As a contributor, I think we should not deal with
an abstraction layer at this time. If the goal is to make it easy to
develop an alternative proposal to TLS, I suggest that using
cut-and-paste techniques to take text from the current syslog/tls
draft (for the threat model discussions) and the current netconf/ssh
draft (for layering over ssh) would be far more efficient than
starting a new document and abstracting the concepts.

My $.02 as a contributor,

David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net
 
> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] 
> Sent: Tuesday, June 20, 2006 6:48 AM
> To: Miao Fuyou; Tom Petch
> Cc: syslog@ietf.org
> Subject: RE: [Syslog] stream 
> transportwasdraft-ietf-syslog-transport-tls-01.txt
> 
> 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
> 


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog