headers
Chris Lonvick | 1 Jun 2009 22:02
Picon
Favicon

syslog WG Rechartering Discussion

Hi Folks,

David and I are going to open the discussion about rechartering.  Below 
are some ideas that we've seen on the list that may fit into a charter for 
a new syslog Working Group.  These seem to fit better in the Operations 
and Management Area than in the Security Area so we are asking the ADs to 
move the WG to there when we do recharter.

We'd like to get the discussion started now on this mailing list and have 
a WG meeting in Stockholm to discuss rechartering issues.  We hope that by 
having a real meeting, we can draw in more OPS people who are willing to 
work on these items, and/or to craft additional goals for syslog.

Please send your comments in about this and help move syslog forward.

Fundamentals
- Documenting how a syslog relay is supposed to work.  RFC3164 says that a
   relay MAY change the header information in a syslog message.  This needs
   to be reexamined since syslog-sign mandates that no changes are allowed
   in the whole syslog message between the sender and the device that
   validates the detached signatures.
- A DHC option for a syslog receiver. Write an ID that standardizes how
   DHCP should specify a syslog server and associated transport (udp, tls,
   beep) in a URI format.
- The OpSec WG was planning to develop a draft about log event taxonomy
   (what to log).  This work should be compared to the syslog-alarm draft
   from Sharon and Rainer, which defines categories for the alarm that are
   fairly consistent with the ALARM-MIB and ITU alarm categories.  There is
   also CEE work that is also trying to define catagories of what to log.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Juergen Schoenwaelder | 1 Jun 2009 22:18
Picon
Favicon

Re: syslog WG Rechartering Discussion

On Mon, Jun 01, 2009 at 10:02:38PM +0200, Chris Lonvick wrote:

> Ancillary
> - There are other documents in the OPSAWG which might be better reviewed
>    in the new syslog WG, if they have not already completed reviews
>    elsewhere:
>     - Mapping Simple Network Management Protocol (SNMP) Notifications to
>       SYSLOG Messages
>     - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple
>       Network Management Protocol (SNMP) Notifications

The two SNMP mapping documents have (as far as I can tell) passed
OPSAWG last call and likely move to the IESG and into IETF wide last
call soon. So people should better take a look at these documents now
since these documents likely move faster than this rechartering
process. Here are the URLs:

http://tools.ietf.org/wg/opsawg/draft-ietf-opsawg-syslog-msg-mib/
http://tools.ietf.org/wg/opsawg/draft-ietf-opsawg-syslog-snmp/

/js

--

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Syslog mailing list
Syslog <at> ietf.org
https://www.ietf.org/mailman/listinfo/syslog
(Continue reading)

Permalink | Reply | 0 comments |
headers
fenghongyan | 4 Jun 2009 12:27

Re: syslog WG Rechartering Discussion

Hi Chris,

I will submit an update of my proposal later.

Before that, I would like anyone here to discuss what changes I need to make to merge Rainer and Tom's draft,
that I can write in my new revision.

I recalled that I wrote a mail before to review Rainer and Tom's draft,
I asked some questions and can be concluded as below:

1. If it is necessary for "a syslog server should be a DTLS client"?
2. If we need ask different "registered port number" for DTLS different transport mapping (udp/sctp...) ?
3. If we need consistent syslog/dtls commands with syslog/tls ?
4. Anything else I need to cover from that covered in Rainer and Tom's ?

I will update my proposal according to the consensus of discussions on these items.
and at the time, I welcome any comments on my proposal, thanks.

The original mail I list here for your information.

-----Original Message-----
Date: Sun, 12 Apr 2009 00:20:28 +0800
From: fenghongyan <hongyanfeng <at> huaweisymantec.com>
Subject: [Syslog] Review of
draft-petch-gerhards-syslog-transport-dtls-01.txt"
To: syslog <at> ietf.org
Message-ID: <fc1e8c655909.49e133cc <at> huaweisymantec.com>
Content-Type: text/plain; charset=us-ascii

Hi,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Balazs Scheidler | 8 Jun 2009 16:10
Picon

Re: syslog WG Rechartering Discussion

