--- 1/draft-ietf-opsawg-syslog-snmp-02.txt 2009-05-15 10:12:11.000000000 +0200 +++ 2/draft-ietf-opsawg-syslog-snmp-03.txt 2009-05-15 10:12:11.000000000 +0200 @@ -1,19 +1,19 @@ Network Working Group V. Marinov Internet-Draft J. Schoenwaelder Intended status: Standards Track Jacobs University Bremen -Expires: September 27, 2009 March 26, 2009 +Expires: November 16, 2009 May 15, 2009 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages - draft-ietf-opsawg-syslog-snmp-02.txt + draft-ietf-opsawg-syslog-snmp-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. @@ -22,56 +22,56 @@ 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 September 27, 2009. + This Internet-Draft will expire on November 16, 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 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 memo defines a mapping from Simple Network Management Protocol - (SNMP) notifications to SYSLOG notifications. + (SNMP) notifications to SYSLOG messages. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3 2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5 - 3. Mapping SNMP Notifications to SYSLOG Notifications . . . . . . 6 + 3. Mapping SNMP Notifications to SYSLOG Messages . . . . . . . . 6 3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7 3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Relationship to the SYSLOG-MSG-MIB . . . . . . . . . . . . . . 10 - 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction SNMP and SYSLOG are two widely used protocols to communicate event notifications. Although co-existence of several management protocols in one operational environment is possible, certain environments require that all event notifications are collected by a single system daemon such as a SYSLOG collector or an SNMP notification receiver @@ -86,24 +86,24 @@ event notifications [RFC3416] into SYSLOG messages [RFC5424]. We specify how the SYSLOG message format should be utilized to carry the information contained in an SNMP notification message. A new SYSLOG structured data element is defined which carries the PDU portion of an SNMP notification message. 1.1. Conventions A system which has the capability of receiving SNMP notification messages from an SNMP Notification Originator and sending the SNMP - data contained inside in a SYSLOG message format to a SYSLOG receiver - is referred in this memo as an "snmp-to-syslog translator". By - definition, such a system should have an SNMP Notification Receiver - application and a SYSLOG sender application running in order to be + data contained inside in a SYSLOG message format to a SYSLOG + collector is referred in this memo as an "snmp-to-syslog translator". + By definition, such a system should have an SNMP Notification + Receiver application and a SYSLOG originator running in order to be able to perform the functions of an "snmp-to-syslog translator". 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 [RFC2119]. 2. Background 2.1. SNMP Notifications @@ -177,21 +177,21 @@ messages. This document assumes that notifications are in the format defined in RFC 3416 [RFC3416]. Notifications in the SNMPv1 notification format must be translated as described in Section 3.1 of RFC 3584 [RFC3584]. 2.2. SYSLOG Notifications The SYSLOG protocol is defined in [RFC5424]. The message contains a global header and a number of structured data elements. The ABNF - [RFC4234] representation of a SYSLOG message is defined in RFC XXXX + [RFC4234] representation of a SYSLOG message is defined in RFC 5424 [RFC5424]. The relevant productions for structured data elements are: STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]" SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34 SD-ID = SD-NAME PARAM-NAME = SD-NAME PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and ; ']' MUST be escaped. @@ -199,57 +199,58 @@ ; except '=', SP, ']', %d34 (") UTF-8-STRING = *OCTET ; Any VALID UTF-8 String ; "shortest form" MUST be used OCTET = %d00-255 SP = %d32 PRINTUSASCII = %d33-126 NILVALUE = "-" -3. Mapping SNMP Notifications to SYSLOG Notifications +3. Mapping SNMP Notifications to SYSLOG Messages In this section, we define how the scopedPDU portion from a SNMP notification message is used to generate a message in the SYSLOG format. The notification receiver application at the snmp-to-syslog translator is listening for incoming notifications. After a notification is received by the SNMP engine the data portion is forwarded to the notification receiver application. The data portion - contains the scopedPDU portion of the message which is used by the - SYSLOG sender on the snmp-to-syslog translator to generate a SYSLOG - notification and send it to a SYSLOG receiver. A common scenario is - the following: + contains the scopedPDU of the message which is used by the SYSLOG + originator on the snmp-to-syslog translator to generate a SYSLOG + message and send it to a SYSLOG collector (or proxy). Note that + every SNMP notification maps to exactly one SYSLOG message. - +-------------------+ snmp +------------+ - | |notification |snmp | - +---------+ syslog | +-------------+ |<------------|notification| - |syslog |notification| |syslog sender| | |originator | - |collector|<-----------| +-------------+ | +------------+ - | | | +------------+ | snmp +------------+ - | | | |snmp | |notification |snmp | - +---------+ | |notification| |<------------|notification| - | |receiver | | |originator | - | +------------+ | +------------+ - | snmp-to-syslog |snmp +------------+ - | translator |notification |snmp | - | |<------------|notification| - +-------------------+ |originator | + +------------+ +------------------+ + |snmp | snmp | | syslog +---------+ + |notification| notification | +------------+ | message |syslog | + |originator |------------->| |syslog | |-------->|collector| + +------------+ | |originator | | +---------+ + +------------+ | +------------+ | + |snmp | snmp | +------------+ | syslog +---------+ + |notification| notification | |snmp | | message |syslog | + |originator |------------->| |notification| |-------->|collector| + +------------+ | |receiver | | +---------+ + +------------+ | +------------+ | + |snmp | snmp | | + |notification| notification | snmp-to-syslog | + |originator |------------->| translator | + +------------+ +------------------+ - There can be many SNMP notification originators which send SNMP event - notifications to a snmp-to-syslog translator. The snmp-to-syslog - translator extracts the data portion of the notification, generates a - SYSLOG message, and send the SYSLOG message to a SYSLOG collector, - which is responsible for collecting and storing all notification - messages. + A common deployment scenario is shown above. There can be many SNMP + notification originators which send SNMP event notifications to a + snmp-to-syslog translator. The snmp-to-syslog translator extracts + the data portion of the notification, generates a SYSLOG message, and + send the SYSLOG message to a SYSLOG collector, which is responsible + for collecting and storing all notification messages. The snmp-to-syslog translator is not transparent for a SYSLOG - receiver. The global header of the SYSLOG message generated by the + collector. The global header of the SYSLOG message generated by the snmp-to-syslog translator is filled with parameters that are specific for the system running the snmp-to-syslog translator such as its hostname, time stamp, etc. The data portion (scopedPDU for SNMPv3 or PDU for SNMPv1/SNMPv2c) of the SNMP notification message is contained in the structured data of the SYSLOG message. Implementations MUST drop invalid SNMP messages before they are passed to the snmp-to-syslog translator. 3.1. SYSLOG Header @@ -328,21 +329,21 @@ HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f NONZERODIGIT = %d49-57 ZERO = %d48 DIGIT = ZERO / NONZERODIGIT SP = %d32 Each SNMP-SD-ELEMENT starts with the SD-ID "snmp". The first two SD-ID parameters are "ctxEngine" and "ctxName". They must be present in an SNMPv3 notification and therefore they must be present in a SYSLOG message generated by an snmp-to-syslog translator from an - SNMPv3 notification. The contexdEngineID is encoded as as + SNMPv3 notification. The contexdEngineID is encoded as an hexadecimal string while the contextName is encoded as a UTF8 string. The remaining parameters in the "snmp" SD-ID correspond to the varbind list elements contained in the SNMP PDU. The name of a varbind is encoded as an OID in dotted notation. The rendered OID is carried in a "vN" parameter, where N identifies the position of the varbind in the varbind list of the SNMP message (the first varbind having the position 1). A MIB aware implementation may in addition generate a parameter "lN" carrying the descriptor of the associated MIB object plus the instance identifier suffix (also called an OID @@ -385,56 +386,71 @@ | Opaque | pN | hexadecimal (BER) string | | TimeTicks | tN | unsigned decimal number | | NULL | nN | zero-length string | +--------------------+------------+--------------------------+ Table 1: Mapping of SNMP Types to SD Params The SYSLOG message generated by the snmp-to-syslog translator may include other structured data elements in its structured part in addition to the SNMP-SD-ELEMENT. These structured data elements are - included in the SYSLOG message by the SYSLOG sender at the snmp-to- - syslog translator and must be compliant to the specification in + included in the SYSLOG message by the SYSLOG originator at the snmp- + to-syslog translator and must be compliant to the specification in [RFC5424]. In particular, the parameters in the "origin" SD-ID should identify the originator of the SNMP notification. A suitable value for the "ip" parameter may be taken from the snmpTrapAddress varbind if present and a suitable value for the "enterpriseId" parameter may be extracted from snmpTrapOID varbind. 3.3. MSG Data The MSG part of the SYSLOG message is optional and may contain a free-form message that provides a textual description of the SNMP event notification. The character set used in MSG SHOULD be UNICODE, - encoded using UTF-8 as specified in [RFC3629]. If the sender can not - encode the MSG in Unicode, it MAY use any other encoding. + encoded using UTF-8 as specified in [RFC3629]. If the originator can + not encode the MSG in Unicode, it MAY use any other encoding. 4. Relationship to the SYSLOG-MSG-MIB A companion document defines an SNMP MIB module to represent SYSLOG messages and to send SYSLOG messages as SNMP notifications to SNMP notification receivers [I-D.ietf-opsawg-syslog-msg-mib]. This section discusses the possibilities of using both specifications in - combination to create notification "tunnels". + combination. - A SYSLOG receiver supporting an SNMP notification originator - implementing this specification SHOULD translate received SYSLOG - messages containing SNMP notifications back into the SNMP - notifications. This allows operators to build a forwarding chain - where SNMP notifications are "tunneled" through SYSLOG messages. + A SYSLOG collector implementing the SYSLOG-MSG-MIB module and the + mapping of SNMP notifications to SYSLOG messages may be configured to + translate received SYSLOG messages containing SNMP notifications back + into the original SNMP notification. In this case, the relevant + tables of the SYSLOG-MSG-MIB will not be populated for SYSLOG + messages carrying SNMP notifications. This configuration allows + operators to build a forwarding chain where SNMP notifications are + "tunneled" through SYSLOG messages. Due to size restrictions of the + SYSLOG transports and the more verbose textual encoding used by + SYSLOG, there is a possibility that SNMP notification content gets + truncated while tunneled through SYSLOG and thus the resulting SNMP + notification may be incomplete. - Due to size restrictions of the SYSLOG transports and the more - verbose textual encoding used by SYSLOG, there is a possibility that - SNMP notification content gets truncated while tunneled through - SYSLOG and thus the resulting SNMP notification may be incomplete. + An SNMP management application supporting the SYSLOG-MSG-MIB and the + mapping of SNMP notifications to SYSLOG messages may process + information from the SYSLOG-MSG-MIB in order to emit a SYSLOG message + representing the SYSLOG message recorded in the SYSLOG-MSG-MIB + module. This configuration allows operators to build a forwarding + chain where SYSLOG messages are "tunneled" through SNMP messages. A + notification receiver can determine whether a syslogMsgNotification + contained all structured data element parameters of a SYSLOG message. + In case parameters are missing, a forwarding application MUST + retrieve the missing parameters from the SYSLOG-MSG-MIB. Regular + polling of the SYSLOG-MSG-MIB can be used to take care of any lost + SNMP notifications. 5. Usage Example Here we provide an example how an SNMP linkUp trap message is mapped into a SYSLOG message by using the mappings defined in Section 3.1 and Section 3.2. The linkUp notification is defined in [RFC2863]: linkUp NOTIFICATION-TYPE @@ -443,21 +459,21 @@ DESCRIPTION "A linkUp trap signifies that the SNMP entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links left the down state and transitioned into some other state (but not into the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 4 } The scopedPDU portion of an SNMP linkUp trap sent using the SNMPv3 - message format is show below (left columns shows the BER encoding + message format is shown below (left columns shows the BER encoding while the right column indicates the corresponding ASN.1 definitions): 30:7C SEQUENCE { 04:08:80:00:02:B8:04:61:62:63 800002b804616263 04:04:63:74:78:31 "ctx1" A7:6A SNMPv2-Trap-PDU { 02:03:6D:08:67 INTEGER 7145575 02:01:00 INTEGER 0 02:01:00 INTEGER 0 @@ -555,22 +571,22 @@ The SNMP architecture supports an access control mechanism ensuring that SNMP notifications are only sent to receivers who are authorized to receive the notification. Users of this mapping of SNMP notifications to SYSLOG messages should enforce a consistent policy preventing people from accessing SNMP notifications via the SYSLOG mapping that would otherwise not be accessible. 8. Acknowledgments The authors wish to thank Martin Bjorklund, Washam Fan, Rainer - Gerhards and all other people who commented on various versions of - this proposal. + Gerhards, Tom Petch and all other people who commented on various + versions of this proposal. 9. References 9.1. Normative References [I-D.ietf-opsawg-syslog-msg-mib] Schoenwaelder, J., Clemm, A., and A. Karmakar, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", Internet Draft (work in progress),