Subject: [Syslog] -transport-tls, section 4.3

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 7 May 2008 14:04:01 +0200

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-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "tom.petch" <[email-masked]>
Date: Thu, 8 May 2008 17:35:50 +0200

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 9 May 2008 10:24:41 +0200

Hi Tom,

> TLS record three - syslog message 1 fragment 2, syslog message 2

That was one of my interpretations and I am fine with that.

> 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

---

From: "tom.petch" <[email-masked]>
Date: Fri, 9 May 2008 13:52:00 +0200

---- Original Message -----
From: "Rainer Gerhards" <[email-masked]>
To: "tom.petch" <[email-masked]>; <[email-masked]>
Sent: Friday, May 09, 2008 10:24 AM
Subject: RE: [Syslog] application data was -transport-tls, section 4.3

Hi Tom,

<tp>

Well if two of us can come up with this interpretation, which does seem rather
silly, then I think that the text should be changed as you suggested to

Tom Petch
<tp>

Rainer