Subject: [Syslog] plain tcp syslog

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 17 Oct 2005 14:49:11 +0200

Hi WG,

Chris has put some questions about RFC 3195 usage on the agenda for the
next IETF. In preparation for this, I am going to ask a question that I
know is very unpopular in the WG.

We have discussed the issue of a very-simple, non-BEEP based plain tcp
syslog several times on this list. The idea always has violently been
rejected.

However, the current status is that RFC 3195 is nicely standardized but
seldomly implemented and even less often deployed. Plain tcp syslog, on
the other hand, is not standardized but widely deployed. It is
implemented at least in:

- syslog-ng
- rsyslog
- Kiwi syslog daemon
- WinSyslog/MonitorWare Agent/EventReporter
- Cisco PIX

As of my experience, many syslog-ng installations use plain tcp syslog.
All of the implementations listed are interoperable. The list is most
probably not complete, these were just the products that came
immediately to my mind. The end user-base is also continously asking
about such a simple transport - this is probably why it is implemented
so often.

Given the obvious importance of this protocol, wouldn't it make sense to
at least document its observed behaviour, much as RFC 3164 documents UDP
based syslog observed behaviour? Such a document could also be useful to
document the security and (un)reliability issues coming along with the
"plain tcp" syslog. Eventually, this could even increase demand for more
reliable solutions like RFC 3195.

Feedback is appreciated.
Rainer Gerhards

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Andrew Ross" <[email-masked]>
Date: Tue, 18 Oct 2005 11:03:06 +1300

Hi Rainer,