On Mon, 2009-06-01 at 13:02 -0700, Chris Lonvick wrote:
> Hi Folks,
> 
> David and I are going to open the discussion about rechartering.  Below 
> are some ideas that we've seen on the list that may fit into a charter for 
> a new syslog Working Group.  These seem to fit better in the Operations 
> and Management Area than in the Security Area so we are asking the ADs to 
> move the WG to there when we do recharter.
> 
> We'd like to get the discussion started now on this mailing list and have 
> a WG meeting in Stockholm to discuss rechartering issues.  We hope that by 
> having a real meeting, we can draw in more OPS people who are willing to 
> work on these items, and/or to craft additional goals for syslog.
> 
> Please send your comments in about this and help move syslog forward.
> 
> 
> 
> Fundamentals
> - Documenting how a syslog relay is supposed to work.  RFC3164 says that a
>    relay MAY change the header information in a syslog message.  This needs
>    to be reexamined since syslog-sign mandates that no changes are allowed
>    in the whole syslog message between the sender and the device that
>    validates the detached signatures.

there are other relay specific discrepancies, like how Structured Data
is supposed to work in relaying scenarios. For example sequenceId is
hop-by-hop or end-to-end. And what if the relay drops some messages
because of filtering?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 9 Jun 2009 09:45
Picon

Re: Syslog-sign -26

Alexander Clemm wrote:

