Subject: Q: syslog over TCP
From: [email-masked]
Date: Mon, 5 Aug 2002 13:40:19 +0200

Hello Chris, (e.a)

Currently, I 'm (and others) are working an "extension" on syslog: a
customer has a demand to
 use a TCP connection, instead of a UDP one, to transmit syslog. (And
syslog-reliable is not
an option, now)

One reason is, that a firewall is involved. Then (they claimed) TCP is more
efficient
then UDP.  We also make it " a little more secure". TCP itself is a little
more. But there
is also an option to make "reverse connections"; were the receiver manages
the (TCP)
connection, instead of the sender.

Furdermore, the customer, (and I) want to
    a) use open/standard protocols whenever possible
    b) donate the protocol and the implementation
    c) [ as the code is based on (free)BSD implementation, the new code will
be
         donated firstly to that community; which makes it very (BSD-style
(C)) open. ]

As we want to use an open standard, I want to publish the protocol as a RFC.
And I hope
this WG (and mailinglist) is willing to help. Unless this is a problem, I'm
planning to mail
a (very draft) 0.0 draft op syslog-tcp in about 1 week on the mailing list.

I hope, the mailinglist will give comments (it is a RfComment:-) And I hope
we can use
this WG/mailinglist (read: you, Chris) to help to make it an official RFC.

Any comment is predicated

Albert

- ---ALbert Mietus
sent prive email to:         [email-masked]
sent business email to:   [email-masked]

------------------------------

Date: Mon, 5 Aug 2002 15:35:40 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: syslog over TCP

Hello,

I strongly hoppe there will be a syslog-tcp. We already have a
non-standard implementation on Win32 and I would definitely like to move
forward to a RFC implementation.

Rainer Gerhards
Adiscon

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, August 05, 2002 1:40 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Q: syslog over TCP
>
>
> Hello Chris, (e.a)
>
> Currently, I 'm (and others) are working an "extension" on
> syslog: a customer has a demand to  use a TCP connection,
> instead of a UDP one, to transmit syslog. (And
> syslog-reliable is not an option, now)
>
> One reason is, that a firewall is involved. Then (they
> claimed) TCP is more efficient then UDP.  We also make it " a
> little more secure". TCP itself is a little more. But there
> is also an option to make "reverse connections"; were the
> receiver manages the (TCP) connection, instead of the sender.
>
> Furdermore, the customer, (and I) want to
>     a) use open/standard protocols whenever possible
>     b) donate the protocol and the implementation
>     c) [ as the code is based on (free)BSD implementation,
> the new code will be
>          donated firstly to that community; which makes it
> very (BSD-style
> (C)) open. ]
>
> As we want to use an open standard, I want to publish the
> protocol as a RFC. And I hope this WG (and mailinglist) is
> willing to help. Unless this is a problem, I'm planning to
> mail a (very draft) 0.0 draft op syslog-tcp in about 1 week
> on the mailing list.
>
> I hope, the mailinglist will give comments (it is a
> RfComment:-) And I hope we can use this WG/mailinglist (read:
> you, Chris) to help to make it an official RFC.
>
> Any comment is predicated
>
> Albert
>
> ---ALbert Mietus
> sent prive email to:         [email-masked]
> sent business email to:   [email-masked]
>
>
>

------------------------------

Date: Tue, 6 Aug 2002 08:47:17 +1000 (EST)
From: Darren Reed <[email-masked]>
Subject: Re: Q: syslog over TCP

There are a few open source programs already available which provide,
amongst other things, sending syslog messages over TCP connections.

So far, however, that has not resulted in any immediate standards track
for such work (and nor should it).

Darren

------------------------------

Date: Tue, 6 Aug 2002 12:33:48 +1200
From: Andrew Ross <[email-masked]>
Subject: RE: syslog over TCP

Hi Albert & Rainer,

How about just using the new Syslog-reliable spec (which uses BEEP as a
protocol)? From my understanding of the BEEP protocol (I'm still reading
the book), you can make a connection and choose not to use any
authentication or encryption. BEEP demands the use of TCP. Let's not
re-invent the wheel here when we already have an excellent example to
use. Maybe MTR would like to pass comment on this?

Cheers

Andrew

- -----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, 5 August 2002 11:40 p.m.
To: [email-masked]
Cc: [email-masked]
Subject: Q: syslog over TCP

Hello Chris, (e.a)

Currently, I 'm (and others) are working an "extension" on syslog: a
customer has a demand to
 use a TCP connection, instead of a UDP one, to transmit syslog. (And
syslog-reliable is not
an option, now)

One reason is, that a firewall is involved. Then (they claimed) TCP is
more
efficient
then UDP.  We also make it " a little more secure". TCP itself is a
little
more. But there
is also an option to make "reverse connections"; were the receiver
manages
the (TCP)
connection, instead of the sender.

Furdermore, the customer, (and I) want to
    a) use open/standard protocols whenever possible
    b) donate the protocol and the implementation
    c) [ as the code is based on (free)BSD implementation, the new code
will
be
         donated firstly to that community; which makes it very
(BSD-style
(C)) open. ]

As we want to use an open standard, I want to publish the protocol as a
RFC.
And I hope
this WG (and mailinglist) is willing to help. Unless this is a problem,
I'm
planning to mail
a (very draft) 0.0 draft op syslog-tcp in about 1 week on the mailing
list.

I hope, the mailinglist will give comments (it is a RfComment:-) And I
hope
we can use
this WG/mailinglist (read: you, Chris) to help to make it an official
RFC.

Any comment is predicated

Albert

- ---ALbert Mietus
sent prive email to:         [email-masked]
sent business email to:   [email-masked]

------------------------------

Date: Tue, 6 Aug 2002 15:52:27 +0200
From: Rainer Gerhards <[email-masked]>
Subject: RE: syslog over TCP

