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
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
