Hello, I have looked for an answer in both Rainer's Blog and the rsyslog doc (on rsyslog.com).
I am using rsyslog in a cloud environment (namely Amazon EC2). Since I have several web servers and need centralized aggregation for both easier management and reliable gross stats, I forward the syslog messages toward a central instance. Since the cloud environment should be considered as hostile (potential MITM attacks and so on) and the system log are critical data, SSL/TLS appears to be the best solution. However It appears that TLS in rsyslog is available only for PTCP transport and not RELP, at lest if I believe what's written on http://www.rsyslog.com/doc/rsyslog_tls.html . Moreover, although PTCP has increased reliability ("decreased unreliability"?), as mentioned in various Rainer's blogposts, it is still far to be reliable. Although I don't need to be audit-grade reliable, I would still prefer to have reasonable reliability and as far as I understand PTCP is not even close to it. My question is therefore the following : Is there a solution appart from stunnel to have RELP over TLS ? and btw, what about TLS authentication ? It seems that currently we are faced with a trade-off between reliability and security. Since cloud-type architecture will be (in my opinion) more and more used, I guess that could be something very relevant to have in rsyslog. Btw, referring to http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html Rainer speaks of double-acking. Although the overhead and delay involved with double acking are very low, I though re-acking with silent drop would be more efficient : The receiver sends only one ack, if it is lost and the message is repeated by the client (detected by the mean of, e.g., a sequence number) the receiver drop the message (this avoid duplication) and re-send the ACK. This could be improved by sending NACK in case of "hole" in the sequence numbers, triggering instant resending of previously dropped messages. Sequential number collisions could then be addressed with sliding windows. If the message was dropped, it is simply resent by the client (after an ACK timeout or a NACK reception) and if the ACK is lost, the duplicated message does not appear but the ACK is sent again. Imho, the sequence numbers and sliding windows do not yield neither development nor complexity overhead because they still need to be implemented with double-acking, in case of a losed reACK. Well that was just my two cents on this idea. It would be great if someone could keep me posted with respect to the RELP/TLS issue. Regards, Mathieu Lemoine _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
