Subject: [Syslog] Framing in syslog-transport-tls

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 13 Dec 2006 09:33:38 +0100

Miao, WG,

I have partially implemented syslog-transport-tls in two different
programs (MonitorWare Agent and rsyslog). My focus was the framing, not
tls itself (I needed the new framing for some other functionality, but
that is a separate story). I would like to share my experience during
that implementation. This is *not* necessarily a request for change. I
just though that might also come up during IETF last call, so I think
the information is useful.

FRAME-LEN is a variable length field. It specifies the length of the
frame including the length of FRAME-LEN itself. This is no real problem
for the receiver. On the sender side, however, it is a bit tricky. I
need to obtain the length of the ASCII-encoded field including the
(potentially changing) size of itself. Let's look at a sample.

We have a message with 996 octets. Now I obtain the information that I
need 4 octets to encode this ("996 "). I need to add that to the total
message length, bringing me up to 1000 octets. Now, I need to re-check
my buffer requirements. I now learn that I need a 5 octect encoding.
This I need to add to the previous length of the message (996),
resulting in a total frame length of 1001 octets.

If we would just count the MSG part of the frame, there would be no such
ambiguity, because I would set FRAME-LEN to whatever size I know the MSG
part has. It would be 996 in this case. However, that would mean we have
two different framing mechanisms inside the frame - octet stuffing (the
SP) after the count and then octet counting for the rest of the message
(I think http uses such a mechanism, but have not verified).

On the other hand, I can easily implement the current specification with
few lines of code. Here is a C sample of the code I actually use in
rsyslog:

iLenBuf = snprintf(szLenBuf, sizeof(szLenBuf)/sizeof(char), "%d ", len);
iLenBuf = snprintf(szLenBuf, sizeof(szLenBuf)/sizeof(char), "%d ", len +
iLenBuf);

Where len is the length of SYSLOG-MSG and iLenBuf the total frame
length. For context, see

http://rsyslog.cvs.sourceforge.net/rsyslog/rsyslog/syslogd.c?revision=1.
159&view=markup

and scroll down to line 1766.

Initially, I was of the view that it would be advisable to think about
changing -transport-tls so that the octet count is just the length of
SYSLOG-MSG. After some thinking, I now believe that it is fine as it
currently is specified. I suggest a sentence "warning to implementors"
to point to the potential mis-implementation. On the other hand, a
receiver must rely on the octet-stuffing in any case. Because it needs
to find the SP in order to find the end of the octet count. That would
be an argument to contain only the size of SYSLOG-MSG in the counter.

Given the fact that -transport-tls is already submitted to the IESG AND
there is no real problem with the current specification, I propose not
to change it (except for adding a warning as outlined above).

Sorry for the late catch, but these things seem to only appear when you
actually implement... 

I would appreciate comments on the issue.

Rainer

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Dec 2006 09:44:43 +0100

> (potentially changing) size of itself. Let's look at a sample.

[...]
 
> (I think http uses such a mechanism, but have not verified).

[...]

> be an argument to contain only the size of SYSLOG-MSG in the counter.

Unfortunately, I did not catch this when I reviewed this document. I
believe not including the framing characters in the length value makes
a lot of sense; in fact, FRAME-LEN should perhaps have been MSG-LEN to
start with. Taking any process issues aside, I would be in favor of
such a change.

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: Miao Fuyou <[email-masked]>
Date: Wed, 13 Dec 2006 17:54:28 +0800

Hi,

My co-workers in university also encountered this issue when implementing
syslog-tls, and used a mechanism similiar to the one of Rainer to overcome
it. As I am aware of, currently there are two syslog framing implementation
and both the implementaters considered this boundary condition. So, my
perception is careful implementater would have no problem, and a note for
reminding is enough.

Regards,
Miao

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Wednesday, December 13, 2006 4:34 PM
> To: [email-masked]
> Subject: [Syslog] Framing in syslog-transport-tls
> 
> Miao, WG,
> 
> I have partially implemented syslog-transport-tls in two 
> different programs (MonitorWare Agent and rsyslog). My focus 
> was the framing, not tls itself (I needed the new framing for 
> some other functionality, but that is a separate story). I 
> would like to share my experience during that implementation. 
> This is *not* necessarily a request for change. I just though 
> that might also come up during IETF last call, so I think the 
> information is useful.
> 
> FRAME-LEN is a variable length field. It specifies the length 
> of the frame including the length of FRAME-LEN itself. This 
> is no real problem for the receiver. On the sender side, 
> however, it is a bit tricky. I need to obtain the length of 
> the ASCII-encoded field including the (potentially changing) 
> size of itself. Let's look at a sample.
> 
> We have a message with 996 octets. Now I obtain the 
> information that I need 4 octets to encode this ("996 "). I 
> need to add that to the total message length, bringing me up 
> to 1000 octets. Now, I need to re-check my buffer 
> requirements. I now learn that I need a 5 octect encoding.
> This I need to add to the previous length of the message 
> (996), resulting in a total frame length of 1001 octets.
> 
> If we would just count the MSG part of the frame, there would 
> be no such ambiguity, because I would set FRAME-LEN to 
> whatever size I know the MSG part has. It would be 996 in 
> this case. However, that would mean we have two different 
> framing mechanisms inside the frame - octet stuffing (the
> SP) after the count and then octet counting for the rest of 
> the message (I think http uses such a mechanism, but have not 
> verified).
> 
> On the other hand, I can easily implement the current 
> specification with few lines of code. Here is a C sample of 
> the code I actually use in
> rsyslog:
> 
> iLenBuf = snprintf(szLenBuf, sizeof(szLenBuf)/sizeof(char), 
> "%d ", len); iLenBuf = snprintf(szLenBuf, 
> sizeof(szLenBuf)/sizeof(char), "%d ", len + iLenBuf);
> 
> Where len is the length of SYSLOG-MSG and iLenBuf the total 
> frame length. For context, see
> 
> Initially, I was of the view that it would be advisable to 
> think about changing -transport-tls so that the octet count 
> is just the length of SYSLOG-MSG. After some thinking, I now 
> believe that it is fine as it currently is specified. I 
> suggest a sentence "warning to implementors"
> to point to the potential mis-implementation. On the other 
> hand, a receiver must rely on the octet-stuffing in any case. 
> Because it needs to find the SP in order to find the end of 
> the octet count. That would be an argument to contain only 
> the size of SYSLOG-MSG in the counter.
> 
> Given the fact that -transport-tls is already submitted to 
> the IESG AND there is no real problem with the current 
> specification, I propose not to change it (except for adding 
> a warning as outlined above).
> 
> Sorry for the late catch, but these things seem to only 
> appear when you actually implement... 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Dec 2006 11:44:56 +0100

> perception is careful implementater would have no problem, and a note for

The fact that two implementars did already run into this is a good
indication that perhaps the format should be changed to what
implementors expect and find easier.

We seem to have some evidence that the current format makes things
more complex to get implemented than it needs to be and I have not
seen yet a technical argument in favor of the current format.

/js

---

From: "John Calcote" <[email-masked]>
Date: Wed, 13 Dec 2006 17:41:39 -0700

Hi all,

I know I'm not very active on this list, but I do monitor all of the traffic. 

I'm totally in favor of the change. It makes sense, and the last thing we need is to publish a mistake at the last minute because we're not willing to make a small change so late in the game. Let's do it right the first time.

--john

>>> Juergen Schoenwaelder <[email-masked]> 12/13/06 3:44 AM >>>

/js