Uniform Logging Protocol BOF Minutes
40th IETF Meeting - Washington
Chair: Erik Guttman <erik.guttman@eng.sun.com>
Minutes taken by Jerome Abela <Jerome.Abela@hsc.fr>
Minutes edited by Erik Guttman <Erik.Guttman@eng.sun.com>
----------------------------------------------------------------------------
Mailing list:
to subscribe: send "subscribe" to gulp-request@hsc.fr
to post: send mail to gulp@hsc.fr
archives: http://www.hsc.fr/gulp/archives/
Web site for information on universal logging work (ULP):
http://www.hsc.fr/gulp
----------------------------------------------------------------------------
The published agenda for this BOF was:
Minutes
10 Presentation: Universal structured logging is a good thing
30 Discussion: A successful Universal Logging Protocol's requirements
might include the following. We won't decide on the problems, just
consider if they are hard or easy, within scope or outside of it.
- A lightweight client implementation must be easy to achieve.
- Is the model that each (client) host has one ULP server? In
other words, ULP configuration would not be available at the
'user' level, it would be a system service.
- Are there compatibility requirements with syslog, NT event
logger, others?
- Should ULP use TCP or UDP?
- It should be a String based protocol.
- Should we allow only logging or also retrieval and erasing
of entries from the client side (as per the NT logger).
- Security (bidirectional authentication? encryption? overcoming
risks of denial of service attacks?)
- Management: Should a ULP server be configurable via SNMP? An
ULP client? How does ULP tie in with RMON2?
- Configuration: Should there be any standard way to configure
a host's ULP server (DHCP, for instance? Or by using SLP?)
- Server to server extensions? (Should we offer control how logs
get forwarded and maintain a 'path' of where they have been?)
- API: should one be offered as Informational, Standards Track?
- Binary compatibiliby of API? protocol on-the-wire compatibility?
Are these good features? Should we pay the price for them?
10 Is ULP really a good thing? Is it a well specified project?
Who wants to work on it? Who would follow the work?
Who would use it?
10 Draft a charter, get volunteers
----------------------------------------------------------------------------
ULM (tag/value log format) was presented by Jerome Abela
Erik explained how the global logging problem could be broken into pieces,
mainly:
- ULM, the message format, for which we have to standardize a few tags. These
tags should be a basic minimal set of tags, which would have a standardized
semantic. More tags could be standardized in the future if there is demand.
A mechanism for standardizing tags would be established.
A similar work has already been done on specific topics, like audit trail,
but the basic set of message tags is not directly concerned with audit
trails, or other domains specific logging applications.
- Protocol: going from a log client to a log destination
- API. Although we don't advocate that this be an IETF standard, it is
really useful to provide an API to understand the semantics of the
protocol and to promote its usage. Furthermore, developing an API
makes it easier for the application developers to transition from
existing logging techniques to the new one. It would be possible to
address source compatibility with syslog and nt event logging here.
Q: what is in the scope and what is not. Are we really talking about
universal ?
A: We only provide a structure for logging
A: The kind of universal we are seeking is the minimal set of tags.
Q: why use tags ?
A: The idea is to build a minimum set of semantics, whether it's based on
tags or position dependant fields or any other scheme may still be
discussed.
Q: What are the problems with syslog ?
A: no semantics, no authentication, no integrity, no structure...
A: we need a way to standardize semantics.
Q: But do we really want authentication ? signatures ?
Q: Who is concerned ? which application? the system ? (some company) is
already using a multi-vendor standard.
A: ULP should not break anything. It should take this into account.
A: It can be an elective standard, coexisting with current logging but offering
more. Vendors could migrate toward using it without breaking existing
logging infrastructure. Interoperation with existing logging technology
would have to be a work item for the ULP WG.
Q: What is the minimum set of attributes/values ?
A: Currently, it's suggested it should be the HOST, DATE, APPLICATION and
PROCESS ID fields.
Q: What are the security requirements ?
A: Suggestion: Mutual authentication of client and server should be possible.
Message integrity is important. Confidentiality might be important.
Q: SASL solve none of the requirements. IPsec doesn't either.
Erik read a proposed charter to bash:
(...)
Q: It's not true that there is no standard. A logging system already
exist: syslogd.
A: But syslog IS the problem.
A: There is an existing successful format. It should not be broken by
ULP. (Consider sendmail, etc. which create structured syslog messages.)
Q: Shouldn't architecture and semantics should be differentiated?
A: An architecture should be provided so that message semantics are possible.
There are already successful schemes. The new mechanism should bridge the
different formats, map them into ULP.
ULP would encourage more logging.
There are people doing audit trails, but their are not to be standardized
here. We only provide a mechanism so their could be standardized.
Q: syslog IS a standard. It should be specified by this group.
Q: Is it in the scope of an IETF WG to standardize an API ?
A: Yes. But we are probably not interested in pursuing a standard API.
An informational API would be quite useful.
Q: If we start with authentication, we will need certificates, then
certificate distribution, ...
A: We won't invent a new security scheme. We only address the problem,
and find which protocol can achieve which level of security for ULP.
Q: How is it better than syslog ?
Security, when ? Someone asked when we would come up with security.
Maybe ipsec will be there before we do ? Is ipsec at the right level ?
Q: Are there enough people here who think we are solving things ?
Regarding the security part of the charter, "we will do this" should be "we
will take care of this, we will look at it." We won't invent new mechanisms
if at all possible.
It was strongly suggested by the Keith Moore that the Correct Way to Proceed
is:
1. Answer the question: "What do we need?"
2. Seek Solutions.
We should not try to build our solutions before having find our needs.
How many people are interested in working on it: 10
Take responsabilities: 4 (more approached the podium after the BOF)
Read and comment: 20
In answer to Keith, what the WG is willing to do is:
- a mechanism to allow blahblah semantics.
- security properties associated with it.
What about syslog which is not documented ?
Action Item: Add a gulp-request@hsc.fr alias so that mail administration
can be done in the standard way. Currently one subscribes by sending
"sub gulp" to sympa@hsc.fr [done]