Hi Andrew,

The problem is that there *ARE* already implementations of syslog over
TCP out there (as you know, for example Cisco PIX). I would appreciate
if we could just gather the facts as they are and add the ability to use
TCP instead of UDP for the transport - but something universal would be
very practical here - at least in my view.

Honestly, I think the BEEP still needs some work and we will probably
not have implementors of simply syslog TCP switching over to BEEP that
fast... Just my 2 cents ;-)

Rainer

> -----Original Message-----
> From: Andrew Ross [mailto:[email-masked]]
> Sent: Tuesday, August 06, 2002 2:34 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: syslog over TCP
>
>
>
> Hi Albert & Rainer,
>
> How about just using the new Syslog-reliable spec (which uses
> BEEP as a protocol)? From my understanding of the BEEP
> protocol (I'm still reading the book), you can make a
> connection and choose not to use any authentication or
> encryption. BEEP demands the use of TCP. Let's not re-invent
> the wheel here when we already have an excellent example to
> use. Maybe MTR would like to pass comment on this?
>
> Cheers
>
> Andrew
>
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On > Behalf Of
> [email-masked]
> Sent: Monday, 5 August 2002 11:40 p.m.
> To: [email-masked]
> Cc: [email-masked]
> Subject: Q: syslog over TCP
>
>
> Hello Chris, (e.a)
>
> Currently, I 'm (and others) are working an "extension" on
> syslog: a customer has a demand to  use a TCP connection,
> instead of a UDP one, to transmit syslog. (And
> syslog-reliable is not an option, now)
>
> One reason is, that a firewall is involved. Then (they
> claimed) TCP is more efficient then UDP.  We also make it " a
> little more secure". TCP itself is a little more. But there
> is also an option to make "reverse connections"; were the
> receiver manages the (TCP) connection, instead of the sender.
>
> Furdermore, the customer, (and I) want to
>     a) use open/standard protocols whenever possible
>     b) donate the protocol and the implementation
>     c) [ as the code is based on (free)BSD implementation,
> the new code will be
>          donated firstly to that community; which makes it
> very (BSD-style
> (C)) open. ]
>
> As we want to use an open standard, I want to publish the
> protocol as a RFC. And I hope this WG (and mailinglist) is
> willing to help. Unless this is a problem, I'm planning to
> mail a (very draft) 0.0 draft op syslog-tcp in about 1 week
> on the mailing list.
>
> I hope, the mailinglist will give comments (it is a
> RfComment:-) And I hope we can use this WG/mailinglist (read:
> you, Chris) to help to make it an official RFC.
>
> Any comment is predicated
>
> Albert
>
> ---ALbert Mietus
> sent prive email to:         [email-masked]
> sent business email to:   [email-masked]
>
>
>
>
>

------------------------------

Date: Tue, 6 Aug 2002 20:13:54 +0200
From: [email-masked]
Subject: TCP-syslog (as RFC)

Halo Darren, Andrew

About syslog-reliable, a syslog "version" that can use TCP instead of UDP:
I know the protocol. But, for the customer I'm working for, syslog-reliable
is not an option.  It
is to complex. And there isn't an implementation that we can use.

So,  we need another syslog-tcp. It will be there. The question is: should
it be an propriety solution, or an standard one. I opt for the latter.

About the current open-source syslogdaemons, that "understand" TCP. for
several reasons, we can not use them.  Mainly because of quality of the
code, the complexity to maintain them, and the lack of standardisation.
That is a main reason to write a RFC. And implement it.

