Internet DRAFT - draft-fan-syslog-sending-policy

draft-fan-syslog-sending-policy






Network Working Group                                             W. Fan
Internet-Draft                                       Huaweisymantec Inc.
Intended status: Standards Track                       February 27, 2009
Expires: August 31, 2009


                     Syslog Sending Policy Messages
                   draft-fan-syslog-sending-policy-00

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 31, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Fan                      Expires August 31, 2009                [Page 1]

Internet-Draft       Syslog Sending Policy Messages        February 2009


   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document defines special syslog messages called Sending Policy
   messages for indicating how syslog senders process syslog messages
   before sending them.  The information Sending Policy messages convey
   is of interest to syslog receivers and helpful for audit.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in this Document  . . . . . . . . . . . . . .  3
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Sending Policy . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Policy Type  . . . . . . . . . . . . . . . . . . . . . . .  4
       4.1.1.  Priority Policy  . . . . . . . . . . . . . . . . . . .  4
       4.1.2.  Filtering Policy . . . . . . . . . . . . . . . . . . .  4
       4.1.3.  Persistency Policy . . . . . . . . . . . . . . . . . .  5
     4.2.  Criteria For Importance Evaluation . . . . . . . . . . . .  5
       4.2.1.  Based on Priority Value  . . . . . . . . . . . . . . .  5
       4.2.2.  Based on Timestamp Value . . . . . . . . . . . . . . .  5
   5.  Sending Policy Messages  . . . . . . . . . . . . . . . . . . .  6
     5.1.  Sending Policy Block Format and Fields . . . . . . . . . .  6
       5.1.1.  Version  . . . . . . . . . . . . . . . . . . . . . . .  7
       5.1.2.  Type . . . . . . . . . . . . . . . . . . . . . . . . .  7
       5.1.3.  TimeType and TimeValue . . . . . . . . . . . . . . . .  8
       5.1.4.  Criteria and Threshold . . . . . . . . . . . . . . . .  8
     5.2.  Usages . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
     6.1.  Message stream . . . . . . . . . . . . . . . . . . . . . . 10
     6.2.  Message loss . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11











Fan                      Expires August 31, 2009                [Page 2]

Internet-Draft       Syslog Sending Policy Messages        February 2009


1.  Introduction

   Generally, syslog senders would send all generated messages to
   targeted receivers.  But there would be a different story in some
   circumstances.  For some reason, syslog system may buffer messages
   before sending them further.  When some important messages have been
   hold in sending queue for a long time, the senders would like to send
   those urgent messages timely even out of order they are in sending
   queue or they were generated.  When transport senders are going to
   drain their sending queue, they would not be able to send all the
   messages timely.  In this case, senders would filter out less
   important messages to reduce queue overload or store new coming
   messages persistently in disk for sending them later.

   These scenarios may be not rare in real world.  When congestion
   control is applied to syslog transport, some mechanisms will be
   employed to adjust sending rate based on feedback approach.  When
   network congestion occurs, in order to reduce package loss in transit
   and improve network throughout, sending rate will slow down.
   Congestion control increase the latency of messages sending and the
   chance sending queue is full.  Message burst due to malicious
   behaviors is likely to exhaust sending queue, too.

   When senders process messages before sending them, something would
   have happend, e.g, network congestion occurs or intrusion led to log
   messages burst.  So the event that senders process messages before
   sending them might be an alert to operators.  Additionally, the
   information how senders process messages before sending them is of
   interest to receivers and helpful for audit, e.g, the information
   which messages are more important than others may be of value to
   receivers.  For an instance, when receivers can identify the more
   important messages from the sender's perspective, it could handle
   this event timely when many messages near-simultaneously arrive.  For
   another instance, taking into account that the sender has dropped
   which messages during which period of time may help us do a more
   accurate audit.  This document defines special messages called
   Sending Policy messages to notify this kind of event and deliver this
   information.

2.  Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].







Fan                      Expires August 31, 2009                [Page 3]

Internet-Draft       Syslog Sending Policy Messages        February 2009


3.  Definitions

   o  Message refer to syslog message whose on-the-wire format is
      defined in section 6, [RFC5424].

   o  Sender refer to transport sender which is defined in section 3,
      [RFC5424].

   o  Receiver refer to transport receiver which is defined in section
      3, [RFC5424].

   o  Sending queue is a conceptual buffer for buffering messages to be
      sent in sender's side.

   o  Receiving queue is a conceptual buffer for buffering messages to
      be received and processed in receiver's side.

