Subject: RE: [Syslog] delineated datagrams

From: Chris Lonvick <[email-masked]>
Date: Fri, 4 Aug 2006 07:13:38 -0700 (PDT)

Hi,

I'd like to get this resolved and put into the next version of the draft.

Many protocols use byte-counting for framing.
Many protocols use a specific character as a delimiter.
Do we need both?

I think that I've seen notes from Rainer, Tom Petch, and Andrew Ross 
saying that we should only use a special character for both simplicity of 
design and for interoperability with current syslog/tls implementations.

Are there other opinions on this?   Please speak up now.

Thanks,
Chris

On Mon, 24 Jul 2006, Miao Fuyou wrote:

>
> Hi, Rainer,
>
> Interop is a compelling reason for protocol design, so I tend to agree with
> you that it is a feature nice to have. I am wondering whether we should
> define procedures for frame delineating processing in syslog-tls draft
> because we have both octect-counter and LF in a record.
>
> Miao
>
>> -----Original Message-----
>> From: Rainer Gerhards [mailto:[email-masked]]
>> Sent: Friday, July 21, 2006 6:16 PM
>> To: Miao Fuyou; Tom Petch; [email-masked]
>> Subject: RE: [Syslog] delineated
>> datagramswasdraft-ietf-syslog-transport-tls-01.txt
>>
>> Miao,
>>
>> I agree with your comments. However, using the LF as a record
>> delimited would still allow us to interop with existing
>> syslog/tls implementations. This is my major point. I think
>> it is worth it.
>>
>> Rainer
>>
>>> -----Original Message-----
>>> From: Miao Fuyou [mailto:[email-masked]]
>>> Sent: Friday, July 21, 2006 12:00 PM
>>> To: 'Tom Petch'; [email-masked]
>>> Subject: RE: [Syslog] delineated
>>> datagramswasdraft-ietf-syslog-transport-tls-01.txt
>>>
>>>
>>> TLS uses SHA-1 or MD5 in ciphersuite for message integrity
>>> verification. If bytes lost happens during transferring,
>> the message
>>> will be dropped by TLS.
>>> That is also the cause that we need a security mechanism
>> for Syslog.
>>>
>>> As for error of encoding/decoding, I believe if an application does
>>> encoding/decoding in a wrong way, you must not expect it do
>> it right
>>> with other mechanism, such as LF.
>>>
>>> Redundancy to improve robustness is  good idea, but I don't
>> think it
>>> applies to this case.
>>>
>>>> -----Original Message-----
>>>> From: Tom Petch [mailto:[email-masked]]
>>>> Sent: Tuesday, June 20, 2006 8:43 PM
>>>> To: [email-masked]
>>>> Subject: Re: [Syslog] delineated datagrams
>>>> wasdraft-ietf-syslog-transport-tls-01.txt
>>>>
>>>> I wonder if others share my concern about the lack of
>> robustness in
>>>> the way in which datagrams are delineated in the stream
>> protocol (a
>>>> TCP rather than a TLS issue).
>>>>
>>>> The system works as long as
>>>>  - the frame length is encoded perfectly
>>>>  - the frame length is decoded perfectly
>>>>  - no bytes are inserted or removed in error which is
>> doubtless true
>>>> in some networks, but I would prefer not to
>>> rely on it.
>>>>
>>>> So, when an error occurs, can the Collector/Relay detect it?
>>>> Can the Collector/Relay recover synch?  If not, what does the
>>>> Collector/Relay do?
>>>>
>>>> There is very little redundancy in the definition of
>> frame length,
>>>> and syslog messages have very little structure to help the
>>>> application, so I think that this is an issue we should address.
>>>>
>>>> Tom Petch
>>>>
>>>> ----- Original Message -----
>>>> From: "David B Harrington" <[email-masked]>
>>>> To: <[email-masked]>
>>>> Sent: Tuesday, May 09, 2006 4:26 PM
>>>> Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt
>>>>
>>>>
>>>> Hi,
>>>>
>>>> A new revision of the syslog/TLS draft is available.
>>>>
>>>
>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01
>>>> .txt
>>>>
>>>> We need reviewers.
>>>> Can we get
>>>> 1) a person to check the grammar?
>>>> 2) a person to check the syslog technical parts?
>>>> 3) a person to check compatibility with the other WG documents?
>>>> 4) a person to check the TLS technical parts?
>>>>
>>>> We also need general reviews of the document by multiple people.
>>>>
>>>> Thanks,
>>>> David Harrington
>>>> co-chair, Syslog WG
>>>> [email-masked]
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>
>
>
> _______________________________________________
> 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: "Rainer Gerhards" <[email-masked]>
Date: Fri, 4 Aug 2006 16:16:36 +0200