The RFC is based on "our"  implementation, but we have studied several other
implementations to. And are trying to incorporate them into the RCF (Witch
isn't fully possible).

Another reason to start an RFC, is to make a standard, which  can be used in
all implementations, that uses syslog on TCP. And to stop "non compatible"
trivial implementations differences
- ---ALbert Mietus
sent prive email to:         [email-masked]
sent business email to:   [email-masked]

------------------------------

Date: Tue, 6 Aug 2002 13:03:06 -0700
From: Marshall Rose <[email-masked]>
Subject: Re: TCP-syslog (as RFC)

> About syslog-reliable, a syslog "version" that can use TCP instead of UDP:
> I know the protocol. But, for the customer I'm working for,
syslog-reliable
> is not an option.  It
> is to complex. And there isn't an implementation that we can use.
>
> So,  we need another syslog-tcp. It will be there. The question is: should
> it be an propriety solution, or an standard one. I opt for the latter.
>
> About the current open-source syslogdaemons, that "understand" TCP. for
> several reasons, we can not use them.  Mainly because of quality of the
> code, the complexity to maintain them, and the lack of standardisation.
> That is a main reason to write a RFC. And implement it.
>
> The RFC is based on "our"  implementation, but we have studied several
other
> implementations to. And are trying to incorporate them into the RCF (Witch
> isn't fully possible).
>
> Another reason to start an RFC, is to make a standard, which  can be used
in
> all implementations, that uses syslog on TCP. And to stop "non compatible"
> trivial implementations differences

well, i guess we can wait for either the chair and/or relevant AD to issue a
ruling, so i'll state my opinion in the interim:

    no, thanks

the ietf and its working groups are not responsible for standardizing all
possible permutations for all solutions to a problem. the working group has
a charter that was agreed to by the iesg, and which was faithfully executed
by the working group. the charter didn't say to produce multiple solutions
to the same problem. it said to produce one solution, and the solution
developed by the working group is based on beep.

obviously, as the ietf's "beep guy", i'm not sad about that. and obviously,
you might say i'm biased. fine, go back and read the previous paragraph,
because it could just as easily be written by someone who doesn't know
anything at all about beep, but does know about both engineering and
standards processes.

even if we were to ignore the fact that what you suggest is outside the
scope of the working group, there's this little fact that there isn't any
concensus on what syslog over raw tcp should look like. why should the
working group favor your implementation over someone else's with whom you
don't interoperate?

it's perfectly fine for there to be multiple proprietary implementations of
things which look like syslog that happen to run over raw tcp. it's not
perfectly fine, or even acceptable, to suggest that the working group have
to adjudicate an issue that's already been solved, just because you have a
customer that thinks that syslog-reliable isn't an option. the answer to
tell them is: "that's fine, we'll sell you a proprietary solution". that's
the choice they're making, and since they're paying the bills, i suggest you
let them make it...

/mtr

------------------------------

Date: Tue, 06 Aug 2002 13:16:09 -0700
From: Darren New <[email-masked]>
Subject: Re: maybe you want to reply to this thread...

> Subject: RE: syslog over TCP
> Date: Tue, 6 Aug 2002 12:33:48 +1200
> From: Andrew Ross <[email-masked]>
> To: [email-masked], [email-masked]
> CC: [email-masked]
>
> Hi Albert & Rainer,
>
> How about just using the new Syslog-reliable spec (which uses BEEP as a
> protocol)? From my understanding of the BEEP protocol (I'm still reading
> the book), you can make a connection and choose not to use any
> authentication or encryption.

That is correct.

> BEEP demands the use of TCP.

BEEP right now is (AFAIK) only implemented on top of TCP. But it does not
*demand* the use of TCP. RFC3080 describes BEEP independent of transport
layer, and RFC3081 describes how to map BEEP to TCP.

But, for the purposes of this question, yes, BEEP runs over TCP. :-)

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, 5 August 2002 11:40 p.m.
> To: [email-masked]
> Cc: [email-masked]
> Subject: Q: syslog over TCP
>
> Hello Chris, (e.a)
>
> Currently, I 'm (and others) are working an "extension" on syslog: a
> customer has a demand to
>  use a TCP connection, instead of a UDP one, to transmit syslog. (And
> syslog-reliable is not
> an option, now)

syslog-reliable ought to be the option now.

> One reason is, that a firewall is involved.

syslog-reliable doesn't have a problem with this any more than syslog over
UDP does. You can either open a port for it thru the firewall or you can use
the TUNNEL profile to let the firewall pass properly-authenticated
syslog-reliable connections.

> Then (they claimed) TCP is more efficient then UDP.

Hmmm....

>  We also make it " a little more secure".

Presumedly because you'd actually have to be able to see a TCP sequence
number to forge injecting a packet into the middle of a TCP stream.

> TCP itself is a
> little
> more. But there
> is also an option to make "reverse connections"; were the receiver
> manages
> the (TCP)
> connection, instead of the sender.

This is also not a problem with syslog-reliable. The receiver connects to
the sender, and the sender starts the profile.

> Furdermore, the customer, (and I) want to
>     a) use open/standard protocols whenever possible

Sounds like syslog-reliable.

>     b) donate the protocol and the implementation

Cool.

>     c) [ as the code is based on (free)BSD implementation, the new code
> will
> be
>          donated firstly to that community; which makes it very
> (BSD-style
> (C)) open. ]

Cool.

> As we want to use an open standard, I want to publish the protocol as a
> RFC.

It's already been done. :-) If you can explain more clearly why you don't
think syslog-reliable will work for you, we can either show you how to
accomplish your goals using syslog-reliable, or we can fix syslog-reliable
to work for you. Starting an entirely new syslog-over-TCP protocol from
scratch seems counterproductive.

- -- 
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

They looked up at me like I was a T-bone steak
  walking into an all-you-can-eat seafood buffet.

------------------------------

Date: Tue, 6 Aug 2002 14:34:04 -0700 (PDT)
From: Lonvick <[email-masked]>
Subject: Re: TCP-syslog (as RFC)

Hi,

Apologies for the delay in answering.

The WG cannot endorse two different standards to address one problem.
That would be a disservice to the Internet community.

Albert:  If you're looking for a good system that you can implement
today, I'd suggest using Darren Reed's work.  I've watched a lot of
lists and it seems to be the consensus that nsyslogd does pretty well.
Just fyi, we did ask Darren during the DC IEFT (where we held the
first BoF) if he would like to submit it as the basis for the work to
be developed in this WG.  He declined.  Also in that BoF, I put on my
Cisco hat for a moment and said that Cisco would not propose the
protocol used by the PIX as the basis of any standard.

I have watched other mailing lists and I have seen that BEEP work is
progressing.  :-)  It is my hope that those people who are developing
syslog-reliable will say so on this list.  I can't make them, but I
can offer to buy beverage-of-choice.  :-)  I can also say that Darren
New presented a proposal to push BEEP stuff through firewalls and
other proxying devices during one of the prior IETFs to the ID-WG
(SLC?).  I don't know what became of that proposal.

Thanks,
Chris

------------------------------

Date: Wed, 7 Aug 2002 11:12:45 +1200
From: Andrew Ross <[email-masked]>
Subject: RE: syslog over TCP

Hi All,

Interesting discussion :-)

There seems to be two different threads going on; documenting current
syslog-tcp implimentations and creating a new one.

I agree with Rainer that documenting the current TCP implimentations
would be a good step to interoperability and would avoid any further
"standards" being developed.

Eventually I would like to see everyone use syslog-reliable since it has
been well documented and thought out from the beginning.

I'll start the ball rolling with the TCP implimentation I know about,
the Cisco PIX.

# Sends on TCP port 1468 by default.
# Can have multiple messages in a single packet. They don't appear to be
seperated by any character. New message is identified by the <PRI> tag.
# TCP connection is made once, and remains open indefinately.
# If the connection is broken and not able to be re-established, the PIX
will stop forwarding network traffic through it's interfaces.
# PIX message format changes depending on timestamp settings on the PIX.

Chris, is this OK to discuss here, or should we take the discussion
somewhere else?