4.  Sending Policy

   A Sending Policy contains an action senders take on messages before
   sending them and criteria which are used to evaluate the importance
   of messages.  Actions should be taken based on criteria.

4.1.  Policy Type

   According to what kind of actions senders would take, Sending
   Policies can be probably divided into three category:

4.1.1.  Priority Policy

   When latency occurs, senders would like to send the more important
   messages timely even out of order the messages were generated or are
   in sending queue.  How to evaluate the importance of messages depend
   on what criteria senders adopts.The criteria are of interest to the
   receiver, as the receiver can also pick up important messages to be
   processed timely when it starves, i.e, when so many near-
   simultaneously messages arrive.

   Priority Policy indicates messages would be sent based on level of
   importance even out of order they were generated or are in sending
   queue.  Priority Policy also contains the criteria adopted to
   evaluate the importance of messages.

4.1.2.  Filtering Policy

   When the number of messages to be sent increases, it is possible to
   drain the sending queue.  Senders may simply dropping messages to
   alleviate sending queue load.  Comparing to messages dropped by



Fan                      Expires August 31, 2009                [Page 4]

Internet-Draft       Syslog Sending Policy Messages        February 2009


   routers in transit, senders has more sense what messages they'd like
   to abondon whilst the others preserved.  We assume senders always
   drop less important messages.

   This policy may do not affect receiver's behavior very much.  But
   when audit later, it would do more accurate analysis by taking
   criteria which are used to evaluate importance of messages into
   account.

   Filtering Policy indicates some messages would be dropped based on
   their importance.  Filtering Policy also contains the criteria
   adopted to evaluate the importance of messages.

4.1.3.  Persistency Policy

   As an alternative to Filtering Policy, Senders may want to store the
   messages persistently for more reliability but less timeliness.  This
   policy may not affect receiver's bahavior very much.  The event that
   this policy has been applied may be of interest to receivers.  It
   would be considered as an alert indicating congestion occurs or
   messages burst.

4.2.  Criteria For Importance Evaluation

   Persistency Policy do not care about importance of messages, since no
   messages dropping and no messages sent out of order.  With regard to
   Priority Policy and Filtering Policy, they both need to identify the
   more important messages to be processed before sending them.  There
   are commonly 2 ways to evaluate importance of syslog messages:

4.2.1.  Based on Priority Value

   Priority Value consists of two parts: Facility and Severity.
   Facility value takes value from 0 to 23.  Severity value takes value
   from 0 to 6.  In both cases, the lower the value is, the more
   important the message is.

4.2.2.  Based on Timestamp Value

   Timestamp Value is not mandatory in syslog messages, but when it
   shows up, it indicates the time when message was generated.  When we
   filter out messages, we can simply dropping new coming messages or
   let new coming messages override the old ones(e.g, circular queue).
   The latter takes newer message more valuable, but the former takes
   newer message less important.  Priority Policy would not base on
   these criteria.





Fan                      Expires August 31, 2009                [Page 5]

Internet-Draft       Syslog Sending Policy Messages        February 2009


5.  Sending Policy Messages

   Sending Policy Messages are used to contain policies specified in
   section 4 and the event when specific policy was applied or revoked.
   These information are carried as Sending Policy Blocks in Sending
   Policy Messages actually.

   There is a need to distinguish the Sendig Policy Block itself from
   the syslog message that is used to carry a Sending Policy Block.
   Sending Policy Blocks MUST be encompassed within completely formed
   syslog messages.  Syslog messages that contain a Sending Policy Block
   are also referred to as Sending Policy messages.

   A Sending Policy message is identified by the presence of an SD
   ELEMENT with an SD-ID with the value "sending-policy".  In addition,
   a Sending Policy message MUST contain valid APP-NAME, PROCID, and
   MSGID fields to be compliant with [RFC5424].  This specification does
   not mandate particular values for these fields; however, for
   consistency, originators MUST use the same values for APP-NAME,
   PROCID, and MSGID fields for every Sending Policy message that is
   sent, whichever values are chosen.  To allow for the possibility of
   multiple originators per host, the combination of APP-NAME, PROCID,
   and MSGID MUST be unique for each such originator.  If an originator
   daemon is restarted, it MAY use a new PROCID for what is otherwise
   the same originator but MUST continue to use the same APP-NAME and
   MSGID.  The Sending Policy Block is carried as Structured Data within
   the Sending Policy Block message, per the definitions that follow in
   the subsection.  The MSG part of a Sending Policy message SHOULD be
   any readable text for explaining the Sending Policy Block.

