RE: [Syslog] delineated datagrams

["Rainer Gerhards" <[e-mail]>]

<inline> 

> -----Original Message-----
> From: Chris Lonvick [mailto:[e-mail]] 
> Sent: Monday, August 14, 2006 8:20 AM
> To: Tom Petch
> Cc: [e-mail]
> Subject: Re: [Syslog] delineated datagrams
> 
> Hi Tom and All,
> 
> What I've seen discussed:
> - There is no character or character sequence that cannot be 
> used in the
>    syslog payload, which might confuse a parser looking to delineate
>    messages in a single packet based upon a character or character
>    sequence.
> - Byte counting can provide assurance for the delineation of messages.
> - {Some | Most | All} syslog daemons already escape LF so a 
> non-escaped LF
>    could be used to delineate messages.
> 
> Is this correct?

Partly: every character can be present in MSG. So no one can be set
aside. However, we can define an escape character (or sequence) and use
that to escape "magic characters". The escape itself is a magic
character and needs to be escaped. With that, LF can be used as
delimiter. Most existing syslogds use LF as a separator (when receiving
via TCP and SSL).

Octet-couting is the cleanest solution. However, it will not work with
existing syslogd - not even in the limited compatibility setting
outlined in -protocol.

Escaping in existing syslogd does not really matter, because it would
interfere with new-style messages (but mostly in an acceptable - and
expected - way).

> 
> Since it's come up on the list before as a concern, what will 
> be done if 
> people start putting binary information into the syslog 
> message payload? 

This is only supported as long as the binary information results to
valid Unicode sequences. If not, the message is invalid and likely to be
discarded.

In short: pure binary is forbidden. Use base-64 or something similar if
you really need to.

> Will that always have to be escaped by the sender and reversed by the 
> receiver?

NO! This is prohibited by -protocol. Any valid Unicode sequence MUST be
supported in MSG. This includes a myriad of (unicode) control sequences.

Think the difference between on the wire and storage here. Inside
storage (outside the scope of this wg), a receiver may escape (in fact
I'd recommend it). But not on the wire.
> 
> Thanks,
> Chris
> 
> On Mon, 14 Aug 2006, Tom Petch wrote:
> 
> > ----- Original Message -----
> > From: "David Harrington" <[e-mail]>
> > To: "'Chris Lonvick'" <[e-mail]>; "'Miao Fuyou'" 
> <[e-mail]>
> > Cc: <[e-mail]>; "'Tom Petch'" <[e-mail]>
> > Sent: Friday, August 04, 2006 7:59 PM
> > Subject: RE: [Syslog] delineated datagrams
> >
> >
> >>
> >> As you probably know by now, I like to see design reuse 
> across IETF NM
> >> solutions, especially across SNMP, syslog, ipfix, and netconf where
> >> feasible.
> >>
> >> As all the IETF NM protocols move toward similar secure transport
> >> solutions, including moving from datagrams to streams, it 
> would be a
> >> good thing to use consistent aproaches to framing.
> >>
> >> Here is what is happening in the other IETF NM protocols:
> >>
> > <snip>
> > >
> >> The NETCONF protocol uses an RPC-based communication model.
> >> From
> >> http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt:
> >>    NETCONF peers use <rpc> and <rpc-reply> elements to provide
> >> transport
> >>    protocol-independent framing of NETCONF requests and responses.
> >
> > Ok as far as it goes but incomplete.  As the ssh mapping says,
> >
> > " As the previous example illustrates, a special character sequence,
> >    ]]>]]>, MUST be sent by both the client and the server 
> after each XML
> >    document in the NETCONF exchange.  This character sequence cannot
> >    legally appear in an XML document, so it can be 
> unambigiously used to
> >    indentify the end of the current document in the event of an XML
> >    syntax or parsing error, allowing resynchronization of 
> the NETCONF
> >    exchange."
> > .
> > Wishing to promote design reuse across IETF NM solutions, 
> especially across the
> > character-based ones, I did propose the same separator for 
> syslog over tls and
> > still see it as the technically best solution (even though 
> our message content
> > can be anything and so, unlike NETCONF, we cannot rely 100% 
> on that not
> > appearing in our message content).
> >
> >>
> >> David Harrington
> >> [e-mail]
> >> [e-mail]
> >> [e-mail]
> >>
> >
> 
> _______________________________________________
> Syslog mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

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