Minutes of the Uniform Logging Protocol (ulp)BOF
Chair: Erik Guttman <erik.guttman@eng.sun.com>
Reported by Jerome Abela <Jerome.Abela@hsc.fr>
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:
10 Minutes:
Presentation: Universal structured logging is a good thing
30 Minutes:
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 Minutes
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 Minutes
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:
I. Answer the question: "What do we need?"
II. 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 responsibilities: 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]
None Received