5.1.  Sending Policy Block Format and Fields

   The Sending Policy Block MUST be encoded as an SD ELEMENT, as defined
   in [RFC5424].

   The SD-ID MUST have the value of "sending-policy".

   The SDE contains the fields of the Sending Policy Block encoded as SD
   Parameters, as specified in the following.  The Sending Policy Block
   is composed of the following fields.  The value of each field MUST be
   printable ASCII.










Fan                      Expires August 31, 2009                [Page 6]

Internet-Draft       Syslog Sending Policy Messages        February 2009


              +-----------+---------------+----------------+
              |   Field   | SD-PARAM-NAME | Size in octets |
              +-----------+---------------+----------------+
              |  Version  |      VER      |        2       |
              |    Type   |      TYPE     |        1       |
              |  TimeType |       TT      |        1       |
              | TimeValue |       TV      |      1-50      |
              |  Criteria |      CRI      |        1       |
              | Threshold |      THRE     |      1-10      |
              +-----------+---------------+----------------+

   The fields MUST be provided in the order listed if they were present.
   Each SD parameter MUST occur once in the Sending Policy Block.
   Version is mandatory.  A Sending Policy Block is likely to be
   accordingly encoded as follows, where xxx denotes a placeholder for
   the particular values:

   [sending-policy VER="xxx" TYPE="xxx" TT="xxx" TV="xxx" CRI="xxx"
   THRE="xxx"]

   Values of the fields constitute SD parameter values and are hence
   enclosed in quotes, per [RFC5424].  The fields are separated by
   single spaces and are described in the subsequent subsections.

5.1.1.  Version

   The Version field is a numeric value that has a length of 2 octets,
   which may include leading zeroes.  The two octets contain a decimal
   character in the range of "0" to "9".  The value in this field
   specifies the version of this Block with "01" as the value for the
   protocol version that is described in this document.

5.1.2.  Type

   This field indicates which type of policies specified in section 4
   the sender has adopted.  The TYPE parameter may take any value from
   0-2 inclusive.

   a.  "0" -- Priority Policy has been adopted by the sender.

   b.  "1" -- Filtering Policy has been adopted by the sender.

   c.  "2" -- Persistency Policy has been adopted by the sender.








Fan                      Expires August 31, 2009                [Page 7]

Internet-Draft       Syslog Sending Policy Messages        February 2009


5.1.3.  TimeType and TimeValue

   The two fields show us when the sender starts to apply the policy
   indicated in TYPE field or when the sender revokes it, that is
   dependent on TimeType Value.  TT parameter may take any value from
   0-1 inclusive

   a.  "0" -- Subsequent TimeValue field represent start time.

   b.  "1" -- Subsequent TimeValue field represent end time.

   When Priority Policy was applied, if TT Value equals "0", TV Value
   SHOULD be the TIMESTAMP Value of the first message out of order; if
   TT Value equals "1", TV Value SHOULD be the TIMESTAMP Value of the
   last message out of order.

   When Filtering Policy was applied, if TT Value equals "0", TV Value
   SHOULD be the TIMESTAMP Value of the first message dropped; if TT
   Value equals "1", TV Value SHOULD be the TIMESTAMP Value of the last
   message dropped.

   When Persistency Policy was applied, if TT Value equals "0" or "1",
   TV Value SHOULD be the system time when the Policy message was
   sent(I.e., TV Value equals to TIMESTAMP Value in message HEADER).

   sending-policy SDE can convey only criteria for importance
   evaluation, in this case, no indicator for policy has been applied or
   revoked, so this two field can be absent.

   TV parameter is a formalized timestamp derived from [RFC3339] and
   follow the restrictions specified in [RFC5424](section 6.2.3).

5.1.4.  Criteria and Threshold

   Criteria field indicates the criteria which are used to evaluate the
   importance of messages.  Criteria parameter may take any value from
   0-2 inclusive.

   a.  "0" -- Evaluate importance of a message based on Severity Value
       which is a part of PRI Value contained in HEADER part.

   b.  "1" -- Evaluate importance of a message based on Facility Value
       which is a part of PRI Value contained in HEADER part.

   c.  "2" -- Evaluate importance of a message based on Timestamp Value
       contained in HEADR part.

   When Criteria field takes value "2", Threshold Value indicates



Fan                      Expires August 31, 2009                [Page 8]

