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 PROTECTED]>
To: [EMAIL PROTECTED]
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 PROTECTED]
list, many out of scope for us, but lots of syslog stuff...
Chris: Adjourn.
