Default engine id and effect of engine id change - SNMP

This is a discussion on Default engine id and effect of engine id change - SNMP ; Hello, Is configuration of engine id a must? If engine id is not configured, what is the recommended default engine id? Default engine id can be constructed from either IP address or MAC address of the management interface. What's the ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Default engine id and effect of engine id change

  1. Default engine id and effect of engine id change

    Hello,

    Is configuration of engine id a must?

    If engine id is not configured, what is the recommended default engine
    id? Default engine id can be constructed from either IP address or
    MAC address of the management interface.

    What's the expected behaviour, when engine id is changed? Change of
    engine id invalidates the previously configured USM user keys.


    Thanks
    Prakash

  2. Re: Default engine id and effect of engine id change

    In article <1144d647.0310021455.362c4b02@posting.google.com>,
    pgpmh@yahoo.com says...
    > Hello,
    >
    > Is configuration of engine id a must?


    Engine IDs are expected to be "administratively unique." Meaning, within
    the full set of agents managed within some administrative domain (such as
    an enterprise network, an ISP, etc.) no two agents should have the same
    Engine ID. This is important for security:

    1. So that the individual [localized] keys used to manage each device are
    different even if the passphrase used to generate the [unlocalized] keys
    are the same for a given user with access to the agent.

    2. So that management applications can use the Engine ID as a key into
    its so-called "local configuration data store" which contains, for
    instance, the "local" notion of the agent's engineBoots and engineTime
    values for timeliness checking. If an NMS keys the LCD purely off of the
    Engine ID, and two agents were to have the same Engine ID, then the NMS
    would constantly be having to resync with each agent: an exchange of
    messages with one of the agents would cause it to no longer use the right
    boots/time values for the other agent.

    Engine IDs are expected to be unique when the agent is deployed on the
    network, usually through configuration, but different agents may provide
    defaults that the vendor has made somewhat unique already. Engine IDs
    are also expected to be changed whenever the engineBoots/engineTime
    values for the agent reach their maximum values, at which point they
    become locked and require administrative intervention. This happens
    after 2147483647 boots or about 68 years if the agent is never rebooted,
    so it's not something one typically needs to worry about, but an agent
    needs to provide a way to change it anyway, since it's possible that two
    different devices may have the same default.

    > If engine id is not configured, what is the recommended default engine
    > id? Default engine id can be constructed from either IP address or
    > MAC address of the management interface.


    The SnmpEngineID TEXTUAL-CONVENTION in RFC 2571 describes some suggested
    conventions for defining an Engine ID that is sufficiently unique. Some
    of the suggestions include things like the vendor's private enterprise
    number combined with IP or MAC addresses and additional bytes for further
    uniqueness.

    > What's the expected behaviour, when engine id is changed? Change of
    > engine id invalidates the previously configured USM user keys.


    Yes, the user keys are invalidated in the process because the agent will
    have no knowledge of the unlocalized keys of users created entirely via
    SNMP and the usmUserTable, and the users will need to be recreated.
    Changing the Engine ID is effectively the same as if you were installing
    a new device and configuring the Engine ID for the first time (though you
    probably won't have to reconfigure other things that aren't tied to the
    Engine ID -- i.e., not necessarily a full reset to factory defaults).

    --
    Michael Kirkham
    Muonics
    http://www.muonics.com/

+ Reply to Thread