[AGENT++] Response to wrong snmpEngineId

[Jochen Katz]

Hi,

> Accordingly to RFC3414, ch. 3.2, 3) the agent should return a
> REPORT-PDU containing the varbind usmUnknownEngineId.
> As far as I've analyzed the code this does not happen. There are (at
> least) two places where the engineId is checked.
> One is in USM::process_msg where usm_time_table->check_time() is
> called. Surprisingly for me, this method succeeds.

possibly the USM is in discovery mode, so it accepts all engine ids.
But what I really want to know: Why does the manager send a message with
a wrong engine id?

> The second check of the engineId is done in v3MP::snmp_parse

> ...
>       if (!(unsignedCharCompare(securityEngineID.data(),
securityEngineID.len(),
>                                 own_engine_id, own_engine_id_len))) {
>         debugprintf(0, "snmp_parse: securityEngineID doesn't match
own_engine_id.");
>         usm->delete_sec_state_reference(securityStateReference);
>         return SNMPv3_MP_MATCH_ERROR;
> ...

> But this check seems only to force the PDU to be discarded, but
> without sending a REPORT.

This is because of rfc 3412 page 36/37:
   13) If the pduType is from the Confirmed Class, then:

       a) If the value of securityEngineID is not equal to the value of
          snmpEngineID, then the security state information is
          discarded, any cached information about this message is
          discarded, the incoming message is discarded without further
          processing, and a FAILURE result is returned.  SNMPv3 Message
          Processing is complete.

Looking at the USM rfc 3414 pages 27:
   3)  If the value of the msgAuthoritativeEngineID field in the
       securityParameters is unknown then:

       a) a non-authoritative SNMP engine that performs discovery may
          optionally create a new entry in its Local Configuration
          Datastore (LCD) and continue processing;

          or

       b) the usmStatsUnknownEngineIDs counter is incremented, and an
          error indication (unknownEngineID) together with the OID and
          value of the incremented counter is returned to the calling
          module.

       Note in the event that a zero-length, or other illegally sized
       msgAuthoritativeEngineID is received, b) should be chosen to
       facilitate engineID discovery.  Otherwise the choice between a)
       and b) is an implementation issue.

The decission between a) and b) is impossible at this time because the
entity does not know the pdu type and so cannot decide if the entity is
authoritative or not. snmp++ currently uses only the flag discovery-mode
to decide.

Regards,
  Jochen