> The most important issue concerned the issue of having multiple
> signers.  After some contemplating, I decided that this can be
> resolved quite simply by clarifying that the combination of APP-NAME
> and PROCID refers to a unique signer (no, I didn't introduce it as a
> new term, it's still originator), and needs to be consistent between
> Certificate Block and Signature Block messages.  If multiple
> originators are used, they each in effect have their own "scope" -
> they each have their own Payload Block and Signature Blocks etc.
>
> The algorithm in section 7 can stay the same, but I added some
> clarification also there about how to identify/distinguish between
> different originators, and the fact that consistency between
> Certificate Block and Signature Block messages with regards to the
> originator needs to be checked.

Hmmm... the major challenge in -25 was that although Payload/Signature
Block identify the originator (HOSTNAME,APP-NAME,PROCID), normal
syslog messages do not. So it seems you cannot separate the stored 
log files by originator, and process the parts one by one.

If I understand you right, you're saying Section 7 does *not*
in fact assume that you can separate the normal syslog messages
by originator?

BTW, version -26 is still silent about whether a single originator
can sign the same set of messages using different algorithms (VER),
and if it can, whether these are same Signature Groups (with same
message number space) or different. What's your proposal for
(Continue reading)

Permalink | Reply | 0 comments |
headers
tom.petch | 10 Jun 2009 19:54

Re: syslog WG Rechartering Discussion

--- Original Message -----
From: "fenghongyan" <hongyanfeng <at> huaweisymantec.com>
To: "Chris Lonvick" <clonvick <at> cisco.com>
Cc: <syslog <at> ietf.org>
Sent: Thursday, June 04, 2009 12:27 PM

> Hi Chris,
>
> I will submit an update of my proposal later.
>
> Before that, I would like anyone here to discuss what changes I need to make
to merge Rainer and Tom's draft,
> that I can write in my new revision.
>
> I recalled that I wrote a mail before to review Rainer and Tom's draft,
> I asked some questions and can be concluded as below:
>
> 1. If it is necessary for "a syslog server should be a DTLS client"?
> 2. If we need ask different "registered port number" for DTLS different
transport mapping (udp/sctp...) ?
> 3. If we need consistent syslog/dtls commands with syslog/tls ?
> 4. Anything else I need to cover from that covered in Rainer and Tom's ?
>
> I will update my proposal according to the consensus of discussions on these
items.
> and at the time, I welcome any comments on my proposal, thanks.

Linda

I think that the problem is that there is not a quorum with which to form
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Clemm (alex | 12 Jun 2009 08:28
Picon
Favicon

Re: Syslog-sign-26

Hello Pasi,

 

I guess any confusion stems from the use of the word “originator”.  Therefore, let me use the term “signer” for the purposes of this discussion.  A signer signs syslog-messages using a specific algorithm; it is an “originator” of syslog-sign messages.  A single host can host multiple signers, which then each use their own Signature Groups and algorithms.  The syslog-sign messages can be attributed to a specific signer using (HOSTNAME, APP-NAME, PROCID).  Section 7 does say that you can separate syslog-sign messages according to signer, using this triple.  (It is the syslog-sign messages you are concerned about; you separate the syslog-sign messages by signers.  You can separate the “normal” messages by virtue of who signed them.)  So, in summary, the ability to be able to use different algorithms to sign messages is supported, but the corresponding syslog-sign messages need to use different (HOSTNAME,APP-NAME,PROCID) to be able to distinguish which is used where. 

 

Now, the question is whether to equate “signer” with “originator”.  If you equate them, then each signer would be considered its own originator of its own syslog messages.  However, you can also simply regard it from the perspective that the same originator can in effect incorporate multiple signers, if wanting to use multiple algorithms concurrently.   It doesn’t really matter – just like with “normal” syslog messages without syslog sign you don’t really distinguish if there are multiple originators on the same host or only one – the syslog message does not contain an “originator-ID” but (HOSTNAME/APP-NAME/PROCID. ) In the end, the effect is the same: you support the ability to sign messages using different algorithms from the same host.   

 

Does this clarify?

--- Alex

 

 

Pasi Eronen wrote:

“Hmmm... the major challenge in -25 was that although Payload/Signature

Block identify the originator (HOSTNAME,APP-NAME,PROCID), normal

syslog messages do not. So it seems you cannot separate the stored

log files by originator, and process the parts one by one.

 

If I understand you right, you're saying Section 7 does *not*

in fact assume that you can separate the normal syslog messages

by originator?

 

BTW, version -26 is still silent about whether a single originator

can sign the same set of messages using different algorithms (VER),

and if it can, whether these are same Signature Groups (with same

message number space) or different. What's your proposal for

addressing this -- or do you think signing using multiple algorithm

doesn't have to be supported?”

 

_______________________________________________
Syslog mailing list
Syslog <at> ietf.org
https://www.ietf.org/mailman/listinfo/syslog
Permalink | Reply | 501 comments |
headers
Glenn M. Keeni | 13 Jun 2009 11:36
Favicon

Re: syslog WG Rechartering Discussion

Hi Chris.
   We also have the Syslog-MIB work
(draft-ietf-syslog-device-mib-17.txt) that is currently on hold.
A lot of work and discussion has gone into the document. Do we
want to move this onto the next charter or, do it in the current
WG ? I think that with another push we can take this through, now
that we understand Syslog better.

   Glenn

> Hi Folks,Chris Lonvick wrote:
> 
> David and I are going to open the discussion about rechartering.  Below 
> are some ideas that we've seen on the list that may fit into a charter 
> for a new syslog Working Group.  These seem to fit better in the 
> Operations and Management Area than in the Security Area so we are 
> asking the ADs to move the WG to there when we do recharter.
> 
> We'd like to get the discussion started now on this mailing list and 
> have a WG meeting in Stockholm to discuss rechartering issues.  We hope 
> that by having a real meeting, we can draw in more OPS people who are 
> willing to work on these items, and/or to craft additional goals for 
> syslog.
> 
> Please send your comments in about this and help move syslog forward.
> 
> 
> 
> Fundamentals
> - Documenting how a syslog relay is supposed to work.  RFC3164 says that a
>   relay MAY change the header information in a syslog message.  This needs
>   to be reexamined since syslog-sign mandates that no changes are allowed
>   in the whole syslog message between the sender and the device that
>   validates the detached signatures.
> - A DHC option for a syslog receiver. Write an ID that standardizes how
>   DHCP should specify a syslog server and associated transport (udp, tls,
>   beep) in a URI format.
> - The OpSec WG was planning to develop a draft about log event taxonomy
>   (what to log).  This work should be compared to the syslog-alarm draft
>   from Sharon and Rainer, which defines categories for the alarm that are
>   fairly consistent with the ALARM-MIB and ITU alarm categories.  There is
>   also CEE work that is also trying to define catagories of what to log.
> 
> 
> Architecture
> - An informational document that describes how each of the header fields
>   should be used.  The technical information is in RFC 5424 but could use
>   some further explanation.
> - Possibly combined with the previous topic, a "practical usage guide"
>   would be a good document for implementors and coders.
> - A relook at the PRI values.  There are currently 7 Severity levels and
>   21 Facilities.  The Facilities are ill-defined and out of date.  The
>   information there could be better described in SDEs.  We kept the
>   historical PRI values so that we would have a smooth(er) transition from
>   historical syslog to the IETF standard syslog.  That has worked as
>   current syslog receivers do receive syslog messages in the new format.
> 
> 
> Transport
> - Documenting a TCP transport for syslog.  There are many implementations
>   in the wild right now with two major variants.  The problem between them
>   is the delimiter; prevalently a CR (I believe) is used to separate
>   multiple messages within a single TCP packet.  The minor-use
>   implementation does not have a delimiter and just assumes one message
>   per packet.  This will be relatively easy to straighten out.
> - Finish syslog-transport-dtls.  There are two individual submissions
>   which may be combined and moved into the WG.
> - We should do something with syslog/BEEP. Should we declare the current
>   syslog/BEEP historic? and/or should we start an effort to publish an
>   update?
> 
> 
> Ancillary
> - There are other documents in the OPSAWG which might be better reviewed
>   in the new syslog WG, if they have not already completed reviews
>   elsewhere:
>    - Alarms in SYSLOG
>    - Mapping Simple Network Management Protocol (SNMP) Notifications to
>      SYSLOG Messages
>    - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple
>      Network Management Protocol (SNMP) Notifications
> - It would be good to encourage other groups to bring drafts of Structured
>   Data implementations to Syslog WG for review.  These would likely not be
>   Syslog WG documents but the documents would benefit from being reviewed
>   by the Syslog WG.
>     - draft-fan-syslog-sending-policy-01 (Syslog Discard Messages) create
>       SDEs to report that a series of messages have been dropped by a
>       sender.  This document defines special syslog messages called
>       Discard messages for carrying logs loss statistics which indicate
>       how many logs (in terms of facility level or/and severity level)
>       were discarded by the syslog sender before they had a chance to hit
>       the wire connected to the syslog receiver during a particular period
>       in an extreme case.  The statistics information Disard messages
>       convey is of interest to syslog receivers and helpful for later on
>       audit.
>     - draft-dulaunoy-syslog-geolocation-00 proposes adding geographic meta
>       information to syslog messages. This might be done using SDEs
> - In an earlier version of netconf, there was work to correlate between
>   the information models of alarms from different NM interfaces.  Part of
>   the purpose was to ease correlation of event reports for the same event
>   via different NM interfaces.
> - Benoit Claise proposed making ipfix a general purpose reporting
>   protocol.  Such a protocol might replace or supplement syslog.  There
>   may be benefit to utilizing ipfix for carrying syslog information, so
>   there might be benefit to defining a way to convert syslog content into
>   ipfix formats, or to modify ipfix PDUs to carry syslog formats (both the
>   human-readable message part and the SDEs).  This was a brand new
>   proposal at IETF 74, so has not had much discussion yet.  We can discuss
>   this to see if there would be interest in such a direction.
> 
> 
> Thanks,
> Chris & David
> _______________________________________________
> Syslog mailing list
> Syslog <at> ietf.org
> https://www.ietf.org/mailman/listinfo/syslog

_______________________________________________
Syslog mailing list
Syslog <at> ietf.org
https://www.ietf.org/mailman/listinfo/syslog
Permalink | Reply | 2 comments |
headers
WashamFan | 17 Jun 2009 05:59

Comments on syslog-sign-26

Hi,

I'd like issue some concerns here.

1. the text below is from sec 4.2.4

   Note that the Global Block Counter crosses Signature Groups; it
   allows one to roughly synchronize when two messages were sent, even
   though they went to different collectors and are part of different
   Signature Groups.

But I am still not quite clear about what the GBC field is for. IMO,
removing this field does not matter much. Or could you elaborate
on how it help sync?

2. sec 6.1.1:

Does certResendDelay or certResendCount refine the resending
behavior after the first normal message is sent or before that or
both? Are you saying resending Payload periodically in a long lived
reboot session?

3. sec 6.1.2:

Why not introduce a param called sigMaxCount to specify the 
max count of hashes in a Signature Block message?

4. signer vs. originator
an originator is specified as (hostname, app-name, procid) triple.
So does a signer? If yes. then an originator can not have multiple
signers in the same time, but multiple originators can share the
same signer. In the latter case, should every originator exchange
its Payload independently?

washam
_______________________________________________
Syslog mailing list
Syslog <at> ietf.org
https://www.ietf.org/mailman/listinfo/syslog
Permalink | Reply | 3 comments |
headers
Pasi.Eronen | 17 Jun 2009 19:43
Picon

Re: Syslog-sign-26

Hi Alex,

 

Thanks for the explanation - it did indeed clarify things, and seems to provide a simple way to fix the situation!

 

The word "originator" comes from RFC 5424, and the current version of syslog-sign seems to assume that originator both originates normal syslog messages *and* signs them (originates Signature/Certificate Block messages). But your explanation -- a single originator (of normal syslog messages) could even have multiple signers (with different APP-NAME,PROCID) that sign the *same* normal syslog messages (with different algorithms) -- would seem to clarify things.

 

However, this does require some changes to the draft, right? (introducing the term "signer", and replacing some instances of "originator" with "signer")

 

Best regards,

Pasi

 

 

From: ext Alexander Clemm (alex) [mailto:alex <at> cisco.com]
Sent: 12 June, 2009 09:28
To: Eronen Pasi (Nokia-NRC/Helsinki)
Cc: syslog <at> ietf.org
Subject: Re: Syslog-sign-26

 

Hello Pasi,

 

I guess any confusion stems from the use of the word “originator”.  Therefore, let me use the term “signer” for the purposes of this discussion.  A signer signs syslog-messages using a specific algorithm; it is an “originator” of syslog-sign messages.  A single host can host multiple signers, which then each use their own Signature Groups and algorithms.  The syslog-sign messages can be attributed to a specific signer using (HOSTNAME, APP-NAME, PROCID).  Section 7 does say that you can separate syslog-sign messages according to signer, using this triple.  (It is the syslog-sign messages you are concerned about; you separate the syslog-sign messages by signers.  You can separate the “normal” messages by virtue of who signed them.)  So, in summary, the ability to be able to use different algorithms to sign messages is supported, but the corresponding syslog-sign messages need to use different (HOSTNAME,APP-NAME,PROCID) to be able to distinguish which is used where. 

 

Now, the question is whether to equate “signer” with “originator”.  If you equate them, then each signer would be considered its own originator of its own syslog messages.  However, you can also simply regard it from the perspective that the same originator can in effect incorporate multiple signers, if wanting to use multiple algorithms concurrently.   It doesn’t really matter – just like with “normal” syslog messages without syslog sign you don’t really distinguish if there are multiple originators on the same host or only one – the syslog message does not contain an “originator-ID” but (HOSTNAME/APP-NAME/PROCID. ) In the end, the effect is the same: you support the ability to sign messages using different algorithms from the same host.   

 

Does this clarify?

--- Alex

 

 

Pasi Eronen wrote:

“Hmmm... the major challenge in -25 was that although Payload/Signature

Block identify the originator (HOSTNAME,APP-NAME,PROCID), normal

syslog messages do not. So it seems you cannot separate the stored

log files by originator, and process the parts one by one.

 

If I understand you right, you're saying Section 7 does *not*

in fact assume that you can separate the normal syslog messages

by originator?

 

BTW, version -26 is still silent about whether a single originator

can sign the same set of messages using different algorithms (VER),

and if it can, whether these are same Signature Groups (with same

message number space) or different. What's your proposal for

addressing this -- or do you think signing using multiple algorithm

doesn't have to be supported?”

 

_______________________________________________
Syslog mailing list
Syslog <at> ietf.org
https://www.ietf.org/mailman/listinfo/syslog
Permalink | Reply | 502 comments |

Gmane