Re: [Syslog] syslog WG Rechartering Discussion

[fenghongyan <[e-mail]>]

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 <[e-mail]>
Subject: [Syslog] Review of
draft-petch-gerhards-syslog-transport-dtls-01.txt"
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii

Hi,

I read this proposal "draft-petch-gerhards-syslog-transport-dtls-01", 
I have some comments on it:

Those changes I made in my new version this draft is also need to make, I think. 


section 1.3
   The security discussion is similar as stated in syslog/tls,  Pasi
   recommended simply pointer to syslog/tls would be better.   

section 1.4
   This is covered in syslog/tls; a pointer to that document would work.

section 2.1
  I don't see if there's a necessary for a syslog server should be a DTLS client. 
  In my understanding, a dtls request is alway initiate by a dtls client, if syslog server being dtls client,
  how does a server know which client want to connect to it?
  I think RFC5425 has state authentication in very detail and come up the corresponding security policy.
  Also, fingerprint is aim to cover the case you discussed in your draft having a certificate url authentication. 
  A pointer to that document would work.

section 2.2
  I think a  udp "registered port number" is required to assign for udp mapping and 
 a sctp "registered port number" is required to assign for sctp mapping respectively.

section 2.3
 I claimed in my proposal to minimize the operation and security where 
 both syslog/tls and syslog/dtls are supported, why do you need write 
 the commands in your proposal?

section 2.6, section 2.8
  It is covered in syslog/tls security policy; a pointer to that document would work.







Thanks
Linda


>  
>  Message: 1
>  Date: Mon, 1 Jun 2009 13:02:38 -0700 (PDT)
>  From: Chris Lonvick <[e-mail]>
>  Subject: [Syslog] syslog WG Rechartering Discussion
>  To: [e-mail]
>  Message-ID: <[e-mail]>
>  Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>  
>  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.
>  
>  
>  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
>