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:clonvick at cisco.com]
Sent: Saturday, October 21, 2006 2:55 AM
To: Miao Fuyou
Cc: 'David Harrington'; myz at huawei.com
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:ekr at networkresonance.com]
Sent: Thursday, October 19, 2006 10:02 AM
To: Miao Fuyou
Cc: 'David Harrington'; myz at huawei.com; 'Chris Lonvick'
Subject: Re: syslog/tls - how to abort because of inconsistent
versions
Miao Fuyou <miaofy at huawei.com> 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
Syslog at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
