Hi,
On Tue, 24 Apr 2007, Eliot Lear wrote:
Miao,
TLS is still duplex even if syslog is simplex. In the same time,
authenticaiton happens in the handshaking phase of TLS when syslog message
transfering does not begin . So, simplex or duplex does not matter for
authentication.
I personally haven't liked those terms since 300 baud modems and 3270s went
out of style ;-)
I had persuaded myself that syslog sender is always hosted on automated
application/appliance, such as web daemon or printer, this make it
impossible for an user to check interactively whether umatched hostname/IP
address is acceptable. However, I am suspecting the perception is wrong.
It
is possible to host syslog sender on a interactive application, such as
database administration tool.
This is not as simple a decision as may first appear. On the one hand, while
you can come up with examples such as the above, and they really do exist
(another good one is when you have some sort of Windows Watcher(*) that you
want to log back to a central source), the two problems with reporting to the
user are (a) the cases where there is no user and (b) the fact that
operational experience has shown that the user really doesn't know what to do
when there is a problem.
On the other hand, we have another little problem in this specific case.
What do we normally say when something goes wrong in one of our protocols?
"Log an error." Here that poses a little bit of a problem ;-) I would
suggest text along the lines of the following:
The application developer must take some care to consider the case
when, for whatever reason, there is a problem with authenticating
the other end of the connection. In the case of a receiving relay
or a receiver, the connection SHOULD be closed and an error logged,
indicating the problem. In the case of a syslog sender or a
transmitting relay, the situation requires more care. Here the
application SHOULD also close the connection and also use whatever
other means are available to it to inform the administrator of the
problem. This may include producing a message on a console,
returning an error to the user, or writing a file to disk, if possible.
There is also a matter of what an application is supposed to do when logging
fails. Some applications should proceed uninterrupted. Others may need to
block. I don't know whether text is appropriate. It's not part of the
protocol, but it does fall under common modes of failure. The reason this
would be an issue with TLS (or BEEP for that matter) and not with UDP is that
one doesn't block with UDP.
I think Eliot is on the right track. However, I wouldn't differentiate
between the actions that a sender or receiver is to take when
authentication fails - both cases should have a recommendation that the
device log the failure _and_ attempt to inform the administrator of the
problem. This might be pop-ups to the unsuspecting user who won't know
what to do about it, it might be messages printed on the console, it might
be a blinky light on the printer, etc. (Most networked printers that I'm
seeing these days have nice displays that are starting to give informative
messages.)
Perhaps this text:
The application developer must take some care to consider the case
when, for whatever reason, there is a problem with authenticating
the other end of the connection. The connection SHOULD be closed and
an error logged indicating the problem. Since this problem will
prevent log messages from being transmitted, each device having this
problem should use whatever means are available to inform the
administrator of the problem. This may include producing a message on a
console, returning an error to a user (if there is one), or writing a
file to disk, if possible.
In addition, you have another problem in the text:
If the client is configured with IP address
of the server, the hostname should be got first through a trusted
mechanism such as a preconfigured hosts table or DNSSEC [8].
It is often the case that a reverse map does not match a forward map. For
example, often times a service provider might allocate IP address space and
route that space to a customer but not delegate the reverse mapping. This is
particularly true in consumer environments. I would suggest that if the
client is configured with an IP address, that it is what should be present in
the certificate, as the name has no meaning at all to the client.
I think that's an operational issue that we're not going to deal with.
We're talking about a domain of administration here. We're not going to
be able to write enough text into this document to cover the case where
the administrators cannot line up dNSName with an IP address within their
own purview.
Thanks,
Chris
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
