... > > 5, Protocol Elements > > 5.1 Initiation > > The Sender should initiate a connection to the Receiver on the > > appropriate port and then send the TLS ClientHello to begin the TLS > > handshake. When the TLS handshake has finished the Sender may then > > initiate the first SYSLOG message. > > Note: We need to define how syslog interpret the authentication > > certificates exchanged by handshake protocol.
Very good point. I think we should specify that Common Name (CN) field of the server certificate must be matched to what's configured on the client. Any other ideas? > > Note: We need to discuss what authentication we need: client > > authenticated to server, server authenticated to client, or both > > (mutual authentication) I think both options should be supported. If we support client authentication, there are two possibilities with certificates: generic vs. unique. With a generic cert I can have all clients have the same cert. In this case, I would authenticate that they all are clients from my organization, for example, but won't ascertain the client identity. With unique certificates, the certificate has to include the identity of the client which must be logged/used by the receiver - otherwise you won't know which client you received the message from. For unique client certificates, I think we should state that the identity of the client must be represented in the certificate CN field, but we can leave the format and content undefined. > 5.3 Closure > Sender MUST send a closure alert before closing the connection. Sender > which are unprepared to receive any more data MAY choose not to wait > for the Receiver 's closure alert and simply close the connection, > thus generating an incomplete close on the Receiver side. Receiver > MUST attempt to initiate an exchange of closure alerts with the Sender before > closing the connection. > Receiver MAY close the connection after sending the closure alert, > thus generating an incomplete close on the Sender side. So, the sender can keep the persistent connection for as long as it wants unless receiver closes it. I think we need to recommend that client SHOULD close the connection if it is not using it. If server always initiates connection closing, can it end up with a bunch of sockets in the TIME_WAIT state, which may hinder scalability? Should we specify client behavior in case of connection reset by the server? It probably SHOULD retry the un-acknowledged message. Should we recommend incremental back-off? Do we need an RPC style message delivery as well, where the server can acknowledge messages after they have been processed by application layer as opposed to ack'ed by the TCP stack? Thanks, Anton. _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