Although I was a big advocate of byte-counting, I now prefer *just*
octet stuffing (LF) for the sake of compatibility with existing
technology.
Rainer 

> From: Chris Lonvick [mailto:[email-masked]] 
> Sent: Friday, August 04, 2006 8:14 AM
> To: Miao Fuyou
> Cc: Rainer Gerhards; 'Tom Petch'; [email-masked]
> Subject: RE: [Syslog] delineated datagrams
> 
> Hi,
>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 4 Aug 2006 13:59:15 -0400

Hi,

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:

SNMPv1/v2c/v3 uses octet-counting within its BER encoded messages.
For SNMP over TCP (RFC3430):
   It is possible that the underlying TCP implementation delivers byte
   sequences that do not align with SNMP message boundaries.  A
   receiving SNMP engine MUST therefore use the length field in the
   BER-encoded SNMP message to separate multiple requests sent over a
   single TCP connection (framing).  An SNMP engine which looses
framing
   (for example due to ASN.1 parse errors) SHOULD close the TCP
   connection. 

SNMP over SSH (ISMS) does not specify how to delineate datagrams,
beyond the BER octet-counting.
(As editor of the SNMP/SSH draft, I will probably copy the text from
RFC3430.)

IPFIX uses octet-counting. See
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-22.txt
section 3.1.

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.
There is ongoing discussion about the framing in the netconf
notification protocol, and the possibility of interleaving
notifications and request/responses within a session or channel. 

David Harrington
[email-masked] 
[email-masked]
[email-masked] 

> Sent: Friday, August 04, 2006 10:14 AM
> To: Miao Fuyou
> Cc: [email-masked]; 'Tom Petch'

---

From: Balazs Scheidler <[email-masked]>
Date: Sun, 06 Aug 2006 13:20:38 +0200

> notifications and request/responses within a session or channel. 

I see a significant difference between syslog and and SNMP, SNMP is
binary and has an internal structure with no appearent record
terminator. 

IPFIX is again different to syslog, it has a well defined binary
structure, adding a "byte counter" is a natural extension of the
protocol.

Netconf as I see from your description started out with a stream based
transport from the first place (and by browsing the RFC quickly)

In this sence Netconf has the most similarities to syslog, it has a
text-based internal structure (XML) and no byte-counter based framing,
the closing XML tag finishes the transaction.

Syslog also has a text based internal structure (one syslog entry),
terminated via NL. Adding a byte counter feels somewhat alien.

I agreed with Rainer about byte-counters when he proposed that, I did it
for the sake of moving forward.

Dropping the byte counter idea and adding simple extensions to the
message format (trying to stay compatible as much as possible) could buy
us very easy migration to the new protocol. In fact this would mean that
currently deployed existing syslog/tls implementations would be
compliant.

I read through the BEEP based syslog protocols and I liked some of the
features it'd provide (see the mailing list archives), however I don't
like that syslog/COOKED is not simply a syslog transport, but a format
spec as well. After specifying syslog-transport-tls we might continue
working on a BEEP based transport but strictly adhering to the current
syslog message model (e.g. skipping the XML message representation which
has no benefits over SD-IDs but is a lot more verbose).

-- 
Bazsi

---

From: "John Calcote" <[email-masked]>
Date: Tue, 08 Aug 2006 13:44:05 -0600

Chris,

While I agree with you in principle that both forms of delineation are
nice to have for interop, I _wish_ we could get rid of LF - that so
limits the sort of data that can be sent in the message. My two
cents...

John

>>> Chris Lonvick <[email-masked]> 8/4/2006 8:13 AM >>>
Hi,

I'd like to get this resolved and put into the next version of the
draft.

I think that I've seen notes from Rainer, Tom Petch, and Andrew Ross 
saying that we should only use a special character for both simplicity
of 
design and for interoperability with current syslog/tls
implementations.

Thanks,
Chris

---

From: Balazs Scheidler <[email-masked]>
Date: Wed, 09 Aug 2006 09:46:50 +0200

> limits the sort of data that can be sent in the message. My two

The message you send are _already_ limited as most syslog daemons
replace "\n" character with something else as it would clobber the
message file when it is written to disk. 

In fact leaving the CR LF characters in the message could be a security
risk as that way messages can be "hidden", for instance if a daemon
writes the following message:

This is a foo message, bar=<data supplied by external entity>

Then the value for "bar" might contain CR, putting the cursor to the
beginning of the line on a usual VT100 compatible terminal, and the rest
of can pose as a regular log message, overwriting the previous one on
the screen.

Of course this can be worked around by using some form of escaping while
data is written to files, but again the LF character does not remain
intact.

