Subject: RE: [Syslog] Working Group Last Call: syslog-tls document

From: Miao Fuyou <[email-masked]>
Date: Mon, 04 Sep 2006 17:29:39 +0800

Hi, 

One "major" change to the document is a "version" field for Syslog TLS
transport is added to the frame header. The field is to make port reusing
possible if the transport mapping document is updated in the future. An IANA
paragraph is added accordingly. 

Another change is about frame length bounding, Min-max values(MUST, SHOULD)
are added to the document. 

The two changed was made after discussion between editors and chairs.
Discussion and feedback is welcome!

Thanks!
Miao

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: Wednesday, August 30, 2006 5:48 AM
> To: [email-masked]
> Subject: [Syslog] Working Group Last Call: syslog-tls document
> 
> 
> Hi,
> 
> This message officially starts the Syslog Working Group Last 
> Call for the following document: 
> 
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03
> .txt
> 
> The Working Group Last Call for this document will end September 12.
> 
> To help get these document reviewed throughly, we are seeking 
> volunteers to review the documents for the following special reviews:
> 	1) Spelling and grammar,
> 	2) boilerplates and reference review, 
> 	3) security review
> 
> The chairs want to see a minimum number of content reviews 
> before we submit the documents to the IESG. If you review the 
> document and it looks fine, please post a statement that you 
> have reviewed and found the document acceptable. Obviously, 
> if it does not look acceptable please identify your 
> objections, preferably with suggested text that would make it 
> acceptable.
> 
> Thanks,
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]
> co-chair, Syslog WG 
> 
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 
> 
> _______________________________________________
> 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: Chris Lonvick <[email-masked]>
Date: Mon, 4 Sep 2006 15:49:18 -0700 (PDT)

Hi All,

Please do consider the version field.  If we don't have one, we would have 
to live forever with the decisions we are making now.  Having a version 
number in there would allow a future group to re-decide things (like 
byte-count v. special character) and to just change the version number 
rather than go asking for a new port number - or have a flag day.

Please review the document and send in your thoughts on this.

Thanks,
Chris

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 5 Sep 2006 03:08:38 +0200

I strongly applaude the version number. Let's keep it in. More reviews
if I manage to do so.

Rainer 

> From: Chris Lonvick [mailto:[email-masked]] 
> Sent: Monday, September 04, 2006 6:49 PM
> To: [email-masked]
> Subject: version field in syslog-tls - was: RE: [Syslog] 
> Working Group LastCall: syslog-tls document
> 
> Hi All,
>

---

From: "John Calcote" <[email-masked]>
Date: Mon, 04 Sep 2006 22:48:51 -0600

Here are a few gnits:

1. Section 5.3, para 1, sentence 2, ...multiple TLS Records.

2. Section 5.3, ABNF, It's not necessarily obvious that the numeric
fields are decimal (base 10).

3. Section 5.3.1, para 1, sentence 3, ...there is no upper limit.

4. Section 5.3.1, para 1, sentence 4, ...must be able to process frames
with...2048 octets.

5. Section 5.3.1, para 1, sentence 5, ...be able to receive frames
with...8192 octets.

More later...

John

-----
John Calcote ([email-masked])
Sr. Software Engineeer
Novell, Inc.

>>> "David Harrington" <[email-masked]> 8/29/2006 3:47 PM >>>

Hi,

This message officially starts the Syslog Working Group Last Call for
the following document: 

.txt

The chairs want to see a minimum number of content reviews before we
submit the documents to the IESG. If you review the document and it
looks fine, please post a statement that you have reviewed and found
the document acceptable. Obviously, if it does not look acceptable
please identify your objections, preferably with suggested text that
would make it acceptable.

Thanks,
David Harrington
[email-masked] 
[email-masked] 
[email-masked] 
co-chair, Syslog WG

---

From: Balazs Scheidler <[email-masked]>
Date: Tue, 05 Sep 2006 09:18:44 +0200

> Please review the document and send in your thoughts on this.

Sending the version field is a good idea in general, however I feel that
adding it to _every single_ message in a conversation is too redundant,
apart from the extra bandwidth used, it causes ambiguities what to do
when different messages use a different version number.

The version should be associated with the channel, and not individual
messages.

Having a simple negotiation at the start would IMHO be way better.
Something like:

HELLO <capabilities>
OK <capabilities>
START
OK
<message stream>

-- 
Bazsi

---

From: Miao Fuyou <[email-masked]>
Date: Tue, 05 Sep 2006 15:30:24 +0800

Good point. I am considering make the version only available at the
beginning of Syslog messages stream to reduce redundency. But, I don't like
capabilies negotiation here because it adds extra complexity to
implementation.

