Subject: Meeting at IETF-56
From: Chris Lonvick <[email-masked]>
Date: Mon, 3 Mar 2003 07:22:14 -0800 (PST)

Hi Folks,

Just to confirm, we will be meeting in San Fracisco on Tuesday afternoon
from 1415-1515.  So far, the only agenda item is a review of the
syslog-mib work by Glenn.  Are there any other agenda items that anyone
would like to discuss during the meeting?

Thanks,
Chris

------------------------------

Date: Tue, 04 Mar 2003 13:48:59 +0900
From: Glenn Mansfield Keeni <[email-masked]>
Subject: Re: draft-ietf-syslog-device-mib-02.txt

Mark Ellison wrote:
> Hi,
>
> A small nit regarding syslogParamsSendToAllAddresses.
>
> Would it be possible to use the TruthValue TC defined in
> SNMPv2-TC (RFC 2579) as the defined syntax for
> syslogParamsSendToAllAddresses instead of reinventing a
> boolean syntax.

Thanks. This done in the revised ID

>
> Regards,
>
> Mark
>

Glenn

------------------------------

Date: Tue, 04 Mar 2003 14:11:51 +0900
From: Glenn Mansfield Keeni <[email-masked]>
Subject: Re: Where we're at

Mike,
     Thanks for the comments. Most of these have been incorporated
into the revised -03- draft. That should appear in the archives
shortly.
     My comments are inline.

      Glenn

Mike MacFaden wrote:
> On Fri, Feb 14, 2003 at 04:53:41AM -0800, Chris Lonvick wrote:
>
>>- Glenn Mansfield Keeni has the syslog-mib draft here:
>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-02.txt
>>and is looking for comments.
>
>
> fwiw...
>
> 1) One syntax error in this mib module:
> smilint 0.4.1 reports one syntax error:
>    syslogAllowedHostsTable : SEQUENCE OF type does not match row type
> Should read as follows
> syslogAllowedHostsTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF SyslogAllowedHostsEntry
Done. [This one fooled the mib-module validator at
http://www.simpleweb.org/Docs/ietf/mibs/validate/]
>
> 2) For the counter objects such as syslogProcMsgsReceived,
> I don't see what object one would poll to discover discontinuities.
> example: ifCounterDiscontinuityTime/rfc2863
> I'd like to throw out invalid samples
> if a proc dies and then restarts between polls
> for some syslogProcIndex. I suggest using something like
>
>   syslogProcStartedAt
>        SYNTAX      TimeStamp
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The time which this process was started."
>        ::= { syslogProcEntry 7 }
Done. Added syslogProcStartTime            TimeStamp.
>
> Some implementations will set syslogProcIndex to an
> underlying process id (pid), but pids might be reused.
>
> 3) I'd prefer having two objects instead of one for
> syslogProcMsgsIgnored. Tracking badly formed messages versus
> a configuration error should be easier for operators to debug.
Done. Added  syslogProcMsgsIllFormed        Counter32.

>
> 4) I recommend adding REFERENCE clauses to your objects.
> That way two implementations will have a higher probability of
> reporting consistent results that way. See section 3.13.3 of
> the document listed below.
Fully agree. I have planned to do that. But a major part of this
work remains pending in the revised draft.
>
> 5) syslogParamsProcDescr: is this a user definable string or
> something an implementation is supposed to define?
This is a user definable string.

>
> 6) syslogParamsConfFileName/syslogParamsPIDFileName:
> what should be stored if the
> config is loaded into memory (embedded system?). Hint: See
> RMON rfc2021/1757 OwnerString for example.
Have clarified in the description clause as follows:
     DESCRIPTION
       "The fullpath name of the configuration file where the
        syslog process's message selection and corresponding action
        rules will be read from.
        Data is loaded from this file into the syslogCtlSelectionTable
        and the syslogCtlLogActionTable.
        If the objects loaded from the file specified by this object
        have an access level of read-create this file MUST be
        be writable so that modifications to the corresponding objects,
        if any, will be effected in this file.
        If the system does not support the specification of a
        configuration file this field will not be accessible.
       "
>
> 7) I don't see a way to adminstratively disable/enable a given
> syslog processes. (like send a SIGTSTP signal) or to report
> present state of process (maybe that would be in hrSWRunTable/rfc2790?
> If so, maybe need to have a foreign key object to access that table.
> Also maybe a foreign key to access the udpTable or tcpConnTable

Have added 'suspended(2)' state to the syslogParamsProcessStatus. This
will allow the change of process atate to suspended.
>
> 8) Please change the name from DRAFT-IETF-SYSLOG-MIB to just SYSLOG-MIB

