Subject: [Syslog-sec] syslog message truncation

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 15 Feb 2005 11:33:29 +0100

Hi WG,

Sharon has provided the following good comment:

###
> S3. In section 6.1, we need some guidelines on how to truncate
> SD-BOUNDARIES. 
> Can the structured data become non-compliant or must it still 
> be valid? If
> within the message part, is it just arbitrary?  Should we indicate
> truncation has occurred in the header or at the very end of 
> the message? Do
> we need to leave room for some extra characters at the end to 
> signify the
> message has been truncated?
###

I've thought and re-thought about this, but I do not have a clear
preferrence, so I would like to bring this up on the WG mailing list.

I think the best solution would be to NOT allow truncation of structured
data elements. I personally think it would complicate things at the
analysis end if we allow truncation of structured data. Keep in mind
that we currently ALLOW such truncations, because we have set up no
specific rules for that. If we now go ahead and disallow it, it might
become more complicated for a relay to carry out the necessary
truncation. This, some might say, is an unnecessary burden. As you can
see, there are pros and cons for each scenario.

The same goes for indication of message (not only structured data)
truncation. I am tempted to add a header field "message truncated".
However, I am not sure if that is something that we actually need. Or,
better said, that is worth it. Keep in mind that we have very limited
space inside the message and such a header would cost additional 2
octets (from a 480 octet minimum size). If we indicate truncation, I
would strongly opt to add this to the header and NOT at the end of the
message (indication at the end of the message would make a MSG delimiter
mandatory, which we do not have currently).

Any comments are deeply appreciated.

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 15 Feb 2005 05:58:48 -0500

hi

I would agree that a truncation bit in the header if truncation is performed
is better than at the end of the message. I would also agree that truncation
within the structured data is too expensive and unstable. I still worry
though, about the loss of information that would result from messages being
systematically dropped due to length mismatches, so would propose something
along the following lines:

If truncation is required, then the point of truncation be determined. If it
is within the message text, then the truncation bit be set within the
message header and the message be sent with its reduced size. If the point
of truncation is somewhere before the message text, then this message be
discarded.

Sharon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Rainer
Gerhards
Sent: Tuesday, February 15, 2005 5:33 AM
To: [email-masked]
Subject: [Syslog-sec] syslog message truncation

Hi WG,

###
> SD-BOUNDARIES. Can the structured data become non-compliant or must it 
> still be valid? If
###

I think the best solution would be to NOT allow truncation of structured
data elements. I personally think it would complicate things at the analysis
end if we allow truncation of structured data. Keep in mind that we
currently ALLOW such truncations, because we have set up no specific rules
for that. If we now go ahead and disallow it, it might become more
complicated for a relay to carry out the necessary truncation. This, some
might say, is an unnecessary burden. As you can see, there are pros and cons
for each scenario.

The same goes for indication of message (not only structured data)
truncation. I am tempted to add a header field "message truncated". However,
I am not sure if that is something that we actually need. Or, better said,
that is worth it. Keep in mind that we have very limited space inside the
message and such a header would cost additional 2 octets (from a 480 octet
minimum size). If we indicate truncation, I would strongly opt to add this
to the header and NOT at the end of the message (indication at the end of
the message would make a MSG delimiter mandatory, which we do not have
currently).

Rainer

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 15 Feb 2005 13:42:13 +0100

Sharon,

> of truncation is somewhere before the message text, then this 

I am not sure if it is appropriate to drop the message completely. At
least the drop should be optional (maybe with a rule that the truncated
message should not further be forwarded).

I am concerned because I think we might loose vital information in this
case.

As an alternate approach, the "truncation information field" could have
three values:

n - no truncation occured
m - truncation im MSG part
s - truncation in STRUCTURED-DATA part

that would convey enough information to the (ultimate) receiver so that
it can decide how to act on a message.

Comments?

Rainer