From syslog-bounces@lists.ietf.org Thu Mar 09 18:57:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHV0v-0001c1-U7; Thu, 09 Mar 2006 18:57:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHV0u-0001bl-RI; Thu, 09 Mar 2006 18:57:48 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHV0u-0007VT-Gl; Thu, 09 Mar 2006 18:57:48 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k29NvlvP027357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Mar 2006 23:57:47 GMT
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1FHV0t-0004lX-DL; Thu, 09 Mar 2006 18:57:47 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: IETF Announcement list <ietf-announce@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Message-Id: <E1FHV0t-0004lX-DL@ietf.org>
Date: Thu, 09 Mar 2006 18:57:47 -0500
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: syslog@ietf.org
Subject: [Syslog] WG Review: Recharter of Security Issues in Network Event
 Logging (syslog) 
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

A modified charter has been submitted for the Security Issues in Network Event
Logging (syslog)working group in the Security Area of the IETF.  
The IESG has not made any determination as yet. The modified charter is provided
below for informational purposes only. Please send your comments to the IESG
mailing list (iesg@ietf.org) by March 15th.

The IESG solicits feedback from those considering implementing or deploying
syslog on the following charter. In particular, the concern has been raised that
insufficient vendors will implement a new syslog protocol and insufficient
operators will deploy it. The IESG requests those who support this effort to
explicitly indicate their support.
If significant community support is not indicated, this work will not be
chartered.

+++

Security Issues in Network Event Logging (syslog) 
====================================

Current Status: Active Working Group

Chair(s):
Chris Lonvick <clonvick@cisco.com>

Security Area Director(s):
Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:
Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: syslog@ietf.org
To Subscribe: syslog-request@ietf.org
In Body: in body: (un)subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/syslog/

Description of Working Group:

Syslog is a de-facto standard for logging system events. However, the protocol
component of this event logging system has not been formally documented. While
the protocol has been very useful and scalable, it has some known security
problems which were documented in the INFORMATIONAL RFC 3164.

The goal of this working group is to address the security and integrity
problems, and to standardize the syslog protocol, transport, and a select set of
mechanisms in a manner that considers the ease of migration between and the
co-existence of existing versions and the standard.

Reviews have shown that there are very few similarities between the message
formats generated by heterogeneous systems. In fact, the only consistent
commonality between messages is that all of them contain the <PRI> at the start.
Additional testing has shown that as long as the <PRI> is present in a syslog
message, all tested receivers will accept any generated message as a valid
syslog message. In designing a standard syslog message format, this Working
Group will retain the <PRI> at the start of the message and will introduce
protocol versioning. Along these same lines, many different charsets have been
used in syslog messages observed in the wild but no indication of the charset
has been given in any message. The Working Group also feels that multiple
charsets will not be beneficial to the community; much code would be needed to
distinguish and interpret different charsets.
For compatibility with existing implementations, the Working Group will allow
that messages may still be sent that do not indicate the charset used.
However, the Working Group will recommend that messages contain a way to
identify the charset used for the message, and will also recommend a single
default charset.

syslog has traditionally been transported over UDP and this WG has already
defined RFC 3195 for the reliable transport for the syslog messages. The WG will
separate the UDP transport from the protocol so that others may define
additional transports in the future.

The threats that this WG will primarily address are modification, disclosure,
and masquerading. A secondary threat is message stream modification. Threats
that will not be addressed by this WG are DoS and traffic analysis. The primary
attacks may be thwarted by a secure transport. However, it must be remembered
that a great deal of the success of syslog has been attributed to its ease of
implementation and relatively low maintenance level. The Working Group will
consider those factors, as well as current implementations, when deciding upon a
secure transport. The secondary threat of message stream modification can be
addressed by a mechanism that will verify the end-to-end integrity and sequence
of messages. The Working Group feels that these aspects may be addressed by a
dissociated signature upon sent messages.

- A document will be produced that describes a standardized syslog protocol.
A mechanism will also be defined in this document that will provide a means to
convey structured data.

- A document will be produced that describes a standardized UDP transport for
syslog.

- A document will be produced that requires a secure transport for the delivery
of syslog messages.

- A document will be produced to describe the MIB for syslog entities.

- A document will be produced that describes a standardized mechanism to sign
syslog messages to provide integrity checking and source authentication.


Milestones:

Nov 2006 Submit Syslog Protocol to the IESG for consideration as a PROPOSED
STANDARD.
Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for consideration as a
PROPOSED STANDARD.
Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for consideration as a
PROPOSED STANDARD.
Nov 2006 Submit Syslog Device MIB to IESG for consideration as a PROPOSED
STANDARD.
Nov 2006 Submit a document that defines a message signing and ordering mechanism
to the IESG for consideration as a PROPOSED STANDARD







_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Fri Mar 10 01:59:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHbaV-0001WM-CH; Fri, 10 Mar 2006 01:58:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHbaT-0001UJ-SW; Fri, 10 Mar 2006 01:58:57 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHbaO-0003Gh-6h; Fri, 10 Mar 2006 01:58:57 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id 481B127C067;
	Fri, 10 Mar 2006 07:04:58 +0100 (CET)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 14698-03; Fri, 10 Mar 2006 07:04:58 +0100 (CET)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id DD9F727C061;
	Fri, 10 Mar 2006 07:04:57 +0100 (CET)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Fri, 10 Mar 2006 07:58:49 +0100
Content-class: urn:content-classes:message
Subject: FW: [Syslog] WG Review: Recharter of Security Issues in Network Event
	Logging (syslog) 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Mar 2006 07:58:44 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174147@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] WG Review: Recharter of Security Issues in Network
	Event Logging (syslog) 
Thread-Index: AcZD1U1XY2Tnnkv9REq9NmlGGUeefQAOo+Mg
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: <iesg@ietf.org>
X-OriginalArrivalTime: 10 Mar 2006 06:58:49.0619 (UTC)
	FILETIME=[156BCE30:01C64410]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

IESG:

we (Adiscon) will implement the upcoming new drafts in our softwares
WinSyslog, EventReporter, Monitorware Agent and rsyslog (already has a
proof-of-concept implementation of -protocol and -transport-tls).

Best regards,
Rainer Gerhards
Adiscon

> -----Original Message-----
> From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20
> Sent: Friday, March 10, 2006 12:58 AM
> To: IETF Announcement list
> Cc: syslog@ietf.org
> Subject: [Syslog] WG Review: Recharter of Security Issues in=20
> Network Event Logging (syslog)=20
>=20
> A modified charter has been submitted for the Security Issues=20
> in Network Event
> Logging (syslog)working group in the Security Area of the IETF. =20
> The IESG has not made any determination as yet. The modified=20
> charter is provided
> below for informational purposes only. Please send your=20
> comments to the IESG
> mailing list (iesg@ietf.org) by March 15th.
>=20
> The IESG solicits feedback from those considering=20
> implementing or deploying
> syslog on the following charter. In particular, the concern=20
> has been raised that
> insufficient vendors will implement a new syslog protocol and=20
> insufficient
> operators will deploy it. The IESG requests those who support=20
> this effort to
> explicitly indicate their support.
> If significant community support is not indicated, this work=20
> will not be
> chartered.
>=20
> +++
>=20
> Security Issues in Network Event Logging (syslog)=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Current Status: Active Working Group
>=20
> Chair(s):
> Chris Lonvick <clonvick@cisco.com>
>=20
> Security Area Director(s):
> Russ Housley <housley@vigilsec.com>
> Sam Hartman <hartmans-ietf@mit.edu>
>=20
> Security Area Advisor:
> Sam Hartman <hartmans-ietf@mit.edu>
>=20
> Mailing Lists:
>=20
> General Discussion: syslog@ietf.org
> To Subscribe: syslog-request@ietf.org
> In Body: in body: (un)subscribe
> Archive: ftp://ftp.ietf.org/ietf-mail-archive/syslog/
>=20
> Description of Working Group:
>=20
> Syslog is a de-facto standard for logging system events.=20
> However, the protocol
> component of this event logging system has not been formally=20
> documented. While
> the protocol has been very useful and scalable, it has some=20
> known security
> problems which were documented in the INFORMATIONAL RFC 3164.
>=20
> The goal of this working group is to address the security and=20
> integrity
> problems, and to standardize the syslog protocol, transport,=20
> and a select set of
> mechanisms in a manner that considers the ease of migration=20
> between and the
> co-existence of existing versions and the standard.
>=20
> Reviews have shown that there are very few similarities=20
> between the message
> formats generated by heterogeneous systems. In fact, the only=20
> consistent
> commonality between messages is that all of them contain the=20
> <PRI> at the start.
> Additional testing has shown that as long as the <PRI> is=20
> present in a syslog
> message, all tested receivers will accept any generated=20
> message as a valid
> syslog message. In designing a standard syslog message=20
> format, this Working
> Group will retain the <PRI> at the start of the message and=20
> will introduce
> protocol versioning. Along these same lines, many different=20
> charsets have been
> used in syslog messages observed in the wild but no=20
> indication of the charset
> has been given in any message. The Working Group also feels=20
> that multiple
> charsets will not be beneficial to the community; much code=20
> would be needed to
> distinguish and interpret different charsets.
> For compatibility with existing implementations, the Working=20
> Group will allow
> that messages may still be sent that do not indicate the charset used.
> However, the Working Group will recommend that messages=20
> contain a way to
> identify the charset used for the message, and will also=20
> recommend a single
> default charset.
>=20
> syslog has traditionally been transported over UDP and this=20
> WG has already
> defined RFC 3195 for the reliable transport for the syslog=20
> messages. The WG will
> separate the UDP transport from the protocol so that others may define
> additional transports in the future.
>=20
> The threats that this WG will primarily address are=20
> modification, disclosure,
> and masquerading. A secondary threat is message stream=20
> modification. Threats
> that will not be addressed by this WG are DoS and traffic=20
> analysis. The primary
> attacks may be thwarted by a secure transport. However, it=20
> must be remembered
> that a great deal of the success of syslog has been=20
> attributed to its ease of
> implementation and relatively low maintenance level. The=20
> Working Group will
> consider those factors, as well as current implementations,=20
> when deciding upon a
> secure transport. The secondary threat of message stream=20
> modification can be
> addressed by a mechanism that will verify the end-to-end=20
> integrity and sequence
> of messages. The Working Group feels that these aspects may=20
> be addressed by a
> dissociated signature upon sent messages.
>=20
> - A document will be produced that describes a standardized=20
> syslog protocol.
> A mechanism will also be defined in this document that will=20
> provide a means to
> convey structured data.
>=20
> - A document will be produced that describes a standardized=20
> UDP transport for
> syslog.
>=20
> - A document will be produced that requires a secure=20
> transport for the delivery
> of syslog messages.
>=20
> - A document will be produced to describe the MIB for syslog entities.
>=20
> - A document will be produced that describes a standardized=20
> mechanism to sign
> syslog messages to provide integrity checking and source=20
> authentication.
>=20
>=20
> Milestones:
>=20
> Nov 2006 Submit Syslog Protocol to the IESG for consideration=20
> as a PROPOSED
> STANDARD.
> Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for=20
> consideration as a
> PROPOSED STANDARD.
> Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for=20
> consideration as a
> PROPOSED STANDARD.
> Nov 2006 Submit Syslog Device MIB to IESG for consideration=20
> as a PROPOSED
> STANDARD.
> Nov 2006 Submit a document that defines a message signing and=20
> ordering mechanism
> to the IESG for consideration as a PROPOSED STANDARD
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Fri Mar 10 02:58:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHcVi-00005U-Ko; Fri, 10 Mar 2006 02:58:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHcVg-0008TH-NU; Fri, 10 Mar 2006 02:58:04 -0500
Received: from sccrmhc12.comcast.net ([63.240.77.82])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FHcVd-0004sC-HS; Fri, 10 Mar 2006 02:58:04 -0500
Received: from djyxpy41 (c-24-128-66-70.hsd1.nh.comcast.net[24.128.66.70])
	by comcast.net (sccrmhc12) with SMTP
	id <2006031007580001200c5p52e>; Fri, 10 Mar 2006 07:58:01 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Rainer Gerhards'" <rgerhards@hq.adiscon.com>,
	<iesg@ietf.org>
Subject: RE: [Syslog] WG Review: Recharter of Security Issues in Network
	EventLogging (syslog) 
Date: Fri, 10 Mar 2006 02:57:56 -0500
Message-ID: <02af01c64418$57fdc2f0$0200a8c0@DJYXPY41>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174147@grfint2.intern.adiscon.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcZD1U1XY2Tnnkv9REq9NmlGGUeefQAOo+MgAAICxuA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

At Huawei, we plan to develop a prototype of syslog/TLS. 

David Harrington
dharrington@huawei.com

> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] 
> Sent: Friday, March 10, 2006 1:59 AM
> To: iesg@ietf.org
> Cc: syslog@ietf.org
> Subject: FW: [Syslog] WG Review: Recharter of Security Issues 
> in Network EventLogging (syslog) 
> 
> IESG:
> 
> we (Adiscon) will implement the upcoming new drafts in our softwares
> WinSyslog, EventReporter, Monitorware Agent and rsyslog (already has
a
> proof-of-concept implementation of -protocol and -transport-tls).
> 
> Best regards,
> Rainer Gerhards
> Adiscon
> 
> > -----Original Message-----
> > From: IESG Secretary [mailto:iesg-secretary@ietf.org] 
> > Sent: Friday, March 10, 2006 12:58 AM
> > To: IETF Announcement list
> > Cc: syslog@ietf.org
> > Subject: [Syslog] WG Review: Recharter of Security Issues in 
> > Network Event Logging (syslog) 
> > 
> > A modified charter has been submitted for the Security Issues 
> > in Network Event
> > Logging (syslog)working group in the Security Area of the IETF.  
> > The IESG has not made any determination as yet. The modified 
> > charter is provided
> > below for informational purposes only. Please send your 
> > comments to the IESG
> > mailing list (iesg@ietf.org) by March 15th.
> > 
> > The IESG solicits feedback from those considering 
> > implementing or deploying
> > syslog on the following charter. In particular, the concern 
> > has been raised that
> > insufficient vendors will implement a new syslog protocol and 
> > insufficient
> > operators will deploy it. The IESG requests those who support 
> > this effort to
> > explicitly indicate their support.
> > If significant community support is not indicated, this work 
> > will not be
> > chartered.
> > 
> > +++
> > 
> > Security Issues in Network Event Logging (syslog) 
> > ====================================
> > 
> > Current Status: Active Working Group
> > 
> > Chair(s):
> > Chris Lonvick <clonvick@cisco.com>
> > 
> > Security Area Director(s):
> > Russ Housley <housley@vigilsec.com>
> > Sam Hartman <hartmans-ietf@mit.edu>
> > 
> > Security Area Advisor:
> > Sam Hartman <hartmans-ietf@mit.edu>
> > 
> > Mailing Lists:
> > 
> > General Discussion: syslog@ietf.org
> > To Subscribe: syslog-request@ietf.org
> > In Body: in body: (un)subscribe
> > Archive: ftp://ftp.ietf.org/ietf-mail-archive/syslog/
> > 
> > Description of Working Group:
> > 
> > Syslog is a de-facto standard for logging system events. 
> > However, the protocol
> > component of this event logging system has not been formally 
> > documented. While
> > the protocol has been very useful and scalable, it has some 
> > known security
> > problems which were documented in the INFORMATIONAL RFC 3164.
> > 
> > The goal of this working group is to address the security and 
> > integrity
> > problems, and to standardize the syslog protocol, transport, 
> > and a select set of
> > mechanisms in a manner that considers the ease of migration 
> > between and the
> > co-existence of existing versions and the standard.
> > 
> > Reviews have shown that there are very few similarities 
> > between the message
> > formats generated by heterogeneous systems. In fact, the only 
> > consistent
> > commonality between messages is that all of them contain the 
> > <PRI> at the start.
> > Additional testing has shown that as long as the <PRI> is 
> > present in a syslog
> > message, all tested receivers will accept any generated 
> > message as a valid
> > syslog message. In designing a standard syslog message 
> > format, this Working
> > Group will retain the <PRI> at the start of the message and 
> > will introduce
> > protocol versioning. Along these same lines, many different 
> > charsets have been
> > used in syslog messages observed in the wild but no 
> > indication of the charset
> > has been given in any message. The Working Group also feels 
> > that multiple
> > charsets will not be beneficial to the community; much code 
> > would be needed to
> > distinguish and interpret different charsets.
> > For compatibility with existing implementations, the Working 
> > Group will allow
> > that messages may still be sent that do not indicate the 
> charset used.
> > However, the Working Group will recommend that messages 
> > contain a way to
> > identify the charset used for the message, and will also 
> > recommend a single
> > default charset.
> > 
> > syslog has traditionally been transported over UDP and this 
> > WG has already
> > defined RFC 3195 for the reliable transport for the syslog 
> > messages. The WG will
> > separate the UDP transport from the protocol so that others 
> may define
> > additional transports in the future.
> > 
> > The threats that this WG will primarily address are 
> > modification, disclosure,
> > and masquerading. A secondary threat is message stream 
> > modification. Threats
> > that will not be addressed by this WG are DoS and traffic 
> > analysis. The primary
> > attacks may be thwarted by a secure transport. However, it 
> > must be remembered
> > that a great deal of the success of syslog has been 
> > attributed to its ease of
> > implementation and relatively low maintenance level. The 
> > Working Group will
> > consider those factors, as well as current implementations, 
> > when deciding upon a
> > secure transport. The secondary threat of message stream 
> > modification can be
> > addressed by a mechanism that will verify the end-to-end 
> > integrity and sequence
> > of messages. The Working Group feels that these aspects may 
> > be addressed by a
> > dissociated signature upon sent messages.
> > 
> > - A document will be produced that describes a standardized 
> > syslog protocol.
> > A mechanism will also be defined in this document that will 
> > provide a means to
> > convey structured data.
> > 
> > - A document will be produced that describes a standardized 
> > UDP transport for
> > syslog.
> > 
> > - A document will be produced that requires a secure 
> > transport for the delivery
> > of syslog messages.
> > 
> > - A document will be produced to describe the MIB for 
> syslog entities.
> > 
> > - A document will be produced that describes a standardized 
> > mechanism to sign
> > syslog messages to provide integrity checking and source 
> > authentication.
> > 
> > 
> > Milestones:
> > 
> > Nov 2006 Submit Syslog Protocol to the IESG for consideration 
> > as a PROPOSED
> > STANDARD.
> > Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for 
> > consideration as a
> > PROPOSED STANDARD.
> > Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for 
> > consideration as a
> > PROPOSED STANDARD.
> > Nov 2006 Submit Syslog Device MIB to IESG for consideration 
> > as a PROPOSED
> > STANDARD.
> > Nov 2006 Submit a document that defines a message signing and 
> > ordering mechanism
> > to the IESG for consideration as a PROPOSED STANDARD
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Syslog mailing list
> > Syslog@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/syslog
> > 
> 
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
> 



_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 13 17:15:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FIvKU-0001Hk-JK; Mon, 13 Mar 2006 17:15:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvKS-0001Ha-Fu
	for syslog@ietf.org; Mon, 13 Mar 2006 17:15:52 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FIvKS-0007M1-1u
	for syslog@ietf.org; Mon, 13 Mar 2006 17:15:52 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-2.cisco.com with ESMTP; 13 Mar 2006 14:15:52 -0800
X-IronPort-AV: i="4.02,188,1139212800"; 
	d="scan'208"; a="313826479:sNHT42894692"
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2DMFpGw024959
	for <syslog@ietf.org>; Mon, 13 Mar 2006 14:15:51 -0800 (PST)
Date: Mon, 13 Mar 2006 14:15:51 -0800 (PST)
From: Chris Lonvick <clonvick@cisco.com>
To: syslog@ietf.org
Message-ID: <Pine.GSO.4.63.0603131411170.3492@sjc-cde-011.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc: 
Subject: [Syslog] WG Review: Recharter of Security Issues in Network Event
 Logging (syslog)  (fwd)
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Hi Folks,

Please do respond to this to the IESG.  Let's get this charter active and 
get our documents standardized.

Thanks,
Chris

---------- Forwarded message ----------
Date: Thu, 09 Mar 2006 18:57:47 -0500
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: iesg@ietf.org
To: IETF Announcement list <ietf-announce@ietf.org>
Cc: Chris Lonvick <clonvick@cisco.com>, syslog@ietf.org
Subject: WG Review: Recharter of Security Issues in Network Event Logging
        (syslog)

A modified charter has been submitted for the Security Issues in Network Event
Logging (syslog)working group in the Security Area of the IETF.
The IESG has not made any determination as yet. The modified charter is provided
below for informational purposes only. Please send your comments to the IESG
mailing list (iesg@ietf.org) by March 15th.

The IESG solicits feedback from those considering implementing or deploying
syslog on the following charter. In particular, the concern has been raised that
insufficient vendors will implement a new syslog protocol and insufficient
operators will deploy it. The IESG requests those who support this effort to
explicitly indicate their support.
If significant community support is not indicated, this work will not be
chartered.

+++

Security Issues in Network Event Logging (syslog)
====================================

Current Status: Active Working Group

Chair(s):
Chris Lonvick <clonvick@cisco.com>

Security Area Director(s):
Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:
Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: syslog@ietf.org
To Subscribe: syslog-request@ietf.org
In Body: in body: (un)subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/syslog/

Description of Working Group:

Syslog is a de-facto standard for logging system events. However, the protocol
component of this event logging system has not been formally documented. While
the protocol has been very useful and scalable, it has some known security
problems which were documented in the INFORMATIONAL RFC 3164.

The goal of this working group is to address the security and integrity
problems, and to standardize the syslog protocol, transport, and a select set of
mechanisms in a manner that considers the ease of migration between and the
co-existence of existing versions and the standard.

Reviews have shown that there are very few similarities between the message
formats generated by heterogeneous systems. In fact, the only consistent
commonality between messages is that all of them contain the <PRI> at the start.
Additional testing has shown that as long as the <PRI> is present in a syslog
message, all tested receivers will accept any generated message as a valid
syslog message. In designing a standard syslog message format, this Working
Group will retain the <PRI> at the start of the message and will introduce
protocol versioning. Along these same lines, many different charsets have been
used in syslog messages observed in the wild but no indication of the charset
has been given in any message. The Working Group also feels that multiple
charsets will not be beneficial to the community; much code would be needed to
distinguish and interpret different charsets.
For compatibility with existing implementations, the Working Group will allow
that messages may still be sent that do not indicate the charset used.
However, the Working Group will recommend that messages contain a way to
identify the charset used for the message, and will also recommend a single
default charset.

syslog has traditionally been transported over UDP and this WG has already
defined RFC 3195 for the reliable transport for the syslog messages. The WG will
separate the UDP transport from the protocol so that others may define
additional transports in the future.

The threats that this WG will primarily address are modification, disclosure,
and masquerading. A secondary threat is message stream modification. Threats
that will not be addressed by this WG are DoS and traffic analysis. The primary
attacks may be thwarted by a secure transport. However, it must be remembered
that a great deal of the success of syslog has been attributed to its ease of
implementation and relatively low maintenance level. The Working Group will
consider those factors, as well as current implementations, when deciding upon a
secure transport. The secondary threat of message stream modification can be
addressed by a mechanism that will verify the end-to-end integrity and sequence
of messages. The Working Group feels that these aspects may be addressed by a
dissociated signature upon sent messages.

- A document will be produced that describes a standardized syslog protocol.
A mechanism will also be defined in this document that will provide a means to
convey structured data.

- A document will be produced that describes a standardized UDP transport for
syslog.

- A document will be produced that requires a secure transport for the delivery
of syslog messages.

- A document will be produced to describe the MIB for syslog entities.

- A document will be produced that describes a standardized mechanism to sign
syslog messages to provide integrity checking and source authentication.


Milestones:

Nov 2006 Submit Syslog Protocol to the IESG for consideration as a PROPOSED
STANDARD.
Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for consideration as a
PROPOSED STANDARD.
Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for consideration as a
PROPOSED STANDARD.
Nov 2006 Submit Syslog Device MIB to IESG for consideration as a PROPOSED
STANDARD.
Nov 2006 Submit a document that defines a message signing and ordering mechanism
to the IESG for consideration as a PROPOSED STANDARD




_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 13 18:45:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FIwjT-0001Nh-Ql; Mon, 13 Mar 2006 18:45:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FIwjT-0001Nc-Aa
	for syslog@ietf.org; Mon, 13 Mar 2006 18:45:47 -0500
Received: from balabit.hu ([195.70.34.196])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIwjS-0001rT-0c
	for syslog@ietf.org; Mon, 13 Mar 2006 18:45:47 -0500
Subject: Re: [Syslog] WG Review: Recharter of Security Issues in Network
	Event Logging (syslog)  (fwd)
From: Balazs Scheidler <bazsi@balabit.hu>
To: Chris Lonvick <clonvick@cisco.com>
In-Reply-To: <Pine.GSO.4.63.0603131411170.3492@sjc-cde-011.cisco.com>
References: <Pine.GSO.4.63.0603131411170.3492@sjc-cde-011.cisco.com>
Content-Type: text/plain
Date: Tue, 14 Mar 2006 00:45:45 +0100
Message-Id: <1142293545.6977.13.camel@bzorp.balabit>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

