gmane.ietf.syslog

Re: Syslog message to Remote Rerver

Rainer Gerhards — 2013-02-26T10:34:47

sorry for the late reply, have been off to a conference...

On Thu, 2013-02-21 at 16:25 +0000, Aditya Dogra (addogra) wrote:


RFC5424 does NOT specify UDP transport. In fact, it does not specify any
transport at all, it just describes the format and the stack. Transport
mappings are done in

RFC5425 - TLS (TCP), the recommended protocol
RFC5426 - UDP

there is also historic RFC6587 on industry standard plain tcp, but this
is just for interoperating with legacy systems, not for new
implementation. It is strongly discouraged to use that in new systems.

RFC3195 is a bit dated and would need to be changed to base on RFC5424.
This has not yet been done as there was no notable implementation of
RFC3195.


There is a very small window of exposure, see section 5.3 of RFC5425. I
also wrote a somewhat more elaborate blog post on this problem, which
may be useful for you:

http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html

that's something that you need to answer based on your use cases and
r

Re: [OPSAWG] Syslog message to Remote Rerver

ietfdbh — 2013-02-25T06:54:14

From: opsawg-bounces< at >ietf.org [mailto:opsawg-bounces< at >ietf.org] On Behalf Of
Aditya Dogra (addogra)
Sent: Thursday, February 21, 2013 11:25 AM
To: syslog< at >ietf.org; opsawg< at >ietf.org
Subject: [OPSAWG] Syslog message to Remote Rerver

Hi All ,

Currently syslog messages collected locally on the network device are
transmitted to the remote syslog servers as per RFC 5424 (UDP protocol used
for transmission) and RFC 3195 (TCP protocol used for transmission) 

[dbh>] RFC5424 defines the IETF version of the syslog protocol message
format (not the UDP transport).

RFC5424 RECOMMENDS using a TLS-based transport (RFC5425) rather than a
UDP-based or plain-TCP-based transport for syslog.

If you use a UDP-based transport for interoperability, it should probably
follow RFC5426.

The IETF standard for syslog over UDP (RFC5426) states:

"   Network administrators and architects should be aware of the

   significant reliability and security issues of this transport, which

   stem from the use of UDP."

N

Syslog message to Remote Rerver

Aditya Dogra (addogra — 2013-02-21T16:25:29

Hi All ,

Currently syslog messages collected locally on the network device are transmitted to the remote syslog servers as per RFC 5424 (UDP protocol used for transmission) and RFC 3195 (TCP protocol used for transmission)

However, we have observed that increasingly, customers are using syslog messages archived in the remote server for business logic .

In some networks, it is possible that some of the syslog messages may be dropped due to link failure or other network conditions.
However, the customers are expecting much higher resiliency for the syslog messages.


The questions we seek clarification are:

a)         What are the expectations from the external syslog delivery?

b)         Should we rely on syslog's alone ? Please note that SNMP traps functionality for network management is also there.?


Your thoughts and suggestions much appreciated.


Regards,
Aditya dogra


_______________________________________________
Syslog mailing list
Syslog< at >ietf.org
https://www.ietf.org/mailman/listinfo/syslog

Re: I-D Action:draft-cloud-log-01.txt (fwd)

Gene Golovinsky — 2011-03-21T12:29:13

Raffael.
I have responded to your blog post in a private e-mail a few weeks ago.

There are two aspects here that I feel need addressing.

1. If I take your statement that that standardization of logging in the cloud is not needed than conversation about technical merits of the proposal is completely irrelevant! Why even bother working out the correct technical solution if the problem does not even exist?
2. I completely agree that we need ONE standard. We actually already have it - Syslog.

CloudLog is an extension to Syslog and using exiting and well defined Syslog facilities. You are proposing CEE instead, which cannot really be easily mapped to Syslog hence all existing facilities will not work.

I would also argue that CloudLog is really a protocol, while CEE looks rather like a data model to me.

If anything they are rather orthogonal to each other. 

I completely disagree that Cloud is not special. Like any other new IT deployment, Cloud brings a slew of new and previously not considered uses cases. T

Re: I-D Action:draft-cloud-log-01.txt (fwd)

Raffael Marty — 2011-03-20T05:05:56

Chris et al.

I have written a technical review of why a cloud logging standard doesn't make any sense here:

- http://raffy.ch/blog/2011/02/14/why-a-cloud-logging-standard-doesnt-make-any-sense/

