Hi list, A couple of more things I noticed while implementing:
Section 4.3, it is specified: APPLICATION-DATA = 1*SYSLOG-FRAME Is it actually required to check if there is at least one SYSLOG-FRAME in a TLS record? That places some additional burden onto the receiving application AND (this is the biggie) requires the application to know about TLS records. I have abstracted this knowledge onto a driver level and I think others will most probably work with a similar abstraction. Knowing about the TLS records IMO unnecessarily breaks the abstraction layers. So I would prefer a definition that permits empty TLS records (at least from the syslog POV). APPLICATION-DATA = *SYSLOG-FRAME Having said this, I am not even sure if the ABNF "APPLICATION-DATA" relates to the TLS record. It may be useful to clarify. If it specifies the stream from an upper layer perspective, it even more must be "*", because I don't think we should require that in a syslog session always at least one message is transmitted. There may be valid reason that a session is closed without a message being sent over it. Again, section 4.3: It states " SYSLOG-MSG is defined in syslog [2] protocol." However, it does not state what MUST/SHOULD happen if the SYSLOG-MSG is malformed. Possible options are a) ignore this message, but continue receiving b) process the message with another parser (e.g. according to RFC 3164) c) ignore the message and close the connection I think we should specify at least a SHOULD. I envision this to become a big interoperability issue. Section 5 ... is missing a security consideration. An attacker may use a maliciously large MSG-LEN (S. 4.3) in order to try DoS (hoping the implementation tries to malloc memory based on the frame size). While this should be a sufficiently well-known attack, I think it doesn't hurt to mention it. In general, I wonder if we should specify the situation where a TLS session is closed by the server (for whatever reason) and the client re-instantiates the connection. For example, if a client tries to connect to a server, but the handshake fails for a persistent reason (e.g. invalid client credentials), the client will eventually run into an endless loop trying to connect to that server. This could lead to a close-to-DoS. I wonder if it would be useful to specify some rate-limiting or similar mechanism to prevent that situation. At a minimum, I think it would make sense to mention it, so that implementers and knowledgeable operators are aware of the potential problem. Thanks, Rainer _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
