--- 1/draft-ietf-opsawg-syslog-snmp-01.txt 2009-03-26 19:12:03.000000000 +0100 +++ 2/draft-ietf-opsawg-syslog-snmp-02.txt 2009-03-26 19:12:03.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group V. Marinov Internet-Draft J. Schoenwaelder Intended status: Standards Track Jacobs University Bremen -Expires: September 10, 2009 March 9, 2009 +Expires: September 27, 2009 March 26, 2009 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages - draft-ietf-opsawg-syslog-snmp-01.txt + draft-ietf-opsawg-syslog-snmp-02.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,21 +22,21 @@ 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 10, 2009. + This Internet-Draft will expire on September 27, 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 @@ -72,26 +72,25 @@ 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 via a single management protocol. In such environments, it is necessary to translate event notifications between management protocols. - The latest version of SYSLOG, specified in - [I-D.ietf-syslog-protocol], supports a structured data element - format. Structured data elements allow us to map between SNMP - notifications and SYSLOG messages without losing information. In - this memo we specify a concrete mapping from SNMP event notifications - [RFC3416] into SYSLOG messages [I-D.ietf-syslog-protocol]. We + The latest version of SYSLOG, specified in [RFC5424], supports a + structured data element format. Structured data elements allow us to + map between SNMP notifications and SYSLOG messages without losing + information. In this memo we specify a concrete mapping from SNMP + 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 @@ -176,25 +175,25 @@ In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID and the contextName parameters are not present in notification 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 [I-D.ietf-syslog-protocol]. 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 [I-D.ietf-syslog-protocol]. The relevant - productions for structured data elements are: + 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 + [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. SD-NAME = 1*32PRINTUSASCII ; except '=', SP, ']', %d34 (") @@ -262,21 +261,21 @@ generated by system daemons. The default severity level should be 5, which correponds to "Notice: normal but significant condition". If the snmp-to-syslog translator has a notion of the type of notification that has been received it might choose other values for facility and severity level. The VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID and MSGID fields in the SYSLOG message header are filled with values that are specific to the system on which the snmp-to-syslog translator is running. The character set used in the HEADER MUST be seven-bit ASCII in an eight- - bit field as described in [I-D.ietf-syslog-protocol]. + bit field as described in [RFC5424]. 3.2. Structured Data The STRUCTURED-DATA field of a SYSLOG message will contain the ScopedPDU (or PDU) portion of the SNMP notification message. For the purpose of carrying SNMP notification data, a new SD-ID element is defined. The ABNF [RFC4234] representation of the new structured element is: SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] *VARBIND "]" @@ -388,21 +387,21 @@ | 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 - [I-D.ietf-syslog-protocol]. + [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 @@ -412,23 +411,30 @@ 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". - [TODO: Add text explaining the combination of the two specifications, - similar to the text in the companion document. Discuss the - implication of message sizes.] + 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. + + 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. 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 @@ -483,28 +488,28 @@ v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0" o2="1.3.6.1.6.3.1.1.5.4" a2="linkUp" v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" a4="up" v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" a5="up"] The corresponding SYSLOG message has a priority value of 29 which means a facility level of 3 (system daemons) and a severity level of 5 (Notice: Normal but significant condition) according to the algorithm for calculation of priority value specified in Section - 6.2.1 of [I-D.ietf-syslog-protocol]. The rest of the fields in the - header of the SYSLOG message are parameters that are specific to the - system running the snmp-to-syslog translator. The SYSLOG version is - 1 and the message was generated at 22:14:15.003Z on 2003-10-11T by - the host "mymachine.example.com". The application on the snmp-to- - syslog translator that generated the message was "snmptrapd", there - is no information about the process id and the message on the snmp- - to-syslog system is identified with the MSGID of ID47. + 6.2.1 of [RFC5424]. The rest of the fields in the header of the + SYSLOG message are parameters that are specific to the system running + the snmp-to-syslog translator. The SYSLOG version is 1 and the + message was generated at 22:14:15.003Z on 2003-10-11T by the host + "mymachine.example.com". The application on the snmp-to-syslog + translator that generated the message was "snmptrapd", there is no + information about the process id and the message on the snmp-to- + syslog system is identified with the MSGID of ID47. The SYSLOG message contains one structured data element with a SD-ID of "snmp" which means that this is the scopedPDU portion of an SNMP event notification message. The data which is contained in the notification is associated with the ContextEngineID "123456" and ContextName "ctx1". The request-id of the SNMP notification message was "7145575". Then follows the data portion of the scopedPDU. The first two variables contained in the data portion are always the sysUpTime.0 and snmpTrapOID.0. An snmpTrapOID.0 with a value of "1.3.6.1.6.3.1.1.5.4" means that this is a linkUp trap. The @@ -514,23 +519,22 @@ v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" mean that the SNMP notification message is carrying the object ifAdminStatus which has type INTEGER and a value of 1. The parameters v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" mean that the SNMP notification message is carrying the object ifOperStatus which has type INTEGER and a value of "1". 6. IANA Considerations IANA is requested to register the SD-ID value "snmp" together with the PARAM-NAME values specified in Section 3.2 in the registry for - SYSLOG structured data id values according to Section 9 in - [I-D.ietf-syslog-protocol]. The notation indicates a position - number. + SYSLOG structured data id values according to Section 9 in [RFC5424]. + The notation indicates a position number. SD-ID PARAM-NAME snmp OPTIONAL ctxEngine OPTIONAL ctxName OPTIONAL v OPTIONAL l OPTIONAL o OPTIONAL x OPTIONAL c OPTIONAL @@ -538,22 +542,22 @@ u OPTIONAL d OPTIONAL i OPTIONAL n OPTIONAL p OPTIONAL t OPTIONAL a OPTIONAL 7. Security Considerations - The security considerations discussed in [I-D.ietf-syslog-protocol] - apply to this document. + The security considerations discussed in [RFC5424] apply to this + document. 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 @@ -565,24 +569,20 @@ 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), March 2009. - [I-D.ietf-syslog-protocol] - Gerhards, R., "The syslog Protocol", Internet Draft (work - in progress), September 2007. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network @@ -602,20 +602,22 @@ RFC 3418, December 2002. [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework.", BCP 74, RFC 3584, August 2003. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. + [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. + 9.2. Informative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,