Done.
>
> 9) Not sure how this mib module can report a failure condition if it fails
> to save a config to a given file as defined in a typical syslog.conf
> See section 3.11 in the document listed below.
Have added
              syslogProcLastError            Integer32,
              syslogProcLastErrorTime        TimeStamp,

These should take care of the error reporting. The enumeration of the errors
remains to be done. Will be done in the next draft. Having done that I think
that something like a syslogProcLastErrorMsg would be helpful.
>
> 10) I would specify if objects are modifiable when rowStatus = active
> (see rfc1757 for example). See section 3.7 in the document listed below.
Done. The corresponding descriptions are revised.
I will need to qualify that all Objects except syslogParamsProcessStatus
can be modified only by deleting the row and recreating it.
syslogParamsProcessStatus can be changed even when syslogParamsRowStatus
is active.
>
> 11) On IP routers, one often wants to set the source ip address
> to use when sending via udp. Don't see how to set that here.

Done. Now we have  syslogCtlFwdActionSrcAddr in the syslogCtlFwdActionTable
that allows the specification of a source ip address.

>
> There might be other useful hints in Section 3 of:
> http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-12.txt

Thanks.

------------------------------

Date: Fri, 07 Mar 2003 15:37:51 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-syslog-device-mib-03.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		: Syslog MIB
	Author(s)	: G. Keeni, B. Pape
	Filename	: draft-ietf-syslog-device-mib-03.txt
	Pages		: 48
	Date		: 2003-3-7

This memo provides a MIB module that can be used to monitor and manage
syslog processes. In addition it defines objects that allow the
collection of statistics related to the generation of syslog messages.
And finally it provides a means for controlling the messages that
individual applications on a device will generate.

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

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-device-mib-03.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-syslog-device-mib-03.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.

------------------------------
Date: Tue, 18 Mar 2003 08:35:50 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: Scribe and Jabber people

Hi Folks,

We're meeting this afternoon and I've been remiss in asking for volunteers
to act as Scibe and to do the text conferencing.  Are there any
volunteers?

The agenda is simple: we're taking about the MIB.  :-)

Thanks,
Chris

------------------------------

Date: Tue, 18 Mar 2003 13:13:37 -0800
From: Marshall Rose <[email-masked]>
Subject: Re: Scribe and Jabber people

> We're meeting this afternoon and I've been remiss in asking for volunteers
> to act as Scibe and to do the text conferencing.  Are there any
> volunteers?

i'm planning on attending, so i'll volunteer for both.

/mtr

------------------------------

Date: Wed, 19 Mar 2003 00:13:18 +0100
From: "Wijnen, Bert (Bert)" <[email-masked]>
Subject: quick scan of draft-ietf-syslog-device-mib-03.txt

First, I am not on your mailing list, so pls copy me on the
follow up email if you want me to see it.

Since I was in the syslog WG session today I quickly scanned
the document. I would STRONGLY URGE you to look at
  draft-ietf-ops-mib-review-guidelines-01.txt
and make sure that you follow those guidelines, certainly before
you submit this to the MIB doctors for review. A lot of my comments
below could/SHOULD have been addressed by just following those
guidelines.

Here is a initial set of things I noticed:
- - do not do

- - Do not include REVISION clauses for I-D revisions.
  You can keep that text in an appendix or so (to be deleted
  when it becomes an RFC).
  A MIB that becomes RFC for the first time has just ONE
  REVISION clause
- - I see you use Integer32 for index objects. It is acceptable,
  but the recommendation is to use Unsigned32 and I do not see
  why that would not work for you
- - You have a RowStatus object that says:

- - you have syslogAllowedHostsMaskLen as a Integer32.
  Why is that not a InetAddressPrefixLength (from RFC3291) ?

- - syslogAllowedHostsTable does not have a StorageType object,
  nor does the table DESCRIPTION clause say anything on
  persistency behaviour

- - you have syslogParamsRowStatus and state in DESCRIPTION clause
       a. change the row status to ''invalid'', causing its deletion
       b. create a new conceptual row with the desired values.
  Well, 'invalid' is NOT one of the values that a RowStatus can
  be set to.