Thanks!
MIao
> From: Balazs Scheidler [mailto:[email-masked]] 
> Sent: Tuesday, September 05, 2006 3:19 PM
> To: Chris Lonvick
> Cc: [email-masked]
> Subject: Re: version field in syslog-tls - was: RE: [Syslog] 
> Working Group Last Call: syslog-tls document
> 
> > Please do consider the version field.  If we don't have 
> one, we would 
> > have to live forever with the decisions we are making now.  
> Having a 
> > version number in there would allow a future group to 
> re-decide things 
> > (like byte-count v. special character) and to just change 
> the version 
> > number rather than go asking for a new port number - or 
> have a flag day.
> > 
> Sending the version field is a good idea in general, however 
> I feel that adding it to _every single_ message in a 
> conversation is too redundant, apart from the extra bandwidth 
> used, it causes ambiguities what to do when different 
> messages use a different version number.
> 
> The version should be associated with the channel, and not 
> individual messages.
>

---

From: "tom.petch" <[email-masked]>
Date: Tue, 5 Sep 2006 20:51:07 +0200

----- Original Message -----
From: "Balazs Scheidler" <[email-masked]>
To: "Chris Lonvick" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 05, 2006 9:18 AM
Subject: Re: version field in syslog-tls - was: RE: [Syslog] Working GroupLast
Call: syslog-tls document

> Having a simple negotiation at the start would IMHO be way better.
I too like starting with a simple negotiation.  I notice that other applications
that started with TCP and then added security have used character strings such
as
AUTH TLS
which has the advantage of readily adding in SSH (or anything else) in the
future.
I also like being able to add later a choice as to which end is client and which
server since I foresee problems here with security credentials (most other
applications have the server on a well-connected device well able to verify
secuirty credentials, something a remote network box is less well able to do).

Tom Petch

---

From: Miao Fuyou <[email-masked]>
Date: Thu, 07 Sep 2006 17:17:58 +0800

Starting from TCP and then upgrading to tls is quite different to current
tls transport mapping document. If we decide to do UPGRADING, we may first
need a TCP transport mapping for Syslog, and then define a specific string
to indicate the other side to upgrade to TLS. We currently assume Syslog has
a IANA allocated port for tls transport mapping, we may not need such
complexity on upgrading. 

FYI, HTTP has two tls mechansims: RFC2818(standards track) is similiar to
this draft, RFC2817(Informational) is on upgrading. 

> From: tom.petch [mailto:[email-masked]] 
> Sent: Wednesday, September 06, 2006 2:51 AM
> To: Balazs Scheidler; Chris Lonvick
> Cc: [email-masked]
> Working GroupLastCall: syslog-tls document
> 
> Working GroupLast
> > > Please do consider the version field.  If we don't have one, we 
> > > would have to live forever with the decisions we are making now.  
> > > Having a version number in there would allow a future group to 
> > > re-decide things (like byte-count v. special character) 
> and to just 
> > > change the version number rather than go asking for a new 
> port number - or have a flag day.
> > >
> > Sending the version field is a good idea in general, however I feel 
> > that adding it to _every single_ message in a conversation is too 
> > redundant, apart from the extra bandwidth used, it causes 
> ambiguities 
> > what to do when different messages use a different version number.
> >
> individual 
> I too like starting with a simple negotiation.  I notice that 
> other applications that started with TCP and then added 
> security have used character strings such as AUTH TLS which 
> has the advantage of readily adding in SSH (or anything else) 
> in the future.
> I also like being able to add later a choice as to which end 
> is client and which server since I foresee problems here with 
> security credentials (most other applications have the server 
> on a well-connected device well able to verify secuirty 
> credentials, something a remote network box is less well able to do).
> 
> Tom Petch
> 
> > --
> > Bazsi
> >
> >

---

From: Balazs Scheidler <[email-masked]>
Date: Thu, 07 Sep 2006 13:37:52 +0200

> this draft, RFC2817(Informational) is on upgrading. 

We clearly stated in our charter that we won't define a plain TCP
version (although I personally disagree).

A simple capability negotiation can be useful for reasons beyond TLS
upgrade, like an optional support for Application Layer
acknowledgements.

-- 
Bazsi

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 7 Sep 2006 05:22:29 -0700 (PDT)

Hi Bazsi,

> version (although I personally disagree).

I think that we have discussed this before; you are free to write your own 
ID on this.  I know that others support this so you should be able to find 
people to help.

> upgrade, like an optional support for Application Layer

I fear that if we start going down that path we will reinvent RFC 3195.

We need to continue addressing simplex syslog with syslog-transport-tls. 
We can address capabilities exchange either in 3195bis or it can be looked 
into in a future revision of syslog/tls (yet another good reason for a 
version field).  If you get a lot of people doing syslog/tcp with a 
capabilities exchange mechanism then it should be simple to put that into 
a subsequent version of syslog-transport-tls.

Thanks,
Chris

---

From: "tom.petch" <[email-masked]>
Date: Mon, 18 Sep 2006 09:22:34 +0200

Apologies for my absence last week.  Comments below

Tom Petch
----- Original Message -----
From: "Miao Fuyou" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'Balazs Scheidler'"
<[email-masked]>; "'Chris Lonvick'" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 07, 2006 11:17 AM
Subject: RE: version field in syslog-tls - was: RE: [Syslog] Working
GroupLastCall: syslog-tls document

> to indicate the other side to upgrade to TLS.

