I don't see it; my reading is that application data as defined in this I-D is a complete syslog message which may span TLS records, may be packed many into one TLS record. TLS allows an empty record, ie one with no application data as defined by TLS. So it would be valid to have TLS record one - syslog message 1 fragment 1 TLS record two - no TLS application data TLS record three - syslog message 1 fragment 2, syslog message 2
The only thing that I take this ABNF as requiring is that at least one syslog message be sent in a TLS session:-) Tom Petch ----- Original Message ----- From: "Rainer Gerhards" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, May 07, 2008 2:04 PM Subject: [Syslog] -transport-tls, section 4.3 > 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 _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
