Re: [Syslog] New Version Notification for draft-gerhards-syslog-plain-tcp-05 (fwd)

[Chris Lonvick <[e-mail]>]

Hi Tom,

On Mon, 1 Nov 2010, t.petch wrote:

> Chris
>
> I had not noticed before but this seems to have changed direction during the
> summer; Informational not Standards Track, and stressing byte-counting more,
> byte-stuffing less.
>
> I do find it less clear.  I think that the Introduction needs more work in the
> light of the changes to the rest of the document. I read
> "This specification includes descriptions of both
>   format options in an attempt to ensure that standardized syslog
>   transport receivers can receive and properly interpret messages sent
>   from legacy syslog senders."
> got to the end of the document and thought 'oh no it does not!' and then
> realised that this is now an Appendix whereas before it was in the main body.
> Of course, if you never knew it was in the body, you might not be as confused as
> I.
>
> But really, the emphasis on standardised and legacy syslog seems misplaced.  The
> carriage over TCP is the same whether the carried is SYSLOG-3164 or SYSLOG-MSG
> so the distinction seems spurious.  And SYSLOG-3164 does not appear in any RFC
> or I-D I can find.
>
> Rather, you have two forms of adaptation to carry a message, and what that
> message is is mostly academic.

I was trying to clean it up so that it would only show that one mechanism 
was available for transporting RFC 5424 syslog messages over TCP, and that 
two mechanisms have been seen for transporting legacy syslog over TCP. 
The one mechanism for RFC 5424 over TCP is "bit counting" and is exactly 
like syslog/tls and syslog/dtls.  The other method of "bit stuffing" has 
been seen in the wild but has problems.

I'll take another look at it and see if I can explain that more clearly.

>
> Separately, I think that more is needed on Security.  It is easier to sabotage
> TCP than it is UDP; spurious FIN, RST etc.

Yeah...  Easier said than done.  A lot of TCP attacks are not documented, 
and there are a lot of them.  I'll see what I can do on that as well.

>
> And I think more is needed on closing the session.  The transport receiver
> detects a format error (well, the transport sender is not going to) sends FIN,
> gets FIN-ACK and ....  the transport sender carries merrily on.  I think that
> there should be a recommendation that the transport sender closes the connection
> and reopens it if it wants to.

Good point.  I'll work on that.

I'll dig through it after the US Thanksgiving holiday.

Thanks,
Chris