Subject: RE: Framing in syslog messages - RE: [Syslog]Preliminarysyslog-transport-tls document - issue 3

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 17 Mar 2006 17:43:13 +0100

Chris,

while I think this sounds very tempting, I also think there are some
inherent problems with it:

#1 you do not know *where* (more precise: after how many octets) that
element is present
In extreme cases, it might only be valid after more then 64k

#2 it could become truncated
Structured data is not guarded against truncation.

#3 architectural concerns
I do not think it is appropriate for a lower layer to obtain information
from an upper-layer field. That would require the lower layer to parse
the upper layer field, which it conceptionally should not even be aware
of.

All in all, I am in strong favour of a dedicated tls-transport only
header for the octet count.

Rainer

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]] 
> Sent: Friday, March 17, 2006 5:38 PM
> To: Rainer Gerhards
> Cc: Balazs Scheidler; [email-masked]
> Subject: RE: Framing in syslog messages - RE: 
> [Syslog]Preliminarysyslog-transport-tls document - issue 3
> 
> Hi,
> 
> Why wouldn't this information be contained in a structured 
> data element 
> within each frame?
> 
> Thanks,
> Chris
> 
> On Fri, 17 Mar 2006, Rainer Gerhards wrote:
> 
> > Bazsi,
> >
> >> Agreed, let's go for octet-counting. How would that look like? Two
> >> octets before every message? That would limit message size 
> to 64k, is
> >> that sufficient? (I personally say it is, messages larger
> >> than 64k would
> >> potentially mean that they cannot be held in memory)
> >
> > there is the good, old size issue resurfacing. I'd say 
> let's not get on
> > that slippery slope again. The compromise so far is - you 
> can use any
> > size as long as the receiver permits it. I'd say we should 
> stick with
> > it. That means we should probably also stick with the 
> ASCII-only Space
> > delimited header. So the transport header would be 
> something like this
> >
> > TLS-HEAD = OCTCOUNT SP
> > OCTCOUNT = 1* DIGIT
> >
> > Two practical samples would be
> >
> > "140 <rest of syslog message"
> >
> > or
> >
> > "256000 <rest of syslog message"
> >
> > The later is an intentionally horrible long message. But again, I'd
> > leave this door open.
> > If the receiver thinks 256000 octets is too large, it can 
> read the first
> > 64k and drop the rest.
> > Rainer
> >
> > _______________________________________________
> > Syslog mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/syslog
> >
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Balazs Scheidler <[email-masked]>
Date: Sat, 18 Mar 2006 23:21:45 +0100

> header for the octet count.

Absolutely agree and I also like the text based format.

-- 
Bazsi

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 19 Mar 2006 16:35:42 -0800 (PST)

Hi All,

This sounds good and I believe that we have had a reasonable discussion of 
all of the options.  Unless there are strong objections, I'll ask Fuyou 
and Yuzhi to incorporate this into their document.

Thanks,
Chris

---

From: Miao Fuyou <[email-masked]>
Date: Mon, 20 Mar 2006 10:34:07 +0800

I will update the document based on mailing list discussion if there is no
strong objection. 

Let's also disscuss other issues:

   [Issue 0]: Do we need a Syslog TCP port for TLS transport?  The
   security community had debates about whether using special ports is
   desirable.

> Sent: Monday, March 20, 2006 8:36 AM
> To: [email-masked]
> Subject: RE: Framing in syslog messages - 
> RE:[Syslog]Preliminarysyslog-transport-tls document - issue 3
> 
> 
> Hi All,
>

---

From: Miao Fuyou <[email-masked]>
Date: Mon, 20 Mar 2006 10:37:44 +0800

[Issue 1]: Is it possible to use "generic certificate for different
   host?  The generic certificate is for specific application type.

   [Issue 2]: What to bind to a certificate?  Hostname, Syslog APP-
   NAME(generic certificate)?  APP-NAME binding makes authentication/
   access control happens both in TLS handshake and Syslog message
   processing, is efficiency a problem?

---

From: Miao Fuyou <[email-masked]>
Date: Mon, 20 Mar 2006 10:37:30 +0800

[Issue 4]: Shall we mandate the sender MUST be authenticated?  Most
   of the Syslogd accepts messages only from configured address.

---

From: Miao Fuyou <[email-masked]>
Date: Mon, 20 Mar 2006 12:28:23 +0800

Section 1 of RFC2817(Upgrading to TLS Within HTTP/1.1) says that special
port is not preferable for security. Now the situation is that there is not
an IANA allocated TCP port for Syslog. So I think it is reasonable to
request a special port for syslog-tls. The disavantage is that we will need
another iana allocated port if TCP transport is standardized in the future.

Https is allocated both 443 for tls and 80 for TCP.

> From: Miao Fuyou [mailto:[email-masked]] 
> Sent: Monday, March 20, 2006 10:34 AM
> To: 'Chris Lonvick'; [email-masked]
> Subject: [Syslog] Other syslog-tls Issues---Issue0
> 
> 
> 
> I will update the document based on mailing list discussion 
> if there is no strong objection. 
> 
> [email-masked] https://www1.ietf.org/mailman/listinfo/syslog
>

---

From: Balazs Scheidler <[email-masked]>
Date: Tue, 21 Mar 2006 10:28:27 +0100

>    of the Syslogd accepts messages only from configured address.

I think this should be optional (probably a SHOULD clause) it is up to
the administrator to decide, with a paragraph on the security
implications.

-- 
Bazsi