Re: [Syslog] syslog WG Rechartering Discussion

["tom.petch" <[e-mail]>]

--- Original Message -----
From: "fenghongyan" <[e-mail]>
To: "Chris Lonvick" <[e-mail]>
Cc: <[e-mail]>
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
a rough consensus at this time ( much as I wish that there were).

I would like a Working Group to agree to take on this work, and then to raise
these questions.  You and me and Rainer and David and Chris ... is not enough,
IMO, for the IETF to make decisions on eg, the idea of having TLS
client/server role negotiable by a protocol.  This is an old idea, which I
happen to think a good one for syslog, but it needs input from others to say
yes, go with
it, or no, not good because ....

So the current step for me is to draft a proposed revision to the charter,
within which syslog over DTLS is a bullet item (as Chris and David have done),
and see if that revised charter finds favour and then proceed from there.

Tom Petch
>
> 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