INTERNET DRAFT                                                  J. Abela
Expires: May 4, 1997                                                 HSC
<draft-abela-ulm-00.txt>                                 4 November 1996


                  Universal Format for Logger Messages

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet- Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   This document presents a format to describe system events for logging
   purpose.  Some of the features presented here are in use with the
   common syslog facility, but most of them are lost in the crowd of
   syslog format freedom.

Introduction

   At the beginning, logs were scanned by the administrator after an
   incident to detect the failure cause. With the increasing concern on
   computer security, and wide area network manangement, the need for
   automated log examination, extraction and reporting has grown.  The
   Universal Logger Message (ULM) format presented here is a set of
   guidelines to formalize the semantics of such messages.

Syntax

   The ABNF for ULM is:

   log_file    ::= *(log_line LF)

   log_line    ::= field *(SP field)



Abela                                                           [Page 1]


RFC 1                  Universal Logger Messages         4 November 1996


   field       ::= field_name "=" field_value

   field_name  ::= ALPHA *(ALPHA_EXT)

   field_value ::= 1*(ALPHA_EXT) / string

   string      ::= QUOTE *(ANY_BUT_Q / esc_quote) QUOTE

   esc_quote   ::= "\" QUOTE

   ANY_BUT_Q   ::= <any CHAR excluding QUOTE and all control characters
                   (US ASCII 0-31 inclusive)>

   ALPHA_EXT   ::= ALPHA / DIGIT / "." / "_" / "-"

   QUOTE       ::= <the double quote character (ASCII decimal code 34)>

   ALPHA       ::= <any one of the 52 alphabetic characters
                   (A through Z in upper case
                   and a through z in lower case)>

   DIGIT       ::= <any one of the 10 numeric characters (0 through 9)>

   LF          ::= <the line-feed character (ASCII decimal code 10)>

   SP          ::= <the space character (ASCII decimal code 32)>


Fields

   The following rules should apply regarding fields:

   (1) Each field name should be unique in a given log event.  If two or
       more fields have the same name in a unique ULM, the expected
       result is undefined.

   (2) The case should not be significant for field names. Thus, DATE
       and dAtE fields both describe the same information in a given
       ULM.

   (3) Each field type sould be registered and have an associated field
       value format.

Mandatory Fields

   The following fields should be present in any ULM: LEVEL, HOST, PROG,
   DATE.




Abela                                                           [Page 2]


RFC 1                  Universal Logger Messages         4 November 1996


   LEVEL

       value.level ::= "Emergency" / "Alert" / "Error"
                      / "Warning" / "Auth" / "Security"
                      / "Usage" / "Important" / "Info"

       The level field specifies the importance and category of the ULM.
       The signification for the different values are:

       Emergency

           A panic condition. It should be broadcast to all users.

       Alert

           A condition that should be corrected immediately.

       Error

           A system error. This level and the previous ones are reserved
           for system conditions.

       Warning

           Program error. The program has detected an incorrect
           behaviour of his own. To clarify the differences between
           these last levels: Absence of a system configuration file is
           an Error, failed assert is a Warning, and erroneous data
           given by a user is never anything more than an Info: typing
           typos is just a normal behaviour.

       Auth

           An authentification failed.  Potential senders for such an
           ULM could be su and login.

       Security

           A standard protection was raised against what could be an
           intrusion.  A connection denial based on the remote network
           address falls into this category.

       Usage

           Normal, standard, authorized day-to-day usage information.

       Important




Abela                                                           [Page 3]


RFC 1                  Universal Logger Messages         4 November 1996


           Important information which could be critical, but is not
           yet.  A configuration change is an important information.

       Info

           The Info level is for somewhat superfluous informations.
           These informations are not hot, they are not to be accounted,
           they are not to be billed. If a daemon says it has reloaded
           it's configuration file after receiving a signal, the log
           level for that event is Info.

   HOST

       value.host  ::= string

       The HOST field contains the name of the host which issues the
       ULM.

   PROG

       value.prog  ::= string

       The PROG field contains the name of the software component which
       issues the ULM. If a software component is a member of a software
       suite, it should be expressed in a hierachical, as in:
       "suite.component.subcomponent".

   DATE

       value.date  ::= <YYYY> <MM> <DD> <hh> <mm> <ss>

       The DATE field contains the instantaneous date of the event. If
       the event last a sufficient amount of time, different ULM sould
       be issued, each marked with its own date.