On Mon, 2006-03-13 at 14:15 -0800, Chris Lonvick wrote:
> Hi Folks,
> 
> Please do respond to this to the IESG.  Let's get this charter active and 
> get our documents standardized.

I sent short me-too message to iesg and forgot to Cc this list. Hope
that's ok.

-- 
Bazsi


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 13 19:34:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FIxUv-0007TS-Aq; Mon, 13 Mar 2006 19:34:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FIxUu-0007Sl-Dh
	for syslog@ietf.org; Mon, 13 Mar 2006 19:34:48 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIxUt-0004DH-Qd
	for syslog@ietf.org; Mon, 13 Mar 2006 19:34:48 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-5.cisco.com with ESMTP; 13 Mar 2006 16:34:47 -0800
X-IronPort-AV: i="4.02,188,1139212800"; 
	d="scan'208"; a="261617786:sNHT55982892"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2E0YlYg026972
	for <syslog@ietf.org>; Mon, 13 Mar 2006 16:34:47 -0800 (PST)
Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 13 Mar 2006 16:34:47 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Syslog] WG Review: Recharter of Security Issues in Network Event
	Logging (syslog) (fwd)
Date: Mon, 13 Mar 2006 16:34:46 -0800
Message-ID: <0DF8CBE327D4654F8567FD8123E328B10177B578@xmb-sjc-237.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] WG Review: Recharter of Security Issues in Network
	Event Logging (syslog) (fwd)
Thread-Index: AcZG69gSd8Tdzo4VS4K/aleJF7H+NwAExYMg
From: "Shyyunn Lin \(sheranl\)" <sheranl@cisco.com>
To: "Chris Lonvick \(clonvick\)" <clonvick@cisco.com>, <syslog@ietf.org>
X-OriginalArrivalTime: 14 Mar 2006 00:34:47.0040 (UTC)
	FILETIME=[18A04800:01C646FF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc: 
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

We will support this effort.=20


Regards,
=20
Sheran

-----Original Message-----
From: Chris Lonvick (clonvick)=20
Sent: Monday, March 13, 2006 2:16 PM
To: syslog@ietf.org
Subject: [Syslog] WG Review: Recharter of Security Issues in Network
Event Logging (syslog) (fwd)

Hi Folks,

Please do respond to this to the IESG.  Let's get this charter active
and get our documents standardized.

Thanks,
Chris

---------- Forwarded message ----------
Date: Thu, 09 Mar 2006 18:57:47 -0500
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: iesg@ietf.org
To: IETF Announcement list <ietf-announce@ietf.org>
Cc: Chris Lonvick <clonvick@cisco.com>, syslog@ietf.org
Subject: WG Review: Recharter of Security Issues in Network Event
Logging
        (syslog)

A modified charter has been submitted for the Security Issues in Network
Event Logging (syslog)working group in the Security Area of the IETF.
The IESG has not made any determination as yet. The modified charter is
provided below for informational purposes only. Please send your
comments to the IESG mailing list (iesg@ietf.org) by March 15th.

The IESG solicits feedback from those considering implementing or
deploying syslog on the following charter. In particular, the concern
has been raised that insufficient vendors will implement a new syslog
protocol and insufficient operators will deploy it. The IESG requests
those who support this effort to explicitly indicate their support.
If significant community support is not indicated, this work will not be
chartered.

+++

Security Issues in Network Event Logging (syslog)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Current Status: Active Working Group

Chair(s):
Chris Lonvick <clonvick@cisco.com>

Security Area Director(s):
Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:
Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: syslog@ietf.org
To Subscribe: syslog-request@ietf.org
In Body: in body: (un)subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/syslog/

Description of Working Group:

Syslog is a de-facto standard for logging system events. However, the
protocol component of this event logging system has not been formally
documented. While the protocol has been very useful and scalable, it has
some known security problems which were documented in the INFORMATIONAL
RFC 3164.

The goal of this working group is to address the security and integrity
problems, and to standardize the syslog protocol, transport, and a
select set of mechanisms in a manner that considers the ease of
migration between and the co-existence of existing versions and the
standard.

Reviews have shown that there are very few similarities between the
message formats generated by heterogeneous systems. In fact, the only
consistent commonality between messages is that all of them contain the
<PRI> at the start.
Additional testing has shown that as long as the <PRI> is present in a
syslog message, all tested receivers will accept any generated message
as a valid syslog message. In designing a standard syslog message
format, this Working Group will retain the <PRI> at the start of the
message and will introduce protocol versioning. Along these same lines,
many different charsets have been used in syslog messages observed in
the wild but no indication of the charset has been given in any message.
The Working Group also feels that multiple charsets will not be
beneficial to the community; much code would be needed to distinguish
and interpret different charsets.
For compatibility with existing implementations, the Working Group will
allow that messages may still be sent that do not indicate the charset
used.
However, the Working Group will recommend that messages contain a way to
identify the charset used for the message, and will also recommend a
single default charset.

syslog has traditionally been transported over UDP and this WG has
already defined RFC 3195 for the reliable transport for the syslog
messages. The WG will separate the UDP transport from the protocol so
that others may define additional transports in the future.

The threats that this WG will primarily address are modification,
disclosure, and masquerading. A secondary threat is message stream
modification. Threats that will not be addressed by this WG are DoS and
traffic analysis. The primary attacks may be thwarted by a secure
transport. However, it must be remembered that a great deal of the
success of syslog has been attributed to its ease of implementation and
relatively low maintenance level. The Working Group will consider those
factors, as well as current implementations, when deciding upon a secure
transport. The secondary threat of message stream modification can be
addressed by a mechanism that will verify the end-to-end integrity and
sequence of messages. The Working Group feels that these aspects may be
addressed by a dissociated signature upon sent messages.

- A document will be produced that describes a standardized syslog
protocol.
A mechanism will also be defined in this document that will provide a
means to convey structured data.

- A document will be produced that describes a standardized UDP
transport for syslog.

- A document will be produced that requires a secure transport for the
delivery of syslog messages.

- A document will be produced to describe the MIB for syslog entities.

- A document will be produced that describes a standardized mechanism to
sign syslog messages to provide integrity checking and source
authentication.


Milestones:

Nov 2006 Submit Syslog Protocol to the IESG for consideration as a
PROPOSED STANDARD.
Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for
consideration as a PROPOSED STANDARD.
Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for
consideration as a PROPOSED STANDARD.
Nov 2006 Submit Syslog Device MIB to IESG for consideration as a
PROPOSED STANDARD.
Nov 2006 Submit a document that defines a message signing and ordering
mechanism to the IESG for consideration as a PROPOSED STANDARD




_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 13 19:51:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FIxl9-0000HQ-1J; Mon, 13 Mar 2006 19:51:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FIxl7-0000HI-3y; Mon, 13 Mar 2006 19:51:33 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FIxl6-0004Xr-Hq; Mon, 13 Mar 2006 19:51:33 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-3.cisco.com with ESMTP; 13 Mar 2006 16:51:32 -0800
X-IronPort-AV: i="4.02,188,1139212800"; 
	d="scan'208"; a="415157977:sNHT45638436"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2E0pVGv024778;
	Mon, 13 Mar 2006 16:51:32 -0800 (PST)
Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 13 Mar 2006 16:51:31 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Syslog] WG Review: Recharter of Security Issues in Network Event
	Logging (syslog) 
Date: Mon, 13 Mar 2006 16:51:31 -0800
Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB01641529@xmb-sjc-236.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] WG Review: Recharter of Security Issues in Network
	Event Logging (syslog) 
Thread-Index: AcZD1U4XrV/r3LPQSNWR19pwqyXBaADK1mlg
From: "Alexander Clemm \(alex\)" <alex@cisco.com>
To: <iesg@ietf.org>
X-OriginalArrivalTime: 14 Mar 2006 00:51:31.0768 (UTC)
	FILETIME=[6F7D9B80:01C64701]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

We are very interested in this; I will push for its implementation on
our end as this becomes standardized. =20

--- Alex

-----Original Message-----
From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20
Sent: Thursday, March 09, 2006 3:58 PM
To: IETF Announcement list
Cc: syslog@ietf.org
Subject: [Syslog] WG Review: Recharter of Security Issues in Network
Event Logging (syslog)=20

A modified charter has been submitted for the Security Issues in Network
Event Logging (syslog)working group in the Security Area of the IETF. =20
The IESG has not made any determination as yet. The modified charter is
provided below for informational purposes only. Please send your
comments to the IESG mailing list (iesg@ietf.org) by March 15th.

The IESG solicits feedback from those considering implementing or
deploying syslog on the following charter. In particular, the concern
has been raised that insufficient vendors will implement a new syslog
protocol and insufficient operators will deploy it. The IESG requests
those who support this effort to explicitly indicate their support.
If significant community support is not indicated, this work will not be
chartered.

+++

Security Issues in Network Event Logging (syslog)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Current Status: Active Working Group

Chair(s):
Chris Lonvick <clonvick@cisco.com>

Security Area Director(s):
Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:
Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: syslog@ietf.org
To Subscribe: syslog-request@ietf.org
In Body: in body: (un)subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/syslog/

Description of Working Group:

Syslog is a de-facto standard for logging system events. However, the
protocol component of this event logging system has not been formally
documented. While the protocol has been very useful and scalable, it has
some known security problems which were documented in the INFORMATIONAL
RFC 3164.

The goal of this working group is to address the security and integrity
problems, and to standardize the syslog protocol, transport, and a
select set of mechanisms in a manner that considers the ease of
migration between and the co-existence of existing versions and the
standard.

Reviews have shown that there are very few similarities between the
message formats generated by heterogeneous systems. In fact, the only
consistent commonality between messages is that all of them contain the
<PRI> at the start.
Additional testing has shown that as long as the <PRI> is present in a
syslog message, all tested receivers will accept any generated message
as a valid syslog message. In designing a standard syslog message
format, this Working Group will retain the <PRI> at the start of the
message and will introduce protocol versioning. Along these same lines,
many different charsets have been used in syslog messages observed in
the wild but no indication of the charset has been given in any message.
The Working Group also feels that multiple charsets will not be
beneficial to the community; much code would be needed to distinguish
and interpret different charsets.
For compatibility with existing implementations, the Working Group will
allow that messages may still be sent that do not indicate the charset
used.
However, the Working Group will recommend that messages contain a way to
identify the charset used for the message, and will also recommend a
single default charset.

syslog has traditionally been transported over UDP and this WG has
already defined RFC 3195 for the reliable transport for the syslog
messages. The WG will separate the UDP transport from the protocol so
that others may define additional transports in the future.

The threats that this WG will primarily address are modification,
disclosure, and masquerading. A secondary threat is message stream
modification. Threats that will not be addressed by this WG are DoS and
traffic analysis. The primary attacks may be thwarted by a secure
transport. However, it must be remembered that a great deal of the
success of syslog has been attributed to its ease of implementation and
relatively low maintenance level. The Working Group will consider those
factors, as well as current implementations, when deciding upon a secure
transport. The secondary threat of message stream modification can be
addressed by a mechanism that will verify the end-to-end integrity and
sequence of messages. The Working Group feels that these aspects may be
addressed by a dissociated signature upon sent messages.

- A document will be produced that describes a standardized syslog
protocol.
A mechanism will also be defined in this document that will provide a
means to convey structured data.

- A document will be produced that describes a standardized UDP
transport for syslog.

- A document will be produced that requires a secure transport for the
delivery of syslog messages.

- A document will be produced to describe the MIB for syslog entities.

- A document will be produced that describes a standardized mechanism to
sign syslog messages to provide integrity checking and source
authentication.


Milestones:

Nov 2006 Submit Syslog Protocol to the IESG for consideration as a
PROPOSED STANDARD.
Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for
consideration as a PROPOSED STANDARD.
Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for
consideration as a PROPOSED STANDARD.
Nov 2006 Submit Syslog Device MIB to IESG for consideration as a
PROPOSED STANDARD.
Nov 2006 Submit a document that defines a message signing and ordering
mechanism to the IESG for consideration as a PROPOSED STANDARD







_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Tue Mar 14 16:59:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJHYa-0001dr-Kb; Tue, 14 Mar 2006 16:59:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJHYZ-0001dj-SW; Tue, 14 Mar 2006 16:59:55 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJHYY-0007CB-3o; Tue, 14 Mar 2006 16:59:55 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2006 13:59:54 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.02,191,1139212800"; 
	d="scan'208"; a="23589981:sNHT27535720"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2ELxpWe023077; 
	Tue, 14 Mar 2006 16:59:53 -0500 (EST)
Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 14 Mar 2006 16:59:52 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Syslog] WG Review: Recharter of Security Issues in Network Event
	Logging (syslog) 
Date: Tue, 14 Mar 2006 16:59:51 -0500
Message-ID: <98AE08B66FAD1742BED6CB9522B73122013190A1@xmb-rtp-20d.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] WG Review: Recharter of Security Issues in Network
	Event Logging (syslog) 