- - The StorageType object that you DO use, does not describe
  what columns MUST be writable for 'permanent' rows. See the
  StorageType TC in rfc 2579.

- - I see
  syslogParamsFacilityTranslation OBJECT-TYPE
      SYNTAX      INTEGER {
                  off       (1),
                  on        (2)
                  }
      MAX-ACCESS  read-write
  Why is that not a TruthValue?
  There are more of those objects that I think can be represented
  with a TruthValue Syntax

- - syslogParamsSecuritySpecs
  Why do the enums start at zero while we recommend to start at 1

There is probably much more. Please review the MIB guidelines and
try to do a good job at following them

Thanks,
Bert

------------------------------

Date: Thu, 20 Mar 2003 08:58:37 -0800 (PST)
From: Chris Lonvick <[email-masked]>
Subject: draft minutes (fwd)

Hi Folks,

These minutes are consistent with my recollection of the meeting.  Are
there any objections to accepting them as the official minutes?  I had
incorrectly noted the Syslog MIB ID in my slides and Marshall used that in
his notes below.  I've edited that (it was -03 rather than -02) in the
notes below but have left everything else as written by Marshall.

Our thanks to Marshall for taking such good notes.  I'll get the
presentations posted as soon as I can.

Thanks,
Chris

- ---------- Forwarded message ----------
Date: Tue, 18 Mar 2003 15:16:46 -0800
From: Marshall Rose <[email-masked]>
To: [email-masked]
Subject: draft minutes

please review and comment.

/mtr

[ syslog-minutes.txt - Tue Mar 18 11:24:33 2003 - 56th IETF - /mtr ]

WG: Security Issues in Network Event Logging (syslog)

Chairs: Chris Lonvick

Monday, March 18th, 2003 14:15-15:15 US/Pacific

Minutes by: Marshall T. Rose

Chris: Agenda

    Agenda Bashing - no changes

    Review of Charter and Status Update

    Review of Syslog MIB

    Wrap Up

Chris: Review of Charter

    - Recall that our focus is about reliable delivery and authentication

    - RFC 3164: How syslog works

    - RFC 3195: Reliable Delivery: 3 implementations out there

    - draft-ietf-syslog-sign-09: looking solid, still lacking "Security"
      and "IANA" considerations, one implementor has surfaced

    - draft-ietf-syslog-device-mib-03: to be discussed today

Glenn: draft-ietf-syslog-device-mib

    - Questions to ask:
        1. Are the right knobs there?
        2. Are the knobs adequately defined?

    - Purpose of the MIB
        - monitoring syslog operation (stats on messages in/out)
        - system-wide parameters: read-write
        - process run-time parameters: read-write
        - process rules for message selection and actions: read-write
        - read-write objects move us from monitoring to configuration

    - MIB Design mimics this architecture
        - system group: models generic information for the service
        - parameters group: models processes that implement the daemon
        - control group: models the syslog.conf file

    - Security Considerations
        - insecure access can allow mis-configuration, start/stop it, etc.
          (e.g., a bad idea given that syslog logs things like intruder
          detection...)
        - mis-configuring tables may result in loss/flood of messages,
          console spamming, attacking collectors, remove shell
          invocation, etc.
        - even R/O access is sensitive, e.g., reading counters.

    - TBD
        - DESCRIPTION/REFERENCE clauses
        - Is the MIB module set-consistent?
        - Editorial nits
        - Implemnet

    Mic: Security considerations can be addressed by access control in SNMPv3

    David: Even with v3, only certain personnel should have access

    Tim: Why is the MIB so close to the BSD syslog implementation?

    Chris: There's no requirement to do so, we just have a lot of info
           on the BSD side of things. We'd certainly like to get info
           from non-BSD folks

    Mike: There may be a lot of duplication with the Host Resources MIB?
          Also, what about SNMP notifications?

    Glenn: I've tried to avoid duplicating HR MIB functionality in the
           SYSLOG MIB module.  I need to document this more.

    Mic: There needs to be a "no DNS lookup"

    Marshall: Can we talk about the decision to do configuration stuff?

    Mic: Often times, simply having the MIB modelling is useful
         independent of actual SNMP implementation (e.g., encouraging
         syslog implementors to have the same feature set, independent
         of the management).

    Glenn: Even having just R/O access to the configuration information is
           good. The design still remains consistent, regardless.

    Mic: Many of the objects can probably be implemented without an
         intrusive approach. We should take note of this in the
         conformance statements.

    Bert: Many operators aren't comfortable doing configuration via
          SNMP, and there's interest in doing configuration other ways
          (cf., netconf). So, there's a risk that even if you define the
          objects, they won't get implemented for setting....

    Mic: Well, it may be used outside the operator community.

    David: I'm familiar with SNMP-manageable syslog stuff.

    Chris: How many people think we should be doing configurable stuff?
               many hands
           How many people think we should be doing monitoring stuff?
               one hand

    Glenn: is there an impact on the MIB module if we just make
           everything R/O?

    Bert: well, you can remove RowStatus objects, etc., so it would make
          things simpler. but, we'll still review the mib in case
          someone chooses to implement objects read-write.

    Steve: i look for what needs to be protected for both a read-only
           for privacy, and read-write for other threats.

    Mic: i haven't had any customers ask for syslog configuration, they
         want to use cli... so, i'd rather see a simpler mib, that's
         faster to implement.

    Mic: it's important that standard protocols have standard knobs

    Steve: netconf uses 3195 for notifications, and we're interested in
           finding out what interest there is in opening up 3195 for our
           needs.  is there interest in this wg?

                   some hands go up, none opposed

