[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
- [Syslog] draft-ietf-syslog-transport-tls-01.txt David B Harrington
- RE: [Syslog] draft-ietf-syslog-transport-tls-01.t… Rainer Gerhards
- Re: [Syslog] stream transport was draft-ietf-sysl… Tom Petch
- Re: [Syslog] ciphersuites was draft-ietf-syslog-t… Tom Petch
- RE: [Syslog] ciphersuites was draft-ietf-syslog-t… Miao Fuyou
- RE: [Syslog] stream transport wasdraft-ietf-syslo… Miao Fuyou
- Re: [Syslog] stream transport wasdraft-ietf-syslo… Darren J Moffat
- RE: [Syslog] stream transportwasdraft-ietf-syslog… Rainer Gerhards
- Re: [Syslog] delineated datagrams was draft-ietf-… Tom Petch
- [Syslog] stream transport David Harrington
- RE: [Syslog] delineated datagrams wasdraft-ietf-s… Miao Fuyou
- RE: [Syslog] delineated datagramswasdraft-ietf-sy… Rainer Gerhards
- RE: [Syslog] delineated datagrams Miao Fuyou
- RE: [Syslog] delineated datagrams Chris Lonvick
- RE: [Syslog] delineated datagrams Rainer Gerhards
- RE: [Syslog] delineated datagrams David Harrington
- RE: [Syslog] delineated datagrams Balazs Scheidler
- RE: [Syslog] delineated datagrams John Calcote
- RE: [Syslog] delineated datagrams Balazs Scheidler
- RE: [Syslog] delineated datagrams John Calcote
- RE: [Syslog] delineated datagrams Rainer Gerhards
- RE: [Syslog] delineated datagrams Balazs Scheidler
- RE: [Syslog] delineated datagrams Rainer Gerhards
- Re: [Syslog] delineated datagrams Chris Lonvick
- RE: [Syslog] delineated datagrams Rainer Gerhards
- RE: [Syslog] delineated datagrams David Harrington