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
On Mon, 23 Oct 2006, Miao Fuyou wrote:
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 PROTECTED]
Sent: Saturday, October 21, 2006 2:55 AM
To: Miao Fuyou
Cc: 'David Harrington'; [EMAIL PROTECTED]
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 PROTECTED]
Sent: Thursday, October 19, 2006 10:02 AM
To: Miao Fuyou
Cc: 'David Harrington'; [EMAIL PROTECTED]; 'Chris Lonvick'
Subject: Re: syslog/tls - how to abort because of inconsistent
versions
Miao Fuyou <[EMAIL PROTECTED]> 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 protected]
https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