syslog-ng for instance replaces CR and LF characters in the message with
a space as it comes in. I rarely heard any complaints about this
behaviour. And another fact is syslog/RAW also uses LF line terminators
when multiple messages are delivered in a single BEEP frame.

-- 
Bazsi

---

From: "John Calcote" <[email-masked]>
Date: Wed, 09 Aug 2006 13:06:44 -0600

Bazsi,

Thanks. You're right of course. I've been considering using a
compressed form of XML for our messages anyway because I don't like the
chatty nature of XML in a logging protocol. One compression technique is
as simple as removing all of the \r\n\t and space characters, and then
removing the closing tag names (eg., </done> becomes </>) as parsers
don't need the tag name in the close tag anyway. This alone would solve
a few problems.

John

>>> Balazs Scheidler <[email-masked]> 8/9/2006 1:46 AM >>>

In fact leaving the CR LF characters in the message could be a
security
risk as that way messages can be "hidden", for instance if a daemon
writes the following message:

Then the value for "bar" might contain CR, putting the cursor to the
beginning of the line on a usual VT100 compatible terminal, and the
rest
of can pose as a regular log message, overwriting the previous one on
the screen.

Of course this can be worked around by using some form of escaping
while
data is written to files, but again the LF character does not remain
intact.

syslog-ng for instance replaces CR and LF characters in the message
with
a space as it comes in. I rarely heard any complaints about this
behaviour. And another fact is syslog/RAW also uses LF line
terminators
when multiple messages are delivered in a single BEEP frame.

-- 
Bazsi

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 10 Aug 2006 05:29:07 +0200

Bazsi, all,

I am not really able to follow the thread, but let me put in an
important thought.

We *must* allow LF inside the message. If we do not do that, it would
cause problems with -protocol. This issue has been discussed at length,
and there are good reasons for allowing it. So while I vote to use LF
for record delineation, I also say that this means LF MUST be escaped if
present in the actual message (transfer encoding). After being decoded,
LF may be present in MSG.

Maybe this already has been said ;)

Rainer 

> From: Balazs Scheidler [mailto:[email-masked]] 
> Sent: Wednesday, August 09, 2006 1:47 AM
> To: John Calcote

---

From: Balazs Scheidler <[email-masked]>
Date: Thu, 10 Aug 2006 10:30:33 +0200

> Maybe this already has been said ;)

This makes sense. What about other control characters?

-- 
Bazsi

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 11 Aug 2006 06:21:50 +0200

> This makes sense. What about other control characters?

We need to differentiate between on-the-wire format and storage format.
On-the-wire, I would escape only LF and the escape character. In
storage, I would escape any control character (which can be quite tricky
with Unicode). Our current scope (and IETF scope) is on-the-wire. So I
propose not to mangle any more characters than absolutely necessary.

Rainer

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 14 Aug 2006 07:20:21 -0700 (PDT)

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?

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? 
Will that always have to be escaped by the sender and reversed by the 
receiver?

Thanks,
Chris

On Mon, 14 Aug 2006, Tom Petch wrote:

> From: "David Harrington" <[email-masked]>
> To: "'Chris Lonvick'" <[email-masked]>; "'Miao Fuyou'" <[email-masked]>
> Cc: <[email-masked]>; "'Tom Petch'" <[email-masked]>
> Sent: Friday, August 04, 2006 7:59 PM
> <snip>
> 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
>> [email-masked]
>> [email-masked]
>> [email-masked]
>>
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 14 Aug 2006 16:31:29 +0200

<inline> 

> Sent: Monday, August 14, 2006 8:20 AM
> To: Tom Petch
> Cc: [email-masked]

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

> people start putting binary information into the syslog 

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 

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.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 14 Aug 2006 18:31:15 -0400

Hi Tom,

You're right; I didn't go far enough. I was looking for a framing
defined by the netconf protocol, not the separator of messages within
a transport. Unfortunately, Netconf uses a number of
transport-dependent schemes within the multiple transports it
supports, including both octet-counting approaches and terminating
character approaches. Sigh.

The "]]>]]>" sequence only works in the SSH transport mapping, not the
BEEP or SOAP mappings. So much for trying to find consistency.

Note that Netconf is considering a design that allows multiple syslog
messages to be sent in a netconf notification session. If we used
"]]>]]>" as a syslog message delimiter, we would prevent netconf from
transporting multiple syslog messages, since netconf can only
transport valid XML, and the "]]>]]>" in a syslog message would
indicate the end of an <rpc-reply>, causing netconf to lose
synchronization? See the Montreal Netconf Interim minutes currently
available on the netconf mailing list for more details.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> Sent: Monday, August 14, 2006 6:36 AM
> To: David Harrington; 'Chris Lonvick'; 'Miao Fuyou'
> Cc: [email-masked]