Ethereal-dev: Re: [ethereal-dev] packet-snmp.c patch to handle zero length context names
>>>>> Guy Harris writes:
>> There is some confusion here. The community based security model
>> is not used with the SNMPv3 message format.
Guy> ...but the SNMP dissector checks for SNMP_SEC_V1 and SNMP_SEC_V2C
Guy> in the code after
Guy> case SNMP_VERSION_3:
Guy> that checks the SNMP version number in the SNMP packet, which I
Guy> infer means either that
Guy> 1) the values "reserved for SNMPv1" and "reserved for SNMPv2c"
Guy> *are* used with the SNMPv3 message format, and the format of the
Guy> msgSecurityParameters field in SNMPv3 packets when those
Guy> "reserved" values are used is documented somewhere
Guy> or
Guy> 2) the SNMPv3 dissection code should just treat the
Guy> msgSecurityParameters field as opaque hex data.
The version number is the first element in every SNMP message. So you
first decode the version number and based on its value, you either
decode an SNMPv1/SNMPv2c or an SNMPv3 message. In other words, the
SNMPv3 message format always uses the version number 3. This is
clearly specified in RFC 2572 section 6.1:
: 6.1. msgVersion
:
: The msgVersion field is set to snmpv3(3) and identifies the message
: as an SNMP version 3 Message.
Guy> Section 5.2.1 says of RFC 2576 says:
Guy> 5.2.1. Processing An Incoming Request
Guy> In RFC1157 [2], section 4.1, item (3) for an entity which
Guy> receives a message, states that various parameters are passed to
Guy> the 'desired authentication scheme.' The desired authentication
Guy> scheme in this case is the SNMPv1 Community-Based Security Model,
Guy> which will be called using the processIncomingMsg ASI. The
Guy> parameters passed to this ASI are:
Guy> - The messageProcessingModel, which will be 0 (or 1 for
Guy> SNMPv2c).
Guy> - The maxMessageSize, which should be the maximum size
Guy> of a message that the receiving entity can generate (since there
Guy> is no such value in the received message).
Guy> - The securityParameters, which consist of the community
Guy> string and the message's source and destination transport domains
Guy> and addresses.
Guy> - The securityModel, which will be 1 (or 2 for SNMPv2c).
Guy> - The securityLevel, which will be noAuthNoPriv.
Guy> - The wholeMsg and wholeMsgLength.
This text is just fine as it describes how you pass a SNMPv1/SNMPv2c
message through the generic SNMP architecture.
Guy> although I don't know whether that section is discussing the way
Guy> incoming SNMPv1 or v2c packets are to be processed by a server
Guy> (which would suggest that 2) is true), or is also discussing the
Guy> way in which the "reserved for SNMPv1" and "reserved for SNMPv2c"
Guy> values are to be handled in incoming SNMPv3 packets (which would
Guy> suggest that 1) is true and that the msgSecurityParameters field
Guy> contains the community string - if "the message's source and
Guy> destination transport domains and addresses" are just obtained
Guy> from the transport-layer and network-layer headers for the
Guy> packet).
For SNMPv3 messages, there currently only exists the user-based
security model. There is no value in encoding community strings in an
SNMPv3 message. If you want to use SNMPv3 without strong security,
than you use noAuth/noPriv USM and you split the community string into
the user name and the context name.
The TC definition of SnmpMessageProcessingModel in RFC 2571 is really
just a mechanism to fit SNMPv1 and SNMPv2c into the architecture so
that infrastructure MIBs (e.g. the target and notification forwarding
MIBs) work with any version of SNMP. Trust me, there is no community
based SNMPv3.
/js
--
Juergen Schoenwaelder Technical University Braunschweig
<schoenw@xxxxxxxxxxxxxxx> Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
