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

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

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

After some thinking, I agree with Anton. I, too, think that
octet-counting is superior, as it leaves the door open for changes in
the upper layer. So I now strongly vote for using this approach.

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

I agree on this point with Anton. We should not add any additional
overhead to the UDP transport. There is few reasoning for multi-chunk
messages in a potentially 448-octet constraint message. There may be
some valid use cases with ultra-compact messenging, but that should
probably done in another transport and/or optionally in a revision once
we got some experience with actual implementations.

Rainer

> 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
> > >
> > > _______________________________________________
> > > Syslog mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > >
> > 
> > _______________________________________________
> > Syslog mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/syslog
> > 
> 

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

---

From: Balazs Scheidler <[email-masked]>
Date: Fri, 17 Mar 2006 16:15:26 +0100

[ stripped Cc line ]

> the upper layer. So I now strongly vote for using this approach.

Agreed, let's go for octet-counting. How would that look like? Two
octets before every message? That would limit message size to 64k, is
that sufficient? (I personally say it is, messages larger than 64k would
potentially mean that they cannot be held in memory)

-- 
Bazsi