Aside from the many many shortcomings that are addressed in my blog post, standardizing cloud logging is like saying we are going to write a standard for mobile phone logging, one for green data center initiatives, one for virtualization, etc. We need one standard. The cloud is not special. It's a virtualized, distributed, asynchronous environment. We need to add these (and other) use-cases to an existing or a new logging standard, but not create a variety of different use-cases. Let's define what the cloud use-case demands and add it as a requirement to some other standard.

Please consider this when looking at the cloud-draft.

Thank you!

  Raffael

--
Raffael Marty                          Founder and COO < at > Loggly
< at >zrlram                                          about.me/raffy

On Mar 16, 2011, at 6:37 AM, Chri

I-D Action:draft-cloud-log-01.txt (fwd)

Chris Lonvick — 2011-03-16T13:37:49

Hi Folks,

Just passing this along.

Thanks,
Chris

---------- Forwarded message ----------
Date: Mon, 14 Mar 2011 14:45:09 -0700
From: Internet-Drafts< at >ietf.org
To: i-d-announce< at >ietf.org
Subject: I-D Action:draft-cloud-log-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

 Title           : Syslog Extension for Cloud Using Syslog Structured Data
 Author(s)       : G. Golovinsky, et al.
 Filename        : draft-cloud-log-01.txt
 Pages           : 11
 Date            : 2011-03-14

This document provides an open and extensible log format to be used
by any cloud entity or cloud application to log and trace activities
that occur in the cloud.  It is equally applicable for cloud
infrastructure (IaaS), platform (PaaS), and application (SaaS)
services.  CloudLog is defferent in content, but not in nature from
the traditional logging as it takes in account transient nature of
identities and resources in the cloud.

A URL for this Internet-Draft is:
http://www.ietf.org/inter

Re: draft-cloud-log-00 / CEE - why not IPFIX?

Gene Golovinsky — 2011-02-17T18:47:33

Is there a link to the article?

--Gene

-----Original Message-----
From: syslog-bounces< at >ietf.org [mailto:syslog-bounces< at >ietf.org] On Behalf Of Dan Schlitt
Sent: Thursday, February 17, 2011 11:21 AM
To: Heinbockel, Bill
Cc: Sam Johnston; Event Expression; syslog< at >ietf.org; Common< at >core3.amsl.com
Subject: Re: [Syslog] draft-cloud-log-00 / CEE - why not IPFIX?

On this topic it might be well to look at Tom Limoncelli's article in the February Communications of the ACM. He is highly respected in the system administrator community and speaks for many of us.

/dan

Re: draft-cloud-log-00 / CEE - why not IPFIX?

Dan Schlitt — 2011-02-17T17:20:58

On this topic it might be well to look at Tom Limoncelli's article in 
the February Communications of the ACM. He is highly respected in the 
system administrator community and speaks for many of us.

/dan

Re: draft-cloud-log-00 / CEE - why not IPFIX?

Heinbockel, Bill — 2011-02-17T16:35:19

Thanks for that, I did not realize that IPFIX had been extended beyond its netflow 
past.

I don't have the time now, but I am interested in looking into it further. It does 
kind of remind me of ASN.1/SNMP, where we need to worry about the names/OID 
translation

Also, a lot of vendors and users seem to prefer the ease of text-based protocols 
like Syslog for logging. I am not saying this is good or bad, but it seems to be 
the sweetspot -- binary is not natively human readable and XML has too much 
overhead.


William Heinbockel
The MITRE Corporation


_______________________________________________
Syslog mailing list
Syslog< at >ietf.org
https://www.ietf.org/mailman/listinfo/syslog

Re: draft-cloud-log-00 / CEE - why not IPFIX?

Jeroen Massar — 2011-02-16T12:54:16

[..]

I might be missing the parsing here, but can you explain what part is
counter-productive to have a single protocol and having to write only a
single parser versus having a lot of different protocols who require
parsers which can resolve ambiguity?


I wonder what the "E" in IETF stands for if I see the above statement.
Why not simply use CSV or hey just pack it in XML! :)

Please note that IPFIX has gathered quite some attention already.

As for the OSI stack argument, the world is not ready for IPv6 either.

I like to also quote:
http://www.ietf.org/mail-archive/web/sip-clf/current/msg00430.html