Cheers

Andrew

- -----Original Message-----
From: Rainer Gerhards [mailto:[email-masked]]
Sent: Wednesday, 7 August 2002 1:52 a.m.
To: Andrew Ross
Cc: [email-masked]
Subject: RE: syslog over TCP

Hi Andrew,

The problem is that there *ARE* already implementations of syslog over
TCP out there (as you know, for example Cisco PIX). I would appreciate
if we could just gather the facts as they are and add the ability to use
TCP instead of UDP for the transport - but something universal would be
very practical here - at least in my view.

Honestly, I think the BEEP still needs some work and we will probably
not have implementors of simply syslog TCP switching over to BEEP that
fast... Just my 2 cents ;-)

Rainer

> -----Original Message-----
> From: Andrew Ross [mailto:[email-masked]]
> Sent: Tuesday, August 06, 2002 2:34 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: syslog over TCP
>
>
>
> Hi Albert & Rainer,
>
> How about just using the new Syslog-reliable spec (which uses
> BEEP as a protocol)? From my understanding of the BEEP
> protocol (I'm still reading the book), you can make a
> connection and choose not to use any authentication or
> encryption. BEEP demands the use of TCP. Let's not re-invent
> the wheel here when we already have an excellent example to
> use. Maybe MTR would like to pass comment on this?
>
> Cheers
>
> Andrew
>
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On > Behalf Of
> [email-masked]
> Sent: Monday, 5 August 2002 11:40 p.m.
> To: [email-masked]
> Cc: [email-masked]
> Subject: Q: syslog over TCP
>
>
> Hello Chris, (e.a)
>
> Currently, I 'm (and others) are working an "extension" on
> syslog: a customer has a demand to  use a TCP connection,
> instead of a UDP one, to transmit syslog. (And
> syslog-reliable is not an option, now)
>
> One reason is, that a firewall is involved. Then (they
> claimed) TCP is more efficient then UDP.  We also make it " a
> little more secure". TCP itself is a little more. But there
> is also an option to make "reverse connections"; were the
> receiver manages the (TCP) connection, instead of the sender.
>
> Furdermore, the customer, (and I) want to
>     a) use open/standard protocols whenever possible
>     b) donate the protocol and the implementation
>     c) [ as the code is based on (free)BSD implementation,
> the new code will be
>          donated firstly to that community; which makes it
> very (BSD-style
> (C)) open. ]
>
> As we want to use an open standard, I want to publish the
> protocol as a RFC. And I hope this WG (and mailinglist) is
> willing to help. Unless this is a problem, I'm planning to
> mail a (very draft) 0.0 draft op syslog-tcp in about 1 week
> on the mailing list.
>
> I hope, the mailinglist will give comments (it is a
> RfComment:-) And I hope we can use this WG/mailinglist (read:
> you, Chris) to help to make it an official RFC.
>
> Any comment is predicated
>
> Albert
>
> ---ALbert Mietus
> sent prive email to:         [email-masked]
> sent business email to:   [email-masked]
>
>
>
>
>

------------------------------

Date: 07 Aug 2002 01:55:59 +0200
From: Daniel Lundin <[email-masked]>
Subject: Re: TCP-syslog (as RFC)

Lonvick <[email-masked]> writes:

> I have watched other mailing lists and I have seen that BEEP work is
> progressing.  :-)  It is my hope that those people who are developing
> syslog-reliable will say so on this list.  I can't make them, but I
> can offer to buy beverage-of-choice.  :-)

Did someone mention beverage-of-choice? :-)

Indeed, within the realms of our RoadRunner (An open source BEEP framework)
project there is a syslog-reliable profile available in CVS.

Although not yet complete, it should already provide a good foundation and the
framework itself is making steady progress.

 RoadRunner BEEP framework - http://rr.codefactory.se/
                Public CVS - http://rr.codefactory.se/cgi-bin/viewcvs.cgi/

Feel free to check it out, and of course feedback and patches are very much
welcome as always.

/D

- -- 
Daniel Lundin  | [email-masked]
CodeFactory AB | http://www.codefactory.se/

------------------------------

Date: Wed, 7 Aug 2002 14:46:45 +0200
From: Balazs Scheidler <[email-masked]>
Subject: Re: syslog over TCP

On Wed, Aug 07, 2002 at 11:12:45AM +1200, Andrew Ross wrote:
>
> Hi All,
>
> Interesting discussion :-)
>
> There seems to be two different threads going on; documenting current
> syslog-tcp implimentations and creating a new one.
>
> I agree with Rainer that documenting the current TCP implimentations
> would be a good step to interoperability and would avoid any further
> "standards" being developed.
>
> Eventually I would like to see everyone use syslog-reliable since it has
> been well documented and thought out from the beginning.
>
> I'll start the ball rolling with the TCP implimentation I know about,
> the Cisco PIX.
>
> # Sends on TCP port 1468 by default.
> # Can have multiple messages in a single packet. They don't appear to be
> seperated by any character. New message is identified by the <PRI> tag.
> # TCP connection is made once, and remains open indefinately.
> # If the connection is broken and not able to be re-established, the PIX
> will stop forwarding network traffic through it's interfaces.
> # PIX message format changes depending on timestamp settings on the PIX.

* syslog-ng uses port 514 by default.
* the TCP connection is kept alive, and is reopened if the connection is broken
* it simply writes the message terminated by a newline to the stream.
* the format always contains a full syslog message (pri, timestamp, tag,
  message)

no traffic in the reverse direction is processed in any way (the channel is
used in a single direction)

- -- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

------------------------------

Date: Wed, 7 Aug 2002 14:12:26 +1000 (EST)
From: Darren Reed <[email-masked]>
Subject: Re: TCP-syslog (as RFC)

