Cisco IOS Non-compliant bug with SNMP v3 (RFC-3411)

Unanswered Question
Jan 28th, 2010

"CISCO" Non-compliant with RFC-3411 bug for SNMPv3 EngineID:

The following are a list of SNMPv3 Engine ID's from various Cisco switches and routers running various IOS versions configured to use SNMPv3.

8000000903000014a81cc301
8000000903000014a81cc340
8000000903000017595ce541
8000000903000017e0119c81
800000090300001cf65ce402
800000090300001d457a4783
800000090300001d713a6401
800000090300001d713be801
800000090300001da23fd503

The top bit set [8] shows that the EngineID confirms that it's following SNMPv3 specifications.

The first 4 octets (less the top bit) comprise the enterprise.id which is "00000009" and correct as it matches Cisco Systems assigned enterprise.id number.

The 5th octet specifies how the remaining octets are to be interpreted.

  0 - reserved, unused

  1 - IPv4 Address (4 octets)

  2 - IPv6 Address (16 octets)

  3 - MAC Address (6 octets) <<- This is what Cisco's Engine ID specifies in the 5th Octet.

There are other types/formats, but I'll omit the rest of the list as Cisco uses 03 by default.

Notice the number of octets after the 03. There are actually 7 octest and not 6 per RFC-3411 specifications not only making this an invalid MAC address, but mistakenly identifies a Cisco product as that of several other vendor products.

7 octet invalid MAC      Prefix        Vendor 
00 00 14 a8 1c c3 01    00:00:14    netronix
00 00 14 a8 1c c3 40    00:00:14    netronix
00 00 17 59 5c e5 41    00:00:17    TEKELEC
00 00 17 e0 11 9c 81    00:00:17    TEKELEC
00 00 1c f6 5c e4 02     00:00:1c    bell technologies
00 00 1d 45 7a 47 83    00:00:1d    Cabletron Systems, Inc.
00 00 1d 71 3a 64 01    00:00:1d    Cabletron Systems, Inc.
00 00 1d 71 3b e8 01    00:00:1d    Cabletron Systems, Inc.

6 Octet valid MAC    Shifted Prefix    Shifted Vendor
00 14 a8 1c c3 01    00:14:a8           Cisco Systems
00 14 a8 1c c3 40    00:14:a8           Cisco Systems
00 17 59 5c e5 41    00:17:59           Cisco Systems
00 17 e0 11 9c 81    00:17:e0           Cisco Systems
00 1c f6 5c e4 02     00:1c:f6            Cisco Systems
00 1d 45 7a 47 83    00:1d:45           Cisco Systems
00 1d 71 3a 64 01    00:1d:71           Cisco Systems
00 1d 71 3b e8 01    00:1d:71           Cisco Systems

In other words, there is one too many leading [00] octets which makes the Engine ID non-conformant per RFC-3411 specifications and also causes for mistaken identity of a Cisco Systems product as that of various other vendors products!

Also note that WireShark v1.2.5 displays the supposed MAC Address as <Data not conforming to RFC3411>.

This should be fixed!

Walter

P.S. If a very security strict NMS manager were to discard this packet for being non-compliant with RFC-3411, then communications would not possible.  Thus far, the NMS managers I've tested don't seem to mind this little annomaly and continue business as usual, but it's still not-compliant and as such, should be fixed.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joe Clarke Fri, 01/29/2010 - 14:22

No, Cisco's engineIDs are not RFC3411 compliant, but this is by design.  The sixth octet indicates whether or not the engine is an agent or manager engine.  A value of 0 indicates that the engine is acting as an agent where as a value of 1 indicates the engine is a manager.  The remaining six octets are the MAC address of the lowest numbered interface.

I don't know of any SNMP manager which would discard a packet which contains such an engineID.  As long as the engineID is unique per agent, managers should accept the value.

Actions

This Discussion