Subject: RE: [Syslog] Preliminary syslog-transport-tls document - issue 3

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 15 Mar 2006 10:55:38 +0100

Miao,

thanks for the great (and quick) work. I can not review it fully right
now, but I have seen one issue that I would like to comment immediately
on. More comments follow later.

>    [Issue 3] The problem of CR LF is it can not process binary data
>    well.  How to process Syslog signature/certificate message?

With the current status of syslog-protocol, you can NOT do
octet-stuffing. The reason is that any character is valid inside MSG and
this includes the CR LF sequence. 

So we have two options:

1. change -protocol to disallow CR LF
2. use byte-counting for framing in -tls

Option 1 has been discussed in the past and mostly been rejected.
However, this is the first time that we have a real standardization use
case for excluding it. Currently existing (non-standard) syslog/TCP uses
CR LF (or lone LF) as record delimiter. So it might be useful to take
that route.

Option 2 has the advantage of greater aplicability plus enables the
application developer to use more efficient buffering (as the needed
buffer space is known in advance).

I have no strong opinion which option is better, but I tend a little bit
to option 2.

Rainer

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

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 15 Mar 2006 14:25:50 -0800 (PST)

Hi,

This is an issue that we need to discuss.  I've had some discussions with 
various people on this subject who's opinions I trust.  They also suggest 
that we do have 2 options as Rainer states.  Let me describe this in a bit 
more detail:

The consensus from all is that syslog-protocol should not explain how to 
have multiple syslog messages in each packet.  That should be done in each 
of the transport documents so that transport mechanisms can frame the 
messages.  This ensures a good fit if syslog is placed into a new 
transport that already has a framing mechanism.  This is how it has been 
done in RFC 3195.

As Rainer says, we can reserve a character or characters to separate 
messages.  We could use ASCII characters such as CRLF or we could use a 
UTF8 character.  See:
   http://www.unicode.org/faq/utf_bom.html       and
   http://www.unicode.org/reports/tr14/index.html
This would require that we place a very strong message in the Security 
Considerations section of each transport document that would warn against 
an inappropriate use of the separator character(s).  For example, if CRLF 
is chosen as the separator, the receiver may get a message with a CRLF in 
it that does not signify a separation of messages.  This will probably go 
away with time as more poeple adopt to the standard.

Alternatively, we could count bytes to show the end of a message.  The 
receiver would count to that point and decide if there is another message 
after that.  Having this option would not require any additional messages 
in the Security Considerations section as there would be no doubt about 
the end of a message.

I want to open this discussion to the group.  If we can agree to some 
mechanism then we'll get Anton, Fuyou and Yuzhi to put this into their 
IDs.

I will say that the WG is not addressing the transport of binary messages 
at this time.  However, I know that it's a concern of this group and I 
would hope that the people who think about this take that thought into 
consideration when they send in their comments.

Thanks,
Chris

---

From: Balazs Scheidler <[email-masked]>
Date: Thu, 16 Mar 2006 10:48:35 +0100

> consideration when they send in their comments.

The only argument for CRLF is its use in current (non-standard)
syslog/tcp implementations (syslog-ng, PIX, NetScreen, Adiscon, etc.).

If I'd start from scratch I would also use some kind of byte-count based
framing.

I'm also undecided :)

How would that framing look like? Binary or text? Would we limit the
size of the frame length (effectively limiting the frame size itself)?
How about adding some kind of application layer acknowledgement support?

What this boils down in my mind is: do we get any additional benefits
from using a more complex framing, as opposed to using CRLF for this
purpose which is filtered out from logfiles anyway?

I see the following possible upsides of using some kind of framing:
* byte-counted messages, effectively allowing the use of the full
character set
* application layer acknowledgements, avoid losing messages sitting in
the TCP socket buffers without knowing that they were not really sent.
* control messages
* multiplexed channels

The question is which ones do we want to implement and how this
correlates with the previous work on BEEP.

-- 
Bazsi