Last Updated: March 5th, 1996, 11:00am CET
This article documents the results of my comparison of the SNMPv2* draft documents (Dec 1995) and the SNMPv2u RFCs (RFC1909-RFC1910, Feb 1996).
The main conclusion is that both designs provide the same functional solution to the same set of problems.
The SNMPv2* design claims to be better extensible in the future and to protect investments better by prescribing an ADMIN FRAMEWORK.
However, studying the SNMPv2* documentation, it is evident that more work needs to be done to cleanly separate the ADMIN FRAMEWORK and the authentication/security protocols. Besides, there is no reason to believe that the similar ADMIN FRAMEWORK that is kind of implied in SNMPv2u does not hold up against future extensions if this model is followed.
The SNMPv2u design currently is more mature, has real interoperable implementations (both academic and commercial), has been well documented as experimental RFCs, and has a very low cost of entry associated with it in terms of complexity, overhead on the wire, code size, and possibly resource requirements at agents.
At last, I come up with a recommendation to learn from both designs, to pick up the best ideas from each, to select a pragmatic and practical approach to the future, in short to work together to get us back into the standardization process for Secure SNMP.
I have spend a lot of time studying SNMPv2u. That was easy, as a member of the USEC design team, I was involved for 4 months in the refinement and improvement process. I also implemented the protocol both at the manager side and at the agent side.
I also studied the SNMPv2* draft documents version 01, as published in December 1995. Those of you who have followed the snmpv2star mailing list can witness that I indeed made a very serious effort to first of all understand the documents, but more importantly to also point out where (and sometimes how) things need to be fixed.
I have not compared (yet) all the implications of the differences in INFORM processing. The big difference is about which side (sender or receiver) is authoritative w.r.t. time information and snmpID (or agentID). I think that either way can be designed such that it works. But reading current design documentation, I do find the SNMPv2u approach much better to understand and so much easier to implement.
When we come to remote configuration, I also have not done the final comparison yet. First of all, the SNMPv2u only has very preliminary drafts for it, and the SNMPv2* version also seems far from complete or final. But I did browse through both draft MIBs enough to find that they easily become very complicated. The reason turns out to be that we ALL seem to be making the same mistake as we made before, namely that we want to create ONE all-encompassing SOLUTION for everything that then (for a great deal) gets forced onto even the smallest environments.
I bigger issue in my view is: "Which functionality is provided and at what complexity and at what cost?" And that is what I will concentrate on in this document.
When we come to remote configuration, I also have not done the final comparison yet. First of all, the SNMPv2u only has very preliminary drafts for it, and the SNMPv2* version also seems far from complete or final. But I did browse through both draft MIBs enough to find that they easily become very complicated. The reason turns out to be that we ALL seem to make the same mistake as we made before, namely that we want to create ONE all-encompassing SOLUTION for everything that then (for a great deal) gets forced onto even the smallest environments.
The good news is that I see lots of good things and lots of opportunity to build a solid case for new work within the IETF in the area of Secure SNMP. Please bear with me, and please do not get emotional. That is difficult at times for me too, but we can only succeed if we take emotions out of this debate and if we base our deliberations on sound technical grounds.
As I said in the introduction, I bigger issue in my view is: "Which functionality is provided and at what complexity and at what cost?" The conclusion I come to is that both current designs basically provide exactly the same functionality, namely: "A design for Secure SNMPv2 communication, providing MD5 authentication and DES privacy". Both designs protect against exactly the same security threats:
Although I could argue that the SNMPv2u design currently has a stronger security (localized keys, Keyed MD5, no indication on the wire as to which protocols are in effect), I feel that it would not be too difficult to crank up the SNMPv2* design to get to the same strength in security.
Lots of smaller differences can be streamlined or are not really essential (like names for objects, sizes of objects, etc).
The current design of SNMPv2* also sort of mandates that a remote configuration MIB be present at each managed entity, whereas the SNMPv2u design considers the whole remote configuration MIB as a separate topic that can be plugged in at will. On the SNMPv2* mailing list, but also verbally, quite a few people do agree that we should try and make the remote config MIB optional and so again, the 2 designs come very very close on this issue.
Both designs have come up with an initial remote configuration MIB. The SNMPv2* design wants this MIB to move along at the same time line as the definition of the protocols. The SNMPv2u design however went ahead and completed the protocols first and is now working on refining the remote configuration MIB.
In this respect, it is worth noting that within the IESG it is common practice that protocols get designed first, and that related MIBs (at PROPOSED status) are only required by the time that a protocol design is elevated to DRAFT status.
In terms of extensibility, it seems on the surface that the SNMPv2* has a better guarantee that a future extension will not overhaul the common ADMIN framework. It states clearly that the ADMIN FRAMEWORK should stay FIXED and that underlying authentication/security protocols can be replaced or expanded. It also prescribes what kind if input and output goes in and comes out of the authentication/security services.
However, the same concepts of the ADMIN FRAMEWORK do exist within SNMPv2u, albeit that they are more merged in a (what some call a more streamlined) writeup. So they are currently not as clearly separated, and certainly there is right now no explicit statement that they should never be changed.
But let us be fair. If in the future there is a need to change the ADMIN FRAMEWORK, then it will be changed, even though SNMPv2* states that such should not be done. Of course such a need will have to be very explicitly justified. And equally so, if technically competent people (we assume that such people work within the IETF, right?) are going to define a new authentication and/or privacy protocol analogue to the SNMPv2u design, then we can be assured that they will not change the ADMIN FRAMEWORK itself, unless they can come up with a good justification.
The big differences between the SNMPv2* and SNMPv2u designs are:
The SNMPv2* design is more complex. Since it tries to separate the ADMIN FRAMEWORK and the authentication and security protocols very rigidly, we end up with a "Elements of Procedure" that are spread over multiple documents, so you have to switch back and forth when trying to follow the process.
Then, there is more en/decoding to do because there are extra ADMIN wrappers around the protocol wrappers. As a result, there are more places where error conditions can occur and where error reports have to be generated.
SNMPv2* also still has the concept of maintenance functions, which turned out to be useless when refining the SNMPv2u design.
In SNMPv2u, the authoritative entity for notifications is always the sending entity. In SNMPv2*. one time it is the sender (for Traps) and another time it is the receiver (for Informs). The result of that is that both sides need an snmpID (same concept as agentID in SNMPv2u), and so in SNMPv2*, one needs to also use one snmpID in case of sending a Trap and another snmpID in case of sending an Inform. To me it seems much easier to make the same entity authoritative in all situations. In any event, I find the current SNMPv2u approach and the way it is documented far better to understand than the SNMPv2* approach.
The SNMPv2u packets are much simpler than the SNMPv2* packets. This not only results in less complexity, but also in smaller packet overhead (see next topic), so there is less to en/decode.
SNMPv2* design allows to have different authentication and security protocols for the same user. So one message can use a different protocol than the next and so on. This is kind of nice, but I wonder if this is really needed/wanted:
In terms of context naming, I also find the design writeup in
SNMPv2u much easier to understand than in SNMPv2*.
In SNMPv2*, the context is made globally unique using an snmpID.
In addition there seems to be a contextName (local name within
an snmpID) and a contextLocalEntityName which sort of duplicates
the contextName (but that is not clear to me yet).
Each entity also has a snmpID associated with the entity itself,
and this id must also be passed as part of the authInfo.
So each SNMP packet carries the authSnmpID and the contextSnmpID
which in most cases is exactly the same, so duplication of data
on the wire is the result.
In SNMPv2u at the other hand, each context has a contextSelector
(same concept as contextName) which is locally defined within
the SNMP entity. The context is made unique by concatenating
the agentID (same concept as authSnmpID) with the contextSelector.
When comparing the "Elements of Procedure", I found that the SNMPv2* approach requires some 13 pages while SNMPv2u only needs 8 pages. In these procedures, there is a lot of error counting and in many cases sending or reportPDUs. The SNMPv2* procedure has both more counters and as a result has many more points in the procedures where counters have to be incremented and where reportPDUs have to be sent. This is not because SNMPv2* has more detail or better procedure, but because SNMPv2* has a more complex structure and thus has more opportunity for error, and thus needs more error checking and error reporting.
As another observation, we can compare number of pages for the documentation. The (now historic) SNMPv2 Party model needed 148 pages. The draft SNMPv2 Party model plus SCM even needed 198 pages. The SCM introduced the user/password concept, which was great and made it easy to explain the surface of Secure SNMPv2. But it added a lot of complexity under the covers. With SNMPv2* we see some 110 pages of documentation, while the SNMPv2u RFCs comprise only 63 pages of documentation. Both counts do not include remote config MIB definitions (by the way, the current drafts for each are approximately the same size). The reason for some 75% more documentation is not that SNMPv2* is so much better documented or in so much more detail (last week it was more to the contrary, but this can and will of course be improved, I am trying to contribute to the improvements). It is also not because of the fact that the current SNMPv2* provides any better authentication or privacy. No the reason is that there are so many extra features and options to allow for a so called easier and better-guided extensibility in the future. None of these options is really required. To name some:
See appendix A for detailed numbers.
To compare the overhead on the wire I have compared the packet size for an SNMP GET request for sysDescr.0. For SNMPv1 and SNMPv2c we use a community name of public. For SNMPv2* and SNMPv2u we use a userName of public and a contextName of "a" (contextName must be at least 1 octet in SNMPv2*) or a contextSelector of the empty string "". Again for reference, I am adding the numbers for SNMPv2p (the now historic SNMPv2 Party model). We use the initial parties/contexts for SNMPv2p.
The data itself (i.e. the PDU) is 32 octets long, including the Sequence/Length fields that the PDU starts with.
The numbers that I found were all from traces of real packets on the wire, except for the SNMPv2* packets which I have manually calculated. The lengths are just the SNMP messages, so there is no length included for UDP headers etc.
Protocol Community noAuth MD5 MD5/DES ============ ========== ========= ========== ============ SNMPv1 40 -- -- -- SNMPv2c 40 -- -- -- SNMPv2u -- 66 82 89 SNMPv2* -- 90 106-112 113-119 SNMPv2p -- 97 127 129+
The ranges for SNMPv2* depend on the value of agentBoots and agentTime. If the values for those are between 0-127 inclusive, then you get the smaller number. The closer they get to the maximum values then closer you get to the larger number in the range.
This actually shows that the overhead on the wire is pretty serious for Secure SNMPv2 in general. Even the shortest packet (SNMPv2u with MD5 authentication only) we basically double the packet size. If we look at just the header (so exclude the PDU), then we see that header consumes:
This I cannot yet fully compare, because so far I have only implemented SNMPv2u (well I also did original SNMPv2p and SCM, but that is history).
I do know from experience that implementing SNMPv2u is pretty straight forward... and you have seen other implementation reports that claim the same.
I do know that it took me quite a while to just try and grasp what exactly is needed for SNMPv2*. And while doing that I did find that the documents need a lot of work. But fair is fair, the initial SNMPv2u documents needed a lot of work too, and that has cost me quite some time over the last 4 months too. So when comparing, I will assume that by the time that one starts to work on an implementation, that by then the SNMPv2* documents will be a crisp as the current SNMPv2u RFCs.
I have gone to the point where I can write down the hexadecimal content of an SNMPv2* packet. For that I had to dig through all of the documentation several times, and I claim that I have a fairly good understanding of what needs to be done to do an implementation. To me it seems it will be more costly than SNMPv2u in terms of:
The SNMPv2u RFCs are in very good shape as the result of a 4-month effort by the USEC-design team. We were not only focused on writing paper, but also writing interoperable code. Two of us did that for academic purposes (and this code is publicly available). The other two did that in order to ship product code that exploits the protocol. The interoperability testing and the preparation for a demo of the four implementations during ComNet 96, helped us to stay focused and to improve and at the same time simplify the original proposal.
The SNMPv2* still has a long way to go. I would certainly recommend that SNMPv2* picks up the improvements that were made to the SNMPv2u design. I would also recommend that SNMPv2* figures out a way so that the remote configuration MIB will not imply such high cost on low end systems. Again, to be fair, this challenge also exists for the design of a remote configuration MIB for SNMPv2u.
For all I know, there have not been any interoperability demos or tests for SNMPv2* (but I may not know everything). However, I find it hard to believe that on the basis of the current documents one could develop such interoperable implementations. That will require a lot of e-mailing or other meetings.
While doing the comparison between SNMPv2* and SNMPv2u, it occurred to me that we have 2 areas which are probably for 90% responsible for the complexity in both protocols. And these are indeed the concepts of proxy-agents and the Trap/Inform (notification) processing.
For the notification processing there are 2 issues that make it complex, namely the access control on outgoing Traps/Informs and the issue of who is authoritative for Informs. The latter issue is well covered in SNMPv2u and has been solved (in my view) with an acceptable (pretty low) level of complexity. The former issue needs some more work and thinking. See below.
This is a step backwards. Sit and think. Barry Sheehan asked me this question a little while ago. And indeed one can wonder, specifically with the more strict definition of PROXY in both SNMPv2u and SNMPv2*.
It seems to me that this is the (kind of useful) functionality that can be provided by a Proxy Agent:
I find that we are adding complexity (in both designs) because of PROXY operations, and one sometimes wonders if that is all justified.
To give you some figures, I checked both the SNMPv2u and SNMPv2* documents. Here are some numbers:
My conclusion is we do not need to include the Proxy Agent approach in all the elements of procedure and/or in a common remote configuration MIB. We can make things much simpler for the masses if we consider Proxy Agents a special case.
To me it seems that we are introducing a lot of complexity for a (in my view) very simple thing like a trap/inform destination table. Why do we think that we really need access control on traps and informs. I still can't grasp that. The destinations are configured either at the agent, or by a manager who has SET privileges to at least some sort of notifyAddressTable, but then most probably also to things like accessTable, userTable, viewTable etc. So the manager can control whatever he wants to get anyway.
So it then seems to me that the access control is basically used for filtering purposes. Did we not say years ago that that filtering services in CMIP agents was a bad idea with needless complexity? Why cannot the manager filter it when it gets to the manager?
We already all agree that traps and informs should not be generously used, but with caution. So there should not be that much to filter anyway.
My conclusion is we do not need access control on outgoing Traps and Informs. And so we can simplify the process.
After careful study of both designs, I come to the conclusion that SNMPv2u is the best base to try and build on. We can do that such that we can come to a good and solid design for Secure SNMPv2 communication. The design is very well documented in RFC1909 and RFC1910 (experimental RFCs) and anyone can implement it at very low cost.
If we look at the real important problems in SNMP, then I strongly believe that these are the top 3, in order of importance:
The priority number one problem is solved by SNMPv2u. And if you look at it, you will see that this alone basically solves 80% of the problems of SNMPv1/SNMPv2c for 20% of the cost of earlier designs. Even compared to SNMPv2*, the ratio is still solving 80% of the problem, but maybe for 30% of the cost as opposed to only 20% of the cost.
The priority number two problem needs to be fixed next.
I firmly believe that we should not prescribe an ADMIN FRAMEWORK,
that is fixed forever. If future designers see a justified need
to change it, they will, and they should be allowed to.
I am also convinced though, that we can guide any future protocol
designers in the correct direction if we try to include the
ADMIN FRAMEWORK concepts from SNMPv2* when designing a remote
configuration MIB. If we do that correctly, then we achieve the same
goal as what a rigid ADMIN FRAMEWORK intends to achieve, but without
fixating it forever.
With regard to the cost of entry, I have also come to the conclusion
that specifically the remote configuration MIB can easily raise the
cost of entry several orders of magnitude. And the reason that I see
is that the current draft designs all seem to try and define one
all encompassing MIB with various layers of conformance so that
low end SNMP entities do not have to implement everything. In some
cases these designs allow for low end systems to implement a lot
of MIB objects in readOnly mode.
When I sat back and thought about it, I found that we introduce most
of the complexity and high cost of entry because indeed we try to
come up with one grand MIB for everybody. And in reality, we see
three different management entities that need remote configuration:
Although I can see that in terms of object definitions we may end up with some duplicate functionality, in practice when implemented, such duplication only exists at managers who will have to recognize the different types of MIBs and act accordingly. But the agents and proxy-agents I think will not be hit with duplication. And we have always lauded the phrase: "keep the agent simple and move the complexity to the manager". We MUST keep that in mind at all times.
The priority number three problem comes as part of the solution for the number one problem. So from a design point of view we're done. However, it is still problematic since a good protocol for privacy (like DES) causes trouble in terms of exportability. Luckily enough, we see that the exploitation the design is not such a high priority, and yet, for those who need it, the design is in place and they can come up with products that fill the gap.
V2* ADMIN 57 pages
USEC 57 pages
PROTO 3 pages (V2* has a modified PROTO doc of
which 3 pages are V2* specific)
==================
total 117 pages
USECMIB 7 pages (V2U has this in config-mib)
=================
total 110 pages
V2u ADMIN draft 23 pages RFC1909 19 pages
USEC draft 55 pages RFC1910 44 pages
===============================================
Total 78 pages 63 pages
So V2* extra overhead is 32 or 47 pages (41% or 74%)
V2p RFC1446 (admin) 47 pages
RFC1447 (sec) 51 pages
RFC1448 (needed with pmodel) 50 pages
=====================================
total 148 pages
May Draft Admin 55 pages
May Draft Security 47 pages
May Draft PartyMIB 48 pages
May Draft SCM 48 pages
=====================================
total 198 pages
I am using a snmp GET for sysDescr.0, using community name public for V1 and V2c and using userName public for V2* and V2u and I am using initial parties/contexts for v2p (old party model).
v1 40 v2c 40 v2u noAuth 66 v2u MD5 82 v2u MD5/DES 89 v2* noAuth 90 v2* MD5 106-112 v2* MD5/DES 113-119 v2p noAuth 97 v2p MD5 127 v2p MD5/DES 127-130
See below for detailed hexadecimal dumps for the packets.
Little bit difficult to compare, but I tried to do it very accurately. Nevertheless it is not 100% accurate because sometimes counting and report generation is sort of implicit without being specifically stated, and so I may have missed some of these. But in general, I think am very close to the actual numbers.
v2u has 10 counters, 7 are usec, 3 are v2. v2* has 12 or 13 counters, 4 or 5 are usec, 5 are admin, 3 are v2. For a received communication: v2u generates a reportPDU at 14 points in the elements of proc. v2* generates a reportPDU at 22 or 23 points in the elements or proc. v2u counts at 17 points in the elements of proc v2* counts at 27 or 29 points in the elements of proc v2u has 3 places where report generation is specific to PROXY only v2* has 8 places where report generation is specific to PROXY only (so one might think that they do a better job, but I doubt that).
Again, I tried to be accurate, but I needed to count like half pages, some sentences and such. But these numbers reflect the reality pretty well I think.
v2u needs 8 pages to describe it v2* needs 13 pages to describe it
For each version (except for the historic Party model) I am giving a detailed example of a SNMP message/packet. I have used simple values like 0 for the ...Boots value and 1 for the ...Time value. I have also set the agentID or snmpID to all hex zeroes, whatever the value, it is always 12 octets.
This is a packet for GET sysDescr.0 with community name public for SNMpv1. Packet was traced on the wire.
30 26 02 01 00 04 06 70 75 62 6c 69 63 a0 19 02 01 02 02 01 00 02 01 00 30 0e 30 0c 06 08 2b 06 01 02 01 01 01 00 05 00 In detail: 30 26 Seq of length 0x26 02 01 00 Version 1 04 06 70 75 62 6c 69 63 Community public a0 19 02 01 02 02 01 00 02 01 00 30 0e 30 GET for sysSecr.0 0c 06 08 2b 06 01 02 01 01 01 00 05 00
This is a packet for GET sysDescr.0 with community name public for SNMpv2c. Packet was traced on the wire.
30 26 02 01 01 04 06 70 75 62 6c 69 63 a0 19 02 01 02 02 01 00 02 01 00 30 0e 30 0c 06 08 2b 06 01 02 01 01 01 00 05 00 In detail: 30 26 Seq of length 0x26 02 01 01 Version 2c 04 06 70 75 62 6c 69 63 Community public a0 19 02 01 02 02 01 00 02 01 00 30 0e 30 GET for sysSecr.0 0c 06 08 2b 06 01 02 01 01 01 00 05 00
This is a packet for GET sysDescr.0 with MD5 authentication for SNMpv2* (my composition). I am using all zeroes for the authSnmpID and the contextSnmpID, both always have a length of 12 octets. I am also using all zeroes for the digest value, which always has a length of 16 octets (for MD5).
30 68 02 01 02 02 02 01 e4 02 01 0d a9 5c a9 2e 04 0c 00 00 00 00 00 00 00 00 00 00 00 00 04 06 70 75 62 6c 69 63 02 01 00 02 01 01 04 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 0c 00 00 00 00 00 00 00 00 00 00 00 00 04 01 61 a0 19 02 01 02 02 01 00 02 01 00 30 0e 30 0c 06 08 2b 06 01 02 01 01 01 00 05 00 Details: 30 68 Seq of length 0x68 02 01 02 Version 2 02 02 01 e4 mms 484 02 01 0d sPI usecAuth a9 5c SnmpV2AuthMsg length 0x5c a9 2e AuthInfo length 0x2e 04 0c 00 00 00 00 00 00 00 00 00 00 00 00 snmpAuthID 04 06 70 75 62 6c 69 63 userName public 02 01 00 snmpAuthBoots is 0 02 01 01 snmpAuthTime is 1 04 10 00 00 00 00 00 00 00 00 00 00 00 00 MD5 digest 00 00 00 00 04 0c 00 00 00 00 00 00 00 00 00 00 00 00 snmpContextID 04 01 61 contextName "a" a0 19 02 01 02 02 01 00 02 01 00 30 0e 30 GET PDU for sysDescr.0 0c 06 08 2b 06 01 02 01 01 01 00 05 00
This is a packet for GET sysDescr.0 without authentication for SNMpv2* (my composition) I am using all zeroes for the authSnmpID and the contextSnmpID, both always have a length of 12 octets.
30 58 02 01 02 02 02 01 e4 02 01 0d a9 4c a9 1e 04 0c 00 00 00 00 00 00 00 00 00 00 00 00 04 06 70 75 62 6c 69 63 02 01 00 02 01 01 04 00 04 0c 00 00 00 00 00 00 00 00 00 00 00 00 04 01 61 a0 19 02 01 02 02 01 00 02 01 00 30 0e 30 0c 06 08 2b 06 01 02 01 01 01 00 05 00 Details: 30 58 Seq of length 0x58 02 01 02 Version 2 02 02 01 e4 mms 484 02 01 09 sPI usecNoAuth a9 4c SnmpV2AuthMsg length 0x4c a9 1e AuthInfo length 0x1e 04 0c 00 00 00 00 00 00 00 00 00 00 00 00 snmpAuthID 04 06 70 75 62 6c 69 63 userName public 02 01 00 snmpAuthBoots is 0 02 01 01 snmpAuthTime is 1 04 00 zero length for Digest 04 0c 00 00 00 00 00 00 00 00 00 00 00 00 snmpContextID 04 01 61 contextName "a" a0 19 02 01 02 02 01 00 02 01 00 30 0e 30 GET PDU for sysDescr.0 0c 06 08 2b 06 01 02 01 01 01 00 05 00
This is a packet for GET sysDescr.0 with MD5 authentication for SNMpv2u (traced on the wire). I am showing all zeroes for the agentID (always 12 octets long) which is the value during discovery. I am showing a real Keyed MD5 digest value.
30 50 02 01 02 04 30 01 05 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 01 e4 06
70 75 62 6c 69 63 10 a0 06 51 0f d4 37 3c d4 26
6a 54 84 88 e3 59 fa a0 19 02 01 02 02 01 00 02
01 00 30 0e 30 0c 06 08 2b 06 01 02 01 01 01 00
05 00
In detail:
30 50 Seq of length 0x50
02 01 02 Version 2
04 30 Parameters length 0x30
01 05 Model 1, authenticated
00 00 00 00 00 00 00 00 00 00 00 00 agentID
00 00 00 00 agentBoots is 0
00 00 00 01 agentTime is 1
01 e4 mms 484
06 70 75 62 6c 69 63 userName public
10 a0 06 51 0f d4 37 3c d4 26 6a 54 84 88 Keyed MD5 digest
e3 59 fa
Empty "" contextSelector
a0 19 02 01 02 02 01 00 02 01 00 30 0e 30 GET PDU for sysDescr.0
0c 06 08 2b 06 01 02 01 01 01 00 05 00
This is a packet for GET sysDescr.0 with no authentication for SNMpv2u (traced on the wire). I am showing all zeroes for the agentID (always 12 octets long) which is the value during discovery.
30 40 02 01 02 04 20 01 04 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 01 e4 06
70 75 62 6c 69 63 00 a0 19 02 01 02 02 01 00 02
01 00 30 0e 30 0c 06 08 2b 06 01 02 01 01 01 00
05 00
In detail:
30 40 Seq of length 0x40
02 01 02 Version 2
04 20 Parameters length 0x30
01 01 Model 1, noAuth
00 00 00 00 00 00 00 00 00 00 00 00 agentID
00 00 00 00 agentBoots is 0
00 00 00 01 agentTime is 1
01 e4 mms 484
06 70 75 62 6c 69 63 userName public
00 Zero length for digest
Empty "" contextSelector
a0 19 02 01 02 02 01 00 02 01 00 30 0e 30 GET PDU for sysDescr.0
0c 06 08 2b 06 01 02 01 01 01 00 05 00
Although I have a lot of information from many sources, I'd like to extend extra thanks to two individuals for their patience and their answers to my questions: