Rainer Gerhards | 2 Jan 11:41 2006

TIMESTAMP and leap seconds

Hi all,

first of all, I would like to whish a happy new year to each of you!

I am now back in the office and at final edits to syslog-protocol. I
discovered one more thing: The current draft supports leap seconds.
There already is a lot of discussion whether or not leap seconds should
be introduced in the future. However, the way leap seconds are handled
will be largely invisible to a syslog sender (except where it is sitting
on a time-tracking device, which is highly unlikely). On the other hand,
leap second processing can be pretty complicated at the receiver side. I
expect that most implementations will not abide strict handling in any
case.

As such, I suggest that leap second support be removed from the
TIMESTAMP. Similarily, a sender with unknown time should then not use
the special TIMESTAMP but "-", which also keeps it consistent with the
rest of the header NIL values.

If nobody objects, I'll change this during the edit.

Rainer

_______________________________________________
Syslog mailing list
Syslog <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

Andrew Ross | 3 Jan 10:32 2006

RE: TIMESTAMP and leap seconds


Hi Rainer,

Happy new year!

Your idea of ignoring the leap seconds sounds very sensible to me.

Cheers

Andrew

-----Original Message-----
From: syslog-bounces <at> lists.ietf.org [mailto:syslog-bounces <at> lists.ietf.org]
On Behalf Of Rainer Gerhards
Sent: Monday, 2 January 2006 11:42 p.m.
To: syslog <at> ietf.org
Subject: [Syslog] TIMESTAMP and leap seconds

Hi all,

first of all, I would like to whish a happy new year to each of you!

I am now back in the office and at final edits to syslog-protocol. I
discovered one more thing: The current draft supports leap seconds.
There already is a lot of discussion whether or not leap seconds should
be introduced in the future. However, the way leap seconds are handled
will be largely invisible to a syslog sender (except where it is sitting
on a time-tracking device, which is highly unlikely). On the other hand,
leap second processing can be pretty complicated at the receiver side. I
expect that most implementations will not abide strict handling in any
(Continue reading)

Internet-Drafts | 3 Jan 21:50 2006
Picon

I-D ACTION:draft-ietf-syslog-protocol-16.txt

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		: The syslog Protocol
	Author(s)	: R. Gerhards
	Filename	: draft-ietf-syslog-protocol-16.txt
	Pages		: 45
	Date		: 2006-1-3
	
This document describes the syslog protocol, which is used to convey
   event notification messages.  This protocol utilizes a layered
   architecture, which allows the use of any number of transport
   protocols for transmission of syslog messages.  It also provides a
   message format that allows vendor-specific extensions to be provided
   in a structured way.

   This document has been written with the spirit of traditional syslog
   in mind.  The reason for a new layered specification has arisen
   because standardization efforts for reliable, and secure syslog
   extensions suffer from the lack of a standards-track and transport
   independent RFC.  Without this document, each other standard needs to
   define its own syslog packet format and transport mechanism, which
   over time will introduce subtle compatibility issues.  This document
   tries to provide a foundation that syslog extensions can build on.
   The layered architecture also provides a solid basis that allows code
   to be written once instead of multiple times, once for each syslog
   feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-16.txt
(Continue reading)

Tom Petch | 5 Jan 21:16 2006

draft-ietf-syslog-device-mib-07.txt

I have had a look at the syslog MIB, and am confused, at a fairly fundamental
level, about the relationship of the MIB to the other documents, RFC3164 and
syslog-protocol.  The last two have a common framework/architecture, spelt out
at the beginning of each, with a common terminology of device, relay, collector,
server.  The MIB is different.

Thus, it is a device MIB (not a protocol MIB) (quoting) 'to monitor a group of
syslog devices' and 'One or more syslog devices which may be on the same host'.
'"facilities" generate messages indicating their own status or the occurance of
events. These messages are handled by what has come to be known as the syslog
process or device'

Which leaves me with the impression of a loosely-coupled system of hosts
communicating via proprietary protocols with multiple instances of a syslog
daemon per host forwarding messages onward.  Really? could be but I think I am
lost here and that the introduction should be recast in the language of
RFC3164/syslog-protocol (even if it is intending to convey the above).

Tom  Petch

_______________________________________________
Syslog mailing list
Syslog <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

Sam Hartman | 5 Jan 23:12 2006
Picon

Charter comments from IESG Review


Hi.  The IESg reviewed the proposed syslog charter at today's telechat
and decided that it requires revision.  The main concern seems to be
the lack of a mandatory to implement security mechanism.  I indicated
this might be the case in the Vancouver meeting.

so, you definitely need to have some sort of mandatory to implement
security mechanism.  I'm not quite sure what needs to be said about
this in the charter.
But the working group will need to:

1) Identify a threat  model for syslog

2) Define mechanisms to address these threats.

So, questions for the threat model include things like whether
confidentiality is important or whether integrity of mesages is
sufficient.

Depending on the threat model here are some possible solutions:

1) Require some transport like syslog over TLS|DTLS be implemented.

2)  Require that all senders implement signatures stored in structured
    data as an option.

I don't think you need to commit to one of these options now.
However, you do need to reflect the security issues in the charter.

--Sam
(Continue reading)

Eric Hibbard | 6 Jan 19:17 2006

Syslog Threat Modeling

If a threat model for Syslog is required, I would be very interested in helping out. Let me know.
 
-Eric
 
Eric A. Hibbard, CISSP, ISSAP, ISSMP, ISSEP
Senior Director, Data Networking Technology
Chair, SNIA Security Technical Work Group
 
Office of the CTO
HITACHI DATA SYSTEMS
750 Central Expressway, MS 3407
Santa Clara, CA 95050-2627
P 408.970.7979/ F 408.562.5477
eric.hibbard <at> hds.com
 
_______________________________________________
Syslog mailing list
Syslog <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
Chris Lonvick | 6 Jan 19:25 2006
Picon

Re: Charter comments from IESG Review

Hi Sam,

On Thu, 5 Jan 2006, Sam Hartman wrote:

>
>
> Hi.  The IESg reviewed the proposed syslog charter at today's telechat
> and decided that it requires revision.  The main concern seems to be
> the lack of a mandatory to implement security mechanism.  I indicated
> this might be the case in the Vancouver meeting.
>
> so, you definitely need to have some sort of mandatory to implement
> security mechanism.  I'm not quite sure what needs to be said about
> this in the charter.
> But the working group will need to:
>
> 1) Identify a threat  model for syslog

Is Section 8 in draft-ietf-syslog-protocol-16.txt sufficient? 
Alternatively, Section 6 in RFC 3164 is fairly comprehensive.

>
>
> 2) Define mechanisms to address these threats.
>
> So, questions for the threat model include things like whether
> confidentiality is important or whether integrity of mesages is
> sufficient.
>
> Depending on the threat model here are some possible solutions:
>
> 1) Require some transport like syslog over TLS|DTLS be implemented.

RFC 3195 requires the use of RFC 3080 which requires TLS.

>
> 2)  Require that all senders implement signatures stored in structured
>    data as an option.

That's likely addressed through syslog-sign.

>
> I don't think you need to commit to one of these options now.
> However, you do need to reflect the security issues in the charter.

The questions for you:

- Do we need to produce a threat model in a new document?

- Can we state that the threats will be addresses in syslog-sign and 
3195bis?  I will also note that there is a group of implementors who have 
already done syslog/tls.  I suspect they would like to codify this in a 
standard and that may also address the threats.

Thanks,
Chris

_______________________________________________
Syslog mailing list
Syslog <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

Chris Lonvick | 6 Jan 19:47 2006
Picon

I-D ACTION:draft-ietf-syslog-protocol-16.txt (fwd)

Hi Folks,

This is it.  We need people to review this and get back to the WG. 
When you reivew it, either send in notes about issues, or respond by 
saying that you have reviewed it.  (We DO need "me too's".)

Thanks,
Chris

---------- Forwarded message ----------
Date: Tue, 03 Jan 2006 15:50:02 -0500
From: Internet-Drafts <at> ietf.org
To: i-d-announce <at> ietf.org
Cc: syslog <at> ietf.org
Subject: I-D ACTION:draft-ietf-syslog-protocol-16.txt

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		: The syslog Protocol
  	Author(s)	: R. Gerhards
  	Filename	: draft-ietf-syslog-protocol-16.txt
  	Pages		: 45
  	Date		: 2006-1-3

This document describes the syslog protocol, which is used to convey
     event notification messages.  This protocol utilizes a layered
     architecture, which allows the use of any number of transport
     protocols for transmission of syslog messages.  It also provides a
     message format that allows vendor-specific extensions to be provided
     in a structured way.

     This document has been written with the spirit of traditional syslog
     in mind.  The reason for a new layered specification has arisen
     because standardization efforts for reliable, and secure syslog
     extensions suffer from the lack of a standards-track and transport
     independent RFC.  Without this document, each other standard needs to
     define its own syslog packet format and transport mechanism, which
     over time will introduce subtle compatibility issues.  This document
     tries to provide a foundation that syslog extensions can build on.
     The layered architecture also provides a solid basis that allows code
     to be written once instead of multiple times, once for each syslog
     feature.

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

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> 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-protocol-16.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 <at> ietf.org.
In the body type:
  	"FILE /internet-drafts/draft-ietf-syslog-protocol-16.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 <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

Sam Hartman | 6 Jan 20:36 2006
Picon

Re: Charter comments from IESG Review

