Hi Tom, > 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
That was one of my interpretations and I am fine with that. > The only thing that I take this ABNF as requiring is that at least one > syslog > message be sent in a TLS session:-) *This* I find problematic. In an implementation, do I need to keep a counter to prevent me from closing a syslog session without sending a single message over it? And, if so, does that mean I need to send a dummy message before closing just to fullfil this requirement? ;) And how should the server react if a session is torn down without a message being sent? Should it treat this as an error? ;) How much simpler would be an implementation if it is permitted to send 0 or more message inside a session... I know I am looking at a very (very!) unusual case. But it may happen. If the draft stays as is, I'll most probably simple ignore the requirement and hope that always at least a single message is sent. But strictly speaking this is not the right thing to do ;) So why not specify it in the way people will implement it in any case? ;) Rainer > > 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