Internet-Draft       Syslog Sending Policy Messages        February 2009


   whether earlier or older messages are considered more important.  In
   this case, Threshold Value can be intepreted in this way:

   a.  "0" -- the earlier messages were generated, more important they
       were.

   b.  "1" -- the older messages were generated, more important they
       were.

   When Criteria field takes value "0" or "1", Threshold Value indicates
   the border of more important messages and less important messages.
   E.g, when Criteria parameter takes value "0", and, Threshold Value
   equals "3", that means any messages bearing severity Value greater
   than 3 may be dropped(when Filter Policy was adopted) or delayed
   their sending(when Priority Policy was adopted).

   When Persistency Policy was adopted, these two fields can be absent.

5.2.  Usages

   Sending Policy messages can only convey criteria for importance
   evaluation, in this case, Version, CRI and THRE MUST be present.
   E.g., senders would send this messages following the session is
   established.

   The following example shows the criteria are that messages bearing
   Severity Value which is less than or equals to 3 are more important.

   [sending-policy VER="01" CRI="0" THRE="3"]

   When Sending Policy messages are used as event notification, TT and
   TV MUST be present, CRI and THRE MUST be present unless criteria for
   importance evaluation have been delivered before. two Sending Policy
   messages are recommended to indicate event start and event end
   respectively.  In this case, Sending Policy messages SHOULD have
   enough high priority to be sent timely and avoid being filtered out.

   The following example shows Filtering Policy has been adopted by the
   sender and the first affected message(i.e. the first message dropped)
   was generated on Feb 24 2009 05:14:15am, 3 microseconds into the next
   second( and the local time is -7 hours from UTC).  The CRI and THRE
   are interpreted as last example

   [sending-policy VER="01" TYPE="1" TT="0" TV="2009-02-
   24T05:14:15.000003-07:00" CRI="0" THRE="3"]






Fan                      Expires August 31, 2009                [Page 9]

Internet-Draft       Syslog Sending Policy Messages        February 2009


6.  Security Considerations

   This specification shares the same security considerations addressed
   in section 8.5, [RFC5424].  Additionally, two issues should be taken
   care of.

6.1.  Message stream

   When Priority Policy was applied, syslog messages may be sent out of
   order they were generated.  The receivers should not reconstruct
   sequence of events based on the order they were received.  In this
   case, TIMESTAMP may be used to do this work.  Besides, when Priority
   Policy message is used as real-time event notification, syslog-sign
   may not work well in this case, since the urgent message sent out of
   order can not be verified until the corresponding Signature message
   has been interpreted.  By the same token, receivers would not process
   messages out of order they were received.

6.2.  Message loss

   When Filtering Policy was applied, syslog messages may be lost by
   senders.  In this case, Sending Policy messages could tell what kind
   of messages was dropped.  If syslog-sign is also applied, syslog-sign
   can tell how many and which messages was dropped.  It is recommended
   that Signature Block messages have enough high priority to avoid
   being filtered out by senders easily.

   If UDP-like congestion control is adopted for syslog transport,
   Sending Policy messages themselves would probably be lost in transit.
   Sending Policy messages should be sent several times in this case.

7.  IANA Considerations

   IANA is requested to register the SD-ID value "sending-policy"
   together with the PARAM-NAME values specified in Section 5.1 in the
   registry for SYSLOG structured data id values according to section 9
   in [RFC5424].

                +----------------+------------+-----------+
                |      SD-ID     | PARAM-NAME |           |
                +----------------+------------+-----------+
                | sending-policy |            |           |
                |                |     VER    | mandatory |
                |                |    TYPE    |  optional |
                |                |     TT     |  optional |
                |                |     TV     |  optional |
                |                |     CRI    |  optional |




Fan                      Expires August 31, 2009               [Page 10]

Internet-Draft       Syslog Sending Policy Messages        February 2009


                |                |    THRE    |  optional |
                +----------------+------------+-----------+

8.  Acknowledgements

9.  References

9.1.  Normative References

   [RFC5424] Gerhards, R., "The syslog Protocol", RFC 5424, December
   2008.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
   Timestamps", RFC 3339, July 2002.

Author's Address

   Washam Fan
   Huaweisymantec Inc.
   Building 17
   Zhongguancun Software Park
   No.8 Dongbeiwang West Road
   Beijing  100085
   PRC

   Phone: +86 010 58791314
   EMail: washam.fan@huaweisymantec.com



















Fan                      Expires August 31, 2009               [Page 11]