Thread-Index: AcZD1VG0JBw5+w4NRzWCBIe/TDGPOwD1kgXg
From: "Anton Okmianski \(aokmians\)" <aokmians@cisco.com>
To: <iesg@ietf.org>
X-OriginalArrivalTime: 14 Mar 2006 21:59:52.0057 (UTC)
	FILETIME=[9ECC2E90:01C647B2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0745853858=="
Errors-To: syslog-bounces@lists.ietf.org

--===============0745853858==
Content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

VG8gc2Vjb25kIG90aGVycy4uLiBXZSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIHdvcmsgYmUgY29t
cGxldGVkIGFuZCBwbGFuIG9uIGJlaW5nIGFjdGl2ZSBwYXJ0aWNpcGFudHMgaW4gdGhlIFdHIHRv
IGhlbHAgaXQgYWNjb21wbGlzaCB0aGlzIGdvYWwuIEkgd291bGQgbGlrZSB0byBzZWUgbXkgY29t
cGFueSBpbXBsZW1lbnQgdGhpcywgYnV0IGNhbid0IGNvbW1lbnQgb24gYW55IHNwZWNpZmljIHBy
b2R1Y3Qgcm9hZCBtYXBzLiAgDQoNClN5c2xvZyBoYXMgYmVlbiBhIHZlcnkgcG9wdWxhciBwcm90
b2NvbC4gSXQgaXMgbG9uZyBvdmVyZHVlIHRvIGdyYWR1YXRlIGl0IGludG8gYSByZWFsIHN0YW5k
YXJkIGZyb20gdGhlIGN1cnJlbnQgbG9vc2VseSBkZWZpbmVkIGluZm9ybWF0aW9uYWwgUkZDLiAg
VGhpcyBjaGFydGVyIHdpbGwgYWNjb21wbGlzaCB0aGlzLCBhcyB3ZWxsIGFzIHByb3ZpZGUgYSBy
b2J1c3Qgc3RhbmRhcmQgc2VjdXJpdHkgbWVjaGFuaXNtIGZvciBzeXNsb2cuIA0KDQpUaGFua3Ms
DQpBbnRvbi4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSUVTRyBT
ZWNyZXRhcnkgW21haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZ10gDQo+IFNlbnQ6IFRodXJz
ZGF5LCBNYXJjaCAwOSwgMjAwNiA2OjU4IFBNDQo+IFRvOiBJRVRGIEFubm91bmNlbWVudCBsaXN0
DQo+IENjOiBzeXNsb2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogW1N5c2xvZ10gV0cgUmV2aWV3OiBS
ZWNoYXJ0ZXIgb2YgU2VjdXJpdHkgSXNzdWVzIGluIA0KPiBOZXR3b3JrIEV2ZW50IExvZ2dpbmcg
KHN5c2xvZykgDQo+IA0KPiBBIG1vZGlmaWVkIGNoYXJ0ZXIgaGFzIGJlZW4gc3VibWl0dGVkIGZv
ciB0aGUgU2VjdXJpdHkgSXNzdWVzIA0KPiBpbiBOZXR3b3JrIEV2ZW50IExvZ2dpbmcgKHN5c2xv
Zyl3b3JraW5nIGdyb3VwIGluIHRoZSANCj4gU2VjdXJpdHkgQXJlYSBvZiB0aGUgSUVURi4gIA0K
PiBUaGUgSUVTRyBoYXMgbm90IG1hZGUgYW55IGRldGVybWluYXRpb24gYXMgeWV0LiBUaGUgbW9k
aWZpZWQgDQo+IGNoYXJ0ZXIgaXMgcHJvdmlkZWQgYmVsb3cgZm9yIGluZm9ybWF0aW9uYWwgcHVy
cG9zZXMgb25seS4gDQo+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIElFU0cgbWFp
bGluZyBsaXN0IA0KPiAoaWVzZ0BpZXRmLm9yZykgYnkgTWFyY2ggMTV0aC4NCj4gDQo+IFRoZSBJ
RVNHIHNvbGljaXRzIGZlZWRiYWNrIGZyb20gdGhvc2UgY29uc2lkZXJpbmcgDQo+IGltcGxlbWVu
dGluZyBvciBkZXBsb3lpbmcgc3lzbG9nIG9uIHRoZSBmb2xsb3dpbmcgY2hhcnRlci4gSW4gDQo+
IHBhcnRpY3VsYXIsIHRoZSBjb25jZXJuIGhhcyBiZWVuIHJhaXNlZCB0aGF0IGluc3VmZmljaWVu
dCANCj4gdmVuZG9ycyB3aWxsIGltcGxlbWVudCBhIG5ldyBzeXNsb2cgcHJvdG9jb2wgYW5kIGlu
c3VmZmljaWVudCANCj4gb3BlcmF0b3JzIHdpbGwgZGVwbG95IGl0LiBUaGUgSUVTRyByZXF1ZXN0
cyB0aG9zZSB3aG8gc3VwcG9ydCANCj4gdGhpcyBlZmZvcnQgdG8gZXhwbGljaXRseSBpbmRpY2F0
ZSB0aGVpciBzdXBwb3J0Lg0KPiBJZiBzaWduaWZpY2FudCBjb21tdW5pdHkgc3VwcG9ydCBpcyBu
b3QgaW5kaWNhdGVkLCB0aGlzIHdvcmsgDQo+IHdpbGwgbm90IGJlIGNoYXJ0ZXJlZC4NCj4gDQo+
ICsrKw0KPiANCj4gU2VjdXJpdHkgSXNzdWVzIGluIE5ldHdvcmsgRXZlbnQgTG9nZ2luZyAoc3lz
bG9nKSANCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+IA0KPiBDdXJy
ZW50IFN0YXR1czogQWN0aXZlIFdvcmtpbmcgR3JvdXANCj4gDQo+IENoYWlyKHMpOg0KPiBDaHJp
cyBMb252aWNrIDxjbG9udmlja0BjaXNjby5jb20+DQo+IA0KPiBTZWN1cml0eSBBcmVhIERpcmVj
dG9yKHMpOg0KPiBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29tPg0KPiBTYW0gSGFy
dG1hbiA8aGFydG1hbnMtaWV0ZkBtaXQuZWR1Pg0KPiANCj4gU2VjdXJpdHkgQXJlYSBBZHZpc29y
Og0KPiBTYW0gSGFydG1hbiA8aGFydG1hbnMtaWV0ZkBtaXQuZWR1Pg0KPiANCj4gTWFpbGluZyBM
aXN0czoNCj4gDQo+IEdlbmVyYWwgRGlzY3Vzc2lvbjogc3lzbG9nQGlldGYub3JnDQo+IFRvIFN1
YnNjcmliZTogc3lzbG9nLXJlcXVlc3RAaWV0Zi5vcmcNCj4gSW4gQm9keTogaW4gYm9keTogKHVu
KXN1YnNjcmliZQ0KPiBBcmNoaXZlOiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi1tYWlsLWFyY2hp
dmUvc3lzbG9nLw0KPiANCj4gRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCj4gDQo+IFN5
c2xvZyBpcyBhIGRlLWZhY3RvIHN0YW5kYXJkIGZvciBsb2dnaW5nIHN5c3RlbSBldmVudHMuIA0K
PiBIb3dldmVyLCB0aGUgcHJvdG9jb2wgY29tcG9uZW50IG9mIHRoaXMgZXZlbnQgbG9nZ2luZyBz
eXN0ZW0gDQo+IGhhcyBub3QgYmVlbiBmb3JtYWxseSBkb2N1bWVudGVkLiBXaGlsZSB0aGUgcHJv
dG9jb2wgaGFzIGJlZW4gDQo+IHZlcnkgdXNlZnVsIGFuZCBzY2FsYWJsZSwgaXQgaGFzIHNvbWUg
a25vd24gc2VjdXJpdHkgcHJvYmxlbXMgDQo+IHdoaWNoIHdlcmUgZG9jdW1lbnRlZCBpbiB0aGUg
SU5GT1JNQVRJT05BTCBSRkMgMzE2NC4NCj4gDQo+IFRoZSBnb2FsIG9mIHRoaXMgd29ya2luZyBn
cm91cCBpcyB0byBhZGRyZXNzIHRoZSBzZWN1cml0eSBhbmQgDQo+IGludGVncml0eSBwcm9ibGVt
cywgYW5kIHRvIHN0YW5kYXJkaXplIHRoZSBzeXNsb2cgcHJvdG9jb2wsIA0KPiB0cmFuc3BvcnQs
IGFuZCBhIHNlbGVjdCBzZXQgb2YgbWVjaGFuaXNtcyBpbiBhIG1hbm5lciB0aGF0IA0KPiBjb25z
aWRlcnMgdGhlIGVhc2Ugb2YgbWlncmF0aW9uIGJldHdlZW4gYW5kIHRoZSBjby1leGlzdGVuY2Ug
DQo+IG9mIGV4aXN0aW5nIHZlcnNpb25zIGFuZCB0aGUgc3RhbmRhcmQuDQo+IA0KPiBSZXZpZXdz
IGhhdmUgc2hvd24gdGhhdCB0aGVyZSBhcmUgdmVyeSBmZXcgc2ltaWxhcml0aWVzIA0KPiBiZXR3
ZWVuIHRoZSBtZXNzYWdlIGZvcm1hdHMgZ2VuZXJhdGVkIGJ5IGhldGVyb2dlbmVvdXMgDQo+IHN5
c3RlbXMuIEluIGZhY3QsIHRoZSBvbmx5IGNvbnNpc3RlbnQgY29tbW9uYWxpdHkgYmV0d2VlbiAN
Cj4gbWVzc2FnZXMgaXMgdGhhdCBhbGwgb2YgdGhlbSBjb250YWluIHRoZSA8UFJJPiBhdCB0aGUg
c3RhcnQuDQo+IEFkZGl0aW9uYWwgdGVzdGluZyBoYXMgc2hvd24gdGhhdCBhcyBsb25nIGFzIHRo
ZSA8UFJJPiBpcyANCj4gcHJlc2VudCBpbiBhIHN5c2xvZyBtZXNzYWdlLCBhbGwgdGVzdGVkIHJl
Y2VpdmVycyB3aWxsIGFjY2VwdCANCj4gYW55IGdlbmVyYXRlZCBtZXNzYWdlIGFzIGEgdmFsaWQg
c3lzbG9nIG1lc3NhZ2UuIEluIGRlc2lnbmluZyANCj4gYSBzdGFuZGFyZCBzeXNsb2cgbWVzc2Fn
ZSBmb3JtYXQsIHRoaXMgV29ya2luZyBHcm91cCB3aWxsIA0KPiByZXRhaW4gdGhlIDxQUkk+IGF0
IHRoZSBzdGFydCBvZiB0aGUgbWVzc2FnZSBhbmQgd2lsbCANCj4gaW50cm9kdWNlIHByb3RvY29s
IHZlcnNpb25pbmcuIEFsb25nIHRoZXNlIHNhbWUgbGluZXMsIG1hbnkgDQo+IGRpZmZlcmVudCBj
aGFyc2V0cyBoYXZlIGJlZW4gdXNlZCBpbiBzeXNsb2cgbWVzc2FnZXMgb2JzZXJ2ZWQgDQo+IGlu
IHRoZSB3aWxkIGJ1dCBubyBpbmRpY2F0aW9uIG9mIHRoZSBjaGFyc2V0IGhhcyBiZWVuIGdpdmVu
IA0KPiBpbiBhbnkgbWVzc2FnZS4gVGhlIFdvcmtpbmcgR3JvdXAgYWxzbyBmZWVscyB0aGF0IG11
bHRpcGxlIA0KPiBjaGFyc2V0cyB3aWxsIG5vdCBiZSBiZW5lZmljaWFsIHRvIHRoZSBjb21tdW5p
dHk7IG11Y2ggY29kZSANCj4gd291bGQgYmUgbmVlZGVkIHRvIGRpc3Rpbmd1aXNoIGFuZCBpbnRl
cnByZXQgZGlmZmVyZW50IGNoYXJzZXRzLg0KPiBGb3IgY29tcGF0aWJpbGl0eSB3aXRoIGV4aXN0
aW5nIGltcGxlbWVudGF0aW9ucywgdGhlIFdvcmtpbmcgDQo+IEdyb3VwIHdpbGwgYWxsb3cgdGhh
dCBtZXNzYWdlcyBtYXkgc3RpbGwgYmUgc2VudCB0aGF0IGRvIG5vdCANCj4gaW5kaWNhdGUgdGhl
IGNoYXJzZXQgdXNlZC4NCj4gSG93ZXZlciwgdGhlIFdvcmtpbmcgR3JvdXAgd2lsbCByZWNvbW1l
bmQgdGhhdCBtZXNzYWdlcyANCj4gY29udGFpbiBhIHdheSB0byBpZGVudGlmeSB0aGUgY2hhcnNl
dCB1c2VkIGZvciB0aGUgbWVzc2FnZSwgDQo+IGFuZCB3aWxsIGFsc28gcmVjb21tZW5kIGEgc2lu
Z2xlIGRlZmF1bHQgY2hhcnNldC4NCj4gDQo+IHN5c2xvZyBoYXMgdHJhZGl0aW9uYWxseSBiZWVu
IHRyYW5zcG9ydGVkIG92ZXIgVURQIGFuZCB0aGlzIA0KPiBXRyBoYXMgYWxyZWFkeSBkZWZpbmVk
IFJGQyAzMTk1IGZvciB0aGUgcmVsaWFibGUgdHJhbnNwb3J0IA0KPiBmb3IgdGhlIHN5c2xvZyBt
ZXNzYWdlcy4gVGhlIFdHIHdpbGwgc2VwYXJhdGUgdGhlIFVEUCANCj4gdHJhbnNwb3J0IGZyb20g
dGhlIHByb3RvY29sIHNvIHRoYXQgb3RoZXJzIG1heSBkZWZpbmUgDQo+IGFkZGl0aW9uYWwgdHJh
bnNwb3J0cyBpbiB0aGUgZnV0dXJlLg0KPiANCj4gVGhlIHRocmVhdHMgdGhhdCB0aGlzIFdHIHdp
bGwgcHJpbWFyaWx5IGFkZHJlc3MgYXJlIA0KPiBtb2RpZmljYXRpb24sIGRpc2Nsb3N1cmUsIGFu
ZCBtYXNxdWVyYWRpbmcuIEEgc2Vjb25kYXJ5IA0KPiB0aHJlYXQgaXMgbWVzc2FnZSBzdHJlYW0g
bW9kaWZpY2F0aW9uLiBUaHJlYXRzIHRoYXQgd2lsbCBub3QgDQo+IGJlIGFkZHJlc3NlZCBieSB0
aGlzIFdHIGFyZSBEb1MgYW5kIHRyYWZmaWMgYW5hbHlzaXMuIFRoZSANCj4gcHJpbWFyeSBhdHRh
Y2tzIG1heSBiZSB0aHdhcnRlZCBieSBhIHNlY3VyZSB0cmFuc3BvcnQuIA0KPiBIb3dldmVyLCBp
dCBtdXN0IGJlIHJlbWVtYmVyZWQgdGhhdCBhIGdyZWF0IGRlYWwgb2YgdGhlIA0KPiBzdWNjZXNz
IG9mIHN5c2xvZyBoYXMgYmVlbiBhdHRyaWJ1dGVkIHRvIGl0cyBlYXNlIG9mIA0KPiBpbXBsZW1l
bnRhdGlvbiBhbmQgcmVsYXRpdmVseSBsb3cgbWFpbnRlbmFuY2UgbGV2ZWwuIFRoZSANCj4gV29y
a2luZyBHcm91cCB3aWxsIGNvbnNpZGVyIHRob3NlIGZhY3RvcnMsIGFzIHdlbGwgYXMgY3VycmVu
dCANCj4gaW1wbGVtZW50YXRpb25zLCB3aGVuIGRlY2lkaW5nIHVwb24gYSBzZWN1cmUgdHJhbnNw
b3J0LiBUaGUgDQo+IHNlY29uZGFyeSB0aHJlYXQgb2YgbWVzc2FnZSBzdHJlYW0gbW9kaWZpY2F0
aW9uIGNhbiBiZSANCj4gYWRkcmVzc2VkIGJ5IGEgbWVjaGFuaXNtIHRoYXQgd2lsbCB2ZXJpZnkg
dGhlIGVuZC10by1lbmQgDQo+IGludGVncml0eSBhbmQgc2VxdWVuY2Ugb2YgbWVzc2FnZXMuIFRo
ZSBXb3JraW5nIEdyb3VwIGZlZWxzIA0KPiB0aGF0IHRoZXNlIGFzcGVjdHMgbWF5IGJlIGFkZHJl
c3NlZCBieSBhIGRpc3NvY2lhdGVkIA0KPiBzaWduYXR1cmUgdXBvbiBzZW50IG1lc3NhZ2VzLg0K
PiANCj4gLSBBIGRvY3VtZW50IHdpbGwgYmUgcHJvZHVjZWQgdGhhdCBkZXNjcmliZXMgYSBzdGFu
ZGFyZGl6ZWQgDQo+IHN5c2xvZyBwcm90b2NvbC4NCj4gQSBtZWNoYW5pc20gd2lsbCBhbHNvIGJl
IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCB0aGF0IHdpbGwgDQo+IHByb3ZpZGUgYSBtZWFucyB0
byBjb252ZXkgc3RydWN0dXJlZCBkYXRhLg0KPiANCj4gLSBBIGRvY3VtZW50IHdpbGwgYmUgcHJv
ZHVjZWQgdGhhdCBkZXNjcmliZXMgYSBzdGFuZGFyZGl6ZWQgDQo+IFVEUCB0cmFuc3BvcnQgZm9y
IHN5c2xvZy4NCj4gDQo+IC0gQSBkb2N1bWVudCB3aWxsIGJlIHByb2R1Y2VkIHRoYXQgcmVxdWly
ZXMgYSBzZWN1cmUgDQo+IHRyYW5zcG9ydCBmb3IgdGhlIGRlbGl2ZXJ5IG9mIHN5c2xvZyBtZXNz
YWdlcy4NCj4gDQo+IC0gQSBkb2N1bWVudCB3aWxsIGJlIHByb2R1Y2VkIHRvIGRlc2NyaWJlIHRo
ZSBNSUIgZm9yIHN5c2xvZyBlbnRpdGllcy4NCj4gDQo+IC0gQSBkb2N1bWVudCB3aWxsIGJlIHBy
b2R1Y2VkIHRoYXQgZGVzY3JpYmVzIGEgc3RhbmRhcmRpemVkIA0KPiBtZWNoYW5pc20gdG8gc2ln
biBzeXNsb2cgbWVzc2FnZXMgdG8gcHJvdmlkZSBpbnRlZ3JpdHkgDQo+IGNoZWNraW5nIGFuZCBz
b3VyY2UgYXV0aGVudGljYXRpb24uDQo+IA0KPiANCj4gTWlsZXN0b25lczoNCj4gDQo+IE5vdiAy
MDA2IFN1Ym1pdCBTeXNsb2cgUHJvdG9jb2wgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24g
DQo+IGFzIGEgUFJPUE9TRUQgU1RBTkRBUkQuDQo+IE5vdiAyMDA2IFN1Ym1pdCBTeXNsb2cgVURQ
IFRyYW5zcG9ydCBNYXBwaW5nIHRvIHRoZSBJRVNHIGZvciANCj4gY29uc2lkZXJhdGlvbiBhcyBh
IFBST1BPU0VEIFNUQU5EQVJELg0KPiBOb3YgMjAwNiBTdWJtaXQgU3lzbG9nIFRMUyBUcmFuc3Bv
cnQgTWFwcGluZyB0byB0aGUgSUVTRyBmb3IgDQo+IGNvbnNpZGVyYXRpb24gYXMgYSBQUk9QT1NF
RCBTVEFOREFSRC4NCj4gTm92IDIwMDYgU3VibWl0IFN5c2xvZyBEZXZpY2UgTUlCIHRvIElFU0cg
Zm9yIGNvbnNpZGVyYXRpb24gDQo+IGFzIGEgUFJPUE9TRUQgU1RBTkRBUkQuDQo+IE5vdiAyMDA2
IFN1Ym1pdCBhIGRvY3VtZW50IHRoYXQgZGVmaW5lcyBhIG1lc3NhZ2Ugc2lnbmluZyBhbmQgDQo+
IG9yZGVyaW5nIG1lY2hhbmlzbSB0byB0aGUgSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBhIA0K
PiBQUk9QT1NFRCBTVEFOREFSRA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU3lzbG9nIG1haWxp
bmcgbGlzdA0KPiBTeXNsb2dAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vc3lzbG9nDQo+IA0K


--===============0745853858==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

--===============0745853858==--



From syslog-bounces@lists.ietf.org Wed Mar 15 04:26:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJSHI-0006WZ-E2; Wed, 15 Mar 2006 04:26:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSHH-0006WU-1a
	for syslog@ietf.org; Wed, 15 Mar 2006 04:26:47 -0500
Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJSGl-0002Gp-9G
	for syslog@ietf.org; Wed, 15 Mar 2006 04:26:47 -0500
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IW500F4KX2IEX@szxga01-in.huawei.com> for
	syslog@ietf.org; Wed, 15 Mar 2006 17:30:18 +0800 (CST)
Received: from szxml01-in ([172.24.1.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IW50045VX2GJH@szxga01-in.huawei.com> for
	syslog@ietf.org; Wed, 15 Mar 2006 17:30:18 +0800 (CST)
Received: from m19684 ([10.111.12.90])
	by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0IW500HB7XC822@szxml01-in.huawei.com> for
	syslog@ietf.org; Wed, 15 Mar 2006 17:36:09 +0800 (CST)
Date: Wed, 15 Mar 2006 17:19:29 +0800
From: Miao Fuyou <miaofy@huawei.com>
To: syslog@ietf.org
Message-id: <001d01c64811$904a2520$5a0c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: multipart/mixed; boundary="Boundary_(ID_j/AbXXz8XBLzp5sdK0JEjQ)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08aa56e70047071f9a3037af5750d40e
Cc: 
Subject: [Syslog] Preliminary syslog-transport-tls document
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--Boundary_(ID_j/AbXXz8XBLzp5sdK0JEjQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi, 

The TLS transport draft now is ready for your comments and recommodations.
Some issues are identified in the documents, which should be discussed in
the mailing list. I list the issues here. 

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

   [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?

   [Issue 3] The problem of CR LF is it can not process binary data
   well.  How to process Syslog signature/certificate message?

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

Sorry for attaching, once IETF lifts the limitation of internet-draft
publish after IETF conference #65 , I will get it published. 

Regards
Miao 

--Boundary_(ID_j/AbXXz8XBLzp5sdK0JEjQ)
Content-type: text/plain; name=draft-miao-syslog-transport-tls-00.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment;
	filename=draft-miao-syslog-transport-tls-00.txt





SYSLOG Working Group                                             F. Miao
Internet-Draft                                                  M. Yuzhi
Expires: September 16, 2006                          Huawei Technologies
                                                          March 15, 2006


                    TLS Transport Mapping for SYSLOG
                 draft-miao-syslog-transport-tls-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 16, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes the security threats to Syslog and counter
   measures of using Transport Layer Security(TLS) protocol for such
   threats.  Different phases are defined for using TLS to secure
   Syslog, such as initiation, sending data and closure phase.







Miao & Yuzhi           Expires September 16, 2006               [Page 1]

Internet-Draft      TLS Transport Mapping for SYSLOG          March 2006


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Security Requirement of Syslog . . . . . . . . . . . . . . . .  3
   3.  Introduction of TLS  . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  How TLS works  . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Security Properties  . . . . . . . . . . . . . . . . . . .  4
   4.  TLS to secure Syslog . . . . . . . . . . . . . . . . . . . . .  5
   5.  Protocol Elements  . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  protocol Port  . . . . . . . . . . . . . . . . . . . . . .  5
     5.2.  Initiation . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.3.  Sending data . . . . . . . . . . . . . . . . . . . . . . .  7
     5.4.  Closure  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Consideration . . . . . . . . . . . . . . . . . . . .  7
     6.1.  TLS and Syslog Signature . . . . . . . . . . . . . . . . .  7
     6.2.  Authentication . . . . . . . . . . . . . . . . . . . . . .  8
     6.3.  TLS Session Resumption . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11




























Miao & Yuzhi           Expires September 16, 2006               [Page 2]

Internet-Draft      TLS Transport Mapping for SYSLOG          March 2006


1.  Terminology

   The following definitions are used in this document:

   o  A sender is an application that can generate and send or forward a
      Syslog [2] message from an application to another application.
      Note: the definition of sender is different from syslog-protocol.

   o  A receiver is an application that can receive a Syslog message.

   o  A originator is an application that can generate a Syslog message.

   o  A relay is an application that can receive syslog messages and
      forward them to another receiver.  A relay will be both a sender
      and receiver.

   o  A collector is an application that receives messages and does not
      relay them to any other receiver.

   o  A TLS client is an application that initiate a TLS connection by
      sending a Client Hello to a peer.

   o  A TLS server is an application that receives a Client Hello from a
      peer and replies with a Server Hello.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1]


2.  Security Requirement of Syslog

   Syslog messages may pass several hops to arrive at the intended
   receiver.  Some intermediary networks may not be trusted by the
   sender or the receiver or both because the network is in a different
   security domain or at a different security level from the receiver or
   sender.  Another security concern is that the sender or receiver
   itself is in an insecure network.

   There are several threats to be addressed for Syslog security.  The
   primary threats are:

   o  Masquerade.  An unauthorized sender may send messages to a
      legitimate receiver, or an unauthorized receiver tries to deceive
      a legitimate sender into sending Syslog messages to it.

   o  Modification.  An attacker between the sender and receiver may
      modify an in-transit Syslog message from the sender and then



Miao & Yuzhi           Expires September 16, 2006               [Page 3]

Internet-Draft      TLS Transport Mapping for SYSLOG          March 2006


      forward the message to receiver.  Such modification may make the
      receiver misunderstand the message or cause the receiver to behave
      in undesirable ways.

   o  Disclosure.  An unauthorized entity may examine the content of the
      Syslog messages, gaining unauthorized access to the information.
      Some data of Syslog message may be trivial for a potential
      attacker, but some data may be critical to launch an attack, such
      as the password of an authorized administrator or user.

   The secondary threat is:

   o  Message stream modification.  An attacker may delete a Syslog
      message from a series of messages, replay message or alter the
      delivery sequence.  Syslog protocol itself is not based on flow,
      but it is possible that an event in a Syslog message semantically
      relates to other events in other messages.

   The following threats are deemd to be of lesser importance for
   syslog, and are not addressed in this document:

   o  Denial of Service

   o  Traffic Analysis


3.  Introduction of TLS

3.1.  How TLS works

   TLS [3] establishes a private end-to-end connection, optionally
   including strong mutual authentication, using a variety of
   cryptosystems.  Initially, a handshake phase uses three subprotocols
   to set up a record layer, authenticate endpoints, set parameters, as
   well as report errors.  Then, there is an ongoing layered record
   protocol that handles encryption, compression, and reassembly for the
   remainder of the connection.  An application data protocol, such as
   Syslog, is layered on the record protocol.

3.2.  Security Properties

   TLS record protocol is used to encapsulate various higher level
   protocols.  It provides connection security with confidentiality,
   integrity, authentication, and replay prevention.

   Confidentiality is provided using symmetric cryptography for data
   encryption.  TLS supports both stream cipher and block cipher.  The
   key for encryption is derived from a secret established by the



Miao & Yuzhi           Expires September 16, 2006               [Page 4]

Internet-Draft      TLS Transport Mapping for SYSLOG          March 2006


   handshake protocol.  The secret is kept private even if there is an
   eavesdropper in the middle.

   Integrity is provided by using HMAC [5] (computed with secure hash
   function) to check the integrity of a message.  Modification without
   the appropriate key is detectable.

   Authentication is provided by a handshake protocol.  The peer's
   identity is authenticated using certificate and signature, based on
   asymmetric cryptography.

   Replay prevention is provided by using a Sequence Number in each TLS
   record which is used to detect potential delete and replay of a
   record or alteration of the delivery sequence.


4.  TLS to secure Syslog

   UDP transport [6] is popular for Syslog, but it does not address
   security.  TLS can be used to counter all the major and secondary
   threats to Syslog described in section 2:

   o  Confidentiality to counter disclosure to message

   o  Integrity check to counter modification to message

   o  Peer identity authentication to counter masquerade

   o  Sequence number along with integrity check to counter message
      stream modification

   The security service is also applicable to BSD Syslog defined in
   RFC3164 [9].  But, it is not ensured that the protocol specification
   defined in this document applicable to BSD Syslog.


5.  Protocol Elements

5.1.  protocol Port

   A Syslog sender is always a TLS client and a Syslog receiver is
   always a TLS server.  Similiar to RFC2818 [8], a special listening
   port is allocated for Syslog over TLS.  A Syslog receiver with TLS
   transport listens on TCP port NNN, which will be IANA-assigned.

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



Miao & Yuzhi           Expires September 16, 2006               [Page 5]

Internet-Draft      TLS Transport Mapping for SYSLOG          March 2006


5.2.  Initiation

   The sender should initiate a connection to the receiver and then send
   the TLS Client Hello to begin the TLS handshake.  When the TLS
   handshake has finished the Sender may then send the first Syslog
   message.

   TLS uses certificate [4] to authenticate the peers.  When sender
   authenticates a receiver it MUST check the common name(CN) of the
   certificate against the host name of the receiver.  If the common
   name does not match the host name, the sender MUST send an
   "access_denied" error alert with TLS alert protocol to terminate
   handshake, and then close the connection.

   When a receiver authenticates a sender, the common name of the
   certificate SHOULD be checked.  If the certificate is not a generic
   certificate and the common name does not match the host name, the
   receiver MAY send an "access_denied" error alert with TLS alert
   protocol to terminate handshake, and then close the connection.  If
   the certificate is a generic certificate, the check MUST be executed
   when processing a Syslog message.  If the APP-NAME of a Syslog
   message does not match the name of the common name of the sender's
   certificate, the receiver MAY send an "access_denied" error alert
   with TLS alert protocol and close the on-going connection.

   [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?

   An administrator should decide what security level (e.g.
   cryptographic algorithms and length of keys) is required.  It is
   local policy and up to administrator's decision.  Syslog applications
   should be implemented in a manner that permits administrators to
   select the cryptographic level they desire.

   An earlier TLS session or another active session MAY be resumed to
   save the effort of TLS handshake.  The security parameters of a
   resumed session are reused for the current session.  The certificate
   MUST be checked when resuming a session.  If the resumed session and
   current session use different certificates, resumption MUST not
   happen.






Miao & Yuzhi           Expires September 16, 2006               [Page 6]

Internet-Draft      TLS Transport Mapping for SYSLOG          March 2006


5.3.  Sending data

   All Syslog messages MUST be sent as TLS "application data".  There
   MAY be multiple Syslog message in same TLS record.  At the end of
   each Syslog message, there MUST be CR LF control characters to
   indicate the termination of a Syslog message.  The last Syslog
   message in a TLS record MUST NOT end with CR LF termination.

   [Issue 3] The problem of CR LF is it can not process binary data
   well.  How to process Syslog signature/certificate message?

5.4.  Closure

   A sender MUST close a connection if it is not using the connection.
   It MUST send a TLS closure_notify alert before closing the
   connection.  A sender MAY choose not to wait for the receiver's
   closure_notify alert and simply close the connection, thus generating
   an incomplete close on the receiver side.  Once the receiver gets
   closure_notify from the sender, it MUST reply with a closure_notify
   unless it becomes aware of the connection is already closed by sender
   (e.g. indicated by TCP).

   When there are no data received from a connection for a long time (it
   is up to the application to decide what "long" means), a receiver MAY
   close a connection.  The receiver MUST attempt to initiate an
   exchange of closure_notify alerts with the sender before closing the
   connection.  Receivers that are unprepared to receive any more data
   MAY close the connection after sending the closure_notify alert, thus
   generating an incomplete close on the sender side.  When the sender
   has received the closure_notify alert from the receiver and still has
   pending data to send, sender SHOULD send the pending data before
   sending closure_notify alert.


6.  Security Consideration

6.1.  TLS and Syslog Signature

   TLS transport and Syslog signature[7] address quite different
   security requirements.  Basically Syslog signature is between an
   originator and a collector.  Contrastively TLS transport is between
   sender and receiver.  The Peer identity authentication of TLS checks
   whether the data is received from a legitimate Syslog peer (message
   originator or relay), but Syslog signature checks whether the data
   generated by a specific originator.  It is possible that
   administrator to enable both TLS and signature to meet specific
   requirement.




Miao & Yuzhi           Expires September 16, 2006               [Page 7]

Internet-Draft      TLS Transport Mapping for SYSLOG          March 2006


6.2.  Authentication

   TLS authentication and secret establishing is based on certificates
   and asymmetric cryptography, and it makes TLS transport is much more
   costly than UDP transport.  An attacker may initialize and keep a lot
   of TLS connection to the receiver to launch a denial of service
   attack.  A receiver SHOULD authenticate the identity of a sender to
   mitigate such attack.

   A sender MAY authenticate the identity of a receiver.  When
   confidentiality is a concern and data encryption is chosen, the
   receiver MUST be authenticated by the Sender to make sure it is
   talking to the right peer.

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

6.3.  TLS Session Resumption

   Different applications in same host may have different security level
   (e.g. kernel may have higher security level than a document editor).
   The application can decrypt the Syslog messages of a resuming or
   resumed session with same cipher parameters.  When a session is being
   resumed from an application in a different security level care must
   be taken to avoid sensitive data is disclosed to unauthorized
   application.  A sensitive session must not be resumable.


7.  Acknowledgments

   Authors appreciate Anton Okmianski for his ideas on certificate, and
   Balazs Scheidler, Tom Petch and other persons because of their input
   on security threats of Syslog.  The author would like to acknowledge
   David Harrington for his detailed reviews of the content and grammar
   of the document.


8.  References

8.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Gerhards, R., "The syslog Protocol",
        draft-ietf-syslog-protocol-16 (work in progress), January 2006.

   [3]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",



Miao & Yuzhi           Expires September 16, 2006               [Page 8]

Internet-Draft      TLS Transport Mapping for SYSLOG          March 2006


        RFC 2246, January 1999.

   [4]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
        Public Key Infrastructure Certificate and Certificate Revocation
        List (CRL) Profile", RFC 3280, April 2002.

   [5]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
        for Message Authentication", RFC 2104, February 1997.

8.2.  Informative References

   [6]  Okmianski, A., "Transmission of syslog messages over UDP",
        draft-ietf-syslog-transport-udp-06 (work in progress),
        November 2005.

   [7]  Kelsey, J., "Signed syslog Messages", draft-ietf-syslog-sign-17
        (work in progress), November 2005.

   [8]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [9]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.






























Miao & Yuzhi           Expires September 16, 2006               [Page 9]

Internet-Draft      TLS Transport Mapping for SYSLOG          March 2006


Authors' Addresses

   Fuyou Miao
   Huawei Technologies
   No. 3, Xinxi Rd
   Shangdi Information Industry Base
   Haidian District, Beijing  100085
   P. R. China

   Phone: +86 10 8283 6032
   Email: miaofy@huawei.com
   URI:   www.huawei.com


   Yuzhi Ma
   Huawei Technologies
   No. 3, Xinxi Rd
   Shangdi Information Industry Base
   Haidian District, Beijing  100085
   P. R. China

   Phone: +86 10 8283 6033
   Email: myz@huawei.com
   URI:   www.huawei.com



























Miao & Yuzhi           Expires September 16, 2006              [Page 10]

Internet-Draft      TLS Transport Mapping for SYSLOG          March 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Miao & Yuzhi           Expires September 16, 2006              [Page 11]



--Boundary_(ID_j/AbXXz8XBLzp5sdK0JEjQ)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

--Boundary_(ID_j/AbXXz8XBLzp5sdK0JEjQ)--




From syslog-bounces@lists.ietf.org Wed Mar 15 04:55:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJSjU-0005Sq-U6; Wed, 15 Mar 2006 04:55:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSjT-0005Pf-9K
	for syslog@ietf.org; Wed, 15 Mar 2006 04:55:55 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJSjQ-0002oZ-Vw
	for syslog@ietf.org; Wed, 15 Mar 2006 04:55:55 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id 043E527C065;
	Wed, 15 Mar 2006 10:01:43 +0100 (CET)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 29694-01; Wed, 15 Mar 2006 10:01:42 +0100 (CET)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id BA55327C061;
	Wed, 15 Mar 2006 10:01:42 +0100 (CET)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Wed, 15 Mar 2006 10:55:48 +0100
Content-class: urn:content-classes:message
Subject: RE: [Syslog] Preliminary syslog-transport-tls document - issue 3
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 15 Mar 2006 10:55:38 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1741D3@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Preliminary syslog-transport-tls document - issue 3
Thread-Index: AcZIEqPZWrhsu++HTYm1l9xNIs/uxgAA2IXA
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Miao Fuyou" <miaofy@huawei.com>
X-OriginalArrivalTime: 15 Mar 2006 09:55:48.0617 (UTC)
	FILETIME=[A2E70F90:01C64816]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Miao,

thanks for the great (and quick) work. I can not review it fully right
now, but I have seen one issue that I would like to comment immediately
on. More comments follow later.

>    [Issue 3] The problem of CR LF is it can not process binary data
>    well.  How to process Syslog signature/certificate message?

With the current status of syslog-protocol, you can NOT do
octet-stuffing. The reason is that any character is valid inside MSG and
this includes the CR LF sequence.=20

So we have two options:

1. change -protocol to disallow CR LF
2. use byte-counting for framing in -tls

Option 1 has been discussed in the past and mostly been rejected.
However, this is the first time that we have a real standardization use
case for excluding it. Currently existing (non-standard) syslog/TCP uses
CR LF (or lone LF) as record delimiter. So it might be useful to take
that route.

Option 2 has the advantage of greater aplicability plus enables the
application developer to use more efficient buffering (as the needed
buffer space is known in advance).

I have no strong opinion which option is better, but I tend a little bit
to option 2.

Rainer

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Wed Mar 15 05:22:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJT9O-0001x5-K3; Wed, 15 Mar 2006 05:22:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJT9O-0001x0-5G
	for syslog@ietf.org; Wed, 15 Mar 2006 05:22:42 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJT9I-0003fi-RO
	for syslog@ietf.org; Wed, 15 Mar 2006 05:22:42 -0500
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IW5005PLZIMD6@szxga02-in.huawei.com> for
	syslog@ietf.org; Wed, 15 Mar 2006 18:23:10 +0800 (CST)
Received: from szxml02-in ([172.24.1.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IW5007Z8ZIMQL@szxga02-in.huawei.com> for
	syslog@ietf.org; Wed, 15 Mar 2006 18:23:10 +0800 (CST)
Received: from m19684 ([10.111.12.90])
	by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0IW50016SZICA7@szxml02-in.huawei.com>; Wed,
	15 Mar 2006 18:23:00 +0800 (CST)
Date: Wed, 15 Mar 2006 18:09:59 +0800
From: Miao Fuyou <miaofy@huawei.com>
Subject: FW: [Syslog] Preliminary syslog-transport-tls document - issue 3
To: 'Rainer Gerhards' <rgerhards@hq.adiscon.com>
Message-id: <002a01c64818$9e9779a0$5a0c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org


Thanks for your quick response!

Comments inline!

> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> Sent: Wednesday, March 15, 2006 5:56 PM
> To: Miao Fuyou
> Cc: syslog@ietf.org
> Subject: RE: [Syslog] Preliminary syslog-transport-tls 
> document - issue 3
> 
> 
> Miao,
> 
> thanks for the great (and quick) work. I can not review it
> fully right now, but I have seen one issue that I would like 
> to comment immediately on. More comments follow later.
> 
> >    [Issue 3] The problem of CR LF is it can not process binary data
> >    well.  How to process Syslog signature/certificate message?
> 
> With the current status of syslog-protocol, you can NOT do
> octet-stuffing. The reason is that any character is valid 
> inside MSG and this includes the CR LF sequence. 
> 
> So we have two options:
> 
> 1. change -protocol to disallow CR LF
> 2. use byte-counting for framing in -tls
> 
> Option 1 has been discussed in the past and mostly been
> rejected. However, this is the first time that we have a real 
> standardization use case for excluding it. Currently existing 
> (non-standard) syslog/TCP uses CR LF (or lone LF) as record 
> delimiter. So it might be useful to take that route.
> 

It is possible that Syslog-sign co-exists with TLS transport, so I think
there is difficulty for disallowing CR LF. 

> Option 2 has the advantage of greater aplicability plus 
> enables the application developer to use more efficient 
> buffering (as the needed buffer space is known in advance).
> 
> I have no strong opinion which option is better, but I tend a 
> little bit to option 2.
> 
> Rainer
> 


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Wed Mar 15 17:25:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJeRH-0003ED-HN; Wed, 15 Mar 2006 17:25:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJeRG-0003DK-8J
	for syslog@ietf.org; Wed, 15 Mar 2006 17:25:54 -0500
Received: from test-iport-1.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJeRD-0001eG-Pz
	for syslog@ietf.org; Wed, 15 Mar 2006 17:25:54 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by test-iport-1.cisco.com with ESMTP; 15 Mar 2006 14:25:51 -0800
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2FMPoGw002481;
	Wed, 15 Mar 2006 14:25:51 -0800 (PST)
Date: Wed, 15 Mar 2006 14:25:50 -0800 (PST)
From: Chris Lonvick <clonvick@cisco.com>
To: Rainer Gerhards <rgerhards@hq.adiscon.com>
Subject: Framing in syslog messages - RE: [Syslog] Preliminary
	syslog-transport-tls document - issue 3
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1741D3@grfint2.intern.adiscon.com>
Message-ID: <Pine.GSO.4.63.0603151040150.29053@sjc-cde-011.cisco.com>
References: <577465F99B41C842AAFBE9ED71E70ABA1741D3@grfint2.intern.adiscon.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Hi,

This is an issue that we need to discuss.  I've had some discussions with 
various people on this subject who's opinions I trust.  They also suggest 
that we do have 2 options as Rainer states.  Let me describe this in a bit 
more detail:

The consensus from all is that syslog-protocol should not explain how to 
have multiple syslog messages in each packet.  That should be done in each 
of the transport documents so that transport mechanisms can frame the 
messages.  This ensures a good fit if syslog is placed into a new 
transport that already has a framing mechanism.  This is how it has been 
done in RFC 3195.

As Rainer says, we can reserve a character or characters to separate 
messages.  We could use ASCII characters such as CRLF or we could use a 
UTF8 character.  See:
   http://www.unicode.org/faq/utf_bom.html       and
   http://www.unicode.org/reports/tr14/index.html
This would require that we place a very strong message in the Security 
Considerations section of each transport document that would warn against 
an inappropriate use of the separator character(s).  For example, if CRLF 
is chosen as the separator, the receiver may get a message with a CRLF in 
it that does not signify a separation of messages.  This will probably go 
away with time as more poeple adopt to the standard.

Alternatively, we could count bytes to show the end of a message.  The 
receiver would count to that point and decide if there is another message 
after that.  Having this option would not require any additional messages 
in the Security Considerations section as there would be no doubt about 
the end of a message.

I want to open this discussion to the group.  If we can agree to some 
mechanism then we'll get Anton, Fuyou and Yuzhi to put this into their 
IDs.

I will say that the WG is not addressing the transport of binary messages 
at this time.  However, I know that it's a concern of this group and I 
would hope that the people who think about this take that thought into 
consideration when they send in their comments.

Thanks,
Chris


On Wed, 15 Mar 2006, Rainer Gerhards wrote:

> Miao,
>
> thanks for the great (and quick) work. I can not review it fully right
> now, but I have seen one issue that I would like to comment immediately
> on. More comments follow later.
>
>>    [Issue 3] The problem of CR LF is it can not process binary data
>>    well.  How to process Syslog signature/certificate message?
>
> With the current status of syslog-protocol, you can NOT do
> octet-stuffing. The reason is that any character is valid inside MSG and
> this includes the CR LF sequence.
>
> So we have two options:
>
> 1. change -protocol to disallow CR LF
> 2. use byte-counting for framing in -tls
>
> Option 1 has been discussed in the past and mostly been rejected.
> However, this is the first time that we have a real standardization use
> case for excluding it. Currently existing (non-standard) syslog/TCP uses
> CR LF (or lone LF) as record delimiter. So it might be useful to take
> that route.
>
> Option 2 has the advantage of greater aplicability plus enables the
> application developer to use more efficient buffering (as the needed
> buffer space is known in advance).
>
> I have no strong opinion which option is better, but I tend a little bit
> to option 2.
>
> Rainer
>
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Wed Mar 15 17:55:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJetO-00066P-Kx; Wed, 15 Mar 2006 17:54:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJetN-00066F-59
	for syslog@ietf.org; Wed, 15 Mar 2006 17:54:57 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJetL-0002ql-SG
	for syslog@ietf.org; Wed, 15 Mar 2006 17:54:57 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-2.cisco.com with ESMTP; 15 Mar 2006 14:54:55 -0800
X-IronPort-AV: i="4.02,196,1139212800"; 
	d="scan'208"; a="314658468:sNHT30753596"
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2FMstw2010657
	for <syslog@ietf.org>; Wed, 15 Mar 2006 14:54:55 -0800 (PST)
Date: Wed, 15 Mar 2006 14:54:55 -0800 (PST)
From: Chris Lonvick <clonvick@cisco.com>
To: syslog@ietf.org
Message-ID: <Pine.GSO.4.63.0603151451240.29053@sjc-cde-011.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 
Subject: [Syslog] [logs] computerworld article: Making the case for an audit
 standard (fwd)
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Hi,

Just FYI - The article is about the US NIST's effort to standardize event 
message formats.  The link to the NIST workshop is:

   http://csrc.nist.gov/CLIX/

Thanks,
Chris


---------- Forwarded message ----------
Date: Wed, 15 Mar 2006 10:40:37 -0800
From: Jian Zhen <jlz@zhen.org>
To: loganalysis@lists.shmoo.com
Subject: [logs] computerworld article: Making the case for an audit standard

An interesting article by Oracle's CSO on audit and logging standard.

http://www.computerworld.com/printthis/2006/0,4814,109554,00.html

just an FYI

_______________________________________________
LogAnalysis mailing list
LogAnalysis@lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/loganalysis

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Thu Mar 16 04:48:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJp60-0003EY-DA; Thu, 16 Mar 2006 04:48:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJp5z-0003ET-6P
	for syslog@ietf.org; Thu, 16 Mar 2006 04:48:39 -0500
Received: from balabit.hu ([195.70.34.196])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJp5x-0003B1-Lk
	for syslog@ietf.org; Thu, 16 Mar 2006 04:48:39 -0500
Subject: Re: Framing in syslog messages - RE: [Syslog] Preliminary
	syslog-transport-tls document - issue 3
From: Balazs Scheidler <bazsi@balabit.hu>
To: Chris Lonvick <clonvick@cisco.com>
In-Reply-To: <Pine.GSO.4.63.0603151040150.29053@sjc-cde-011.cisco.com>
References: <577465F99B41C842AAFBE9ED71E70ABA1741D3@grfint2.intern.adiscon.com>
	<Pine.GSO.4.63.0603151040150.29053@sjc-cde-011.cisco.com>
Content-Type: text/plain
Date: Thu, 16 Mar 2006 10:48:35 +0100
Message-Id: <1142502515.6882.12.camel@bzorp.balabit>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

On Wed, 2006-03-15 at 14:25 -0800, Chris Lonvick wrote:
> I will say that the WG is not addressing the transport of binary messages 
> at this time.  However, I know that it's a concern of this group and I 
> would hope that the people who think about this take that thought into 
> consideration when they send in their comments.

The only argument for CRLF is its use in current (non-standard)
syslog/tcp implementations (syslog-ng, PIX, NetScreen, Adiscon, etc.).

If I'd start from scratch I would also use some kind of byte-count based
framing.

I'm also undecided :)

How would that framing look like? Binary or text? Would we limit the
size of the frame length (effectively limiting the frame size itself)?
How about adding some kind of application layer acknowledgement support?

What this boils down in my mind is: do we get any additional benefits
from using a more complex framing, as opposed to using CRLF for this
purpose which is filtered out from logfiles anyway?

I see the following possible upsides of using some kind of framing:
* byte-counted messages, effectively allowing the use of the full
character set
* application layer acknowledgements, avoid losing messages sitting in
the TCP socket buffers without knowing that they were not really sent.
* control messages
* multiplexed channels

The question is which ones do we want to implement and how this
correlates with the previous work on BEEP.

-- 
Bazsi


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Thu Mar 16 06:12:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJqP2-0001Ox-1l; Thu, 16 Mar 2006 06:12:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJqP0-0001K7-NJ
	for syslog@ietf.org; Thu, 16 Mar 2006 06:12:22 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJqOz-0005aP-7C
	for syslog@ietf.org; Thu, 16 Mar 2006 06:12:22 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id C0AB327C069;
	Thu, 16 Mar 2006 11:18:07 +0100 (CET)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 23239-02; Thu, 16 Mar 2006 11:18:07 +0100 (CET)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id 85F3727C067;
	Thu, 16 Mar 2006 11:18:07 +0100 (CET)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Thu, 16 Mar 2006 12:12:18 +0100
Content-class: urn:content-classes:message
Subject: RE: Framing in syslog messages - RE: [Syslog]
	Preliminarysyslog-transport-tls document - issue 3
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 16 Mar 2006 12:12:18 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1741F3@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Framing in syslog messages - RE: [Syslog]
	Preliminarysyslog-transport-tls document - issue 3
Thread-Index: AcZI3tGqvIT163pCQCClh4Xjy7tHmwAC0byA
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Balazs Scheidler" <bazsi@balabit.hu>, "Chris Lonvick" <clonvick@cisco.com>
X-OriginalArrivalTime: 16 Mar 2006 11:12:18.0551 (UTC)
	FILETIME=[7D212870:01C648EA]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Baszi,=20

> I see the following possible upsides of using some kind of framing:
> * byte-counted messages, effectively allowing the use of the full
> character set
> * application layer acknowledgements, avoid losing messages sitting in
> the TCP socket buffers without knowing that they were not really sent.
> * control messages
> * multiplexed channels
>=20
> The question is which ones do we want to implement and how this
> correlates with the previous work on BEEP.

Honestly, I think if we take that route, we can simply implement RFC
3195. Actually, it offers all this and I do not see any way it could be
done with much less effort than already done in RFC 3195. BEEP looks
complex, but it is not all that bad once you nail it down.=20

For this discussion thread, I think we are looking at a very simplistic
SSL based transport.

Rainer

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Thu Mar 16 10:37:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJuXC-0006Cv-P2; Thu, 16 Mar 2006 10:37:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuXB-0006Co-KJ
	for syslog@ietf.org; Thu, 16 Mar 2006 10:37:05 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJuX9-0005vt-3W
	for syslog@ietf.org; Thu, 16 Mar 2006 10:37:05 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-4.cisco.com with ESMTP; 16 Mar 2006 07:37:03 -0800
X-IronPort-AV: i="4.02,198,1139212800"; 
	d="scan'208"; a="1785519674:sNHT33156628"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2GFb1Yg024089;
	Thu, 16 Mar 2006 07:37:02 -0800 (PST)
Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 16 Mar 2006 10:37:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Framing in syslog messages - RE: [Syslog]
	Preliminarysyslog-transport-tls document - issue 3
Date: Thu, 16 Mar 2006 10:36:59 -0500
Message-ID: <98AE08B66FAD1742BED6CB9522B7312201319757@xmb-rtp-20d.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Framing in syslog messages - RE: [Syslog]
	Preliminarysyslog-transport-tls document - issue 3
Thread-Index: AcZIf3YRcgtAMYFOTlGii8EG74K3JwAj2GuQ
From: "Anton Okmianski \(aokmians\)" <aokmians@cisco.com>
To: "Chris Lonvick \(clonvick\)" <clonvick@cisco.com>,
	"Rainer Gerhards" <rgerhards@hq.adiscon.com>
X-OriginalArrivalTime: 16 Mar 2006 15:37:00.0782 (UTC)
	FILETIME=[77AD48E0:01C6490F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

My 2 cents... Do the byte counting. Look at the headers of pretty much =
any successful protocol (TCP, IP, UDP, etc) - they all specify length of =
payload.  Special character sequence is really a hack IMO! =20

Just to be clear, there was never any intention to allow multiple =
messages per UDP datagram.  So, this discussion probably does not apply =
to the UDP transport mapping.=20

Thanks,
Anton.=20

> -----Original Message-----
> From: Chris Lonvick (clonvick)=20
> Sent: Wednesday, March 15, 2006 5:26 PM
> To: Rainer Gerhards
> Cc: syslog@ietf.org
> Subject: Framing in syslog messages - RE: [Syslog]=20
> Preliminarysyslog-transport-tls document - issue 3
>=20
> Hi,
>=20
> This is an issue that we need to discuss.  I've had some=20
> discussions with various people on this subject who's=20
> opinions I trust.  They also suggest that we do have 2=20
> options as Rainer states.  Let me describe this in a bit more detail:
>=20
> The consensus from all is that syslog-protocol should not=20
> explain how to have multiple syslog messages in each packet. =20
> That should be done in each of the transport documents so=20
> that transport mechanisms can frame the messages.  This=20
> ensures a good fit if syslog is placed into a new transport=20
> that already has a framing mechanism.  This is how it has=20
> been done in RFC 3195.
>=20
> As Rainer says, we can reserve a character or characters to=20
> separate messages.  We could use ASCII characters such as=20
> CRLF or we could use a
> UTF8 character.  See:
>    http://www.unicode.org/faq/utf_bom.html       and
>    http://www.unicode.org/reports/tr14/index.html
> This would require that we place a very strong message in the=20
> Security Considerations section of each transport document=20
> that would warn against an inappropriate use of the separator=20
> character(s).  For example, if CRLF is chosen as the=20
> separator, the receiver may get a message with a CRLF in it=20
> that does not signify a separation of messages.  This will=20
> probably go away with time as more poeple adopt to the standard.
>=20
> Alternatively, we could count bytes to show the end of a=20
> message.  The receiver would count to that point and decide=20
> if there is another message after that.  Having this option=20
> would not require any additional messages in the Security=20
> Considerations section as there would be no doubt about the=20
> end of a message.
>=20
> I want to open this discussion to the group.  If we can agree=20
> to some mechanism then we'll get Anton, Fuyou and Yuzhi to=20
> put this into their IDs.
>=20
> I will say that the WG is not addressing the transport of=20
> binary messages at this time.  However, I know that it's a=20
> concern of this group and I would hope that the people who=20
> think about this take that thought into consideration when=20
> they send in their comments.
>=20
> Thanks,
> Chris
>=20
>=20
> On Wed, 15 Mar 2006, Rainer Gerhards wrote:
>=20
> > Miao,
> >
> > thanks for the great (and quick) work. I can not review it=20
> fully right=20
> > now, but I have seen one issue that I would like to comment=20
> > immediately on. More comments follow later.
> >
> >>    [Issue 3] The problem of CR LF is it can not process binary data
> >>    well.  How to process Syslog signature/certificate message?
> >
> > With the current status of syslog-protocol, you can NOT do=20
> > octet-stuffing. The reason is that any character is valid=20
> inside MSG=20
> > and this includes the CR LF sequence.
> >
> > So we have two options:
> >
> > 1. change -protocol to disallow CR LF
> > 2. use byte-counting for framing in -tls
> >
> > Option 1 has been discussed in the past and mostly been rejected.
> > However, this is the first time that we have a real standardization=20
> > use case for excluding it. Currently existing (non-standard)=20
> > syslog/TCP uses CR LF (or lone LF) as record delimiter. So=20
> it might be=20
> > useful to take that route.
> >
> > Option 2 has the advantage of greater aplicability plus enables the=20
> > application developer to use more efficient buffering (as=20
> the needed=20
> > buffer space is known in advance).
> >
> > I have no strong opinion which option is better, but I tend=20
> a little=20
> > bit to option 2.
> >
> > Rainer
> >
> > _______________________________________________
> > Syslog mailing list
> > Syslog@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/syslog
> >
>=20
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Thu Mar 16 10:51:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJulV-00081S-SK; Thu, 16 Mar 2006 10:51:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJulT-0007rG-Rh
	for syslog@ietf.org; Thu, 16 Mar 2006 10:51:52 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJulR-0006HH-9Z
	for syslog@ietf.org; Thu, 16 Mar 2006 10:51:51 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id AC2D427C065;
	Thu, 16 Mar 2006 15:57:35 +0100 (CET)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 27636-09; Thu, 16 Mar 2006 15:57:35 +0100 (CET)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id 9D90527C061;
	Thu, 16 Mar 2006 15:57:34 +0100 (CET)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Thu, 16 Mar 2006 16:51:45 +0100
Content-class: urn:content-classes:message
Subject: RE: Framing in syslog messages - RE: [Syslog]
	Preliminarysyslog-transport-tls document - issue 3
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 16 Mar 2006 16:51:15 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174205@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Framing in syslog messages - RE: [Syslog]
	Preliminarysyslog-transport-tls document - issue 3
Thread-Index: AcZIf3YRcgtAMYFOTlGii8EG74K3JwAj2GuQAACMqFA=
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Anton Okmianski (aokmians)" <aokmians@cisco.com>,
	"Chris Lonvick (clonvick)" <clonvick@cisco.com>
X-OriginalArrivalTime: 16 Mar 2006 15:51:45.0227 (UTC)
	FILETIME=[86D8E1B0:01C64911]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

> My 2 cents... Do the byte counting. Look at the headers of=20
> pretty much any successful protocol (TCP, IP, UDP, etc) -=20
> they all specify length of payload.  Special character=20
> sequence is really a hack IMO! =20

After some thinking, I agree with Anton. I, too, think that
octet-counting is superior, as it leaves the door open for changes in
the upper layer. So I now strongly vote for using this approach.

> Just to be clear, there was never any intention to allow=20
> multiple messages per UDP datagram.  So, this discussion=20
> probably does not apply to the UDP transport mapping.=20

I agree on this point with Anton. We should not add any additional
overhead to the UDP transport. There is few reasoning for multi-chunk
messages in a potentially 448-octet constraint message. There may be
some valid use cases with ultra-compact messenging, but that should
probably done in another transport and/or optionally in a revision once
we got some experience with actual implementations.

Rainer

> Thanks,
> Anton.=20
>=20
> > -----Original Message-----
> > From: Chris Lonvick (clonvick)=20
> > Sent: Wednesday, March 15, 2006 5:26 PM
> > To: Rainer Gerhards
> > Cc: syslog@ietf.org
> > Subject: Framing in syslog messages - RE: [Syslog]=20
> > Preliminarysyslog-transport-tls document - issue 3
> >=20
> > Hi,
> >=20
> > This is an issue that we need to discuss.  I've had some=20
> > discussions with various people on this subject who's=20
> > opinions I trust.  They also suggest that we do have 2=20
> > options as Rainer states.  Let me describe this in a bit=20
> more detail:
> >=20
> > The consensus from all is that syslog-protocol should not=20
> > explain how to have multiple syslog messages in each packet. =20
> > That should be done in each of the transport documents so=20
> > that transport mechanisms can frame the messages.  This=20
> > ensures a good fit if syslog is placed into a new transport=20
> > that already has a framing mechanism.  This is how it has=20
> > been done in RFC 3195.
> >=20
> > As Rainer says, we can reserve a character or characters to=20
> > separate messages.  We could use ASCII characters such as=20
> > CRLF or we could use a
> > UTF8 character.  See:
> >    http://www.unicode.org/faq/utf_bom.html       and
> >    http://www.unicode.org/reports/tr14/index.html
> > This would require that we place a very strong message in the=20
> > Security Considerations section of each transport document=20
> > that would warn against an inappropriate use of the separator=20
> > character(s).  For example, if CRLF is chosen as the=20
> > separator, the receiver may get a message with a CRLF in it=20
> > that does not signify a separation of messages.  This will=20
> > probably go away with time as more poeple adopt to the standard.
> >=20
> > Alternatively, we could count bytes to show the end of a=20
> > message.  The receiver would count to that point and decide=20
> > if there is another message after that.  Having this option=20
> > would not require any additional messages in the Security=20
> > Considerations section as there would be no doubt about the=20
> > end of a message.
> >=20
> > I want to open this discussion to the group.  If we can agree=20
> > to some mechanism then we'll get Anton, Fuyou and Yuzhi to=20
> > put this into their IDs.
> >=20
> > I will say that the WG is not addressing the transport of=20
> > binary messages at this time.  However, I know that it's a=20
> > concern of this group and I would hope that the people who=20
> > think about this take that thought into consideration when=20
> > they send in their comments.
> >=20
> > Thanks,
> > Chris
> >=20
> >=20
> > On Wed, 15 Mar 2006, Rainer Gerhards wrote:
> >=20
> > > Miao,
> > >
> > > thanks for the great (and quick) work. I can not review it=20
> > fully right=20
> > > now, but I have seen one issue that I would like to comment=20
> > > immediately on. More comments follow later.
> > >
> > >>    [Issue 3] The problem of CR LF is it can not process=20
> binary data
> > >>    well.  How to process Syslog signature/certificate message?
> > >
> > > With the current status of syslog-protocol, you can NOT do=20
> > > octet-stuffing. The reason is that any character is valid=20
> > inside MSG=20
> > > and this includes the CR LF sequence.
> > >
> > > So we have two options:
> > >
> > > 1. change -protocol to disallow CR LF
> > > 2. use byte-counting for framing in -tls
> > >
> > > Option 1 has been discussed in the past and mostly been rejected.
> > > However, this is the first time that we have a real=20
> standardization=20
> > > use case for excluding it. Currently existing (non-standard)=20
> > > syslog/TCP uses CR LF (or lone LF) as record delimiter. So=20
> > it might be=20
> > > useful to take that route.
> > >
> > > Option 2 has the advantage of greater aplicability plus=20
> enables the=20
> > > application developer to use more efficient buffering (as=20
> > the needed=20
> > > buffer space is known in advance).
> > >
> > > I have no strong opinion which option is better, but I tend=20
> > a little=20
> > > bit to option 2.
> > >
> > > Rainer
> > >
> > > _______________________________________________
> > > Syslog mailing list
> > > Syslog@lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > >
> >=20
> > _______________________________________________
> > Syslog mailing list
> > Syslog@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/syslog
> >=20
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Thu Mar 16 12:51:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJwd5-0000wC-Nx; Thu, 16 Mar 2006 12:51:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwd4-0000w7-In
	for syslog@ietf.org; Thu, 16 Mar 2006 12:51:18 -0500
Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJwd1-0002El-Cx
	for syslog@ietf.org; Thu, 16 Mar 2006 12:51:18 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 1EF27E006A; Thu, 16 Mar 2006 12:51:15 -0500 (EST)
To: syslog@ietf.org
From: Sam Hartman <hartmans-ietf@mit.edu>
Message-Id: <20060316175115.1EF27E006A@carter-zimmerman.mit.edu>
Date: Thu, 16 Mar 2006 12:51:15 -0500 (EST)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: 
Subject: [Syslog] Charter Approved
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org


Hi.  I'm pleased to report that your charter has been approved.  It
will take a few days for official word to come out but you can move forward under this charter.

--Sam


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Fri Mar 17 10:15:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKGfs-0006sp-FT; Fri, 17 Mar 2006 10:15:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGfq-0006s4-M9
	for syslog@ietf.org; Fri, 17 Mar 2006 10:15:30 -0500
Received: from balabit.hu ([195.70.34.196])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKGfp-0001lF-B6
	for syslog@ietf.org; Fri, 17 Mar 2006 10:15:30 -0500
Subject: RE: Framing in syslog messages - RE: [Syslog]
	Preliminarysyslog-transport-tls document - issue 3
From: Balazs Scheidler <bazsi@balabit.hu>
To: Rainer Gerhards <rgerhards@hq.adiscon.com>
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174205@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA174205@grfint2.intern.adiscon.com>
Content-Type: text/plain
Date: Fri, 17 Mar 2006 16:15:26 +0100
Message-Id: <1142608526.27538.13.camel@bzorp.balabit>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

[ stripped Cc line ]

On Thu, 2006-03-16 at 16:51 +0100, Rainer Gerhards wrote:
> > My 2 cents... Do the byte counting. Look at the headers of 
> > pretty much any successful protocol (TCP, IP, UDP, etc) - 
> > they all specify length of payload.  Special character 
> > sequence is really a hack IMO!  
> 
> After some thinking, I agree with Anton. I, too, think that
> octet-counting is superior, as it leaves the door open for changes in
> the upper layer. So I now strongly vote for using this approach.

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)

-- 
Bazsi


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Fri Mar 17 10:52:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKHFw-0006mF-Pz; Fri, 17 Mar 2006 10:52:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHFv-0006mA-9g
	for syslog@ietf.org; Fri, 17 Mar 2006 10:52:47 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKHFu-0003Db-0S
	for syslog@ietf.org; Fri, 17 Mar 2006 10:52:47 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id E276327C065;
	Fri, 17 Mar 2006 15:58:26 +0100 (CET)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 23407-06; Fri, 17 Mar 2006 15:58:26 +0100 (CET)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id A1EBD27C061;
	Fri, 17 Mar 2006 15:58:26 +0100 (CET)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Fri, 17 Mar 2006 16:52:42 +0100
Content-class: urn:content-classes:message
Subject: RE: Framing in syslog messages - RE:
	[Syslog]Preliminarysyslog-transport-tls document - issue 3
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Mar 2006 16:52:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17424B@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Framing in syslog messages - RE:
	[Syslog]Preliminarysyslog-transport-tls document - issue 3
Thread-Index: AcZJ2hsmTsMdphbHSpipoODyl/fZ9gAACnbA
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Balazs Scheidler" <bazsi@balabit.hu>
X-OriginalArrivalTime: 17 Mar 2006 15:52:42.0201 (UTC)
	FILETIME=[D3382C90:01C649DA]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

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=20
> 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 =3D OCTCOUNT SP
OCTCOUNT =3D 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
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Fri Mar 17 11:37:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKHxM-0005lR-4K; Fri, 17 Mar 2006 11:37:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHxK-0005lM-WC
	for syslog@ietf.org; Fri, 17 Mar 2006 11:37:39 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKHxJ-0004vk-Mk
	for syslog@ietf.org; Fri, 17 Mar 2006 11:37:38 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-3.cisco.com with ESMTP; 17 Mar 2006 08:37:37 -0800
X-IronPort-AV: i="4.03,105,1141632000"; 
	d="scan'208"; a="417117352:sNHT23948400"
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2HGba7U006431;
	Fri, 17 Mar 2006 08:37:36 -0800 (PST)
Date: Fri, 17 Mar 2006 08:37:35 -0800 (PST)
From: Chris Lonvick <clonvick@cisco.com>
To: Rainer Gerhards <rgerhards@hq.adiscon.com>
Subject: RE: Framing in syslog messages - RE:
	[Syslog]Preliminarysyslog-transport-tls document - issue 3
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA17424B@grfint2.intern.adiscon.com>
Message-ID: <Pine.GSO.4.63.0603170836230.28511@sjc-cde-011.cisco.com>
References: <577465F99B41C842AAFBE9ED71E70ABA17424B@grfint2.intern.adiscon.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

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
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Fri Mar 17 11:43:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKI2p-00083r-1f; Fri, 17 Mar 2006 11:43:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKI2n-00083m-7q
	for syslog@ietf.org; Fri, 17 Mar 2006 11:43:17 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKI2m-00053E-Q1
	for syslog@ietf.org; Fri, 17 Mar 2006 11:43:17 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id 1193727C065;
	Fri, 17 Mar 2006 16:49:00 +0100 (CET)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 24437-05; Fri, 17 Mar 2006 16:49:00 +0100 (CET)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id C450227C061;
	Fri, 17 Mar 2006 16:48:59 +0100 (CET)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Fri, 17 Mar 2006 17:43:14 +0100
Content-class: urn:content-classes:message
Subject: RE: Framing in syslog messages - RE:
	[Syslog]Preliminarysyslog-transport-tls document - issue 3
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Mar 2006 17:43:13 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17424D@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Framing in syslog messages - RE:
	[Syslog]Preliminarysyslog-transport-tls document - issue 3
Thread-Index: AcZJ4SGR+uWY2y1OTwSMDFYjd+csRgAABh+w
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Chris Lonvick" <clonvick@cisco.com>
X-OriginalArrivalTime: 17 Mar 2006 16:43:15.0022 (UTC)
	FILETIME=[E2EBEEE0:01C649E1]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

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:clonvick@cisco.com]=20
> Sent: Friday, March 17, 2006 5:38 PM
> To: Rainer Gerhards
> Cc: Balazs Scheidler; syslog@ietf.org
> Subject: RE: Framing in syslog messages - RE:=20
> [Syslog]Preliminarysyslog-transport-tls document - issue 3
>=20
> Hi,
>=20
> Why wouldn't this information be contained in a structured=20
> data element=20
> within each frame?
>=20
> Thanks,
> Chris
>=20
> On Fri, 17 Mar 2006, Rainer Gerhards wrote:
>=20
> > Bazsi,
> >
> >> Agreed, let's go for octet-counting. How would that look like? Two
> >> octets before every message? That would limit message size=20
> 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=20
> let's not get on
> > that slippery slope again. The compromise so far is - you=20
> can use any
> > size as long as the receiver permits it. I'd say we should=20
> stick with
> > it. That means we should probably also stick with the=20
> ASCII-only Space
> > delimited header. So the transport header would be=20
> something like this
> >
> > TLS-HEAD =3D OCTCOUNT SP
> > OCTCOUNT =3D 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=20
> read the first
> > 64k and drop the rest.
> > Rainer
> >
> > _______________________________________________
> > Syslog mailing list
> > Syslog@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/syslog
> >
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Fri Mar 17 13:42:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKJti-00083p-Hr; Fri, 17 Mar 2006 13:42:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJth-00083k-AP
	for syslog@ietf.org; Fri, 17 Mar 2006 13:42:01 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJth-0000lQ-1U
	for syslog@ietf.org; Fri, 17 Mar 2006 13:42:01 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 17 Mar 2006 10:42:01 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.03,105,1141632000"; 
	d="scan'208"; a="23859443:sNHT23108784"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2HIfxVU006281; 
	Fri, 17 Mar 2006 13:42:00 -0500 (EST)
Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 17 Mar 2006 13:41:59 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Framing in syslog messages - RE:
	[Syslog]Preliminarysyslog-transport-tls document - issue 3
Date: Fri, 17 Mar 2006 13:41:58 -0500
Message-ID: <98AE08B66FAD1742BED6CB9522B731220135E851@xmb-rtp-20d.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Framing in syslog messages - RE:
	[Syslog]Preliminarysyslog-transport-tls document - issue 3
Thread-Index: AcZJ1atFn9Ublj9iQ3O2m3HXC+TGoQAG9EkA
From: "Anton Okmianski \(aokmians\)" <aokmians@cisco.com>
To: "Balazs Scheidler" <bazsi@balabit.hu>,
	"Rainer Gerhards" <rgerhards@hq.adiscon.com>
X-OriginalArrivalTime: 17 Mar 2006 18:41:59.0411 (UTC)
	FILETIME=[79636C30:01C649F2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

I'd vote for a much larger limit (4 byte prefix =3D 4MB) to make it more =
future-proof regardless of the limit set by current version of =
syslog-protocol.  In recent history, XML has increased data size =
requirements by as much as an order of magnitute. There could be more =
such developments in the future. =20

Besides, you don't always have to hold the message in memory.  You can =
stream it to disk, for example, if you are just a collector and wish to =
support such huge messages.  Or is there something in syslog-protocol =
that requires you to hold it in memory completely?

Anton. =20

> -----Original Message-----
> From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20
> Sent: Friday, March 17, 2006 10:15 AM
> To: Rainer Gerhards
> Cc: syslog@ietf.org
> Subject: RE: Framing in syslog messages - RE:=20
> [Syslog]Preliminarysyslog-transport-tls document - issue 3
>=20
> [ stripped Cc line ]
>=20
> On Thu, 2006-03-16 at 16:51 +0100, Rainer Gerhards wrote:
> > > My 2 cents... Do the byte counting. Look at the headers of pretty=20
> > > much any successful protocol (TCP, IP, UDP, etc) - they=20
> all specify=20
> > > length of payload.  Special character sequence is really=20
> a hack IMO!
> >=20
> > After some thinking, I agree with Anton. I, too, think that=20
> > octet-counting is superior, as it leaves the door open for=20
> changes in=20
> > the upper layer. So I now strongly vote for using this approach.
>=20
> Agreed, let's go for octet-counting. How would that look=20
> like? Two octets before every message? That would limit=20
> message size to 64k, is that sufficient? (I personally say it=20
> is, messages larger than 64k would potentially mean that they=20
> cannot be held in memory)
>=20
> --
> Bazsi
>=20
>=20
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Fri Mar 17 13:43:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKJvE-0000Av-6Y; Fri, 17 Mar 2006 13:43:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJvD-00008T-4F
	for syslog@ietf.org; Fri, 17 Mar 2006 13:43:35 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJvB-0000nc-M7
	for syslog@ietf.org; Fri, 17 Mar 2006 13:43:35 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 17 Mar 2006 10:43:34 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.03,105,1141632000"; 
	d="scan'208"; a="23859661:sNHT24159912"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2HIhXVU006724; 
	Fri, 17 Mar 2006 13:43:33 -0500 (EST)
Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 17 Mar 2006 13:43:32 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Framing in syslog messages -
	RE:[Syslog]Preliminarysyslog-transport-tls document - issue 3
Date: Fri, 17 Mar 2006 13:43:32 -0500
Message-ID: <98AE08B66FAD1742BED6CB9522B731220135E856@xmb-rtp-20d.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Framing in syslog messages -
	RE:[Syslog]Preliminarysyslog-transport-tls document - issue 3
Thread-Index: AcZJ2hsmTsMdphbHSpipoODyl/fZ9gAACnbAAAYWLiA=
From: "Anton Okmianski \(aokmians\)" <aokmians@cisco.com>
To: "Rainer Gerhards" <rgerhards@hq.adiscon.com>,
	"Balazs Scheidler" <bazsi@balabit.hu>
X-OriginalArrivalTime: 17 Mar 2006 18:43:32.0921 (UTC)
	FILETIME=[B11FEA90:01C649F2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

That's a good suggestion. A little less efficient, but that's probably =
not an issue.  I prefer this to a small limit.=20

Anton. =20

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

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Sat Mar 18 17:22:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKjo0-0004DI-7A; Sat, 18 Mar 2006 17:21:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKjny-0004DD-CD
	for syslog@ietf.org; Sat, 18 Mar 2006 17:21:50 -0500
Received: from balabit.hu ([195.70.34.196])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKjnw-0001c2-Sh
	for syslog@ietf.org; Sat, 18 Mar 2006 17:21:50 -0500
Subject: RE: Framing in syslog messages - RE:
	[Syslog]Preliminarysyslog-transport-tls document - issue 3
From: Balazs Scheidler <bazsi@balabit.hu>
To: Rainer Gerhards <rgerhards@hq.adiscon.com>
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA17424D@grfint2.intern.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA17424D@grfint2.intern.adiscon.com>
Content-Type: text/plain
Date: Sat, 18 Mar 2006 23:21:45 +0100
Message-Id: <1142720505.28442.2.camel@bzorp.balabit>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

On Fri, 2006-03-17 at 17:43 +0100, Rainer Gerhards wrote:
> 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.

Absolutely agree and I also like the text based format.

-- 
Bazsi


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Sun Mar 19 19:36:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FL8N7-000793-Fw; Sun, 19 Mar 2006 19:35:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FL8N6-00078x-A7
	for syslog@ietf.org; Sun, 19 Mar 2006 19:35:44 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FL8N5-0001gF-1p
	for syslog@ietf.org; Sun, 19 Mar 2006 19:35:44 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-3.cisco.com with ESMTP; 19 Mar 2006 16:35:42 -0800
X-IronPort-AV: i="4.03,109,1141632000"; 
	d="scan'208"; a="417950766:sNHT24646656"
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2K0Zgw2019627
	for <syslog@ietf.org>; Sun, 19 Mar 2006 16:35:42 -0800 (PST)
Date: Sun, 19 Mar 2006 16:35:42 -0800 (PST)
From: Chris Lonvick <clonvick@cisco.com>
To: syslog@ietf.org
Subject: RE: Framing in syslog messages - RE:
	[Syslog]Preliminarysyslog-transport-tls document - issue 3
In-Reply-To: <1142720505.28442.2.camel@bzorp.balabit>
Message-ID: <Pine.GSO.4.63.0603182125560.25084@sjc-cde-011.cisco.com>
References: <577465F99B41C842AAFBE9ED71E70ABA17424D@grfint2.intern.adiscon.com>
	<1142720505.28442.2.camel@bzorp.balabit>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: 
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

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

On Sat, 18 Mar 2006, Balazs Scheidler wrote:

> On Fri, 2006-03-17 at 17:43 +0100, Rainer Gerhards wrote:
>> 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.
>
> Absolutely agree and I also like the text based format.
>
> -- 
> Bazsi
>

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Sun Mar 19 21:36:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLAFm-00036d-Qr; Sun, 19 Mar 2006 21:36:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAFl-00034T-Pq
	for syslog@ietf.org; Sun, 19 Mar 2006 21:36:17 -0500
Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLAFk-0005W5-2Z
	for syslog@ietf.org; Sun, 19 Mar 2006 21:36:17 -0500
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWE00G8ONHEOL@szxga03-in.huawei.com> for
	syslog@ietf.org; Mon, 20 Mar 2006 10:41:38 +0800 (CST)
Received: from szxml02-in ([172.24.1.6])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWE008YJNHEPW@szxga03-in.huawei.com> for
	syslog@ietf.org; Mon, 20 Mar 2006 10:41:38 +0800 (CST)
Received: from m19684 ([10.110.115.32])
	by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0IWE00ELHNQTWZ@szxml02-in.huawei.com>; Mon,
	20 Mar 2006 10:47:17 +0800 (CST)
Date: Mon, 20 Mar 2006 10:34:07 +0800
From: Miao Fuyou <miaofy@huawei.com>
In-reply-to: <Pine.GSO.4.63.0603182125560.25084@sjc-cde-011.cisco.com>
To: 'Chris Lonvick' <clonvick@cisco.com>, syslog@ietf.org
Message-id: <000001c64bc6$c3324fe0$20736e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: 
Subject: [Syslog] Other syslog-tls Issues---Issue0
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org


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.


> -----Original Message-----
> From: Chris Lonvick [mailto:clonvick@cisco.com] 
> Sent: Monday, March 20, 2006 8:36 AM
> To: syslog@ietf.org
> Subject: RE: Framing in syslog messages - 
> RE:[Syslog]Preliminarysyslog-transport-tls document - issue 3
> 
> 
> 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
> 
> On Sat, 18 Mar 2006, Balazs Scheidler wrote:
> 


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Sun Mar 19 21:38:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLAHt-0003qr-AM; Sun, 19 Mar 2006 21:38:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAHs-0003qb-0O
	for syslog@ietf.org; Sun, 19 Mar 2006 21:38:28 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLAHq-0005XW-9T
	for syslog@ietf.org; Sun, 19 Mar 2006 21:38:27 -0500
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWE00CNLNX4FJ@szxga02-in.huawei.com> for
	syslog@ietf.org; Mon, 20 Mar 2006 10:51:04 +0800 (CST)
Received: from szxml01-in ([172.24.1.3])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWE00HTPNX3EP@szxga02-in.huawei.com> for
	syslog@ietf.org; Mon, 20 Mar 2006 10:51:04 +0800 (CST)
Received: from m19684 ([10.110.115.32])
	by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0IWE0090EO2XPI@szxml01-in.huawei.com>; Mon,
	20 Mar 2006 10:54:33 +0800 (CST)
Date: Mon, 20 Mar 2006 10:37:44 +0800
From: Miao Fuyou <miaofy@huawei.com>
In-reply-to: <Pine.GSO.4.63.0603182125560.25084@sjc-cde-011.cisco.com>
To: 'Chris Lonvick' <clonvick@cisco.com>, syslog@ietf.org
Message-id: <000201c64bc7$44ceb390$20736e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: 
Subject: [Syslog] Other syslog-tls Issues---Issue 1 and 2
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org


   [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?



_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Sun Mar 19 21:39:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLAJ4-00051T-Kp; Sun, 19 Mar 2006 21:39:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAJ3-0004x0-3p
	for syslog@ietf.org; Sun, 19 Mar 2006 21:39:41 -0500
Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLAIx-0005YC-Dj
	for syslog@ietf.org; Sun, 19 Mar 2006 21:39:41 -0500
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWE00ENPNSO0D@szxga01-in.huawei.com> for
	syslog@ietf.org; Mon, 20 Mar 2006 10:48:25 +0800 (CST)
Received: from szxml01-in ([172.24.1.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWE007C8NSOJ3@szxga01-in.huawei.com> for
	syslog@ietf.org; Mon, 20 Mar 2006 10:48:24 +0800 (CST)
Received: from m19684 ([10.110.115.32])
	by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0IWE009YLO2JPI@szxml01-in.huawei.com>; Mon,
	20 Mar 2006 10:54:19 +0800 (CST)
Date: Mon, 20 Mar 2006 10:37:30 +0800
From: Miao Fuyou <miaofy@huawei.com>
In-reply-to: <Pine.GSO.4.63.0603182125560.25084@sjc-cde-011.cisco.com>
To: 'Chris Lonvick' <clonvick@cisco.com>, syslog@ietf.org
Message-id: <000101c64bc7$3c3af630$20736e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d62ab47271805379d7172ee693a45db
Cc: 
Subject: [Syslog] Other syslog-tls Issues---Issue 4
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org



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


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Sun Mar 19 23:30:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLC1v-0003Lk-S7; Sun, 19 Mar 2006 23:30:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLC1u-0003LX-8d
	for syslog@ietf.org; Sun, 19 Mar 2006 23:30:06 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLC1p-0000ER-Gm
	for syslog@ietf.org; Sun, 19 Mar 2006 23:30:06 -0500
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWE002N6T1IYJ@szxga02-in.huawei.com> for
	syslog@ietf.org; Mon, 20 Mar 2006 12:41:43 +0800 (CST)
Received: from huawei.com ([172.24.1.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWE002FXT1IW3@szxga02-in.huawei.com> for
	syslog@ietf.org; Mon, 20 Mar 2006 12:41:42 +0800 (CST)
Received: from m19684 ([10.110.115.32])
	by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0IWE00G90T19QA@szxml02-in.huawei.com> for
	syslog@ietf.org; Mon, 20 Mar 2006 12:41:33 +0800 (CST)
Date: Mon, 20 Mar 2006 12:28:23 +0800
From: Miao Fuyou <miaofy@huawei.com>
Subject: RE: [Syslog] Other syslog-tls Issues---Issue0
In-reply-to: <000001c64bc6$c3324fe0$20736e0a@china.huawei.com>
To: syslog@ietf.org
Message-id: <000101c64bd6$b9b66220$20736e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: 
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org


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.

> -----Original Message-----
> From: Miao Fuyou [mailto:miaofy@huawei.com] 
> Sent: Monday, March 20, 2006 10:34 AM
> To: 'Chris Lonvick'; syslog@ietf.org
> Subject: [Syslog] Other syslog-tls Issues---Issue0
> 
> 
> 
> 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.
> 
> 
> > -----Original Message-----
> > From: Chris Lonvick [mailto:clonvick@cisco.com]
> > Sent: Monday, March 20, 2006 8:36 AM
> > To: syslog@ietf.org
> > Subject: RE: Framing in syslog messages - 
> > RE:[Syslog]Preliminarysyslog-transport-tls document - issue 3
> > 
> > 
> > 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
> > 
> > On Sat, 18 Mar 2006, Balazs Scheidler wrote:
> > 
> 
> 
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
> 


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 20 02:30:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLEqI-0000B8-Gz; Mon, 20 Mar 2006 02:30:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLEqH-0000Ar-SY
	for syslog@ietf.org; Mon, 20 Mar 2006 02:30:17 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLEmj-0006NB-G4
	for syslog@ietf.org; Mon, 20 Mar 2006 02:26:38 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id 09CAB27C065
	for <syslog@ietf.org>; Mon, 20 Mar 2006 07:32:10 +0100 (CET)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 17821-04 for <syslog@ietf.org>;
	Mon, 20 Mar 2006 07:32:09 +0100 (CET)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id BF09F27C061
	for <syslog@ietf.org>; Mon, 20 Mar 2006 07:32:09 +0100 (CET)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Mon, 20 Mar 2006 08:26:32 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 20 Mar 2006 08:26:33 +0100
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174251@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: syslog-tls issue 0 (was FW: Evaluation:
	draft-ietf-netconf-ssh-05.txt to Proposed Standar d)
Thread-Index: AcZLGXn8lpz8cHsMSG+VpudsEJKeCAA1aaMg
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: <syslog@ietf.org>
X-OriginalArrivalTime: 20 Mar 2006 07:26:32.0319 (UTC)
	FILETIME=[9C9930F0:01C64BEF]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: 
Subject: [Syslog] syslog-tls issue 0 (was FW: Evaluation:
	draft-ietf-netconf-ssh-05.txt to Proposed Standar d)
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Hi all,

the exact same issue (dedicated port or not and if so in which port
range) has been discussed on the netconf mailing list. I encourage
everyone to have a look at their archive. For details on netconf
(including mailing list archive link), please see:

   http://www.ops.ietf.org/netconf/

Below is a forward from the - IMHO - most important message on that
list. This could be our guideline for discussion.

Rainer
> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert)
> Sent: Sunday, March 19, 2006 6:44 AM
> >=20
> > Netconf is at best a 'niche' protocol at present, because:
> >=20
> > (a) Netconf currently has no standard data models
> >=20
> > (b) Netconf currently is intended for use only with routers and
> >     other intermediate network elements
> >=20
> > (c) Netconf operations have fuzzy semantics, due to the lack of any
> >     standard data models (e.g., "merge this blob with that blob")
> >=20
> > Therefore, Netconf in not plausibly a critical system service.
> >=20
> > An IANA-assigned "Registered Port" (greater than 1024) is=20
> appropriate.
> >=20
> > The argument that user processes may pre-bind the Netconf=20
> port applies
> > equally to an IANA-assigned "Well Known Port" (less than 1024).
> >=20
> > I encourage the IETF ADs to intervene here and provide direction.
> >=20
>=20
> The direction is that:
>=20
> - The IESG is OK if the WG wants system ports if they have some=20
>   reasonable argument to request so. The stronger the argument,
>   the better.  But a reasonable argument is OK.
> - I think the arguments I have seen pro and against sofar make me
>   tend to agree with selecting <1024. They seem at least reasonable.
>   (I am in the air right now, so I can only comment as to=20
> what I have seen
>   up till now).
> - I have seen arguments for using ports above 1024 too.=20
>   they are OK but I do not find them as convincing (yet) as the ones
>   in favor fo <1024.
> - I have not seen arguments that point out a fatal problem if we
>   assign below 1024.
> - I find it important that people who have implented (or are=20
> implementing)
>   or those who plan to deploy now or within a year are=20
> speaking up. Their
>   view counts heavily as far as I am concerned.
>=20
> Hope this helps,
> Bert (speaking as AD)
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 20 03:14:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLFXS-0001gT-6g; Mon, 20 Mar 2006 03:14:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFXQ-0001Rd-Js
	for syslog@ietf.org; Mon, 20 Mar 2006 03:14:52 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLFXI-0007sb-Vn
	for syslog@ietf.org; Mon, 20 Mar 2006 03:14:49 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id DEEA027C065;
	Mon, 20 Mar 2006 08:20:19 +0100 (CET)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 17821-07; Mon, 20 Mar 2006 08:20:19 +0100 (CET)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id 849C227C061;
	Mon, 20 Mar 2006 08:20:19 +0100 (CET)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Mon, 20 Mar 2006 09:14:41 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Syslog] Other syslog-tls Issues---Issue0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 20 Mar 2006 09:14:39 +0100
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174254@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Other syslog-tls Issues---Issue0
Thread-Index: AcZLxxNQPgRWPu+ZTSC/mm5IenRp/QALNTAg
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Miao Fuyou" <miaofy@huawei.com>,
	"Chris Lonvick" <clonvick@cisco.com>, <syslog@ietf.org>
X-OriginalArrivalTime: 20 Mar 2006 08:14:41.0553 (UTC)
	FILETIME=[56B75010:01C64BF6]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: 
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Miao, all,

I've already sent a message on similar discussion in the netconf wg.
Please read this too. In this mail, I try to provide argument why (and
how) we should use a dedicated port and that port should be in the range
< 1024. I try to word my arguments so that they can also be used in
negotiations with the IESG/IANA.

There are a number of arguments:

#1 We expect syslog-tls to become widespread adopted (if we would not
expect this, we could simply drop the effort - the IESG poll has shown
sufficient interest, and this is why this WG has been rechartered).

#2 syslog traditionally has been assigned a dedicated port in the system
range (514 and 601).

#3 syslog was considered important enough to assign a dedicated port in
the past (601 with RFC 3195) - the same, IMHO, applies to this effort
(but see note below)

#4 the syslog daemon is considered an essential system service and part
of many important operating systems

#5 I think operators expect a dedicated port for an essential protocol

#6 a dedicated port greatly reduces the likelyhood of syslogd startup
errors due to port being used by another process

#7 a dedicated port greatly reduces ambiguity, which is especially
important as a number of SOHO decives/applications is expected to
implement the protocol. For low-knowledge, "nearly plug-and-play"
scenarios, senders and receivers need a universal understanding of the
port number to use.

#8 (derived argument) If I combine argument #1 and #4, there will be a
very large number of systems utilizing that port, thus justifying
assigning a scarce ressource.

SO I think the importance of the protocol, user expectations and
potential deployment justify the assignment of a port in the range <
1024.

HOWEVER, the next question is if we actually need a *new* port. IANA has
registered port 601 for "reliable syslog". This is an excerpt from the
IANA table (http://www.iana.org/assignments/port-numbers):

syslog-conn     601/tcp    Reliable Syslog Service
syslog-conn     601/udp    Reliable Syslog Service
#                          RFC 3195
=20
Obviously, this is assigned for RFC 3195. As it currently looks, RFC
3195 does not live up to the expectation of widespread deployment
(though it might be too early to judge this).

If I look at syslog-tls and RFC 3195, both of them address the same
need. Thus, a listener will probably listen to either of them, but not
to both of them (IMHO at least in the majority of cases). It must be
noted, however, that there may be cases where a single listener listens
to both protocols.

Even with the later, I would recommend to use already-assigned port 601
for syslog-tls in addition to RFC 3195. That would enable us to enjoy
all the benefits of a dedicated port while we have only a slight chance
of potential conflict with a very-seldomly-deployed other syslog
protocol.

I think the TLS negotiation phase will be totally different from RFC
3195 negotiation, so a receiver might be able to detect which syslog
protocol is trying to connect and handle it accordingly. However, this
must be seen in the light of real-world implementations (and most
importantly openssl), because we should not rely on something that
implementors can not implement with existing technology. Maybe it would
pay to have an optional app-level negotiation phase (BEEP GREETINGS
could be used for that! - so we could essentially change RFC 3195bis to
allow the fallback to syslog-tls, removing any ambiguity).

I hope this argument is convincing.

Rainer

> -----Original Message-----
> From: Miao Fuyou [mailto:miaofy@huawei.com]=20
> Sent: Monday, March 20, 2006 3:34 AM
> To: 'Chris Lonvick'; syslog@ietf.org
> Subject: [Syslog] Other syslog-tls Issues---Issue0
>=20
>=20
> I will update the document based on mailing list discussion=20
> if there is no
> strong objection.=20
>=20
> Let's also disscuss other issues:
>=20
>    [Issue 0]: Do we need a Syslog TCP port for TLS transport?  The
>    security community had debates about whether using special ports is
>    desirable.
>=20
>=20
> > -----Original Message-----
> > From: Chris Lonvick [mailto:clonvick@cisco.com]=20
> > Sent: Monday, March 20, 2006 8:36 AM
> > To: syslog@ietf.org
> > Subject: RE: Framing in syslog messages -=20
> > RE:[Syslog]Preliminarysyslog-transport-tls document - issue 3
> >=20
> >=20
> > Hi All,
> >=20
> > This sounds good and I believe that we have had a reasonable=20
> > discussion of=20
> > all of the options.  Unless there are strong objections, I'll=20
> > ask Fuyou=20
> > and Yuzhi to incorporate this into their document.
> >=20
> > Thanks,
> > Chris
> >=20
> > On Sat, 18 Mar 2006, Balazs Scheidler wrote:
> >=20
>=20
>=20
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 20 04:31:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLGju-00066I-5V; Mon, 20 Mar 2006 04:31:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLGjs-0005zs-IP
	for syslog@ietf.org; Mon, 20 Mar 2006 04:31:48 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLGjs-0002H8-4N
	for syslog@ietf.org; Mon, 20 Mar 2006 04:31:48 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id DB00827C067;
	Mon, 20 Mar 2006 09:37:22 +0100 (CET)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 20254-01; Mon, 20 Mar 2006 09:37:22 +0100 (CET)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id 91E1C27C061;
	Mon, 20 Mar 2006 09:37:22 +0100 (CET)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Mon, 20 Mar 2006 10:31:45 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Syslog] Other syslog-tls Issues---Issue0
Content-Transfer-Encoding: quoted-printable
Date: Mon, 20 Mar 2006 10:31:42 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17425D@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Other syslog-tls Issues---Issue0
Thread-Index: AcZL1v5Sx+W4tQeQRKq/VrTgxR35GwAKf5Fg
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Miao Fuyou" <miaofy@huawei.com>
X-OriginalArrivalTime: 20 Mar 2006 09:31:45.0906 (UTC)
	FILETIME=[1B0B9520:01C64C01]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Miao,

> Section 1 of RFC2817(Upgrading to TLS Within HTTP/1.1) says=20
> that special
> port is not preferable for security. Now the situation is=20
> 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=20
> that we will need
> another iana allocated port if TCP transport is standardized=20
> in the future.

I think a plain TCP transport is quite unlikely, given the concerns in
this WG. Anyhow, let's care about that when it is time to do so, which
at best is another year away...

Rainer
>=20
> Https is allocated both 443 for tls and 80 for TCP.
>=20
> > -----Original Message-----
> > From: Miao Fuyou [mailto:miaofy@huawei.com]=20
> > Sent: Monday, March 20, 2006 10:34 AM
> > To: 'Chris Lonvick'; syslog@ietf.org
> > Subject: [Syslog] Other syslog-tls Issues---Issue0
> >=20
> >=20
> >=20
> > I will update the document based on mailing list discussion=20
> > if there is no strong objection.=20
> >=20
> > Let's also disscuss other issues:
> >=20
> >    [Issue 0]: Do we need a Syslog TCP port for TLS transport?  The
> >    security community had debates about whether using=20
> special ports is
> >    desirable.
> >=20
> >=20
> > > -----Original Message-----
> > > From: Chris Lonvick [mailto:clonvick@cisco.com]
> > > Sent: Monday, March 20, 2006 8:36 AM
> > > To: syslog@ietf.org
> > > Subject: RE: Framing in syslog messages -=20
> > > RE:[Syslog]Preliminarysyslog-transport-tls document - issue 3
> > >=20
> > >=20
> > > Hi All,
> > >=20
> > > This sounds good and I believe that we have had a reasonable
> > > discussion of=20
> > > all of the options.  Unless there are strong objections, I'll=20
> > > ask Fuyou=20
> > > and Yuzhi to incorporate this into their document.
> > >=20
> > > Thanks,
> > > Chris
> > >=20
> > > On Sat, 18 Mar 2006, Balazs Scheidler wrote:
> > >=20
> >=20
> >=20
> > _______________________________________________
> > Syslog mailing list
> > Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
> >=20
>=20
>=20
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 20 04:37:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLGpX-00014F-H9; Mon, 20 Mar 2006 04:37:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLGpV-00014A-Dv
	for syslog@ietf.org; Mon, 20 Mar 2006 04:37:37 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLGpU-0002WN-4G
	for syslog@ietf.org; Mon, 20 Mar 2006 04:37:37 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id 63E8A27C067;
	Mon, 20 Mar 2006 09:43:11 +0100 (CET)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 20198-03; Mon, 20 Mar 2006 09:43:11 +0100 (CET)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id 28C9227C061;
	Mon, 20 Mar 2006 09:43:11 +0100 (CET)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Mon, 20 Mar 2006 10:37:33 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Syslog] Other syslog-tls Issues---Issue 4
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 20 Mar 2006 10:37:33 +0100
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA17425E@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Other syslog-tls Issues---Issue 4
Thread-Index: AcZLx4XH1OPsz96bTlCypiSho/Y4fgAOfTUA
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Miao Fuyou" <miaofy@huawei.com>,
	"Chris Lonvick" <clonvick@cisco.com>, <syslog@ietf.org>
X-OriginalArrivalTime: 20 Mar 2006 09:37:33.0741 (UTC)
	FILETIME=[EA5EFDD0:01C64C01]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: 
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

My opinion is that this should not be a MUST, maybe not even a SHOULD. I
think this decision needs to be left to the operator. While it is
advisable to authenticate peers, operators might decide against it. This
is especially the case in SOHO environments, where the user is typically
not knowledgeable enough to set it up. I think it would be better to
have some degree of "out of the box interop" than make people resort to
unsecured UDP syslog. Of course, there is ample argument that this lax
"out of the box" (in)security is the root cause of botnets and other
security issues.

In any case, I think a MUST would be overdone IMHO.

Rainer=20

> -----Original Message-----
> From: Miao Fuyou [mailto:miaofy@huawei.com]=20
> Sent: Monday, March 20, 2006 3:38 AM
> To: 'Chris Lonvick'; syslog@ietf.org
> Subject: [Syslog] Other syslog-tls Issues---Issue 4
>=20
>=20
>=20
>    [Issue 4]: Shall we mandate the sender MUST be authenticated?  Most
>    of the Syslogd accepts messages only from configured address.
>=20
>=20
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 20 10:58:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLMlq-0001V8-Os; Mon, 20 Mar 2006 10:58:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMlp-0001V3-IU
	for syslog@ietf.org; Mon, 20 Mar 2006 10:58:13 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMln-0007XK-9N
	for syslog@ietf.org; Mon, 20 Mar 2006 10:58:13 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 20 Mar 2006 07:58:11 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.03,111,1141632000"; 
	d="scan'208"; a="23999414:sNHT23324444"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2KFw7VW015756; 
	Mon, 20 Mar 2006 10:58:10 -0500 (EST)
Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 20 Mar 2006 10:58:15 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Syslog] Other syslog-tls Issues---Issue 1 and 2
Date: Mon, 20 Mar 2006 10:58:08 -0500
Message-ID: <98AE08B66FAD1742BED6CB9522B731220135EBFA@xmb-rtp-20d.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Other syslog-tls Issues---Issue 1 and 2
Thread-Index: AcZLx2toqZ1asBnwQwKBkeNBC/5ETwAbra2w
From: "Anton Okmianski \(aokmians\)" <aokmians@cisco.com>
To: "Miao Fuyou" <miaofy@huawei.com>,
	"Chris Lonvick \(clonvick\)" <clonvick@cisco.com>, <syslog@ietf.org>
X-OriginalArrivalTime: 20 Mar 2006 15:58:15.0073 (UTC)
	FILETIME=[18DDA910:01C64C37]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: 
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Miao:=20

> -----Original Message-----
> From: Miao Fuyou [mailto:miaofy@huawei.com]=20
> Sent: Sunday, March 19, 2006 9:38 PM
> To: Chris Lonvick (clonvick); syslog@ietf.org
> Subject: [Syslog] Other syslog-tls Issues---Issue 1 and 2
>=20
>=20
>    [Issue 1]: Is it possible to use "generic certificate for different
>    host? =20

Yes, this should not precluded. But it would be nice to make the =
implications clear in security section.=20

> The generic certificate is for specific application type.

Could be specific to app type. Could be generic across other aspect of =
commonality.  For example, all hosts of a certain type (say lab hosts).=20

>    [Issue 2]: What to bind to a certificate?  Hostname, Syslog APP-
>    NAME(generic certificate)? =20

I think any binding should be allowed. The default or recommended one =
could be APP-NAME.=20

I think we could communicate the type of binding in the cert itself or =
make it completely configurable on hosts.  Communication of type of =
binding in cert can't be used for security anyway, just for =
troubleshooting maybe.=20

> APP-NAME binding makes authentication/
>    access control happens both in TLS handshake and Syslog message
>    processing, is efficiency a problem?

Not clear, what authentication is done on APP-NAME as part of "Syslog =
message processing". =20

Thanks,
Anton.=20

>=20
>=20
>=20
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 20 11:16:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLN3P-0006hr-HG; Mon, 20 Mar 2006 11:16:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLN3O-0006eN-2X
	for syslog@ietf.org; Mon, 20 Mar 2006 11:16:22 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLN3N-0008MR-L6
	for syslog@ietf.org; Mon, 20 Mar 2006 11:16:22 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id 698E027C065;
	Mon, 20 Mar 2006 16:21:55 +0100 (CET)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 27243-04; Mon, 20 Mar 2006 16:21:55 +0100 (CET)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id 07AB927C061;
	Mon, 20 Mar 2006 16:21:54 +0100 (CET)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Mon, 20 Mar 2006 17:16:19 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Syslog] Other syslog-tls Issues---Issue 1 and 2
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 20 Mar 2006 17:16:18 +0100
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174284@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Other syslog-tls Issues---Issue 1 and 2
Thread-Index: AcZLx2toqZ1asBnwQwKBkeNBC/5ETwAbra2wAADO4UA=
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Anton Okmianski (aokmians)" <aokmians@cisco.com>,
	"Miao Fuyou" <miaofy@huawei.com>,
	"Chris Lonvick (clonvick)" <clonvick@cisco.com>, <syslog@ietf.org>
X-OriginalArrivalTime: 20 Mar 2006 16:16:19.0281 (UTC)
	FILETIME=[9F1AAC10:01C64C39]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: 
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Hi all,

I have been silent so far on this topic, because I have not made my mind
up yet. However, let me point you to some important fact:

APP-NAME would be e.g. "postfix", "kernel", "syslogd", ... So you have a
potentially very large number of APP-NAMES all sent from the same
syslogd. I think this does not make up for a good value that can be
checked against in the cert.

As I said: other than that, I do not yet have an opinion.

Rainer

> -----Original Message-----
> From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20
> Sent: Monday, March 20, 2006 4:58 PM
> To: Miao Fuyou; Chris Lonvick (clonvick); syslog@ietf.org
> Subject: RE: [Syslog] Other syslog-tls Issues---Issue 1 and 2
>=20
> Miao:=20
>=20
> > -----Original Message-----
> > From: Miao Fuyou [mailto:miaofy@huawei.com]=20
> > Sent: Sunday, March 19, 2006 9:38 PM
> > To: Chris Lonvick (clonvick); syslog@ietf.org
> > Subject: [Syslog] Other syslog-tls Issues---Issue 1 and 2
> >=20
> >=20
> >    [Issue 1]: Is it possible to use "generic certificate=20
> for different
> >    host? =20
>=20
> Yes, this should not precluded. But it would be nice to make=20
> the implications clear in security section.=20
>=20
> > The generic certificate is for specific application type.
>=20
> Could be specific to app type. Could be generic across other=20
> aspect of commonality.  For example, all hosts of a certain=20
> type (say lab hosts).=20
>=20
> >    [Issue 2]: What to bind to a certificate?  Hostname, Syslog APP-
> >    NAME(generic certificate)? =20
>=20
> I think any binding should be allowed. The default or=20
> recommended one could be APP-NAME.=20
>=20
> I think we could communicate the type of binding in the cert=20
> itself or make it completely configurable on hosts. =20
> Communication of type of binding in cert can't be used for=20
> security anyway, just for troubleshooting maybe.=20
>=20
> > APP-NAME binding makes authentication/
> >    access control happens both in TLS handshake and Syslog message
> >    processing, is efficiency a problem?
>=20
> Not clear, what authentication is done on APP-NAME as part of=20
> "Syslog message processing". =20
>=20
> Thanks,
> Anton.=20
>=20
> >=20
> >=20
> >=20
> > _______________________________________________
> > Syslog mailing list
> > Syslog@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/syslog
> >=20
>=20
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 20 21:56:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLX2p-0004oh-DJ; Mon, 20 Mar 2006 21:56:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLX2o-0004mZ-6I
	for syslog@ietf.org; Mon, 20 Mar 2006 21:56:26 -0500
Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLX2Z-00014i-EO
	for syslog@ietf.org; Mon, 20 Mar 2006 21:56:26 -0500
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWG00F6NJ2ZWE@szxga03-in.huawei.com> for
	syslog@ietf.org; Tue, 21 Mar 2006 11:01:47 +0800 (CST)
Received: from huawei.com ([172.24.1.3])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWG00EKPJ2ZZM@szxga03-in.huawei.com> for
	syslog@ietf.org; Tue, 21 Mar 2006 11:01:47 +0800 (CST)
Received: from m19684 ([10.110.115.32])
	by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0IWG00JAVJIG1O@szxml01-in.huawei.com>; Tue,
	21 Mar 2006 11:11:04 +0800 (CST)
Date: Tue, 21 Mar 2006 10:54:14 +0800
From: Miao Fuyou <miaofy@huawei.com>
Subject: RE: [Syslog] Other syslog-tls Issues---Issue 1 and 2
In-reply-to: <98AE08B66FAD1742BED6CB9522B731220135EBFA@xmb-rtp-20d.amer.cisco.com>
To: "'Anton Okmianski (aokmians)'" <aokmians@cisco.com>
Message-id: <000001c64c92$bd293b50$20736e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Comments inline.

> -----Original Message-----
> From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] 
> Sent: Monday, March 20, 2006 11:58 PM
> To: Miao Fuyou; Chris Lonvick (clonvick); syslog@ietf.org
> Subject: RE: [Syslog] Other syslog-tls Issues---Issue 1 and 2
> 
> 
> Miao: 
> 
> > -----Original Message-----
> > From: Miao Fuyou [mailto:miaofy@huawei.com]
> > Sent: Sunday, March 19, 2006 9:38 PM
> > To: Chris Lonvick (clonvick); syslog@ietf.org
> > Subject: [Syslog] Other syslog-tls Issues---Issue 1 and 2
> > 
> > 
> >    [Issue 1]: Is it possible to use "generic certificate 
> for different
> >    host?
> 
> Yes, this should not precluded. But it would be nice to make 
> the implications clear in security section. 
> 

Yes, I think so.

> > The generic certificate is for specific application type.
> 
> Could be specific to app type. Could be generic across other 
> aspect of commonality.  For example, all hosts of a certain 
> type (say lab hosts). 
> 
> >    [Issue 2]: What to bind to a certificate?  Hostname, Syslog APP-
> >    NAME(generic certificate)?
> 
> I think any binding should be allowed. The default or 
> recommended one could be APP-NAME. 
> 
> I think we could communicate the type of binding in the cert 
> itself or make it completely configurable on hosts.  
> Communication of type of binding in cert can't be used for 
> security anyway, just for troubleshooting maybe. 
> 
> > APP-NAME binding makes authentication/
> >    access control happens both in TLS handshake and Syslog message
> >    processing, is efficiency a problem?
> 
> Not clear, what authentication is done on APP-NAME as part of 
> "Syslog message processing".  
> 

There are difference between Host name binding and app-name binding when
being checked. For host name binding, application can check the binding only
based on inforamtion(cert and hostname) at TLS layer and check it once for
the session. For app-name binding, application must check information from
both TLS(cert) and syslog(app-name). 

Is app-name consistent/constant for a specific connection? If no,
application must check each syslog message against the cert. 

> Thanks,
> Anton. 
> 
> > 
> > 
> > 
> > _______________________________________________
> > Syslog mailing list
> > Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
> > 
> 


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Tue Mar 21 04:28:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLdAG-0002dp-KV; Tue, 21 Mar 2006 04:28:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLdAF-0002dk-KK
	for syslog@ietf.org; Tue, 21 Mar 2006 04:28:31 -0500
Received: from balabit.hu ([195.70.34.196])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLdAE-0006QF-AL
	for syslog@ietf.org; Tue, 21 Mar 2006 04:28:31 -0500
Subject: Re: [Syslog] Other syslog-tls Issues---Issue 4
From: Balazs Scheidler <bazsi@balabit.hu>
To: Miao Fuyou <miaofy@huawei.com>
In-Reply-To: <000101c64bc7$3c3af630$20736e0a@china.huawei.com>
References: <000101c64bc7$3c3af630$20736e0a@china.huawei.com>
Content-Type: text/plain
Date: Tue, 21 Mar 2006 10:28:27 +0100
Message-Id: <1142933307.7142.12.camel@bzorp.balabit>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

On Mon, 2006-03-20 at 10:37 +0800, Miao Fuyou wrote:
> 
>    [Issue 4]: Shall we mandate the sender MUST be authenticated?  Most
>    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


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Tue Mar 21 06:07:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLehz-0001Ih-9H; Tue, 21 Mar 2006 06:07:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLehx-0001H1-Bu
	for syslog@ietf.org; Tue, 21 Mar 2006 06:07:25 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLdzv-0001In-SF
	for syslog@ietf.org; Tue, 21 Mar 2006 05:21:55 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLdme-00088F-5P
	for syslog@ietf.org; Tue, 21 Mar 2006 05:08:26 -0500
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWH00G7M32GP3@szxga02-in.huawei.com> for
	syslog@ietf.org; Tue, 21 Mar 2006 18:13:28 +0800 (CST)
Received: from huawei.com ([172.24.1.3])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWH00DPC32FMF@szxga02-in.huawei.com> for
	syslog@ietf.org; Tue, 21 Mar 2006 18:13:28 +0800 (CST)
Received: from m19684 ([10.110.115.32])
	by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0IWH004WM38ALR@szxml01-in.huawei.com>; Tue,
	21 Mar 2006 18:16:59 +0800 (CST)
Date: Tue, 21 Mar 2006 18:00:04 +0800
From: Miao Fuyou <miaofy@huawei.com>
Subject: RE: [Syslog] Other syslog-tls Issues---Issue 1 and 2
In-reply-to: <1142933230.7142.10.camel@bzorp.balabit>
To: 'Balazs Scheidler' <bazsi@balabit.hu>
Message-id: <000001c64cce$39eff940$20736e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org



> -----Original Message-----
> From: Balazs Scheidler [mailto:bazsi@balabit.hu] 
> Sent: Tuesday, March 21, 2006 5:27 PM
> To: Miao Fuyou
> Subject: RE: [Syslog] Other syslog-tls Issues---Issue 1 and 2
> 
> 
> On Tue, 2006-03-21 at 10:54 +0800, Miao Fuyou wrote:
> > > 
> > > Not clear, what authentication is done on APP-NAME as part of
> > > "Syslog message processing".  
> > > 
> > 
> > There are difference between Host name binding and app-name binding 
> > when being checked. For host name binding, application can 
> check the 
> > binding only based on inforamtion(cert and hostname) at TLS 
> layer and 
> > check it once for the session. For app-name binding, 
> application must 
> > check information from both TLS(cert) and syslog(app-name).
> > 
> > Is app-name consistent/constant for a specific connection? If no, 
> > application must check each syslog message against the cert.
> > 
> 
> Definitely no, a single connection will be used to deliver 
> messages for multiple applications, so the ceritificate 
> should be bound to the syslog sender and not any individual 
> applications running on the sender.
> 

I infer from your sentence that "generic" certificate is not possible. Each
TLS connection is associated with only one certificate at most for each
direction. However, multiple app-name requires multiple certificate. It
conflicts TLS specification. Right?

> The question is how the receiver resolves the sender host, 
> using reverse DNS? or it simply accepts any trusted 
> certificates no matter what the name is.
> 

I don't think it is a problem, application should decide how to resolves the
sender host.

> -- 
> Bazsi
> 


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Tue Mar 21 11:11:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLjSZ-0006Ag-JM; Tue, 21 Mar 2006 11:11:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjSY-00068L-E2
	for syslog@ietf.org; Tue, 21 Mar 2006 11:11:50 -0500
Received: from balabit.hu ([195.70.34.196])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjSW-0005l9-T3
	for syslog@ietf.org; Tue, 21 Mar 2006 11:11:50 -0500
Subject: RE: [Syslog] Other syslog-tls Issues---Issue 1 and 2
From: Balazs Scheidler <bazsi@balabit.hu>
To: Miao Fuyou <miaofy@huawei.com>
In-Reply-To: <000001c64cce$39eff940$20736e0a@china.huawei.com>
References: <000001c64cce$39eff940$20736e0a@china.huawei.com>
Content-Type: text/plain
Date: Tue, 21 Mar 2006 17:11:45 +0100
Message-Id: <1142957506.1444.5.camel@bzorp.balabit>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

On Tue, 2006-03-21 at 18:00 +0800, Miao Fuyou wrote:
> > 
> > Definitely no, a single connection will be used to deliver 
> > messages for multiple applications, so the ceritificate 
> > should be bound to the syslog sender and not any individual 
> > applications running on the sender.
> > 
> 
> I infer from your sentence that "generic" certificate is not possible. Each
> TLS connection is associated with only one certificate at most for each
> direction. However, multiple app-name requires multiple certificate. It
> conflicts TLS specification. Right?

right.

> 
> > The question is how the receiver resolves the sender host, 
> > using reverse DNS? or it simply accepts any trusted 
> > certificates no matter what the name is.
> > 
> 
> I don't think it is a problem, application should decide how to resolves the
> sender host.

If we are to propose that certificates should be bound to the name of
the sender hosts, and receivers should check that the certificates
contain a proper hostnames, then we need to propose what kind of
information it needs to compare it to.

Sure it can be a configuration item (e.g. client 10.10.10.10 should come
with a certificate assigned to logsender.domain.com), but it is
preferable to allow syslog connections from an unlisted set of hosts,
(e.g. open to anyone with a valid certificate), in which case the
configuration example I gave above does not apply.

Receiver side certificates are easier, just like for servers in HTTPS,
we have a hostname for them in the sender's configuration.

So we either leave the SSL certificate binding undefined for the
operators to decide, or we need to clarify how certificate is to be
validated.

-- 
Bazsi


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Tue Mar 21 13:22:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLlVH-0004uM-Mg; Tue, 21 Mar 2006 13:22:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlVF-0004rw-Sw
	for syslog@ietf.org; Tue, 21 Mar 2006 13:22:45 -0500
Received: from dsl-202-45-110-141-static.vic.netspace.net.au ([202.45.110.141]
	helo=firewall.reed.wattle.id.au)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLlVE-0002s0-1b
	for syslog@ietf.org; Tue, 21 Mar 2006 13:22:45 -0500
Received: (from root@localhost)
	by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k2LIL9We022440;
	Wed, 22 Mar 2006 05:21:09 +1100 (EST)
From: Darren Reed <darrenr@reed.wattle.id.au>
Message-Id: <200603211821.k2LIL5Lf013292@firewall.reed.wattle.id.au>
Subject: Re: [Syslog] Other syslog-tls Issues---Issue 1 and 2
In-Reply-To: <1142957506.1444.5.camel@bzorp.balabit>
To: Balazs Scheidler <bazsi@balabit.hu>
Date: Wed, 22 Mar 2006 05:21:04 +1100 (EST)
X-Mailer: ELM [version 2.4ME+ PL107a (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

> On Tue, 2006-03-21 at 18:00 +0800, Miao Fuyou wrote:
> 
> So we either leave the SSL certificate binding undefined for the
> operators to decide, or we need to clarify how certificate is to be
> validated.

How much of this is an operational matter that varies from site to site
with local policies on such things ?

Darren

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Tue Mar 21 16:00:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLnxU-0002xo-AT; Tue, 21 Mar 2006 16:00:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLnxT-0002xM-4K; Tue, 21 Mar 2006 16:00:03 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLnxS-00025J-Qi; Tue, 21 Mar 2006 16:00:03 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k2LL01vP008518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 21 Mar 2006 21:00:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FLnxR-0006sS-LU; Tue, 21 Mar 2006 16:00:01 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: ietf-announce@ietf.org
From: IESG Secretary <iesg-secretary@ietf.org>
Message-Id: <E1FLnxR-0006sS-LU@stiedprstage1.ietf.org>
Date: Tue, 21 Mar 2006 16:00:01 -0500
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Cc: syslog@ietf.org
Subject: [Syslog] WG Action: RECHARTER: Security Issues in Network Event
 Logging (syslog) 
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

The Security Issues in Network Event Logging (syslog) working group in the
Security Area of the IETF has been rechartered. For additional information, 
please contact the Area Directors or the working group Chairs.

+++

Security Issues in Network Event Logging (syslog)
====================================

Current Status: Active Working Group

Chair(s):
Chris Lonvick <clonvick@cisco.com>

Security Area Director(s):
Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:
Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: syslog@ietf.org
To Subscribe: syslog-request@ietf.org
In Body: in body: (un)subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/syslog/

Description of Working Group:

Syslog is a de-facto standard for logging system events. However, the
protocol component of this event logging system has not been formally
documented. While the protocol has been very useful and scalable, it has
some known security problems which were documented in the INFORMATIONAL RFC
3164.

The goal of this working group is to address the security and integrity
problems, and to standardize the syslog protocol, transport, and a select
set of mechanisms in a manner that considers the ease of migration between
and the co-existence of existing versions and the standard.

Reviews have shown that there are very few similarities between the message
formats generated by heterogeneous systems. In fact, the only consistent
commonality between messages is that all of them contain the <PRI> at the
start. Additional testing has shown that as long as the <PRI> is present in
a syslog message, all tested receivers will accept any generated message as
a valid syslog message. In designing a standard syslog message format, this
Working Group will retain the <PRI> at the start of the message and will
introduce protocol versioning. Along these same lines, many different
charsets have been used in syslog messages observed in the wild but no
indication of the charset has been given in any message. The Working Group
also feels that multiple charsets will not be beneficial to the community;
much code would be needed to distinguish and interpret different charsets.
For compatibility with existing implementations, the Working Group will
allow that messages may still be sent that do not indicate the charset used.
However, the Working Group will recommend that messages contain a way to
identify the charset used for the message, and will also recommend a single
default charset.

syslog has traditionally been transported over UDP and this WG has already
defined RFC 3195 for the reliable transport for the syslog messages. The WG
will separate the UDP transport from the protocol so that others may define
additional transports in the future.

The threats that this WG will primarily address are modification,
disclosure, and masquerading. A secondary threat is message stream
modification. Threats that will not be addressed by this WG are DoS and
traffic analysis. The primary attacks may be thwarted by a secure
transport. However, it must be remembered that a great deal of the
success of syslog has been attributed to its ease of implementation and
relatively low maintenance level. The Working Group will consider those
factors, as well as current implementations, when deciding upon a secure
transport. The secondary threat of message stream modification can be
addressed by a mechanism that will verify the end-to-end integrity and
sequence of messages. The Working Group feels that these aspects may be
addressed by a dissociated signature upon sent messages.

- A document will be produced that describes a standardized syslog protocol.
A mechanism will also be defined in this document that will provide a means
to convey structured data.

- A document will be produced that describes a standardized UDP transport
for syslog.

- A document will be produced that requires a secure transport for the
delivery of syslog messages.

- A document will be produced to describe the MIB for syslog entities.

- A document will be produced that describes a standardized mechanism to
sign syslog messages to provide integrity checking and source
authentication.


Milestones:

Nov 2006 Submit Syslog Protocol to the IESG for consideration as a
PROPOSED STANDARD.
Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for
consideration as a PROPOSED STANDARD.
Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for
consideration as a PROPOSED STANDARD.
Nov 2006 Submit Syslog Device MIB to IESG for consideration as a
PROPOSED STANDARD.
Nov 2006 Submit a document that defines a message signing and
ordering mechanism to the IESG for consideration as a
PROPOSED STANDARD

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Wed Mar 22 01:57:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLxHD-00084k-FQ; Wed, 22 Mar 2006 01:57:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLxHC-00084f-J1
	for syslog@ietf.org; Wed, 22 Mar 2006 01:57:02 -0500
Received: from balabit.hu ([195.70.34.196])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLxHB-0000vn-7N
	for syslog@ietf.org; Wed, 22 Mar 2006 01:57:02 -0500
Subject: Re: [Syslog] Other syslog-tls Issues---Issue 1 and 2
From: Balazs Scheidler <bazsi@balabit.hu>
To: Darren Reed <darrenr@reed.wattle.id.au>
In-Reply-To: <200603211821.k2LIL5Lf013292@firewall.reed.wattle.id.au>
References: <200603211821.k2LIL5Lf013292@firewall.reed.wattle.id.au>
Content-Type: text/plain
Date: Wed, 22 Mar 2006 07:56:59 +0100
Message-Id: <1143010619.7365.2.camel@bzorp.balabit>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

On Wed, 2006-03-22 at 05:21 +1100, Darren Reed wrote:
> > On Tue, 2006-03-21 at 18:00 +0800, Miao Fuyou wrote:
> > 
> > So we either leave the SSL certificate binding undefined for the
> > operators to decide, or we need to clarify how certificate is to be
> > validated.
> 
> How much of this is an operational matter that varies from site to site
> with local policies on such things ?

Honestly I don't know. HTTPS gives you a certificate model on the server
side as well. (e.g. use server name in subjectAltName or in CN)

I would say that the basic model is mandated by the protocol, with
overrides in the operator's hand (e.g. the "Yes, I want to continue"
button in the browser, in the case of HTTPS).

-- 
Bazsi


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Thu Mar 23 21:20:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMbuB-0003P2-5R; Thu, 23 Mar 2006 21:19:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FMbu9-0003Om-G9
	for syslog@ietf.org; Thu, 23 Mar 2006 21:19:57 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMbu3-0006lZ-60
	for syslog@ietf.org; Thu, 23 Mar 2006 21:19:57 -0500
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWM005GW1OUDG@szxga02-in.huawei.com> for
	syslog@ietf.org; Fri, 24 Mar 2006 10:31:42 +0800 (CST)
Received: from huawei.com ([172.24.1.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWM00KLW1OTTT@szxga02-in.huawei.com> for
	syslog@ietf.org; Fri, 24 Mar 2006 10:31:41 +0800 (CST)
Received: from m19684 ([10.110.115.32])
	by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0IWM001EO1OIBW@szxml02-in.huawei.com> for
	syslog@ietf.org; Fri, 24 Mar 2006 10:31:31 +0800 (CST)
Date: Fri, 24 Mar 2006 10:18:16 +0800
From: Miao Fuyou <miaofy@huawei.com>
To: syslog@ietf.org
Message-id: <002b01c64ee9$35ec4160$20736e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: 
Subject: [Syslog] FYI: I-D ACTION:draft-miao-syslog-transport-tls-00.txt
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org



-----Original Message-----

From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] 
Sent: Friday, March 24, 2006 4:50 AM
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-miao-syslog-transport-tls-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: TLS Transport Mapping for SYSLOG
	Author(s)	: F. Miao, M. Yuzhi
	Filename	: draft-miao-syslog-transport-tls-00.txt
	Pages		: 11
	Date		: 2006-3-23
	
   This document describes the security threats to Syslog and counter
   measures of using Transport Layer Security(TLS) protocol for such
   threats.  Different phases are defined for using TLS to secure
   Syslog, such as initiation, sending data and closure phase.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-miao-syslog-transport-tls-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-miao-syslog-transport-tls-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-miao-syslog-transport-tls-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Mon Mar 27 15:50:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNyfF-0000cV-28; Mon, 27 Mar 2006 15:50:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNyf5-0000Zc-Bs; Mon, 27 Mar 2006 15:50:03 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNyf5-00006O-9d; Mon, 27 Mar 2006 15:50:03 -0500
Received: from cypress.neustar.com ([209.173.57.84])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FNyf3-0002Bj-Rt; Mon, 27 Mar 2006 15:50:03 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k2RKo10e003759
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Mar 2006 20:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FNyf3-0008H3-Em; Mon, 27 Mar 2006 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1FNyf3-0008H3-Em@stiedprstage1.ietf.org>
Date: Mon, 27 Mar 2006 15:50:01 -0500
X-Spam-Score: -2.6 (--)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: syslog@ietf.org
Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-00.txt 
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF.

	Title		: TLS Transport Mapping for SYSLOG
	Author(s)	: F. Miao, M. Yuzhi
	Filename	: draft-ietf-syslog-transport-tls-00.txt
	Pages		: 11
	Date		: 2006-3-27
	
   This document describes the security threats to Syslog and counter
   measures of using Transport Layer Security(TLS) protocol for such
   threats.  Different phases are defined for using TLS to secure
   Syslog, such as initiation, sending data and closure phase.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-syslog-transport-tls-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-syslog-transport-tls-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-3-27113439.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-syslog-transport-tls-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-syslog-transport-tls-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-3-27113439.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

--NextPart--





From syslog-bounces@lists.ietf.org Tue Mar 28 11:42:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOHGs-0001xH-2v; Tue, 28 Mar 2006 11:42:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOHDV-0008B2-0w
	for syslog@ietf.org; Tue, 28 Mar 2006 11:38:49 -0500
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOHDS-0002Fy-N7
	for syslog@ietf.org; Tue, 28 Mar 2006 11:38:49 -0500
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IWU000JJJFBRF@usaga01-in.huawei.com> for
	syslog@ietf.org; Tue, 28 Mar 2006 08:35:35 -0800 (PST)
Received: from Harrington73653 ([10.124.8.206])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0IWU001FFJFA55@usaga01-in.huawei.com> for
	syslog@ietf.org; Tue, 28 Mar 2006 08:35:35 -0800 (PST)
Date: Tue, 28 Mar 2006 10:38:44 -0600
From: David Harrington <dharrington@huawei.com>
To: syslog@ietf.org
Message-id: <011001c65286$148a48a0$e4087c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
X-Mailman-Approved-At: Tue, 28 Mar 2006 11:42:17 -0500
Cc: 
Subject: [Syslog] FW: Real Notification Requirements for Netconf
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Hi,

There is a discussion about  netconf notification messages going on in
the netconf WG. Part of the discussion is about carrying syslog
content in netconf notifications. It might be useful to have some
syslog experts monitor and contribute to the discussion.

David Harrington
dharrington@huawei.com 

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, March 28, 2006 9:18 AM
To: Shane Kerr
Cc: Andy Bierman; Netconf (E-mail)
Subject: Re: Real Notification Requirements


On Tue, Mar 28, 2006 at 05:02:25PM +0200, Shane Kerr wrote:
 
> Perhaps it would be better to focus on adding a subscription
mechanism
> to SYSLOG?

Certainly an option. Having a subcription mechanism is actually for me
an important feature. Some 12 years ago, we hacked our central syslog
daemon to actually ship syslog messages once you connected to it and
it was a lovely hack which we used a lot (since it makes access to
syslog message real simply for programs).

On the classification question: I think you can put anything into
syslog, so the distinction between syslog messages, configuration
change notifications, or SNMP notifications is kind of artificial.

In fact, it seems popular in many operational environments to have
SNMP notification receivers which simply write to syslog, probably
because there are also pretty nice syslog readers that can trigger all
sorts of actions when they discover certain input patterns.

If we do an interim, it would be valuable to get some syslog experts
there as well so that we can evaluate whether structured syslog and
syslog enhancements will actually solve the problem.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
Germany

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Wed Mar 29 02:14:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOUsq-0008Fr-IC; Wed, 29 Mar 2006 02:14:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOUsp-0008Fm-BW
	for syslog@ietf.org; Wed, 29 Mar 2006 02:14:23 -0500
Received: from hetzner.adiscon.com ([85.10.201.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOUsn-0005So-Ln
	for syslog@ietf.org; Wed, 29 Mar 2006 02:14:23 -0500
Received: from localhost (localhost [127.0.0.1])
	by hetzner.adiscon.com (Postfix) with ESMTP id 1C4B927C066
	for <syslog@ietf.org>; Wed, 29 Mar 2006 08:19:28 +0200 (CEST)
Received: from hetzner.adiscon.com ([127.0.0.1])
	by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 13048-01 for <syslog@ietf.org>;
	Wed, 29 Mar 2006 08:19:27 +0200 (CEST)
Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de
	[217.91.104.213])
	by hetzner.adiscon.com (Postfix) with ESMTP id A2F8327C061
	for <syslog@ietf.org>; Wed, 29 Mar 2006 08:19:27 +0200 (CEST)
Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by
	fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830);
	Wed, 29 Mar 2006 09:14:19 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 29 Mar 2006 09:14:17 +0200
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1743CD@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Why are we doing netconf?
Thread-Index: AcZSolQtkrzQ66qlQYiQnLb3eaavBgAXf7uw
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: <syslog@ietf.org>
X-OriginalArrivalTime: 29 Mar 2006 07:14:19.0409 (UTC)
	FILETIME=[6577C010:01C65300]
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a
Cc: 
Subject: [Syslog] FW: Why are we doing netconf?
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

WG,

this is another posting from the NETCONF WG which I also consider quite
important for the syslog WG.

Rainer=20

> -----Original Message-----
> From: owner-netconf@ops.ietf.org=20
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of David Harrington
> Sent: Tuesday, March 28, 2006 8:26 PM
> To: 'Netconf (E-mail)'
> Subject: Why are we doing netconf?
>=20
> Hi,
>=20
> I would like a better understasnding of why we are doing
> notifications. I am struck by what appears to me to be two very
> different drivers for netconf, and the "why are we doing
> notifications?" question relates to these different motivations.
>=20
> I have suggested that the O&M and Security communities should work at
> establishing a strategic vision about converging aspects of the
> various NM protocols and NM security solutions. If this is a path
> worth taking, it should be a deliberate decision to do so because
> there are some real problems associated with a convergence approach.
>=20
> For this reason, I would like to understand what we are trying to
> achieve with netconf and the current proposal for notifications, to
> determine if the goals are compatible.
>=20
> If the purpose of netconf is to provide a machine-friendly,
> standardized protocol to eliminate the need for screen scraping CLI
> expect scripts, I am not convinced we need notifications in the
> netconf protocol. I think the netconf WG has done a reasonably good
> job of standardizing the operations, but to achieve the goals, we also
> need to improve the parseability of the data that now needs to be
> screen scraped. The parseability of the data contained in the
> responses coming back must be addressed. If vendors simply take their
> existing screens of data and surround them with <cli></cli> tags, then
> I think we've failed to eliminate the screen-scraping problem, and
> other problems identified by operators at the IAB NM workshop:
>=20
>    -  Some command line interfaces lack a common data model.  It is
> very
>       well possible that the same command on different devices, even
>       from the same vendor, behaves differently.
>=20
>    -  The command line interface is primarily targeted to humans which
>       can adapt to minor syntax and format changes easily.  Using
>       command line interfaces as a programmatic interface is
> troublesome
>       because of parsing complexities.
>=20
>    -  Command line interfaces often lack proper version control for
> the
>       syntax and the semantics.  It is therefore time consuming and
>       error prone to maintain programs or scripts that interface with
>       different versions of a command line interface.
>=20
>    -  Since command line interfaces are proprietary, they can not be
>       used efficiently to automate processes in an environment with a
>       heterogenous set of devices.
>=20
>    -  The access control facilities, if present at all, are often
> ad-hoc
>       and sometimes insufficient.
>=20
> Netconf does not seem to resolve these operational disadvantages of
> the CLI, and notifications aren't even mentioned as a problem to be
> solved.
>=20
> If the purpose of netconf is to standardzie existing practice, and
> existing practice is defined as screen scraping CLI expect scripts
> plus syslog notifications, then I question whether we need to include
> syslog notifications in netconf; syslog works well in its special
> niche, and really doesn't need to be added to netconf.
>=20
> The Syslog (-security) WG has been working to standardize the message
> header format. The syslog community has not reached consensus on the
> need to standard message content, except to add a structured data
> component. The WG had difficulty even reaching agreement on
> standardizing their message header format beyond starting the message
> with <PRI>. I do not believe that netconf would be more successful at
> standardizing syslog content than the syslog community, so I do not
> believe that standardizing syslog message content should be a
> justification for adding notifications to netconf, without a long
> discussion about the feasibility of accomplishing this goal. I think
> the standardization of syslog belongs in a (O&M) syslog WG, not the
> netconf WG (and not the syslog security WG).
>=20
> If the purpose of netconf is to assimilate the functionality of older
> protocols like syslog and SNMP - to integrate them into a collective
> netconf structure, and to eventually replace the old protocols with a
> new general purpose management protocol minus the known problems, then
> netconf has a higher bar to meet in its design requirements than have
> been acknowledged. SNMPv3 is complex because it needed to deal with
> security issues and troubleshooting requirements and other things;
> syslog does not have a standard content format because there are a
> wide number of vendors protecting their space, and the demand for
> backwards compatibility to all or most existing header formats has
> prevented progress in the syslog (security) WG. Faced with
> requirements comparable to those faced by the older protocols during
> their design, I expect netconf would fail to assimilate them properly.
> Therefore, if the purpose of netconf is to be a general purpose NM
> protocol, we need to have a serious discussion about the requirements
> that must be met to achieve successful assimilation.
>=20
> I find the existing proposal has plans to assimilate other protocols -
> "The purpose of this [syslog-to-netconf] mapping is to provide an
> unambiguous mapping to enable consistent multi-protocol
> implementations as well as to enable future migration." and to attempt
> to standardize that which the syslog community has failed to
> standardize - "The intent is to promote the use of the NETCONF
> interface and not to simply provide a wrapper and additional delivery
> mechanism for syslog messages.  NETCONF events are intended to be well
> defined and structured, therefore providing an advantage over the
> unstructured and often times arbitrarily defined syslog messages (i.e.
> the message field)."
>=20
> I am a strong supporter of judicious reuse of NM and security
> solutions across NM interfaces, but I believe apparent convergence
> opportunities need to be discussed and for  each convergence we need
> to consider the requirements met by each protocol and whether a
> converged solution continues to meet those requirements or
> deliberately does not meet some requirements.
>=20
> I am bothered by the fact that netconf, a configuration protocol, is
> being redesigned in the current proposal to carry syslog messages that
> may have nothing to do with configuration, and it is expected that
> even more stuff, also possibly not related to configuration, will be
> carried in a new event message format. Operators at the IAB Network
> Management Workshop apparently did not find syslog sufficiently broken
> to request that a new event messaging capability be designed, so I
> have concerns that the current proposal includes a brand-new
> notification solution.
>=20
> If netconf will become the new general purpose mgmt protocol for the
> IETF, we should do this deliberately, not as a side-effect of adding a
> notification operation to netconf.
>=20
> David Harrington
> FutureWei Technologies, a Huawei company
> dharrington@huawei.com=20
> dbharrington@comcast.net
> ietfdbh@comcast.net
>=20
> > -----Original Message-----
> > From: owner-netconf@ops.ietf.org=20
> > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan
> (Dan)
> > Sent: Monday, March 27, 2006 5:20 AM
> > To: Andy Bierman
> > Cc: Netconf (E-mail)
> > Subject: RE: Interim attendance survey
> >=20
> > [...] I am aware that this good shape is
> > apparent, and there is little agreement on the problem space, and
> too
> > little review of the draft that includes a proposed solution even to
> > determine the level of agreement. I would encourage the WG to focus
> on
> > discussing the problem space (why are we doing notifications?) and
> the
> > draft and other options for solutions more intensively on the=20
> > list. Let
> > us see in the next couple of weeks if we can reach more convergence
> on
> > the 'why' and 'how' questions.=20
> >=20
> > If we do have contributions about the scope and reviews of=20
> > the draft and
> > solutions on the list we have a chance to better converge and reach
> > agreement. If the level of apathy stays the same, I am not sure that
> a
> > partially attended interim meeting would help.=20
> >=20
>=20
>=20
>=20
>=20
>=20
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>=20

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Wed Mar 29 08:19:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOaaM-0003ZJ-Bx; Wed, 29 Mar 2006 08:19:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOaaM-0003Yk-12
	for syslog@ietf.org; Wed, 29 Mar 2006 08:19:42 -0500
Received: from test-iport-1.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOaaK-0003sx-5X
	for syslog@ietf.org; Wed, 29 Mar 2006 08:19:41 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by test-iport-1.cisco.com with ESMTP; 29 Mar 2006 05:19:39 -0800
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2TDJdw2005248;
	Wed, 29 Mar 2006 05:19:39 -0800 (PST)
Date: Wed, 29 Mar 2006 05:19:39 -0800 (PST)
From: Chris Lonvick <clonvick@cisco.com>
To: Rainer Gerhards <rgerhards@hq.adiscon.com>
Subject: Re: [Syslog] FW: Why are we doing netconf?
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1743CD@grfint2.intern.adiscon.com>
Message-ID: <Pine.GSO.4.63.0603290512370.23699@sjc-cde-011.cisco.com>
References: <577465F99B41C842AAFBE9ED71E70ABA1743CD@grfint2.intern.adiscon.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a743e34ab8eb08259de9a7307caed594
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Hi Folks,

This has been a debate in the netconf WG for some time.  I've had talks 
with many of the people participating in netconf over the past few years. 
I've been urging them to use syslog-protocol if they decide to pursue 
notifications within netconf.  At various past IETF meetings I've usually 
gotten people to agree to that.  And at other IETF meetings, and on their 
mailing list, the question continues to resurface and they have to address 
it again.

For those who are interested in the discussion but who are not subscribed 
to both WG mailing lists, please visit the netconf archive:
   https://ops.ietf.org/lists/netconf/

Thanks,
Chris


On Wed, 29 Mar 2006, Rainer Gerhards wrote:

> WG,
>
> this is another posting from the NETCONF WG which I also consider quite
> important for the syslog WG.
>
> Rainer
>
>> -----Original Message-----
>> From: owner-netconf@ops.ietf.org
>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of David Harrington
>> Sent: Tuesday, March 28, 2006 8:26 PM
>> To: 'Netconf (E-mail)'
>> Subject: Why are we doing netconf?
>>
>> Hi,
>>
>> I would like a better understasnding of why we are doing
>> notifications. I am struck by what appears to me to be two very
>> different drivers for netconf, and the "why are we doing
>> notifications?" question relates to these different motivations.
>>
>> I have suggested that the O&M and Security communities should work at
>> establishing a strategic vision about converging aspects of the
>> various NM protocols and NM security solutions. If this is a path
>> worth taking, it should be a deliberate decision to do so because
>> there are some real problems associated with a convergence approach.
>>
>> For this reason, I would like to understand what we are trying to
>> achieve with netconf and the current proposal for notifications, to
>> determine if the goals are compatible.
>>
>> If the purpose of netconf is to provide a machine-friendly,
>> standardized protocol to eliminate the need for screen scraping CLI
>> expect scripts, I am not convinced we need notifications in the
>> netconf protocol. I think the netconf WG has done a reasonably good
>> job of standardizing the operations, but to achieve the goals, we also
>> need to improve the parseability of the data that now needs to be
>> screen scraped. The parseability of the data contained in the
>> responses coming back must be addressed. If vendors simply take their
>> existing screens of data and surround them with <cli></cli> tags, then
>> I think we've failed to eliminate the screen-scraping problem, and
>> other problems identified by operators at the IAB NM workshop:
>>
>>    -  Some command line interfaces lack a common data model.  It is
>> very
>>       well possible that the same command on different devices, even
>>       from the same vendor, behaves differently.
>>
>>    -  The command line interface is primarily targeted to humans which
>>       can adapt to minor syntax and format changes easily.  Using
>>       command line interfaces as a programmatic interface is
>> troublesome
>>       because of parsing complexities.
>>
>>    -  Command line interfaces often lack proper version control for
>> the
>>       syntax and the semantics.  It is therefore time consuming and
>>       error prone to maintain programs or scripts that interface with
>>       different versions of a command line interface.
>>
>>    -  Since command line interfaces are proprietary, they can not be
>>       used efficiently to automate processes in an environment with a
>>       heterogenous set of devices.
>>
>>    -  The access control facilities, if present at all, are often
>> ad-hoc
>>       and sometimes insufficient.
>>
>> Netconf does not seem to resolve these operational disadvantages of
>> the CLI, and notifications aren't even mentioned as a problem to be
>> solved.
>>
>> If the purpose of netconf is to standardzie existing practice, and
>> existing practice is defined as screen scraping CLI expect scripts
>> plus syslog notifications, then I question whether we need to include
>> syslog notifications in netconf; syslog works well in its special
>> niche, and really doesn't need to be added to netconf.
>>
>> The Syslog (-security) WG has been working to standardize the message
>> header format. The syslog community has not reached consensus on the
>> need to standard message content, except to add a structured data
>> component. The WG had difficulty even reaching agreement on
>> standardizing their message header format beyond starting the message
>> with <PRI>. I do not believe that netconf would be more successful at
>> standardizing syslog content than the syslog community, so I do not
>> believe that standardizing syslog message content should be a
>> justification for adding notifications to netconf, without a long
>> discussion about the feasibility of accomplishing this goal. I think
>> the standardization of syslog belongs in a (O&M) syslog WG, not the
>> netconf WG (and not the syslog security WG).
>>
>> If the purpose of netconf is to assimilate the functionality of older
>> protocols like syslog and SNMP - to integrate them into a collective
>> netconf structure, and to eventually replace the old protocols with a
>> new general purpose management protocol minus the known problems, then
>> netconf has a higher bar to meet in its design requirements than have
>> been acknowledged. SNMPv3 is complex because it needed to deal with
>> security issues and troubleshooting requirements and other things;
>> syslog does not have a standard content format because there are a
>> wide number of vendors protecting their space, and the demand for
>> backwards compatibility to all or most existing header formats has
>> prevented progress in the syslog (security) WG. Faced with
>> requirements comparable to those faced by the older protocols during
>> their design, I expect netconf would fail to assimilate them properly.
>> Therefore, if the purpose of netconf is to be a general purpose NM
>> protocol, we need to have a serious discussion about the requirements
>> that must be met to achieve successful assimilation.
>>
>> I find the existing proposal has plans to assimilate other protocols -
>> "The purpose of this [syslog-to-netconf] mapping is to provide an
>> unambiguous mapping to enable consistent multi-protocol
>> implementations as well as to enable future migration." and to attempt
>> to standardize that which the syslog community has failed to
>> standardize - "The intent is to promote the use of the NETCONF
>> interface and not to simply provide a wrapper and additional delivery
>> mechanism for syslog messages.  NETCONF events are intended to be well
>> defined and structured, therefore providing an advantage over the
>> unstructured and often times arbitrarily defined syslog messages (i.e.
>> the message field)."
>>
>> I am a strong supporter of judicious reuse of NM and security
>> solutions across NM interfaces, but I believe apparent convergence
>> opportunities need to be discussed and for  each convergence we need
>> to consider the requirements met by each protocol and whether a
>> converged solution continues to meet those requirements or
>> deliberately does not meet some requirements.
>>
>> I am bothered by the fact that netconf, a configuration protocol, is
>> being redesigned in the current proposal to carry syslog messages that
>> may have nothing to do with configuration, and it is expected that
>> even more stuff, also possibly not related to configuration, will be
>> carried in a new event message format. Operators at the IAB Network
>> Management Workshop apparently did not find syslog sufficiently broken
>> to request that a new event messaging capability be designed, so I
>> have concerns that the current proposal includes a brand-new
>> notification solution.
>>
>> If netconf will become the new general purpose mgmt protocol for the
>> IETF, we should do this deliberately, not as a side-effect of adding a
>> notification operation to netconf.
>>
>> David Harrington
>> FutureWei Technologies, a Huawei company
>> dharrington@huawei.com
>> dbharrington@comcast.net
>> ietfdbh@comcast.net
>>
>>> -----Original Message-----
>>> From: owner-netconf@ops.ietf.org
>>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan
>> (Dan)
>>> Sent: Monday, March 27, 2006 5:20 AM
>>> To: Andy Bierman
>>> Cc: Netconf (E-mail)
>>> Subject: RE: Interim attendance survey
>>>
>>> [...] I am aware that this good shape is
>>> apparent, and there is little agreement on the problem space, and
>> too
>>> little review of the draft that includes a proposed solution even to
>>> determine the level of agreement. I would encourage the WG to focus
>> on
>>> discussing the problem space (why are we doing notifications?) and
>> the
>>> draft and other options for solutions more intensively on the
>>> list. Let
>>> us see in the next couple of weeks if we can reach more convergence
>> on
>>> the 'why' and 'how' questions.
>>>
>>> If we do have contributions about the scope and reviews of
>>> the draft and
>>> solutions on the list we have a chance to better converge and reach
>>> agreement. If the level of apathy stays the same, I am not sure that
>> a
>>> partially attended interim meeting would help.
>>>
>>
>>
>>
>>
>>
>> --
>> to unsubscribe send a message to netconf-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
>>
>
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
>

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Wed Mar 29 09:39:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FObpw-0003HP-Mz; Wed, 29 Mar 2006 09:39:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FObpw-0003HF-7f
	for syslog@ietf.org; Wed, 29 Mar 2006 09:39:52 -0500
Received: from ns1.cpanel.btnaccess.com ([205.177.121.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FObpw-0007UL-0H
	for syslog@ietf.org; Wed, 29 Mar 2006 09:39:52 -0500
Received: from [65.213.193.6] (helo=ISODELL001)
	by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52)
	id 1FObpu-0008Gk-Uj
	for syslog@ietf.org; Wed, 29 Mar 2006 09:39:50 -0500
From: "Robert Holliday" <robholliday@isocore.com>
To: <syslog@ietf.org>
Date: Wed, 29 Mar 2006 09:39:45 -0500
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcZTPp9uBiSMCpndQoONpdy8dp22Og==
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - isocore.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
Cc: 
Subject: [Syslog] ICNS 2006: Early Registration Ends April 1
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1211569922=="
Errors-To: syslog-bounces@lists.ietf.org
Message-Id: <E1FObpw-0003HP-Mz@megatron.ietf.org>

This is a multi-part message in MIME format.

--===============1211569922==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002B_01C65314.B7440F20"

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C65314.B7440F20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

International Conference on Network Security 2006, April 17-19, Reston,
Virginia

 

Only a few days remain to take advantage of Early Bird Specials when
registering for ICNS2006.  All those registering before April 1 receive will
receive a $200 dollar discount.  Don't miss out on the chance to interact
with industry leaders in a personal setting and unique format.

 

Technical Program: http://www.isocore.com/networksecurity2006/program.htm 

 

Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm

 


------=_NextPart_000_002B_01C65314.B7440F20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3Dtexte><b><font size=3D1 color=3Dblue =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial;color:blue;font-weight:
bold'>International Conference on Network Security 2006, April 17-19, =
Reston, Virginia</span></font></b></span></p>

<p class=3DMsoNormal><span class=3Dtexte><font size=3D1 =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:9.0pt;font-family:Arial'>&nbsp;</span></font></span></=
p>

<p class=3DMsoNormal><span class=3Dtexte><font size=3D1 =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:9.0pt;font-family:Arial'>Only a few days remain to =
take
advantage of Early Bird Specials when registering for ICNS2006.&nbsp; =
All those
registering before April 1 receive will receive a $200 dollar =
discount.&nbsp;
Don&#8217;t miss out on the chance to interact with industry leaders in =
a
personal setting and unique format.</span></font></span></p>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>&nbsp;</span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Technical =
Program:</span></font></b><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> <a
href=3D"http://www.isocore.com/networksecurity2006/program.htm">http://ww=
w.isocore.com/networksecurity2006/program.htm</a>
</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><span class=3Dtexte><b><font size=3D1 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial;font-weight:bold'>Registration=
:</span></font></b></span><span
class=3Dtexte><font size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:9.0pt;
font-family:Arial'> <a
href=3D"http://www.isocore.com/networksecurity2006/onlineregis.htm">http:=
//www.isocore.com/networksecurity2006/onlineregis.htm</a></span></font></=
span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_002B_01C65314.B7440F20--




--===============1211569922==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

--===============1211569922==--






From syslog-bounces@lists.ietf.org Wed Mar 29 17:57:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOjbD-0005Og-Nz; Wed, 29 Mar 2006 17:57:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOjbD-0005Ob-3l
	for syslog@ietf.org; Wed, 29 Mar 2006 17:57:11 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOjbC-0004at-Dl
	for syslog@ietf.org; Wed, 29 Mar 2006 17:57:11 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-3.cisco.com with ESMTP; 29 Mar 2006 14:57:09 -0800
X-IronPort-AV: i="4.03,144,1141632000"; 
	d="scan'208"; a="421195700:sNHT48528112"
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2TMv9Gw016382
	for <syslog@ietf.org>; Wed, 29 Mar 2006 14:57:09 -0800 (PST)
Date: Wed, 29 Mar 2006 14:57:09 -0800 (PST)
From: Chris Lonvick <clonvick@cisco.com>
To: syslog@ietf.org
Message-ID: <Pine.GSO.4.63.0603291456290.23699@sjc-cde-011.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fe105289edd72640d9f392da880eefa2
Cc: 
Subject: [Syslog] Re: Why are we doing netconf? (fwd)
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Hi Folks,

I think that this resolves the netconf discussion.

Thanks,
Chris

---------- Forwarded message ----------
Date: Wed, 29 Mar 2006 14:53:20 -0800
From: Andy Bierman <ietf@andybierman.com>
To: Sharon Chisholm <schishol@nortel.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: Re: Why are we doing netconf?

Sharon Chisholm wrote:
>  hi

To all the people who want netconf to be a replacement
for syslog, snmp, ipfix, or whatever:

How about if we solve network configuration first,
then replace every other MGMT protocol in the world
with our new protocol?  (!)

I don't think the WG agrees that notifications in the
NETCONF protocol is a critical missing component,
let alone the most important critical missing component.

For NETCONF to be truly content-independent, the notification
delivery mechanism needs to be totally decoupled from
notification content.  There are a lot of different
ideas on this content, and who should standardize it.

I am totally opposed to the NETCONF WG working on syslog
content.  We need syslog experts (and the Chair) for that.
Sounds like a BOF in the works, but no NETCONF work item here.

I am also totally opposed to working on anything but
the bare minimum number of standard notifications
(like config-change) at this time.  You want a data model,
how about creating a writable interfaces table and an access control
model?  These are critical missing data models.


Andy

>
>  Thanks Dave for the well-thought through post.
>
>  I think the 'restriction' on Netconf for configuration has always been
>  an artificial one, but it has served us well. One of the big problems we
>  ran into with SNMP was we kept picking off the easier problem of
>  monitoring and never giving configuration enough focus. By limiting the
>  focusing primarily on configuration for Netconf 1.0, we have ended up
>  with a great technical solution that is seeing some good market uptake.
>
>  I think actual implementations of Netconf are not limiting themselves to
>  just configuration. The CLI never did. For deployments, the high cost of
>  having to integrate information from different sources gets weighed
>  against the cost of having to replace legacy systems. Sometimes it wins.
>  Sometimes it doesn't. For the most part, all this can be done using the
>  existing framework. The gaps that people run into when trying to do this
>  are, I believe, the same ones they run into while trying to use Netconf
>  for configuration - access control, data model and notifications.
>  Another gap might be 'operational' commands such as rebooting and
>  maintenance, but the universal requirements there are not yet clear to
>  me.
>
>  I've personally been working both the data modeling and the notification
>  issue. I'd work access control, but other then a sense that I'd like
>  something simpler then we've seen in the past, I have no idea what we
>  would need. They are all important, both for configuration-only
>  implementations and configuration-plus ones.  I've focused more on the
>  notification work lately because I was getting a lot of pushback on the
>  data model work from certain people, but I'm willing to put time on that
>  topic again. I think though, that for people looking to be able to pick
>  up third-party Netconf stacks, there are some big advantages to being
>  able to standardize on any extended protocol operations sooner rather
>  then later.
>
>  As far as whether if we said from day one that netconf would do more
>  than configuration and things would have been designed differently, I
>  don't now if that is the case. As far as being forced to solve problems
>  at some point in the future related to performance management if we
>  don't somehow engineer/re-engineer the protocol so it can't be used for
>  things like that, I don't think that would be helpful.   At that day in
>  the future the community can decide whether it wants to spend time on
>  that particular problem. Plus, unless at that point in the future we
>  learned that they were not also using Netconf for configuration, this
>  would be a sign of success.
>
>  So, in summary, I think the current notification work absolutely is
>  necessary for configuration management. I don't see the value of
>  precluding its use for other functions and I believe for the other
>  functions all we need to do is provide the ability to specify the
>  correct event class. I'm also willing to work on the other gaps.
>
>  Sharon
>
>  -----Original Message-----
>  From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
>  Behalf Of David Harrington
>  Sent: Tuesday, March 28, 2006 1:26 PM
>  To: 'Netconf (E-mail)'
>  Subject: Why are we doing netconf?
>
>
>  Hi,
>
>  I would like a better understasnding of why we are doing notifications.
>  I am struck by what appears to me to be two very different drivers for
>  netconf, and the "why are we doing notifications?" question relates to
>  these different motivations.
>
>  I have suggested that the O&M and Security communities should work at
>  establishing a strategic vision about converging aspects of the various
>  NM protocols and NM security solutions. If this is a path worth taking,
>  it should be a deliberate decision to do so because there are some real
>  problems associated with a convergence approach.
>
>  For this reason, I would like to understand what we are trying to
>  achieve with netconf and the current proposal for notifications, to
>  determine if the goals are compatible.
>
>  If the purpose of netconf is to provide a machine-friendly, standardized
>  protocol to eliminate the need for screen scraping CLI expect scripts, I
>  am not convinced we need notifications in the netconf protocol. I think
>  the netconf WG has done a reasonably good job of standardizing the
>  operations, but to achieve the goals, we also need to improve the
>  parseability of the data that now needs to be screen scraped. The
>  parseability of the data contained in the responses coming back must be
>  addressed. If vendors simply take their existing screens of data and
>  surround them with <cli></cli> tags, then I think we've failed to
>  eliminate the screen-scraping problem, and other problems identified by
>  operators at the IAB NM workshop:
>
>     -  Some command line interfaces lack a common data model.  It is very
>        well possible that the same command on different devices, even
>        from the same vendor, behaves differently.
>
>     -  The command line interface is primarily targeted to humans which
>        can adapt to minor syntax and format changes easily.  Using
>        command line interfaces as a programmatic interface is troublesome
>        because of parsing complexities.
>
>     -  Command line interfaces often lack proper version control for the
>        syntax and the semantics.  It is therefore time consuming and
>        error prone to maintain programs or scripts that interface with
>        different versions of a command line interface.
>
>     -  Since command line interfaces are proprietary, they can not be
>        used efficiently to automate processes in an environment with a
>        heterogenous set of devices.
>
>     -  The access control facilities, if present at all, are often ad-hoc
>        and sometimes insufficient.
>
>  Netconf does not seem to resolve these operational disadvantages of the
>  CLI, and notifications aren't even mentioned as a problem to be solved.
>
>  If the purpose of netconf is to standardzie existing practice, and
>  existing practice is defined as screen scraping CLI expect scripts plus
>  syslog notifications, then I question whether we need to include syslog
>  notifications in netconf; syslog works well in its special niche, and
>  really doesn't need to be added to netconf.
>
>  The Syslog (-security) WG has been working to standardize the message
>  header format. The syslog community has not reached consensus on the
>  need to standard message content, except to add a structured data
>  component. The WG had difficulty even reaching agreement on
>  standardizing their message header format beyond starting the message
>  with <PRI>. I do not believe that netconf would be more successful at
>  standardizing syslog content than the syslog community, so I do not
>  believe that standardizing syslog message content should be a
>  justification for adding notifications to netconf, without a long
>  discussion about the feasibility of accomplishing this goal. I think the
>  standardization of syslog belongs in a (O&M) syslog WG, not the netconf
>  WG (and not the syslog security WG).
>
>  If the purpose of netconf is to assimilate the functionality of older
>  protocols like syslog and SNMP - to integrate them into a collective
>  netconf structure, and to eventually replace the old protocols with a
>  new general purpose management protocol minus the known problems, then
>  netconf has a higher bar to meet in its design requirements than have
>  been acknowledged. SNMPv3 is complex because it needed to deal with
>  security issues and troubleshooting requirements and other things;
>  syslog does not have a standard content format because there are a wide
>  number of vendors protecting their space, and the demand for backwards
>  compatibility to all or most existing header formats has prevented
>  progress in the syslog (security) WG. Faced with requirements comparable
>  to those faced by the older protocols during their design, I expect
>  netconf would fail to assimilate them properly. Therefore, if the
>  purpose of netconf is to be a general purpose NM protocol, we need to
>  have a serious discussion about the requirements that must be met to
>  achieve successful assimilation.
>
>  I find the existing proposal has plans to assimilate other protocols -
>  "The purpose of this [syslog-to-netconf] mapping is to provide an
>  unambiguous mapping to enable consistent multi-protocol implementations
>  as well as to enable future migration." and to attempt to standardize
>  that which the syslog community has failed to standardize - "The intent
>  is to promote the use of the NETCONF interface and not to simply provide
>  a wrapper and additional delivery mechanism for syslog messages.
>  NETCONF events are intended to be well defined and structured, therefore
>  providing an advantage over the unstructured and often times arbitrarily
>  defined syslog messages (i.e. the message field)."
>
>  I am a strong supporter of judicious reuse of NM and security solutions
>  across NM interfaces, but I believe apparent convergence opportunities
>  need to be discussed and for  each convergence we need to consider the
>  requirements met by each protocol and whether a converged solution
>  continues to meet those requirements or deliberately does not meet some
>  requirements.
>
>  I am bothered by the fact that netconf, a configuration protocol, is
>  being redesigned in the current proposal to carry syslog messages that
>  may have nothing to do with configuration, and it is expected that even
>  more stuff, also possibly not related to configuration, will be carried
>  in a new event message format. Operators at the IAB Network Management
>  Workshop apparently did not find syslog sufficiently broken to request
>  that a new event messaging capability be designed, so I have concerns
>  that the current proposal includes a brand-new notification solution.
>
>  If netconf will become the new general purpose mgmt protocol for the
>  IETF, we should do this deliberately, not as a side-effect of adding a
>  notification operation to netconf.
>
>  David Harrington
>  FutureWei Technologies, a Huawei company
>  dharrington@huawei.com dbharrington@comcast.net
>  ietfdbh@comcast.net
> 
> >  -----Original Message-----
> >  From: owner-netconf@ops.ietf.org
> >  [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan
>  (Dan)
> >  Sent: Monday, March 27, 2006 5:20 AM
> >  To: Andy Bierman
> >  Cc: Netconf (E-mail)
> >  Subject: RE: Interim attendance survey
> > 
> >  [...] I am aware that this good shape is
> >  apparent, and there is little agreement on the problem space, and
>  too
> >  little review of the draft that includes a proposed solution even to 
> >  determine the level of agreement. I would encourage the WG to focus
>  on
> >  discussing the problem space (why are we doing notifications?) and
>  the
> >  draft and other options for solutions more intensively on the
> >  list. Let
> >  us see in the next couple of weeks if we can reach more convergence
>  on
> >  the 'why' and 'how' questions.
> > 
> >  If we do have contributions about the scope and reviews of
> >  the draft and
> >  solutions on the list we have a chance to better converge and reach
> >  agreement. If the level of apathy stays the same, I am not sure that
>  a
> >  partially attended interim meeting would help.
> >
>
>
>
>
>
>  --
>  to unsubscribe send a message to netconf-request@ops.ietf.org with
>  the word 'unsubscribe' in a single line as the message text body.
>  archive: <http://ops.ietf.org/lists/netconf/>
>
>
>  --
>  to unsubscribe send a message to netconf-request@ops.ietf.org with
>  the word 'unsubscribe' in a single line as the message text body.
>  archive: <http://ops.ietf.org/lists/netconf/>
>
>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



From syslog-bounces@lists.ietf.org Wed Mar 29 18:00:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOjem-0006Fp-1Z; Wed, 29 Mar 2006 18:00:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOjek-0006Dt-Pp
	for syslog@ietf.org; Wed, 29 Mar 2006 18:00:50 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOjej-0004qr-HP
	for syslog@ietf.org; Wed, 29 Mar 2006 18:00:50 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-3.cisco.com with ESMTP; 29 Mar 2006 15:00:49 -0800
X-IronPort-AV: i="4.03,144,1141632000"; 
	d="scan'208"; a="421198144:sNHT27000482"
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2TN0mGw020598
	for <syslog@ietf.org>; Wed, 29 Mar 2006 15:00:48 -0800 (PST)
Date: Wed, 29 Mar 2006 15:00:48 -0800 (PST)
From: Chris Lonvick <clonvick@cisco.com>
To: syslog@ietf.org
Message-ID: <Pine.GSO.4.63.0603291457130.23699@sjc-cde-011.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 
Subject: [Syslog] Revised Additional syslog Page
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>,
	<mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Hi,

I've updated our WG page:

   http://www.employees.org/~lonvick/index.shtml

The most important piece of work at this moment is a review of 
syslog-transport-tls.

http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-00.txt

Let's get the discussion going on this.  Once we get this one finalized, 
then we can submit syslog-protocol, syslog-transport-udp, and 
syslog-transport-tls.  That clears the road for us to work on syslog-sign, 
syslog-device-mib and a revision to RFC 3195.

Thanks,
Chris

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog