Subject: RE: [Syslog-sec] cooked messages max size

From: [email-masked]
Date: Wed, 18 May 2005 09:55:22 -0400

Sorry for that but I have to insist. Could anyone please have have a look
on that issue?

I really need to know how IETF interpret RFC 3195:
Are Syslog Cooked messages allowed to be longer than 1024 characters?
I have read RFC 3195 and 3164 several times and I have not found any
undeniable specification about that.

Best Regards

MC

My question is based on RFC 3195 & 3164.
In those RFC, it is clearly specified that BSD & RAW messages can't be
longer than 1024 characters. Otherwise, the syslog servers & relays
ignore the end of the message. What about cooked messages?

The part of the cooked message which could get long is the CDATA of the
entry element. In RFC 3195, we can read this:
  The character data for the element is the unstructured syslog event
  message being logged.  If the original device delivers the message
  for the first time via the COOKED profile, it may have any structure
  inside the CDATA.  However, for maximum compatibility, the device
  SHOULD format the CDATA of the message in accordance with Sections
  4.2.1 through 4.2.3 of [1].
[1] is RFC 3164.
First, sections 4.2.1 to 4.2.3 in RFC 3164 don't exist. I assume that
RFC 3195 refers to sections 4.1.1 to 4.1.3 of RFC 3164. (Since many
sites have copied RFC 3195, it will probably be difficult to catch up
that error.)

The limit of BSD messages size is not defined in those sections. It is
defined just before it, between the 4.1 title and the 4.1.1 title. The
result is that, technicaly, no size limit seems to be defined for cooked
messages.
I suppose that, for backward compatibility reasons, cooked messages have
to be shorter than 1024 characters. Could anyone confirm this, please?

MC
<
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 18 May 2005 07:30:10 -0700 (PDT)

Hi MC,

> undeniable specification about that.

If you've looked and can't figure it out, then it must not be properly
specified.  The Working Group would like to hear your opnion on a
resolution.

The IETF process works this way:
- An INFORMATIONAL document (like RFC 3164) can be used to tell how things
  have been done in the past.  It's really not a STANDARD and shouldn't be
  treated as one.  The most important thing about RFC 3164 was its
  Security Considerations part that showed most of the flaws in a "fire &
  forget" system.

- There are three stages of a document that is on the STANDARDS TRACK.
  These are shown in RFC 2026.
  http://www.ietf.org/rfc/rfc2026.txt

  - RFC 3195 is currently in the Proposed Standard state.  It's been out
    for a while and people are implementing it and coming up with concerns
    about it.

  - The problems that are seen in implementations and deployments of an
    RFC can be addressed by revising the document.  This will "obsolete"
    the prior RFC.  If the protocol is widely deployed and everyone seems
    happy with it, then it will be moved to Draft Standard.

  - Once someone has been out for a while and everyone is happy with it
    and the documents are very thorough then it can be moved to Internet
    Standard state.

The Working Group will need to revise RFC 3195 based upon two things:
- People who are developing code and deploying it need to speak up and let
  us know what works, and what doesn't work and how it can be resolved.
- The acceptance of syslog-protocol will force some changes as a reliable
  transport for syslog should have mechanisms to convey the newly defined
  fields in a proper manner.

Essentially, if you write your implementation of RFC 3195 to convey
messages larger than 1024 bytes, and you convince a majority of others to
do the same, then the revision of RFC 3195 will follow what you've done.

This mailing list is open for people to discuss implementation problems
and how things should be resolved.  :)

Thanks,
Chris