8<-----------------------------------------------------------------------------
1. Shall we use a TAB or a SPACE (or any LWS) as field delimiters?
Considerations and points raised:

- TABs don’t survive Telnet or web pages very well, especially when
copy/pasting.
- spaces can appear inside fields (as can most other delimiters we choose)
- how do TAB and SPACE delimiters interact with shell tools (rep, cut,

Re: draft-cloud-log-00 / CEE - why not IPFIX?

Rainer Gerhards — 2011-02-16T11:34:06

Well I really don't like to restart that discussion in this context here
again, but let me note that what you are doing with your converter is very
useful. It actually normalizes data into a canonical format. This is
something that CEE tends to do, but in a protocol agnostic format (and I do
similar things in my projects as well). The general utility is unquestioned.
The question is if such an effort must be bound restricted to a single
protocol. My PoV is that this is counter-productive.

You definitely have a point in that IPFIX may be superior than syslog in many
regards. I do not intend to argue against this. But often a simpler solution
is able to draw more attention, and thus deployments, than a (potentially or
actually) technical superior one (shouldn't we all use the OSI stack by now,
just as one example...). 

I don't think it is useful to include IPFIX in syslog. But it may be an
option that IPFIX makes syslog obsolete. I think you should take that later
route.

But as I said -- I do not intend to

Re: draft-cloud-log-00 / CEE - why not IPFIX?

Jeroen Massar — 2011-02-16T10:56:41

Why would they expect anything about the *DATA* format of a protocol?

Note that the whole point that IPFIX (or any other structured data
format for that matter) 'solves' is that one has to make a parser for
every single log file format out there. Doing this at the meter tends to
be cheaper due to the ability to distribute that than at the aggregated
part. (then again sFlow as an example does it exactly the other way
around, just pushing packets and letting the collector do the hard
parsing part, but we are talking about sampled flows here thus you will
miss out on events which is not a decision you can make at the meter if
you are looking at say breaking attempts or failures ;)

I think the pro-ascii versus binary argument comes effectively primarily
from organizations who process large amounts of variable-string ascii
data already and who do not really care about a few extra bits or a bit
more overhead in processing data as they have large global clusters of
hosts already doing that work. Their programmin

Re: draft-cloud-log-00 / CEE - why not IPFIX?

Rainer Gerhards — 2011-02-16T10:39:43

The SIP CLF WG has just recently rejected IPFIX for it being binary and
chosen indexed ASCII instead for their format. Their reasoning (after a long
struggle) is probably educating:

http://www.ietf.org/mail-archive/web/sip-clf/current/msg00364.html

I don't think that IPFIX is a good solution *in the syslog context*. It is
very far from what people expect. Other than that, I'd probably need to
re-iterate the arguments made on the SIP CLF mailing list, so it probably is
better to refer to their archive ;)

Rainer

_______________________________________________
Syslog mailing list
Syslog< at >ietf.org
https://www.ietf.org/mailman/listinfo/syslog

Re: draft-cloud-log-00 / CEE - why not IPFIX?

Jeroen Massar — 2011-02-16T10:35:07

For a short bit forget about the history of IPFIX, it indeed comes from
NetFlow, and thus is used quite in a network centric way, but
effectively it is a structured streaming data format.


There are two parts to IPFIX: Templates + Data

The template describes how the data looks like, for instance, lets take
an Apache CLF log entry:

66.249.66.174 - - [16/Feb/2011:10:48:11 +0100] "GET /robots.txt
HTTP/1.1" 200 2629 "-" "Googlebot-Image/0"

We can make an IPFIX template for that

[
{4, IPv4_SRC },
{4, TIMESTAMP},
{4, HTTP_METHOD},
{v, URL},
{v, HTTP_PROTOCOL},
{2, HTTP_RESULT},
{8, OCTETS},
{v, HTTP_REFER},
{v, HTTP_USERAGENT},
]

The 'v' markers indicate variable fieldlengths, the others indicates the
number of bytes such a field takes. The data is then just encoded in the
above format, presto.

The above is a simple example, one can also have repeating lists and of
course you could make a variable template which just includes the fields
that you actually want to look at or you could already do som

draft-cloud-log-00 / CEE - why not IPFIX?

Jeroen Massar — 2011-02-15T11:17:28

Hi,

As the subject states, for both this cloud[1] and CEE[2] proposals, why
not use IPFIX instead for structured logging data!?

Greets,
 Jeroen

