Subject: RE: Framing in syslog messages - RE: [Syslog] Preliminarysyslog-transport-tls document - issue 3

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 16 Mar 2006 12:12:18 +0100

Baszi, 

> 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.

Honestly, I think if we take that route, we can simply implement RFC
3195. Actually, it offers all this and I do not see any way it could be
done with much less effort than already done in RFC 3195. BEEP looks
complex, but it is not all that bad once you nail it down. 

For this discussion thread, I think we are looking at a very simplistic
SSL based transport.

Rainer

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

---

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Thu, 16 Mar 2006 10:36:59 -0500

My 2 cents... Do the byte counting. Look at the headers of pretty much any successful protocol (TCP, IP, UDP, etc) - they all specify length of payload.  Special character sequence is really a hack IMO!  

Just to be clear, there was never any intention to allow multiple messages per UDP datagram.  So, this discussion probably does not apply to the UDP transport mapping. 

Thanks,
Anton. 

> -----Original Message-----
> From: Chris Lonvick (clonvick) 
> Sent: Wednesday, March 15, 2006 5:26 PM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: Framing in syslog messages - RE: [Syslog] 
> Preliminarysyslog-transport-tls document - issue 3
> 
> 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
> 
> 
> On Wed, 15 Mar 2006, Rainer Gerhards wrote:
> 
> > 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
> >