Subject: RE: [Syslog] delineated datagrams wasdraft-ietf-syslog-transport-tls-01.txt

From: Miao Fuyou <[email-masked]>
Date: Fri, 21 Jul 2006 17:59:34 +0800

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 21 Jul 2006 12:16:28 +0200

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 

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

---

From: Miao Fuyou <[email-masked]>
Date: Mon, 24 Jul 2006 21:32:44 +0800

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

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Friday, July 21, 2006 6:16 PM
> To: Miao Fuyou; Tom Petch; [email-masked]
> 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 
> 
> > 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.
> > 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.
> > 
> robustness in 
> > > the way in which datagrams are delineated in the stream 
> protocol (a 
> > > TCP rather than a TLS issue).
> > > 
> doubtless true 
> > > in some networks, but I would prefer not to
> > rely on it.
> > > 
> > > 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
> > >