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

From: "t.petch" <[email-masked]>
Date: Mon, 1 Nov 2010 18:01:49 +0100

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.

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

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.

Tom Petch
----- Original Message -----
From: "Chris Lonvick" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 01, 2010 9:16 PM
Subject: [Syslog] New Version Notification for
draft-gerhards-syslog-plain-tcp-05 (fwd)

> Hi Folks,
>
> While this is a non-WG item, there are some people interested.  I've
> updated the syslog/tcp draft and I'll invite reviews and comments.
>
> Thanks,
> Chris
>
> ---------- Forwarded message ----------
> Date: Thu, 30 Sep 2010 09:04:15 -0700 (PDT)
> From: IETF I-D Submission Tool <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-gerhards-syslog-plain-tcp-05
>
>
> A new version of I-D, draft-gerhards-syslog-plain-tcp-05.txt has been
successfully submitted by Chris Lonvick and posted to the IETF repository.
>
> Filename: draft-gerhards-syslog-plain-tcp
> Revision: 05
> Title: Transmission of Syslog Messages over TCP
> Creation_date: 2010-09-30
> WG ID: Independent Submission
> Number_of_pages: 14
>
> Abstract:
> There have been many implementations and deployments of legacy syslog
> over TCP for many years.  That protocol has evolved without being
> standardized and has proven to be quite interoperable in practice.
>
> The aim of this specification is to document three things: how to
> transmit standardized syslog over TCP, how TCP has been used as a
> transport for legacy syslog, and how to correlate these usages.
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/syslog

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 16 Nov 2010 11:46:43 -0800 (PST)

Hi Tom,

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

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