I am NOT suggesting that we have a TCP transport which can be switched
dynamically to be or not be TLS; that was not my intended meaning of the words I
used..

Rather I was saying that other applications, forget how they got there, found it
useful to have a string at the front stating their intentions, eg to use TLS.
Of course, no matter how simple, like a single digit for a version number, this
is in some sense an application protocol.  What does the recipient do if it
agrees, what if it disagrees?  Terminating the connection may cause the
transmitter to try again and then what?  All soluble problems.

I also think that hard coding this 'information' into a well known port is
wrong.  Ports may or may not be in short supply but the management associated
with them by anyone with firewall or gateway, ie many if not most enterprises.
is a pain so I am very much of the view to keep the number of ports few in
number, and reuse them by changing the initial string.

We currently assume Syslog has

---

From: "David Harrington" <[email-masked]>
Date: Mon, 18 Sep 2006 14:56:28 -0400

Hi Tom,

Welcome back.

I agree that section 5.3.2 should describe the behavior of the
receiver if a message with a protocol version that is not supported is
received, and it should recognize that future version #s are possible
in this position. Could you suggest text for this?

Can you identify which applications find it useful to have a string at
the front, and what was found useful about it? Would the string be
required, and the text be standard? I would be interested in seeing
others' comments on this suggestion. 

Personally, I think using an assigned port serves the purpose of
differentiating syslog from syslog/tls for receiving applications and
for applications such as firewalls; use of a reserved port number
alleviates the need for the string and is consistent with other
Internet standards. Other protocols retrofitted to run over secure
protocols have been assigned separate ports to differentiate the
secure and non-secure versions of the protocol. Presumably there have
been good justifications for the IESG to approve such port
assignments. BCP 72, RFC 3552 section 4.5.2 supports the practice.

I will note that so many applications are retrofitting to TLS that
maybe IANA should consider port assignment ranges for udp, tcp, and
tls/ssl ;-)

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> Sent: Monday, September 18, 2006 3:23 AM
> To: Miao Fuyou; 'Balazs Scheidler'; 'Chris Lonvick'
> Cc: [email-masked]
> WorkingGroupLastCall: syslog-tls document
>

---

From: "tom.petch" <[email-masked]>
Date: Tue, 19 Sep 2006 15:05:41 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'Miao Fuyou'" <[email-masked]>;
"'Balazs Scheidler'" <[email-masked]>; "'Chris Lonvick'" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 18, 2006 8:56 PM
Subject: RE: version field in syslog-tls - was: RE: [Syslog]
WorkingGroupLastCall: syslog-tls document

> in this position. Could you suggest text for this?
Not yet; I do not yet see one obvious right action to text.  Rather I see
choices:-
a) receiver terminates session unilaterally; currently this is only allowed
after an 'idle timeout' and closure alert.  'protocol_version' alert would seem
appropriate; do the TLS stacks allow syslog to generate this?.

b) receiver returns syslog text message 'not ok' which rather implies a message
'ok' when it is, all of which is alien to this simplex application.

c) receiver terminates session. simple, but likely to cause the sender to keep
retrying for a while.

Thoughts?

Tom Petch

---

From: Miao Fuyou <[email-masked]>
Date: Wed, 20 Sep 2006 10:36:52 +0800

Comments inline. 

> a) receiver terminates session unilaterally; currently this 
> is only allowed after an 'idle timeout' and closure alert.  
> 'protocol_version' alert would seem appropriate; do the TLS 
> stacks allow syslog to generate this?.
> 

"protocol_version" is only for TLS version, it may not be inappropriate to
indicate unsupporting application protocol version, it also may invoke
another TLS handshaking. 

I checked "user_canceled" alert, TLS suggests (not strongly) that it can
only be permitted during TLS handshaking, not after handshaking. Another
option is to use "internal_error" alert, it is not very proper to meet this
requirement. I tend to use "user_canceled" to indicate that the server does
not support the version. Openssl has a fucntion ssl3_send_alert() to serve
this purpose. 

> b) receiver returns syslog text message 'not ok' which rather 
> implies a message 'ok' when it is, all of which is alien to 
> this simplex application.
> 
> c) receiver terminates session. simple, but likely to cause 
> the sender to keep retrying for a while.
> 
> Thoughts?
> 
> Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Fri, 22 Sep 2006 12:14:05 +0200

----- Original Message -----
From: "Miao Fuyou" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'David Harrington'"
<[email-masked]>; "'Balazs Scheidler'" <[email-masked]>; "'Chris
Lonvick'" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 20, 2006 4:36 AM
Subject: RE: protocol was Re: version field in syslog-tls - was: RE: [Syslog]
WorkingGroupLastCall: syslog-tls document

> not support the version. Openssl has a fucntion ssl3_send_alert() to serve
I agree; TLS alerts are attractive but seem to lack a user extension which
allows TLS applications to specify their own, context-specific ones, so using
one of them is a fudge.  Alternatively, creating our own application level 'ok'
or 'not ok' seems more alien to syslog; I await any other suggestions.

Tom Petch