A document describing syslog over TCP would be very handy. Two things that
need to be identified are: the delimiting character - usually a LF (ASCII
&H0A) and how long the maximum message length should be (4096 chrs seems to
cover most implementations I've seen in the wild).

NetScreen firewalls can also send syslog via TCP.

Regards

Andrew

Kiwi Enterprises

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Rainer Gerhards
Sent: Tuesday, 18 October 2005 1:49 a.m.
To: [email-masked]
Subject: [Syslog] plain tcp syslog

Hi WG,

- syslog-ng
- rsyslog
- Kiwi syslog daemon

Feedback is appreciated.
Rainer Gerhards

---

From: Albert Mietus <[email-masked]>
Date: Tue, 18 Oct 2005 14:40:30 +0200

> syslog several times on this list. The idea always has violently been

Iff (if and only if) there will be a standard for syslog-over-tcp, I  
think it should do more then replace UDP by TCP.

Some years ago, we have studied this. And found that in environments  
where UDP  'will not do' a simple replacement will not suffice to.
E.g. We needed to be able to transfer log from a hostile, "unsafe"  
environment (e.g. the systems just before the firewall), to a safe  
place (behind the FW). UDP isn't an option;  nobody will accept such  
a DOS-hole. But for the same reasons, any TCP session from a possible  
hijacked host through  the FW is not a good idea.
So, we implemented a 'reverse, buffered' TCP syslog.

The idea: a (controlled, safe) host will start an (outward)  TCP  
session, fetching log from the 'unsafe' area. When there is no  
connections the host in the hostile environment will buffer log (for  
some time) in memory. The latter will give stat-up log. But also make  
sure the "log during an attack" (when possible some systems/ the FW  
are down/closed) can be saved (and studied later). The reverse-flow  
will make sure never a 'hijacked' host can send data through the FW.  
Sure, some loglines that can be faked. But the control of that  
session is full: only a secure host can start a session.

Note: For political reasons, the code is never put in production. (I  
have it laying somewhere, it is open ...). But it works.

I mention this example; to show replacing UDP by TCP is simple and  
will suffice. I think, there is need for a TCP version. Personally, I  
don't like BEEP, nor the syslog-over-BEEP option. But a don't like a  
simple TCP syslog nether.

Note: It just me.  But I'm not actively involved in syslog anymore.  
And will be offline for some time. So I can't discuses a follow up

--Groetjes
ALbert Mietus
     Send prive mail to:          ALbert at ons-huis dot net
     Send business mail to:  Albert dot Mietus at PTS dot nl
     Don't send spam mail!
http://albert.mietus.nl               http://albert.mietus.nl/read.IT

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 18 Oct 2005 10:28:38 -0400

Hi,

There will be much discussion of "call-home" functionality, something
akin to the reverese buffered approach described here, at the upcoming
Vancouver meeting. It may be a BOF, or it may be a discussion in the
O&M open area meeting. See
https://www1.ietf.org/mailman/listinfo/call-home for information about
the call-home mailing list.

The proponents are looking for operators who think this is really
needed for network management protocols, and should be addressed as
part of the ISMS WG work or in a separate WG.

This discussion is largely targeted at SNMP and NETCONF over TCP-based
transports, such as SSH. It sounds like the syslog WG should be
involved in this discussion as well, even if the WG chooses to just do
a TCP transport mapping. The security and transport needs for SNMP,
Netconf, and syslog are converging.

Note that a TCP transport mapping was developed for SNMP (RFC3430),
and the demand was for more than just TCP; the demand was for a
secured TCP transport. Currently the ISMS WG is working on an
SSH-secured transport for SNMP to parallel Netconf's use of SSH,
although the ISMS version has more to it than Netconf's because we are
also tying into RADIUS centralized authentication through SSH, and
tying the centralized RADIUS authorization into SNMP access control.

For the record, I believe standardizing a TCP-based transport mapping
for syslog, preferably using SSH, would be a good supplement to the
UDP transport mapping.

David Harrington
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Albert Mietus
> Sent: Tuesday, October 18, 2005 8:41 AM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: Re: [Syslog] plain tcp syslog
>

---

From: Darren Reed <[email-masked]>
Date: Wed, 19 Oct 2005 00:19:03 +1000 (EST)

> think it should do more then replace UDP by TCP.

Eventually, yes.

But we don't have to get there in one big jump, especially if there is
evidence that the proposed result will be widely rejected.

> simple TCP syslog nether.

I think starting off with a simple TCP syslog and adding to it with a
reliable version (matching the UDP progress) is the right way to start.

I think there is much more chance of getting progress and useful RFCs
and internet drafts published that way than trying to solve the entire
solution space in one hit.

i.e. BEEP has been proposed as "the solution", nobody likes it, lets
back off, do what we know people like and along the way maybe we
will learn about how to deliver the ultimate solution that people do
want.

btw, I'm willing to add my voice to this in Vancouver, if it matters
to anyone.

Darren

---

From: Darren Reed <[email-masked]>
Date: Wed, 19 Oct 2005 01:01:07 +1000 (EST)

..
> Netconf, and syslog are converging.

So what you're saying is that the others are tunelling via ssh to
deliver data back via secure means as well as have that connection
properly authenticated ?  (for some value of "proper")

> secured TCP transport.

Why was SSL/TLS rejected ?

> for syslog, preferably using SSH, would be a good supplement to the

How do you propose (or imagine) that this would work for an arbitrary
device connected to your network (say printer) that wants to use this
mechanism to deliver syslog messages ?

Darren

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 18 Oct 2005 11:46:16 -0400

Hi,

Comments inline 

> From: Darren Reed [mailto:[email-masked]] 
> Sent: Tuesday, October 18, 2005 11:01 AM
> To: [email-masked]
> Cc: 'Albert Mietus'; 'Rainer Gerhards'; [email-masked]

Other WGs are using user authenticated sessions over a secure
connection for request-response types of network management data, and
plan to use similar tunnels for notification types of traffic.

The ISMS and Netconf WGs are considering using a call-back approach.

> Why was SSL/TLS rejected ?

SSL/TLS was not rejected.

SSH was identified by the Netconf WG as the "transport" of preference
for operators performing configuration tasks using CLI scripting, and
Netconf is an effort to provide a machine-parseable alternative to CLI
scripting.

SSH was identified by the ISMS WG as one of the secure "transport"
protocols that operators would like to see utilized for SNMP. TLS was
another. The ISMS WG chose to design an SSH security model for SNMP
because it had a slight edge over other protocols in a survey of NANOG
operators, and it had already been chosen by Netconf as the
mandatory-to-implement protocol. 

> mechanism to deliver syslog messages ?

About the same as it would work for an arbitrary device that wants to
use this mechanism to deliver SNMP or Netconf notifications.

See draft-ietf-isms-secshell-00.txt for more information (in the I-D
queue at this point, but not yet available). An earlier version can be
found in
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-harrington-ism
s-secshell-01.txt.