[1] http://www.ietf.org/id/draft-cloud-log-00.txt
[2] http://cee.mitre.org/
_______________________________________________
Syslog mailing list
Syslog< at >ietf.org
https://www.ietf.org/mailman/listinfo/syslog

I-D Action:draft-gerhards-syslog-plain-tcp-08.txt (fwd)

Chris Lonvick — 2011-02-02T14:39:56

Hi Folks,

I've updated the document to include the reference from Steve Bellovin.

We'd appreciate reviews and feedback.

Thanks,
Chris

---------- Forwarded message ----------
Date: Tue, 01 Feb 2011 18:15:01 -0800
From: Internet-Drafts< at >ietf.org
To: i-d-announce< at >ietf.org
Subject: I-D Action:draft-gerhards-syslog-plain-tcp-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

 Title           : Transmission of Syslog Messages over TCP
 Author(s)       : R. Gerhards, C. Lonvick
 Filename        : draft-gerhards-syslog-plain-tcp-08.txt
 Pages           : 13
 Date            : 2011-02-01

There have been many implementations and deployments of legacy syslog
over TCP for many years.  That protocol has evolved without being
standardized and has proven to be quite interoperable in practice.

The aim of this specification is to document three things: how to
transmit standardized syslog over TCP, how TCP has been used as a
transport for legacy syslog, and how to correlate thes

Re: New syslog/tcp draft available

Sean Turner — 2011-02-01T13:47:10

Chris,

I am sympathetic to not wanting to get stuck waiting for a reference.  I 
think the informative reference you cite would past muster.

spt

On 1/31/11 9:48 PM, Chris Lonvick wrote:
_______________________________________________
Syslog mailing list
Syslog< at >ietf.org
https://www.ietf.org/mailman/listinfo/syslog

Re: New syslog/tcp draft available

Chris Lonvick — 2011-02-01T02:48:45

Hi Sean,

I've seen that but I don't want this document to sit idle for the next 
couple of years while that matures and becomes a normative and 
stable reference via becoming an RFC.

I'm really thinking that putting in definitive references for transport 
layer vulnerabilities is going a bit beyond what is expected of an 
INFORMATIONAL document.  That being said, I think it's a good idea and am 
willing to pursue it within reason.

Gont's document does reference a paper by Steve Bellovin:
    Bellovin, S. M. 1989.  Security Problems in the TCP/IP Protocol
    Suite.  Computer Communication Review, Vol. 19, No. 2, pp. 32-48.
That may be found here:
   http://portal.acm.org/citation.cfm?id=378449

What would you think about referencing that document as an INFORMATIVE 
reference in the third subsection of the Security Considerations section?

Thanks,
Chris

On Sun, 30 Jan 2011, Sean Turner wrote:

_______________________________________________
Syslog mailing list
Syslog< at >ietf.org
https://www.ietf.org/mailman/

Re: New syslog/tcp draft available

Sean Turner — 2011-01-30T17:12:25

Chris,

Not sure if this is what you're looking for, but have you checked out:
http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-security/

spt


On 1/30/11 12:01 PM, Chris Lonvick wrote:
_______________________________________________
Syslog mailing list
Syslog< at >ietf.org
https://www.ietf.org/mailman/listinfo/syslog

New syslog/tcp draft available

Chris Lonvick — 2011-01-30T17:01:07

Hi Folks,

We've finally gotten around to revising draft-gerhards-syslog-plain-tcp. 
:-)

This addresses the issues that Tom raised about
- the intro specifically stating what to expect in the body of the text
- a note on the transport security.

For the first, we just sort'a straightened things out with a few edits. 
For the latter, I looked in many places for a list of TCP vulnerabilities 
but couldn't find anything substantial.  The US-CERT had a few 
implementation things and there were a scattering of other things.  In the 
end, I just added a subsection to warn impelemters to look closely before 
writing code.  If anyone has any other suggestions, please let us know.

Thanks,
Chris
_______________________________________________
Syslog mailing list
Syslog< at >ietf.org
https://www.ietf.org/mailman/listinfo/syslog

Re: [Editorial Errata Reported] RFC5424 (2682)

Rainer Gerhards — 2011-01-11T12:05:45

I agree, this is definitely a useful correction :(

rainer

_______________________________________________
Syslog mailing list
Syslog< at >ietf.org
https://www.ietf.org/mailman/listinfo/syslog