>>>>> "Chris" == Chris Lonvick <clonvick <at> cisco.com> writes:

    Chris> Is Section 8 in draft-ietf-syslog-protocol-16.txt
    Chris> sufficient?  Alternatively, Section 6 in RFC 3164 is fairly
    Chris> comprehensive.

Both of these look good.  My main question with them is whether you
believe it is a requirement to address all these threats or whether
addressing a subset is sufficient.

    >> 
    >> 
    >> 2) Define mechanisms to address these threats.
    >> 
    >> So, questions for the threat model include things like whether
    >> confidentiality is important or whether integrity of mesages is
    >> sufficient.
    >> 
    >> Depending on the threat model here are some possible solutions:
    >> 
    >> 1) Require some transport like syslog over TLS|DTLS be
    >> implemented.

    Chris> RFC 3195 requires the use of RFC 3080 which requires TLS.

Noted.

    >>  2) Require that all senders implement signatures stored in
    >> structured data as an option.

    Chris> That's likely addressed through syslog-sign.

Agreed.

    >>  I don't think you need to commit to one of these options now.
    >> However, you do need to reflect the security issues in the
    >> charter.

    Chris> The questions for you:

    Chris> - Do we need to produce a threat model in a new document?

No, although you probably need to decide which threats you are
addressing.

    Chris> - Can we state that the threats will be addresses in
    Chris> syslog-sign and 3195bis?  I will also note that there is a
    Chris> group of implementors who have already done syslog/tls.  I
    Chris> suspect they would like to codify this in a standard and
    Chris> that may also address the threats.

You need to require everyone who implements syslog-protocol to
implement your mandatory to implement security mechanism.  That could
be syslog-sign or 3195bis, but you'd have to actually make that
normative requirement in protocol.

I think the real question here is what mechanism can you choose that
people will actually implement.

--Sam

_______________________________________________
Syslog mailing list
Syslog <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

Anton Okmianski (aokmians | 6 Jan 21:47 2006
Picon

Sec 6.1: Truncation

Rainer and all:

I started reading draft #16. Since we are revisiting everything... I am not very comfortable with the
current truncation rules. 

"Receivers SHOULD follow this order of preference when it comes to truncation:

 1) No truncation
 2) Truncation by dropping SD-ELEMENTs
 3) If 2) not sufficient, truncate MSG"

I don't think that this is a good recommendation.  I would assume that in many cases people would try to
tokenize more important data into structured data and use message text as a secondary user-friendly
description. For example, for LINK_DOWN message, I would probably encode link ID in the structured
elements as this is something that should be readily available for receivers. The MSGID could be
"LINK_DOWN" and the MSG text may simply be "Link down".  If you truncate the structured data, it makes it
harder. 

I also think, in general it is useful to put more important data first, which is another reason for putting
more valuable data into structured data in a more compact way.  

Additionally, structured data can be used to provide message length or digest, which can help receiver to
determine if message was truncated. 

Also, I think this statement is very convoluted:

"Please note that it is possible that the MSG field is truncated without dropping any SD-PARAMS.  This is the
case if a message with an empty STRUCTURED-DATA field must be truncated."

I think I understand what you are driving at, but I don't see it as adding any requirements or clarification. 

This sentence is not clear although I know what you are trying to say:

"The limits below are minimum maximum lengths, not maximum length."

I propose replacing the entire section 6.1 with this text:

"Syslog message limits are dictated by the syslog transport mapping in use. Each transport mapping MUST
define the minimum required message length support. Any syslog transport mapping MUST support messages
of up to and including 480 octets in length. 

Any syslog receiver MUST be able to accept messages of up to and including 480 octets in length.  All receiver
implementations SHOULD be able to accept messages of up to and including 2048 octets in length. Receivers
MAY receive messages larger than 2048 octets in length. If a receiver receives a message with a length
larger than it supports, the receiver MAY discard the message or truncate the payload.  

If truncation is performed by the receiver, it MUST first truncate the MSG field as necessary to meet the
supported length limit. If truncation of the entire MSG field is not sufficient, then additionally, the
STRUCTURED-DATA field MUST be truncated by removing one or more SD-ELEMENT fields. A minimum number of
SD-ELEMENT fields MUST be truncated starting from the end as necessary to meet the supported length
limit. SD-ELEMENT field can't be truncated partially. If all SD-ELEMENT fields are removed, NILVALUE
MUST be specified for STRUCTURED-DATA field. Truncation of HEADER field MUST NOT be performed."   

BTW, in your text or mine, what happens if message is malformed?  A proxy won't be able to truncate it properly
then. We don't want to prevent it from truncating it in some way and sending the message further, I would
think.  At least you will see something at the final destination, which maybe more useful than nothing. If
we just made truncation a simple take the first X octets out of Y octets, it would not be an issue, but then
proxy would be allowed to turn a well-formed message into malformed message upon truncation.   

What do you think?

Thanks,
Anton. 

_______________________________________________
Syslog mailing list
Syslog <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog


Gmane