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.
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.
Eliot
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