Optional Fields

   The following fields could be added in any ULM. Any application
   reading log files should be aware of these: DURATION, PROCESS, ID,
   SOURCE.IP, SOURCE.FQDN, SOURCE.NAME, SOURCE.PORT, SOURCE.USER,
   DEST.IP, DEST.FQDN, DEST.NAME, DEST.PORT, DEST.USER, SENT.VOLUME,
   SENT.COUNT, RECEIVED.VOLUME, RECEIVED.COUNT, TTY, DOCUMENT, MESSAGE.

   DURATION

       value.duration ::= [[[<DDDD>] <hh>] <mm>] <ss>

       The DURATION indicates the duration of the event whose end is



Abela                                                           [Page 4]


RFC 1                  Universal Logger Messages         4 November 1996


       given by the DATE field. This field is mandatory if the ULM
       announces the end of an event for which another ULM was issued at
       the beginning.

   PROCESS

       value.process     ::= integer

       In a multi-tasking environment, this field specifies the process
       id which issued de ULM. On some systems, this id may not be
       unique, but it should however be unique on the specified HOST,
       over the specified DURATION, if appropriate.  Thus, the ULM
       announcing the end of a session should specifiy the duration of
       the session, and guarantee that all the ULM issued between the
       beginning of the session and this ULM with the same HOST value
       and the same PROCESS values concern to this session.

   ID

       value.id          ::= string

       The ID field is a system reference to the concerned document. It
       could be a mail or Usenet news message-id, or an incremented
       counter. It should not be mistaken with the DOCUMENT field, which
       a user-level name.

   SOURCE.IP

       value.source.ip   ::= ipv4 / ipv6 ipv4              ::= byte-
       integer "." byte-integer
                            "." byte-integer "." byte-integer

       The SOURCE.IP field contains the IP number of the source host.
       Other SOURCE.* fields could describe network source address in
       other realms (IPX, X25, ...).

       The SOURCE.* fields all contain informations about the host
       connected, connecting, or trying to connect.

   SOURCE.FQDN

       value.source.fqdn ::= string

       Fully Qualified Domain Name for the source host.

   SOURCE.NAME

       value.source.name ::= string



Abela                                                           [Page 5]


RFC 1                  Universal Logger Messages         4 November 1996


       Generic name qualifying the source host, if fqdn is not
       available.  For example, "local" qualifies a host, but is not an
       FQDN.

   SOURCE.PORT

       value.source.port ::= integer

       Port number for TCP, UDP or another protocol.


   SOURCE.USER

       value.source.user ::= string

       User name or user id.

   DEST.IP DEST.FQDN DEST.NAME DEST.PORT DEST.USER

       All the DEST.* fields have the same signification as the SOURCE.*
       fields, except that they qualify the destination.

   SENT.VOLUME SENT.COUNT RECEIVED.VOLUME RECEIVED.COUNT

       Nnumber of bytes and count (of articles, or files) sent, and
       received, from the source point of view.

   TTY

       value.tty         ::= string

       The tty field describes the physical connection of a user to the
       host.

   DOCUMENT

       value.document    ::= string

       The document field is the name of an accessed document, like the
       path of an ftp file, the name of a newsgroup, or the non-host
       part of an URL.

   MESSAGE

       value.message     ::= string

       The MESSAGE field is the only field which should contain
       arbitrary data.  Any important information which doesn't fit any



Abela                                                           [Page 6]


RFC 1                  Universal Logger Messages         4 November 1996


       of the other standard fields could be stored here. Use of the
       message field for an information which does fit another standard
       field is forbidden.


Other more fields

   Any other field of interest could be added, but it sould be
   registered first to the Internet Assigned Number Authority (IANA).

Security Considerations

   ULM includes no security functions. However, sites should worry about
   the vulnerabilites of their logging architecture, especially when
   networks are used to transport ULM, as these messages may be critical
   for the security.

Author's Address

   Jerome Abela
   Herve Schauer Consultant
   142, rue de Rivoli
   75039 Paris cedex 01
   France

   Phone: (+33) 146 38 89 90

   EMail: Jerome.Abela@hsc.fr























Abela                                                           [Page 7]