Chris: Wrapup

    Internationalization? Characters are currently us-ascii

    syslog-sign needs review
        - using rfc 3164 (timestamp, hostname, etc.)
        - need to update rfc3195 to reflect this

    Continue work on syslog-mib

    Folks may want to take a look at the [email-masked]
    list, many out of scope for us, but lots of syslog stuff...

Chris: Adjourn.

------------------------------
Date: Fri, 21 Mar 2003 07:04:02 +0900
From: Glenn Mansfield Keeni <[email-masked]>
Subject: Re: quick scan of draft-ietf-syslog-device-mib-03.txt

Bert,
    Thanks for the quick review. The next revision of the draft
will rectify the errors pointed out in your mail and will be
aligned with the guidelines in
           draft-ietf-ops-mib-review-guidelines-01.txt

     Glenn

Wijnen, Bert (Bert) wrote:
> First, I am not on your mailing list, so pls copy me on the
> follow up email if you want me to see it.
>
> Since I was in the syslog WG session today I quickly scanned
> the document. I would STRONGLY URGE you to look at
>   draft-ietf-ops-mib-review-guidelines-01.txt
> and make sure that you follow those guidelines, certainly before
> you submit this to the MIB doctors for review. A lot of my comments
> below could/SHOULD have been addressed by just following those
> guidelines.
>
> Here is a initial set of things I noticed:
> - do not do
>
> - Do not include REVISION clauses for I-D revisions.
>   You can keep that text in an appendix or so (to be deleted
>   when it becomes an RFC).
>   A MIB that becomes RFC for the first time has just ONE
>   REVISION clause
> - I see you use Integer32 for index objects. It is acceptable,
>   but the recommendation is to use Unsigned32 and I do not see
>   why that would not work for you
> - You have a RowStatus object that says:
>
> - you have syslogAllowedHostsMaskLen as a Integer32.
>   Why is that not a InetAddressPrefixLength (from RFC3291) ?
>
> - syslogAllowedHostsTable does not have a StorageType object,
>   nor does the table DESCRIPTION clause say anything on
>   persistency behaviour
>
> - you have syslogParamsRowStatus and state in DESCRIPTION clause
>        a. change the row status to ''invalid'', causing its deletion
>        b. create a new conceptual row with the desired values.
>   Well, 'invalid' is NOT one of the values that a RowStatus can
>   be set to.
>
> - The StorageType object that you DO use, does not describe
>   what columns MUST be writable for 'permanent' rows. See the
>   StorageType TC in rfc 2579.
>
> - I see
>   syslogParamsFacilityTranslation OBJECT-TYPE
>       SYNTAX      INTEGER {
>                   off       (1),
>                   on        (2)
>                   }
>       MAX-ACCESS  read-write
>   Why is that not a TruthValue?
>   There are more of those objects that I think can be represented
>   with a TruthValue Syntax
>
> - syslogParamsSecuritySpecs
>   Why do the enums start at zero while we recommend to start at 1
>
> There is probably much more. Please review the MIB guidelines and
> try to do a good job at following them
>
> Thanks,
> Bert
>

------------------------------