Subject: RE: Aside - isms genesis was Re: Why not TLS was Re: [Syslog] Securesubstrate - need your input

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 26 Oct 2005 17:59:37 +0200

Tom,

I think part of the problem ob being out of sync in our interpretation
is that we are probably thinking about different user bases. As of my
understanding, SNMP most often has the "high end" users, the guys with
many ressources and good knowledge. Many of them also use syslog.
HOWEVER, syslog is also used by many "low end" users, those with limited
ressources and knowledge and only a handful of servers and routers. Most
probably, the later would not install SNMP based solutions and even not
care about things like NETCONF. Their problem is to see these few events
they have on a central machine and (hopefully) run some analysis against
it.

This diverse user base might be the root problem. In my experience,
syslog solutions and development tend to lean toward the low end, in
part because the high end already uses other event notification methods.
With syslog, we also have application developers who simply want to log
an error message somewhere. If we are lucky, they know about the
syslog() call, if not, they'll dump the message somewhere...

What I am trying to convey is that the different target user base
eventually requires different approaches for the protocols.

Then, there is the fact that syslog currently *is* being *deployed* via
TCP and via SSL(TLS). For example, these links are quite popular:

http://freshmeat.net/articles/view/1781/
http://www.stunnel.org/examples/syslog-ng.html
http://www.monitorware.com/Common/en/Articles/eventlog-stunnel-syslog.ph
p
http://www.sun.com/bigadmin/features/articles/syslog_ng.html?biga=15

Is actual *deployment* of a technology not a good indication that there
is need in the market for it? Frankly, the syslog developer community
cares very little about the IETF. This community develops what is in
demand, and unfortunately what we are currently doing is not demanded...
I think it is not wise to ignore the fact that a healthy developer and
user community has already solved (well, mostly) the problems we are
discussing. We just do not like their conclusions. The results that
practice tells us. But if practice is so broken, how can it work?

The one thing that is asked for ever and ever again by syslog users is
standardization of message *content*. That is the topic that urgently
needs work. That is the topic we have excluded in our charter ;) Folks,
I know this is my personal rant and frustration, but aren't we ready for
a reality check?

Ok, cooling down... I am sure that the survey you mentioned did very
well look at the needs and whishes of the big guys. But does it equally
well tell about the small ones? As a side note, I would find a link to
the survey questions (as suggested by David) very helpful.

Co-incidently, I'd begun to craft a small survey in the mean time.
Definitely not as well thought-out, but hopefully good enough to see
what is deployed in practice. I intended to ask for participation on
several mailing list. Now that I have finished it, I think I at least
provide a link to the proposal I intended to make

http://survey2.adiscon.com/phpESP/public/survey.php?name=syslog1_NonLive
1

(This survey is NOT LIVE - do NOT pass it to anyone outside the WG;
results will be discarded)

Rainer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Wednesday, October 26, 2005 4:22 PM
> To: [email-masked]
> Subject: Aside - isms genesis was Re: Why not TLS was Re: 
> [Syslog] Securesubstrate - need your input
> 
> In case anyone else should be interested, the survey I keep 
> referring to was
> performed of 149 operators at NANOG at the request of the 
> IETF AD to provide
> evidence that there was a problem with SNMPv3 security that 
> the IETF should work
> on.  The results were presented at IETF60 and the IESG were 
> convinced; hence the
> isms WG.
> 
> I refer to it because the IETF often bemoans the lack of 
> operator input and this
> is one time when it was sought and obtained.
> 
> And yes, as Rainer pointed out, we don't know what X.509 
> means and SSL/TLS (and
> a few others) could be lurking in there (nothing like a 
> survey for creating the
> need for more surveys:-(.
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Darren Reed" <[email-masked]>
> To: "Tom Petch" <[email-masked]>
> Cc: "Rodney Thayer" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, October 26, 2005 2:48 PM
> Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - 
> need your input
> 
> 
> > [ Charset ISO-8859-1 unsupported, converting... ]
> > > Just to add the figures that support my assertion, in an 
> e-mail from Wes
> > > Hardaker, who surveyed the network operators, to isms
> > >
> > > "Of the various authentication systems in use at that 
> time by the people
> that
> > > responded:
> > >
> > >   66%  local accounts
> > >   49%  SSH-keys
> > >   40%  Radius
> > >   29%  TACACS+
> > >   14%  X.509 Certificates
> > >   10%  Kerberos
> > >
> > >   [numbers don't add to 100 because more than one option 
> could be selected]"
> > >
> > > which I have paraphrased as
> > > SSH a significant number
> > > TLS so small as to be invisible
> >
> > I disagree.  I don't think the numbers above provide that kind of
> > conclusion at all.  We don't know what the survey was, etc.  Just
> > like any set of statistics, they can be interpreted to mean many
> > things, depending on how you want to read them.
> >
> > Anyway, I'm not interested in that.
> >
> > But, to put the problem differently, in how many different 
> places can
> > you use TLS/SSL for authentication today, to sign in ?
> >
> > If there's nowhere for people to use TLS then of course the numbers
> > won't be high.
> >
> > Darrn
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

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