idnits 2.17.1 draft-ietf-opsawg-syslog-snmp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 6, 2009) is 5377 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '7' on line 140 -- Looks like a reference, but probably isn't: '0' on line 156 -- Looks like a reference, but probably isn't: '1' on line 157 -- Looks like a reference, but probably isn't: '2' on line 158 -- No information found for draft-ietf-opsawg-syslog-msg-mib - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-opsawg-syslog-msg-mib' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Marinov 3 Internet-Draft J. Schoenwaelder 4 Intended status: Standards Track Jacobs University Bremen 5 Expires: February 7, 2010 August 6, 2009 7 Mapping Simple Network Management Protocol (SNMP) Notifications to 8 SYSLOG Messages 9 draft-ietf-opsawg-syslog-snmp-04.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 7, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This memo defines a mapping from Simple Network Management Protocol 48 (SNMP) notifications to SYSLOG messages. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3 56 2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5 57 3. Mapping SNMP Notifications to SYSLOG Messages . . . . . . . . 6 58 3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 7 59 3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7 60 3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 4. Relationship to the SYSLOG-MSG-MIB . . . . . . . . . . . . . . 10 62 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 11 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 71 1. Introduction 73 SNMP and SYSLOG are two widely used protocols to communicate event 74 notifications. Although co-existence of several management protocols 75 in one operational environment is possible, certain environments 76 require that all event notifications are collected by a single system 77 daemon such as a SYSLOG collector or an SNMP notification receiver 78 via a single management protocol. In such environments, it is 79 necessary to translate event notifications between management 80 protocols. 82 The latest version of SYSLOG, specified in [RFC5424], supports a 83 structured data element format. Structured data elements allow us to 84 map between SNMP notifications and SYSLOG messages without losing 85 information. In this memo we specify a concrete mapping from SNMP 86 event notifications [RFC3416] into SYSLOG messages [RFC5424]. We 87 specify how the SYSLOG message format should be utilized to carry the 88 information contained in an SNMP notification message. A new SYSLOG 89 structured data element is defined which carries the PDU portion of 90 an SNMP notification message. 92 1.1. Conventions 94 A system which has the capability of receiving SNMP notification 95 messages from an SNMP Notification Originator and sending the SNMP 96 data contained inside in a SYSLOG message format to a SYSLOG 97 collector is referred in this memo as an "SNMP-to-SYSLOG translator". 98 By definition, such a system should have an SNMP Notification 99 Receiver application and a SYSLOG originator running in order to be 100 able to perform the functions of an "SNMP-to-SYSLOG translator". 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. Background 108 2.1. SNMP Notifications 110 A detailed introduction to the SNMP Management Framework can be found 111 in [RFC3410]. The SNMP Management Architecture is described in 112 [RFC3411]. Managed objects are accessed via a virtual information 113 store, termed the Management Information Base or MIB [RFC3418]. 114 Objects in the MIB are defined using the mechanisms defined in the 115 SMI [RFC2578]. 117 An SNMP notification message is generated and transmitted by an SNMP 118 entity on behalf of a Notification Originator application [RFC3413]. 119 SNMP notifications are often used to notify a Notification Receiver 120 application at a logically remote SNMP entity that an event has 121 occurred or that a certain condition is present. There are two types 122 of SNMP protocol operations that are associated with SNMP 123 notification messages [RFC3416]: 125 o SNMPv2-Trap-PDU, an unconfirmed notification delivery mechanisms 126 o InformRequest-PDU, a confirmed notification delivery mechanism 128 The scopedPDU portion of an SNMPv3 trap or inform message has the 129 following format [RFC3412]: 131 ScopedPDU ::= SEQUENCE { 132 contextEngineID OCTET STRING, 133 contextName OCTET STRING, 134 data ANY -- e.g., PDUs as defined in [RFC3416] 135 } 137 The data member of the SEQUENCE ScopedPDU carries a SNMPv2-Trap-PDU 138 or an InformRequest-PDU. They both have the same structure: 140 PDUs ::= [7] IMPLICIT SEQUENCE { 141 request-id INTEGER, 142 error-status INTEGER, -- ignored in notifications 143 error-index INTEGER, -- ignored in notifications 144 variable-bindings VarBindList 145 } 147 -- variable binding 149 VarBind ::= SEQUENCE { 150 name ObjectName, 152 CHOICE { 153 value ObjectSyntax, 154 unSpecified NULL, -- in retrieval requests 155 -- exceptions in responses 156 noSuchObject [0] IMPLICIT NULL, 157 noSuchInstance [1] IMPLICIT NULL, 158 endOfMibView [2] IMPLICIT NULL 159 } 160 } 162 -- variable-binding list 164 VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind 166 The first two variable bindings in the variable binding list of an 167 SNMPv2-Trap-PDU or InformRequest-PDU are sysUpTime.0 [RFC3418] and 168 snmpTrapOID.0 [RFC3418] respectively. If the OBJECTS clause is 169 present in the invocation of the corresponding NOTIFICATION-TYPE 170 macro, then each corresponding variable, as instantiated by this 171 notification, is copied, in order, to the variable-bindings field. 172 If any additional variables are being included (at the option of the 173 generating SNMP entity), then each is copied to the variable-bindings 174 field. 176 In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID 177 and the contextName parameters are not present in notification 178 messages. 180 This document assumes that notifications are in the format defined in 181 RFC 3416 [RFC3416]. Notifications in the SNMPv1 notification format 182 MUST be translated as described in Section 3.1 of RFC 3584 [RFC3584]. 184 2.2. SYSLOG Notifications 186 The SYSLOG protocol is defined in [RFC5424]. The message contains a 187 global header and a number of structured data elements. The ABNF 188 [RFC5234] representation of a SYSLOG message is defined in RFC 5424 189 [RFC5424]. The relevant productions for structured data elements 190 are: 192 STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT 193 SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]" 194 SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34 195 SD-ID = SD-NAME 196 PARAM-NAME = SD-NAME 197 PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and 198 ; ']' MUST be escaped. 199 SD-NAME = 1*32PRINTUSASCII 200 ; except '=', SP, ']', %d34 (") 202 UTF-8-STRING = *OCTET ; Any VALID UTF-8 String 203 ; "shortest form" MUST be used 205 OCTET = %d00-255 206 SP = %d32 207 PRINTUSASCII = %d33-126 208 NILVALUE = "-" 210 3. Mapping SNMP Notifications to SYSLOG Messages 212 In this section, we define how the scopedPDU portion from a SNMP 213 notification message is used to generate a message in the SYSLOG 214 format. The notification receiver application at the SNMP-to-SYSLOG 215 translator is listening for incoming notifications. After a 216 notification is received by the SNMP engine the data portion is 217 forwarded to the notification receiver application. The data portion 218 contains the scopedPDU of the message which is used by the SYSLOG 219 originator on the SNMP-to-SYSLOG translator to generate a SYSLOG 220 message and send it to a SYSLOG collector (or proxy). Note that 221 every SNMP notification maps to exactly one SYSLOG message. 223 +------------+ +------------------+ 224 |snmp | snmp | | syslog +---------+ 225 |notification| notification | +------------+ | message |syslog | 226 |originator |------------->| |syslog | |-------->|collector| 227 +------------+ | |originator | | +---------+ 228 +------------+ | +------------+ | 229 |snmp | snmp | +------------+ | syslog +---------+ 230 |notification| notification | |snmp | | message |syslog | 231 |originator |------------->| |notification| |-------->|collector| 232 +------------+ | |receiver | | +---------+ 233 +------------+ | +------------+ | 234 |snmp | snmp | | 235 |notification| notification | SNMP-to-SYSLOG | 236 |originator |------------->| translator | 237 +------------+ +------------------+ 239 Figure 1: SNMP-to-SYSLOG translator deployment 241 A common deployment scenario is shown in Figure 1. There can be many 242 SNMP notification originators which send SNMP event notifications to 243 a SNMP-to-SYSLOG translator. The SNMP-to-SYSLOG translator extracts 244 the data portion of the notification, generates a SYSLOG message, and 245 send the SYSLOG message to a SYSLOG collector, which is responsible 246 for collecting and storing all notification messages. The arrows in 247 Figure 1 indicate message flows, not individual messages. 249 The SNMP-to-SYSLOG translator is not transparent for a SYSLOG 250 collector. The global header of the SYSLOG message generated by the 251 SNMP-to-SYSLOG translator is filled with parameters that are specific 252 for the system running the SNMP-to-SYSLOG translator such as its 253 hostname, time stamp, etc. The data portion (scopedPDU for SNMPv3 or 254 PDU for SNMPv1/SNMPv2c) of the SNMP notification message is contained 255 in the structured data of the SYSLOG message. 257 Implementations MUST drop invalid SNMP messages before they are 258 passed to the SNMP-to-SYSLOG translator. 260 3.1. SYSLOG Header 262 The SNMP-to-SYSLOG translator fills the HEADER field of a SYSLOG 263 message with parameters specific to the system on which it is 264 running. The default facility level for SYSLOG messages containing 265 SNMP notifications SHOULD be 3, which corresponds to messages 266 generated by system daemons. The default severity level SHOULD be 5, 267 which correponds to "Notice: normal but significant condition". If 268 the SNMP-to-SYSLOG translator has a notion of the type of 269 notification that has been received it might choose other values for 270 facility and severity level. 272 The VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID and MSGID fields 273 in the SYSLOG message header are filled with values that are specific 274 to the system on which the SNMP-to-SYSLOG translator is running. The 275 character set used in the HEADER MUST be seven-bit ASCII in an eight- 276 bit field as described in [RFC5424]. 278 3.2. Structured Data 280 The STRUCTURED-DATA field of a SYSLOG message carries the ScopedPDU 281 (or PDU) portion of an SNMP notification message. For the purpose of 282 carrying SNMP notification data, a new SD-ID element is defined. The 283 ABNF [RFC5234] representation of the new structured element is: 285 SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] *VARBIND "]" 286 SNMP-SD-ID = %x73.6E.6D.70 ; snmp 287 CTX = CTXENGINE CTXNAME 288 CTXENGINE = SP "ctxEngine=" %d34 HEXSTRING %d34 289 CTXNAME = SP "ctxName=" %d34 PARAM-VALUE %d34 290 VARBIND = SP VARNAME [SP VARLABEL] SP VARVALUE [SP VALSTRING] 291 VARNAME = %d118 NUM "=" %d34 OID %d34 ; "vN=" 292 VARLABEL = %d108 NUM "=" %d34 PARAM-VALUE %d34 ; "lN=" 293 VARVALUE = VALOID / VALHEXSTRING / VALCOUNTER32 / VALCOUNTER64 294 / VALUNSIGNED32 / VALINTEGER32 / VALIP / VALNULL 295 / VALOPAQUE / VALTIMETICKS / VALUTF8STRING 297 VALOID = %d111 NUM "=" %d34 OID %d34 ; "oN=" 298 VALHEXSTRING = %d120 NUM "=" %d34 HEXSTRING %d34 ; "xN=" 299 VALCOUNTER32 = %d99 NUM "=" %d34 UNSIGNED32 %d34 ; "cN=" 300 VALCOUNTER64 = %d67 NUM "=" %d34 UNSIGNED64 %d34 ; "CN=" 301 VALUNSIGNED32 = %d117 NUM "=" %d34 UNSIGNED32 %d34 ; "uN=" 302 VALINTEGER32 = %d100 NUM "=" %d34 INTEGER32 %d34 ; "dN=" 303 VALIP = %d105 NUM "=" %d34 IPV4ADDRESS %d34 ; "iN=" 304 VALNULL = %d110 NUM "=" %d34 NULL %d34 ; "nN=" 305 VALOPAQUE = %d112 NUM "=" %d34 HEXSTRING %d34 ; "pN=" 306 VALTIMETICKS = %d116 NUM "=" %d34 UNSIGNED32 %d34 ; "tN=" 307 VALSTRING = %d97 NUM "=" %d34 PARAM-VALUE %d34 ; "aN=" 309 NUM = NONZERODIGIT 0*DIGIT 311 OID = OIDSTART *("." OIDSUBID) 312 OIDSTART = (("0." / "1.")[%d49-51] DIGIT) / ("2." OIDSUBID) 313 OIDSUBID = ZERO / (NONZERODIGIT *DIGIT) 315 PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and 316 ; ']' MUST be escaped. 317 UTF-8-STRING = *OCTET ; Any VALID UTF-8 String 318 ; "shortest form" MUST be used 319 HEXSTRING = *HEX 320 INTEGER32 = ["-"] NONZERODIGIT 0*DIGIT 321 UNSIGNED32 = NONZERODIGIT 0*DIGIT 322 UNSIGNED64 = NONZERODIGIT 0*DIGIT 323 NULL = "" 324 IPV4ADDRESS = d8 "." d8 "." d8 "." d8 326 d8 = DIGIT ; 0-9 327 / %d49-57 DIGIT ; 10-99 328 / "1" 2DIGIT ; 100-199 329 / "2" %d48-52 DIGIT ; 200-249 330 / "25" %d48-53 ; 250-255 332 HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f 333 NONZERODIGIT = %d49-57 334 ZERO = %d48 335 DIGIT = ZERO / NONZERODIGIT 336 SP = %d32 338 Each SNMP-SD-ELEMENT starts with the SD-ID "snmp". The first two 339 SD-ID parameters are "ctxEngine" and "ctxName". The context MUST be 340 present in an SNMPv3 notification and therefore they MUST be present 341 in a SYSLOG message generated by an SNMP-to-SYSLOG translator from an 342 SNMPv3 notification. The contexdEngineID is encoded as an 343 hexadecimal string while the contextName is encoded as a UTF8 string. 345 The remaining parameters in the "snmp" SD-ID correspond to the 346 varbind list elements contained in the SNMP PDU. The name of a 347 varbind is encoded as an OID in dotted notation. The rendered OID is 348 carried in a "vN" parameter, where N identifies the position of the 349 varbind in the varbind list of the SNMP message (the first varbind 350 having the position 1). A MIB aware implementation may in addition 351 generate a parameter "lN" carrying the descriptor of the associated 352 MIB object plus the instance identifier suffix (also called an OID 353 label). The number N again identifies the position of the varbind in 354 the varbind list of the SNMP message. 356 The value of a varbind is encoded depending on its type according to 357 the rules shown in Table 1 and type specific parameter names are used 358 to convey the type information. The number N again identifies the 359 position of the varbind in the varbind list of the SNMP message. A 360 MIB aware implementation may in addition generate a parameter "aN" 361 carrying a alternate textual representation of the value, which is 362 obtained by applying DISPLAY-HINTs and translating named numbers into 363 corresponding labels or OBJECT IDENTIFIER values to descriptors. For 364 SNMP object types that have a DISPLAY-HINT of the form 'Ma' or 'Mt' 365 where M is some number, a MIB aware implementation can choose to 366 include the "aN" parameter and to suppress the corresponding "xN" 367 parameter. This special case allows to save space for textual 368 objects. A receiver receiving a "aN" parameter without a matching 369 value at position N can unambiguously convert the value carried in 370 the "aN" parameter back to an OCTET STRING value. 372 While the inclusion of additional parameters carrying OID labels or 373 alternate value representations increases human readability, this 374 comes at the cost of increased message size which may cause 375 truncation of SYSLOG message. Therefore, implementations SHOULD 376 provide a configuration mechanism to enable/disable the generation of 377 parameters carrying OID labels or alternate value representations. 379 +--------------------+------------+--------------------------+ 380 | SNMP Type | PARAM-NAME | Value Encoding | 381 +--------------------+------------+--------------------------+ 382 | OBJECT IDENTIFIER | oN | dotted-decimal notation | 383 | OCTET STRING | xN | hexadecimal string | 384 | Counter32 | cN | unsigned decimal number | 385 | Counter64 | CN | unsigned decimal number | 386 | Unsigned32 | uN | unsigned decimal number | 387 | INTEGER, Integer32 | dN | signed decimal number | 388 | IpAddress | iN | dotted quad notation | 389 | Opaque | pN | hexadecimal (BER) string | 390 | TimeTicks | tN | unsigned decimal number | 391 | NULL | nN | zero-length string | 392 +--------------------+------------+--------------------------+ 394 Table 1: Mapping of SNMP Types to SD Params 396 The SYSLOG message generated by the SNMP-to-SYSLOG translator may, in 397 addition to the SNMP-SD-ELEMENT, include other structured data 398 elements in its structured data part. These additional structured 399 data elements MUST comply with the specification in [RFC5424]. 401 In particular, the parameters in the "origin" SD-ID SHOULD identify 402 the originator of the SNMP notification. A suitable value for the 403 "ip" parameter MAY be taken from the snmpTrapAddress varbind if 404 present and a suitable value for the "enterpriseId" parameter MAY be 405 extracted from snmpTrapOID varbind. 407 3.3. MSG Data 409 The MSG part of the SYSLOG message is optional and may contain a 410 free-form message that provides a textual description of the SNMP 411 event notification. The character set used in MSG SHOULD be UNICODE, 412 encoded using UTF-8 as specified in [RFC3629]. If the originator can 413 not encode the MSG in Unicode, it MAY use any other encoding. 415 4. Relationship to the SYSLOG-MSG-MIB 417 A companion document defines an SNMP MIB module to represent SYSLOG 418 messages and to send SYSLOG messages as SNMP notifications to SNMP 419 notification receivers [I-D.ietf-opsawg-syslog-msg-mib]. This 420 section discusses the possibilities of using both specifications in 421 combination. 423 A SYSLOG collector implementing the SYSLOG-MSG-MIB module and the 424 mapping of SNMP notifications to SYSLOG messages may be configured to 425 translate received SYSLOG messages containing SNMP notifications back 426 into the original SNMP notification. In this case, the relevant 427 tables of the SYSLOG-MSG-MIB will not be populated for SYSLOG 428 messages carrying SNMP notifications. This configuration allows 429 operators to build a forwarding chain where SNMP notifications are 430 "tunneled" through SYSLOG messages. Due to size restrictions of the 431 SYSLOG transports and the more verbose textual encoding used by 432 SYSLOG, there is a possibility that SNMP notification content gets 433 truncated while tunneled through SYSLOG and thus the resulting SNMP 434 notification may be incomplete. 436 An SNMP management application supporting the SYSLOG-MSG-MIB and the 437 mapping of SNMP notifications to SYSLOG messages may process 438 information from the SYSLOG-MSG-MIB in order to emit a SYSLOG message 439 representing the SYSLOG message recorded in the SYSLOG-MSG-MIB 440 module. This configuration allows operators to build a forwarding 441 chain where SYSLOG messages are "tunneled" through SNMP messages. A 442 notification receiver can determine whether a syslogMsgNotification 443 contained all structured data element parameters of a SYSLOG message. 444 In case parameters are missing, a forwarding application MUST 445 retrieve the missing parameters from the SYSLOG-MSG-MIB. Regular 446 polling of the SYSLOG-MSG-MIB can be used to take care of any lost 447 SNMP notifications. 449 5. Usage Example 451 Here we provide an example how an SNMP linkUp trap message is mapped 452 into a SYSLOG message by using the mappings defined in Section 3.1 453 and Section 3.2. 455 The linkUp notification is defined in [RFC2863] as follows: 457 linkUp NOTIFICATION-TYPE 458 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 459 STATUS current 460 DESCRIPTION 461 "A linkUp trap signifies that the SNMP entity, acting in an 462 agent role, has detected that the ifOperStatus object for 463 one of its communication links left the down state and 464 transitioned into some other state (but not into the 465 notPresent state). This other state is indicated by the 466 included value of ifOperStatus." 467 ::= { snmpTraps 4 } 469 The scopedPDU portion of an SNMP linkUp trap sent using the SNMPv3 470 message format is shown below (left columns shows the BER encoding 471 while the right column indicates the corresponding ASN.1 472 definitions): 474 30:7C SEQUENCE { 475 04:08:80:00:02:B8:04:61:62:63 800002b804616263 476 04:04:63:74:78:31 "ctx1" 477 A7:6A SNMPv2-Trap-PDU { 478 02:03:6D:08:67 INTEGER 7145575 479 02:01:00 INTEGER 0 480 02:01:00 INTEGER 0 481 30:5D SEQUENCE OF { 482 30:0F SEQUENCE { 483 06:08:2B:06:01:02:01:01:03:00 sysUpTime.0 484 43:03:01:72:8C 94860 } 485 30:17 SEQUENCE { 486 06:0A:2B:06:01:06:03:01:01:04:01:00 snmpTrapOID.0 487 06:09:2B:06:01:06:03:01:01:05:04 linkUp } 488 30:0F SEQUENCE { 489 06:0A:2B:06:01:02:01:02:02:01:01:03 ifIndex.3 490 02:01:03 3 } 491 30:0F SEQUENCE { 492 06:0A:2B:06:01:02:01:02:02:01:07:03 ifAdminStatus.3 493 02:01:01 up(1) } 494 30:0F SEQUENCE { 495 06:0A:2B:06:01:02:01:02:02:01:08:03 ifOperStatus.3 496 02:01:01 up(1) } } } } 498 The corresponding SYSLOG message generated by the SNMP-to-SYSLOG 499 translator is shown below. (SYSLOG examples should be considered to 500 be on one line. They are wrapped on multiple lines in this document 501 for readability purposes only.) 503 <29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47 504 [snmp ctxEngine="800002b804616263" ctxName="ctx1" 505 v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860" 506 v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0" 507 o2="1.3.6.1.6.3.1.1.5.4" a2="linkUp" 508 v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" 509 v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" a4="up" 510 v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" a5="up"] 512 The corresponding SYSLOG message has a priority value of 29 which 513 means a facility level of 3 (system daemons) and a severity level of 514 5 (Notice: Normal but significant condition) according to the 515 algorithm for calculation of priority value specified in Section 516 6.2.1 of [RFC5424]. The rest of the fields in the header of the 517 SYSLOG message are parameters that are specific to the system running 518 the SNMP-to-SYSLOG translator. The SYSLOG version is 1 and the 519 message was generated at 22:14:15.003Z on 2003-10-11T by the host 520 "mymachine.example.com". The application on the SNMP-to-SYSLOG 521 translator that generated the message was "snmptrapd", there is no 522 information about the process id and the message on the SNMP-to- 523 SYSLOG system is identified with the MSGID of ID47. 525 The SYSLOG message contains one structured data element with a SD-ID 526 of "snmp" which means that this is the scopedPDU portion of an SNMP 527 event notification message. The data which is contained in the 528 notification is associated with the ContextEngineID "123456" and 529 ContextName "ctx1". The request-id of the SNMP notification message 530 was "7145575". Then follows the data portion of the scopedPDU. The 531 first two variables contained in the data portion are always the 532 sysUpTime.0 and snmpTrapOID.0. An snmpTrapOID.0 with a value of 533 "1.3.6.1.6.3.1.1.5.4" means that this is a linkUp trap. The 534 parameters v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" mean that the SNMP 535 notification message is carrying the ifIndex object which has a type 536 INTEGER and has a value of 3. The parameters 537 v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" mean that the SNMP notification 538 message is carrying the object ifAdminStatus which has type INTEGER 539 and a value of 1. The parameters v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" 540 mean that the SNMP notification message is carrying the object 541 ifOperStatus which has type INTEGER and a value of "1". 543 6. IANA Considerations 545 IANA is requested to register the SD-ID value "snmp" together with 546 the PARAM-NAME values specified in Section 3.2 in the registry for 547 SYSLOG structured data id values according to Section 9 in [RFC5424]. 548 The notation indicates a position number. 550 SD-ID PARAM-NAME 551 snmp OPTIONAL 552 ctxEngine OPTIONAL 553 ctxName OPTIONAL 554 v OPTIONAL 555 l OPTIONAL 556 o OPTIONAL 557 x OPTIONAL 558 c OPTIONAL 559 C OPTIONAL 560 u OPTIONAL 561 d OPTIONAL 562 i OPTIONAL 563 n OPTIONAL 564 p OPTIONAL 565 t OPTIONAL 566 a OPTIONAL 568 7. Security Considerations 570 The security considerations discussed in [RFC5424] apply to this 571 document. 573 The SNMP architecture supports an access control mechanism ensuring 574 that SNMP notifications are only sent to receivers who are authorized 575 to receive the notification. Network operators using this mapping of 576 SNMP notifications to SYSLOG messages should enforce a consistent 577 policy preventing people from accessing SNMP notifications via the 578 SYSLOG mapping that would otherwise not be accessible. 580 8. Acknowledgments 582 The editors wish to thank the following individuals for providing 583 helpful comments on various versions of this document: Martin 584 Bjorklund, Washam Fan, Rainer Gerhards, Tom Petch, and Dan Romascanu. 586 9. References 587 9.1. Normative References 589 [I-D.ietf-opsawg-syslog-msg-mib] 590 Schoenwaelder, J., Clemm, A., and A. Karmakar, 591 "Definitions of Managed Objects for Mapping SYSLOG 592 Messages to Simple Network Management Protocol (SNMP) 593 Notifications", Internet Draft (work in progress), 594 March 2009. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 600 Architecture for Describing Simple Network Management 601 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 602 December 2002. 604 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 605 "Message Processing and Dispatching for the Simple Network 606 Management Protocol (SNMP)", STD 62, RFC 3412, 607 December 2002. 609 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 610 Management Protocol (SNMP) Applications", STD 62, 611 RFC 3413, December 2002. 613 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 614 Simple Network Management Protocol (SNMP)", STD 62, 615 RFC 3416, December 2002. 617 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 618 Simple Network Management Protocol (SNMP)", STD 62, 619 RFC 3418, December 2002. 621 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 622 "Coexistence between Version 1, Version 2, and Version 3 623 of the Internet-standard Network Management Framework.", 624 BCP 74, RFC 3584, August 2003. 626 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 627 Specifications: ABNF", RFC 5234, January 2008. 629 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 631 9.2. Informative References 633 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 634 "Structure of Management Information Version 2 (SMIv2)", 635 RFC 2578, STD 58, April 1999. 637 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 638 MIB", RFC 2863, June 2000. 640 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 641 "Introduction and Applicability Statements for Internet- 642 Standard Management Framework", RFC 3410, December 2002. 644 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 645 10646", STD 63, RFC 3629, November 2003. 647 Authors' Addresses 649 Vladislav Marinov 650 Jacobs University Bremen 651 Campus Ring 1 652 28725 Bremen 653 Germany 655 Email: v.marinov@jacobs-university.de 657 Juergen Schoenwaelder 658 Jacobs University Bremen 659 Campus Ring 1 660 28725 Bremen 661 Germany 663 Email: j.schoenwaelder@jacobs-university.de