Subject: [Syslog] RE: syslog/tls - how to abort because of inconsistent versions

From: Miao Fuyou <[email-masked]>
Date: Mon, 23 Oct 2006 11:52:41 +0800

Hi, 

There are several possible options to solve this issue:

1, Using a TLS alert to signal the inconsistent versions as the current
draft does. The drawback is it violate the layer, using TLS alert to notify
an application event seems ugly. 

2, Saving the data (TLS app-data, not syslog message, different to UDP
transport) no matter what the version is. This may mean a receiver should be
able to save a stream without any knowledge about the structure of the
stream. The data can not be stored in the same file/database to the one for
syslog messages, because it has no way to delimit frames.

3, Change the simplex of syslog, add an application level notification from
receiver to sender, this may increase the effort of implementation greatly,

4, Do nothing, the sender may keep connecting the receiver. But, we can
recommend in that specification like "if connections are closed just after
successful TLS handshake for three times with same transport mapping
version, the sender SHOULD not connect the receiver again with the same
transport version".  Does it work?

My preference is 4 > 1 > 2 > 3. 

Miao

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]] 
> Sent: Saturday, October 21, 2006 2:55 AM
> To: Miao Fuyou
> Cc: 'David Harrington'; [email-masked]
> Subject: RE: syslog/tls - how to abort because of 
> inconsistent versions
> 
> Hi Miao,
> 
> We need this issue resolved in the WG.  Please bring up the 
> discussion on the list with a proposal.  I suggest that we 
> not use TLS to signal a failure in the upper level.
> 
> Thanks,
> Chris
> 
> On Thu, 19 Oct 2006, Miao Fuyou wrote:
> 
> > Hi, Eric,
> >
> > One clarification to version #: syslog/tls version is the one for 
> > "syslog/tls transport mapping", but syslog version # is the one for 
> > syslog-protocol, they are diffirent numbers.
> >
> > When a receiver gets a message with a **syslog version number** it 
> > does not understand, it could save the message in local storage or 
> > forward to other receiver because it know exact the boundary of the 
> > message (actually a receiver does not have to understand 
> the version 
> > of syslog protocol in most cases, because the only task for 
> receiver is to store or forward).
> >
> > But, this may not apply to syslog/tls transport mapping. Diffirent 
> > **syslog/tls version number** may mean diffirent APP-DATA format. A 
> > receiver with a diffrent version may not be able to parse 
> the stream 
> > or delimit syslog messages, the only thing that it can do 
> is to save 
> > the tls stream in local storage if it is linient. But, 
> saving stream 
> > seems ugly, maybe more ugly than making tls alert to serve 
> > application:-)
> >
> > Thanks!
> > Miao
> >
> >> -----Original Message-----
> >> From: EKR [mailto:[email-masked]]
> >> Sent: Thursday, October 19, 2006 10:02 AM
> >> To: Miao Fuyou
> >> Cc: 'David Harrington'; [email-masked]; 'Chris Lonvick'
> >> Subject: Re: syslog/tls - how to abort because of inconsistent 
> >> versions
> >>
> >> Miao Fuyou <[email-masked]> wrote:
> >>> Hi, Eric,
> >>>
> >>> The primary reason to use a TLS level notification to
> >> notify an event
> >>> for application level is to keep Syslog still simplex, 
> but it seem 
> >>> violative to clear layership. An application notification
> >> will change
> >>> that simplex of syslog, which is alien to syslog. The wg 
> is in the 
> >>> dilemma to process this issue.
> >>>
> >>> Your sugestion?
> >>
> >> Well, I see that draft-ietf-syslog-protocol-17.txt 
> contains a version 
> >> #. What do you do if that is something you don't understand?
> >>
> >> -Ekr
> >>
> >
> 

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

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 26 Oct 2006 11:17:44 -0700 (PDT)

Hi Miao and All,

We had a discussion with Eric Rescorla (as a technical expert) about 
the use of a TLS alert to signal a version exchange problem.  He 
recommended that TLS alerts are to be used by TLS and should not be used 
for signalling of upper-layer events.  From that, we should not be 
considering #1 below.

For #3, we are not going to examine the simplex nature of syslog for each 
new transport.  That work has been done in RFC 3195.

I recommend that we go with #4.  This seems to be no different from 
current implementations of syslog/udp.  In this, it is always wise to 
check that messages are being received from a syslog sender since the 
sender gets no indication that the message has been received from the 
server.  It would be appropriate for the document to note this in the 
security considerations section and perhaps to even point out that #2 is a 
viable step.

I would like to close this out very soon.  Please comment back to the list 
if you have an opinion on this.

Thanks,
Chris