In some email I received from [email-masked], sie wrote:
> Halo Darren, Andrew
>
> About syslog-reliable, a syslog "version" that can use TCP instead of UDP:
> I know the protocol. But, for the customer I'm working for, syslog-reliable
> is not an option.  It
> is to complex. And there isn't an implementation that we can use.
>
> So,  we need another syslog-tcp. It will be there. The question is: should
> it be an propriety solution, or an standard one. I opt for the latter.
>
> About the current open-source syslogdaemons, that "understand" TCP. for
> several reasons, we can not use them.  Mainly because of quality of the
> code, the complexity to maintain them, and the lack of standardisation.
> That is a main reason to write a RFC. And implement it.

This sounds like the typical "because we didn't do it or because we didn't
invent it" excuse.  Typically the end result from people who uses excuses
like that (commonly known as the "Not-Invented Here" syndrome) hardly ever
produce something that is better, just different.

I don't make any pretense about what I wrote so far as being standardised
goes.  I prefer to think of it as just something that can be used, looked
at and learnt from.  It definately didn't go through peer review.

I haven't looked at BEEP(!) but if it's going to be used for syslog, I hope
that it at least fulfills all the requirements that syslog over TCP has
(and that's more than just sending messages in text over a TCP connection.)

Darren

------------------------------

Date: Mon, 12 Aug 2002 11:54:50 -0700
From: Marshall Rose <[email-masked]>
Subject: Re: RFC 3195 DTD problem

> I was using fleXML to generate a parser for the syslog COOKED DTD and
> ran across a little ommission.  The entity %ATEXT used to define some of
> the attributes seems to be missing.  Is this an omission or am just
> missing something (I'm not very familiar with DTDs).

hi. you're right.

darren - start an errata list for the next editing session for the document.
add this to it.

devin - add this line

    <!ENTITY % ATEXT "CDATA">

after the definition of IDINT

/mtr

------------------------------

Date: Mon, 12 Aug 2002 11:46:15 -0700
From: Devin Kowatch <[email-masked]>
Subject: RFC 3195 DTD problem

Hi,
I'm not on the list so please keep followups direted at me.

I was using fleXML to generate a parser for the syslog COOKED DTD and
ran across a little ommission.  The entity %ATEXT used to define some of
the attributes seems to be missing.  Is this an omission or am just
missing something (I'm not very familiar with DTDs).

thanks,

- -- 
Devin Kowatch
[email-masked]

------------------------------

Date: Mon, 12 Aug 2002 17:13:55 -0700
From: Darren New <[email-masked]>
Subject: Re: RFC 3195 DTD problem

Devin Kowatch wrote:
> I was using fleXML to generate a parser for the syslog COOKED DTD and
> ran across a little ommission.  The entity %ATEXT used to define some of
> the attributes seems to be missing.  Is this an omission or am just
> missing something (I'm not very familiar with DTDs).

Thanks! I've added this to the DTD for the next time.

- -- 
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

They looked up at me like I was a T-bone steak
  walking into an all-you-can-eat seafood buffet.

------------------------------

Date: Tue, 13 Aug 2002 10:47:22 +0200
From: [email-masked]
Subject: Re: TCP-syslog (as RFC)

> > code, the complexity to maintain them, and the lack of standardisation.
> > That is a main reason to write a RFC. And implement it.

> This sounds like the typical "because we didn't do it or because we didn't
> invent it" excuse.  Typically the end result from people who uses excuses
> like that (commonly known as the "Not-Invented Here" syndrome) hardly ever
> produce something that is better, just different.

Hai Darren  (I'm Sorry for the late reaction ..)

When I back read my mail and you reaction on it, it sound like I have
offended some people, including you, which wasn't I intention. I'm sorry!

Hai all,

I"dare say we do not suffer on a "Not Invented Here" syndrome! Personally, I
have argued to use  syslog-sign and syslog-reliable. I did look into the
latter
implementations efforts.

However for syslog-reliable, as good as the protocol is, there are no
implementations yet!

We (my customer: "the Dutch tax computer centre") are not developing a
"box", or
sw in general!
We try to run a network :-) And USE the standard. And/or demand (ask
politely:-) that
it is used by the boxes (routers, switches, computers, ...) we need.
We can make small implementations ourselves (or let them make ..) , as last
resort.

So, Syslog-reliable isn't option NOW. As we can't "get" it!

And for security and efficiently (of out firewall), UDP isn't "nice". The
management demands a
TCP link.

So, I had several options and non options
    * NO syslog-reliable
    * NO UDP
    * NO    "self invented, hard to maintain ..."
    * Bay something that is open and good    (Non found)
    * Use opensource, and make sure the customer can maintain it themselves
    * Implement a simple protocol
    * ...

As said, syslog-ng, and others, already do use a TCP binding. I have opt for
that.
However, as it only sends the rawdata, which make it hard to extent,  should
it ever
be needed. E.g. to incorporate  kerberios authentication (which is "hot"
here:-)

So, we tried to extend "your" protocol. We use small headers as "commands",
but still
have the /n as sync. But we can also setting up "reverse" connections (to
fetch log,
instead of push it) and do other "tricks".
As this with a small protocol, and a small, simple to maintain
implementation.

ALL I'M ASKING IS: Please read the protocol, see where we can change the
document, so that most current TCP implementations are "within spec".
(or can simple become ...)

ALL I CAN OFFER IS: to document the protocol as a RFC. And to publish the
implementation.

I will end with another quote of Darren:
> that it at least fulfills all the requirements that syslog over TCP has
> (and that's more than just sending messages in text over a TCP
connection.)
Because I really agree with him. We (I) needed a simple protocol.

We have it, I can offer it. You can ignore it.
However, I hope we can cooperate and fill the gape between the current
not-standard
pratice of syslog-over-TCP and the "high end" syslog-reliable. I would like
that,

Please respond!

------------------------------

Date: Wed, 14 Aug 2002 22:27:59 +1000 (EST)
From: Darren Reed <[email-masked]>
Subject: Re: TCP-syslog (as RFC)

In some email I received from [email-masked], sie wrote:
[...]
> I"dare say we do not suffer on a "Not Invented Here" syndrome! Personally, I
> have argued to use  syslog-sign and syslog-reliable. I did look into the
> latter
> implementations efforts.
>
> However for syslog-reliable, as good as the protocol is, there are no
> implementations yet!

And you didn't implement it because ?

> We (my customer: "the Dutch tax computer centre") are not developing a
> "box", or
> sw in general!
> We try to run a network :-) And USE the standard. And/or demand (ask
> politely:-) that
> it is used by the boxes (routers, switches, computers, ...) we need.
> We can make small implementations ourselves (or let them make ..) , as last
> resort.
>
> So, Syslog-reliable isn't option NOW. As we can't "get" it!

...and rather than build syslog-reliable, which has been put through a
process of international peer review, by intelligent people, you've gone
away and designed your own protocol.

I imagine this is because it is easier to hack together some software to
do what you want and invent it as you go rather than implement to a pre-
published spec.  (I know, I write software too :)

> And for security and efficiently (of out firewall), UDP isn't "nice". The
> management demands a
> TCP link.
>
> So, I had several options and non options
>     * NO syslog-reliable
>     * NO UDP
>     * NO    "self invented, hard to maintain ..."
>     * Bay something that is open and good    (Non found)
>     * Use opensource, and make sure the customer can maintain it themselves
>     * Implement a simple protocol
>     * ...
>
> As said, syslog-ng, and others, already do use a TCP binding. I have opt for
> that.
> However, as it only sends the rawdata, which make it hard to extent,  should
> it ever
> be needed. E.g. to incorporate  kerberios authentication (which is "hot"
> here:-)

nsyslogd wasn't just rawdata when I last looked but maybe syslog-ng is
much more different now (I haven't looked in ages.)  I could probably
extend the nsyslogd protocol to do Kerberos authentication, as required,
the hard part is, typically speaking, getting things like that to happen
in an asynchronous manner over a network connection it doesn't control.

> So, we tried to extend "your" protocol. We use small headers as "commands",
> but still
> have the /n as sync. But we can also setting up "reverse" connections (to
> fetch log,
> instead of push it) and do other "tricks".
> As this with a small protocol, and a small, simple to maintain
> implementation.

Generating log information is about having it pushed from the source,
not pulled from something else.  What you think of as a neat "trick"
might be seen by others as an obscene 'hack'.

I don't understand what you mean about '/n' as a sync, unless you mean
to say you're using a text protocol.  I threw out doing a protocol like
that because it is harder to make secure (IMHO) because you have to deal
with text things that may have an arbitary length, complicating parsing
the information.

[...]
> I will end with another quote of Darren:
> > that it at least fulfills all the requirements that syslog over TCP has
> > (and that's more than just sending messages in text over a TCP
> connection.)
> Because I really agree with him. We (I) needed a simple protocol.

Simple but not secure or both or maybe neither, just syslog-over-TCP ?

> However, I hope we can cooperate and fill the gape between the current
> not-standard
> pratice of syslog-over-TCP and the "high end" syslog-reliable. I would like

I don't see how anything anyone could offer, at this point in time, can
be classed as anything but "not-standard practive of syslog-over-TCP", to
use your own terminology.

Darren

------------------------------

Date: Wed, 14 Aug 2002 21:39:45 +0200
From: "[email-masked]" <[email-masked]>
Subject: Re: TCP-syslog (as RFC)

Darren,

with thre risk of starting a flamwar ..
> > However for syslog-reliable, as good as the protocol is, there are no
> > implementations yet!
> And you didn't implement it because ?

As said, NO

S-R is to complex to implement _*_ for us _*_ ( my custumor the _user_) !
Our implemenation is based on BSD's syslogd, with a few hundred line of
C-code extended.

The custumor can manage that .. But for working on S-R: no, not an option. Tryed it.
But no, no go, no budget ...
(personally, .... But that's another storry. ..)

(Yes, You can say that is a kind of not here ... But not one I can influance)

> ...and rather than build syslog-reliable, which has been put through a
> process of international peer review, by intelligent people, you've gone
> away and designed your own protocol.

Wel kind of. Choosen to use an option.
 And yes, build it, reviewed it internally. But also (trying) to ask for your help!

To review it, to make use of this WG to fill the gap  "we found, we think"
So I hope you will help.

But as nobody is willing to comment on this protocol,  even without willing to read it,
I think it's better  no to send our "Req for comment" to this group. Maybe some other time,
some other place ..

------------------------------

Date: 20 Aug 2002 14:00:23 +0200
From: "Jonas [iso-8859-1] Borgström" <[email-masked]>
Subject: ANNOUNCE: roadrunner-0.9

- ----------------------------------------------------------------------------
- -- RoadRunner 0.9 (An Egg) -------------------------------------------------

20 Aug, 2002

CodeFactory proudly announces the availability of a new release of
RoadRunner, an open source  BEEP framework implemented in C.

Introduction
- --------------
RoadRunner is an application toolkit library implementing BEEP (Blocks
Extensible Exchange Protocol). Apart from implementing a powerful and
flexible BEEP framework, RoadRunner also contains a useful set of profiles,
readily available and usable with applications.

RoadRunner provides a portable and powerful high-performance framework for
developing network applications making use of the BEEP protocol.

Changes since version 0.8
- ---------------------------

 * Simplified API. For more info see the API_CHANGES file.
 * Stability improvements.
 * New functions.
 * Improved portability.
 * Support for AIX added.

Supported Platforms
- ---------------------
RoadRunner is primarily developed and regularly tested on GNU/Linux,
NetBSD and OpenBSD, but has been compiled and tested on:

 * GNU/Linux
 * NetBSD
 * OpenBSD
 * FreeBSD
 * Solaris
 * MS Windows
 * AIX

RoadRunner is written in portable C code, and should work without modification
on all platforms supported by GLib 2 (GNU Utility library).

Language Bindings
- -------------------
The portable design of RoadRunner and the fact that it is written in C enables
simple creation of bindings for various languages.
Experimental python bindings already exists (in the pyrr cvs module) and other
bindings such as C++, Java, perl and scheme are planned.

Strengths and Features
- ------------------------
 * Portable
 * Object oriented design
 * High performance
 * Multi-threaded
 * Open Source

Implemented BEEP Profiles
- ---------------------------
RR/TLS -- Transport layer security
RR/SASL -- Simple Authentication and Security Layer
RR/Syslog -- Reliable delivery for syslog
RR/IDXP -- Intrusion detection exchange protocol

System Requirements
- ---------------------
RoadRunner requires the following libraries to compile:

 * Glib 2.0.1 or higher    (http://www.gtk.org/)
 * libxml 2.4.16 or higher (http://www.libxml.org/)

The RoadRunner profiles require some extra libraries:

 * OpenSSL        (Used by RR/TLS.  http://www.openssl.org/)
 * Cyrus libsasl2 (Used by RR/SASL. http://asg.web.cmu.edu/sasl/)

What is BEEP
- --------------
BEEP (the Block Extensible Exchange Protocol, rfc3080,3081) is a protocol
framework for connection oriented asynchronous message exchange. All message
exchange occur in the context of a channel. A profile defines the syntax
and semantics of the message exchange.

Licensing and Support
- -----------------------
RoadRunner is distributed under an open source license similar to that of
Berkeley DB,  permitting unrestricted use of the software at no charge for
development of open source applications. This requires the complete source
code for your application being available and freely distributable.

The terms and details of the license are available at:
http://rr.codefactory.se/license.php

If you do not wish to freely distribute the source code for your application,
or desire commercial support, please visit the CodeFactory website at
http://www.codefactory.se/ or email [email-masked].

Mailing Lists
- ---------------
There are currently two public mailing lists supporting RoadRunner, one
for general discussion and one for tracking CVS commits.

More information and subscription is available at:

 http://rr.codefactory.se/mailinglist.php

More information about BEEP and RoadRunner
- --------------------------------------------
Documentation, source code, sample code, bug repository and more can be found
at the RoadRunner project site:

 http://rr.codefactory.se/

About CodeFactory
- -------------------
CodeFactory provides development and consulting services enabling
organizations to develop, use and learn about open source software and
UNIX-like operating systems.

CodeFactory is based in Umeå, Sweden. For more information please contact
Daniel Lundin at +46 90 718 614 or visit http://www.codefactory.se/

Finally, acknowledgements to Marshall Rose and the rest of the BEEP community
for bringing the BEEP protocol to the world.

We hope the software will be useful,

The RoadRunner team.

- -- 
Jonas Borgström                  [email-masked]
CodeFactory AB                   http://www.codefactory.se/
Office: +46 (0)90 71 86 10       Cell: +46 (0)70 248 89 58

------------------------------

Date: Tue, 27 Aug 2002 09:46:42 -0400
From: "Pape, Bruno" <[email-masked]>
Subject: RE: [Fwd: Re: draft-ietf-syslog-device-mib-00.txt - Enums startin g at zero]

Hi Joan,

I like starting at zero as well.  It does present some issues
for SNMPv1 implementations that might want to support the MIB.

Even though v1 has been declared historic I would tend to wager
that it is still the norm in the industry even though the IETF
might wish that it were not.

So there is a choice between new and elegant, and old and more
widely adoptable.  I could go with a majority vote on this one,
or just a plain old good thrashing by Mr. Rose or one of his
peers.  Either way I am sure that it will be fun.

The MIB is in the security/syslog working group and there might
be an -02 version making the rounds.

Thank you,

Bruno

- -----Original Message-----
From: Joan Cucchiara [mailto:[email-masked]]
Sent: Monday, August 26, 2002 6:20 PM
To: Pape, Bruno
Subject: [Fwd: Re: draft-ietf-syslog-device-mib-00.txt - Enums starting at
zero]

Hello Bruno,

I posted this to the mibs email list (not sure if you
saw) but would like to request that this
enum start at zero.  Could you put this in the next
revision of the draft?

Also, which working group is this MIB being developed in?
And when can we expect to see a new rev of this MIB?

  Thanks, Joan

- -------- Original Message --------
Subject: Re: draft-ietf-syslog-device-mib-00.txt - Enums starting at
zero
Date: Mon, 26 Aug 2002 14:40:01 -0700 (PDT)
From: "C. M. Heard" <[email-masked]>
To: [email-masked]

On Mon, 26 Aug 2002, Joan Cucchiara wrote:
> My question is about what the current practice is
> for starting enums at zero when there is a reason
> for starting at zero.

Values of enums in SMIv2 are not restricted like they
were in SMIv1 -- they can have any integer value.
There is no longer any reason to require them to
start at 1.

> Specifically in this MIB, there is an enum:
>
> SyslogSeverity  ::=  TEXTUAL-CONVENTION
>     STATUS  current
>     DESCRIPTION
>         "This textual convention maps out to the severity levels
>          of syslog messages.  The syslog protocol uses the values
>          0 (emergency), to 7 (debug)."
>     SYNTAX  INTEGER {
>                       emergency(1),
>                       alert(2),
>                       critical(3),
>                       error(4),
>                       warning(5),
>                       notice(6),
>                       info(7),
>                       debug(8)
>                     }

Re-numbering the enums from 0 to 7 to match RFC 3164 would make
more sense than what is done above.

> At one point having enums start at zero in SMIv2 was
> not encouraged due to backwards compatibility with SMIv1,
> but am wondering if this is still the case?

No, not any more.  We keep SMIv1 around because we don't
want to have to re-write perfectly good SMIv1 MIBs, but
essentially all new work these days is done in SMIv2,
both within and outside the IETF.

//cmh

------------------------------

Date: Tue, 27 Aug 2002 14:44:44 -0400
From: Phil Roberts <[email-masked]>
Subject: Nomcom call for volunteers

The members of the IESG and IAB and the IETF chair are selected
by a nominations committee made up of volunteers from the
IETF community.  The nominations committee is now in the process
of being formed and volunteers are being accepted until Sep 6.
Please see (http://www.ietf.org/nomcom/msg19765.html)
for information if you are interested in volunteering
to be on the nominations committee.

------------------------------

Date: Tue, 27 Aug 2002 12:45:51 -0700 (PDT)
From: Christopher Lonvick <[email-masked]>
Subject: Where We're At

Hi Folks,

I'm pulling my head above water on several things now and I'm
going to try to push these last few things through.  :-)

We have the latest version of the syslog-sign ID here:
  http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-07.txt
The obvious glaring omission is the author information for
Jon Callas.  (Hint:  http://www.pgp.com/ :-)  Please review
this ID and send your comments to the mailing list.

I'm going to try to scrub through syslog-sign in the next
few days and then hopefully push it to WG Last Call again.
The last version was reviewed by Steve Bellovin (our AD and
advisor) who asked for some clarifications in the text.  I
think that Jon and John have those in there now but, as
always, more eyes looking it over would be better.

We also have the latest version of the MIB ID.
  http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-01.txt
Please get your comments in to the list on this as well.
I'm not a MIB person but I'll try looking it over.  Please
do the same.

Thanks,
Chris

------------------------------

Date: Tue, 27 Aug 2002 16:42:53 -0700
From: Devin Kowatch <[email-masked]>
Subject: Questions about RFC 3196

Hi,
I have a few questions about syslog-relaible, I was hoping that this
group could help clarify some things.

1. BUG: the syslog COOKED DTD is missing a hostname attribute to the
   <entry> tag.

2. What is the difference between the hostname atribute and deviceFQDN
   attribute (in the <entry> tag)?

3. The link properties described in section 4.4.3 lists a 'U' property
   that indicates that a valid user has been authenticated.  I find this
   a little strange because I don't really see users authenticating
   to a syslog server, I only see other hosts authenticating.  Is 'U'
   meant to be used when a vaild host has sucessfully authenticated?

   Also how is this different than the 'A' link property, which
   indicates that an authentication layer is being used?

5. What is the intended treatment of white space in betewen <entry> and
   </entry>.  Would
   <entry ...>
    Some message.</entr>

   be printed as "\nSome message." or as " Some message." or as "Some
   Message" or does it matter?

7. Can the syslog server (BEEP Listener) cut off the client (BEEP
   Initiator) by sending a <close ...> before the client has indicated
   that it's done?

thanks,

- -- 
Devin Kowatch
[email-masked]

------------------------------

Date: Wed, 28 Aug 2002 13:47:49 -0700
From: Darren New <[email-masked]>
Subject: Re: Questions about RFC 3196

Devin Kowatch wrote:
>
> Hi,
> I have a few questions about syslog-relaible, I was hoping that this
> group could help clarify some things.
>
> 1. BUG: the syslog COOKED DTD is missing a hostname attribute to the
>    <entry> tag.

Yes. I've added that for the next iteration.

> 2. What is the difference between the hostname atribute and deviceFQDN
>    attribute (in the <entry> tag)?

The deviceFQDN is the fully qualified domain name for the device that
originated the message. The hostname is taken from the message and is not
fully qualified. That is, "hostname" is a mirror of the same field as
described in RFC3164 part 4.1.2, while deviceFQDN gives the DNS name of the
device. I would think that if you're normally using TCP/IP for everything,
the hostname would match the start of the deviceFQDN in the usual
circumstances. I can imagine they might differ if you're also running
NetBEUI that allows spaces and apostrophes and such in the names.

> 3. The link properties described in section 4.4.3 lists a 'U' property
>    that indicates that a valid user has been authenticated.  I find this
>    a little strange because I don't really see users authenticating
>    to a syslog server, I only see other hosts authenticating.  Is 'U'
>    meant to be used when a vaild host has sucessfully authenticated?

Yes. "User" is SASL-speak for a login name, basically. The host is the user
of the connection.

>    Also how is this different than the 'A' link property, which
>    indicates that an authentication layer is being used?

It's possible that a user has logged in on this link, but that messages
could be injected by an intruder without said injections being detected. In
other words, it's the fourth part of A/I/L/R - In reverse order, no replay,
no loss, no modifications, no additions. I.e., every message is
authentically coming from where it claims to be coming from.

> 5. What is the intended treatment of white space in betewen <entry> and
>    </entry>.  Would
>    <entry ...>
>     Some message.</entr>
>
>    be printed as "\nSome message." or as " Some message." or as "Some
>    Message" or does it matter?

Ummmm... Don't do that. :-)  See 4.1.3 of RFC3164.

> 7. Can the syslog server (BEEP Listener) cut off the client (BEEP
>    Initiator) by sending a <close ...> before the client has indicated
>    that it's done?

According to the rules on page 20 of RFC3080 (regarding the <close>
operation), if the peer has sent the MSG but not received any ANS frames, it
may not issue the <close>. Once the peer starts getting ANS frames back, it
can issue the close, but must continue processing ANS frames until it gets
the OK. The device has to finish sending all ANS frames, then the NUL, and
then can close the channel.

- -- 
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

Try our EbolaBurgers...
      So tender they melt in your mouth.

------------------------------