Hi -
ARRGH! I apologize for sending a blast of HTML gobbledygook.
Here's what I intended to say:
Sorry, I don't mean to be dense, but I can't provide text to
explain this because this rationale doesn't make any sense to
me at all. I still don't see how monitoring a not-necessarily-
trusted VM is in any way different from monitoring any other
not-necessarily-trusted resource. Let me explain why this
makes no sense to me.
There are about two-and-a-half strategies for connecting MIB
module instrumentation to SNMP engines:
(1) build the instrumentation into the same process as the
SNMP engine. Straightforward, but becomes a software
configuration management nightmare.
(2) use a mechanism such as AgentX to handle the chit-chat
between the master agent (home to the SNMP engine) and
subagents
(a) instrumentation can be built directly into the resources,
implying a certain level of trust that the subagent will
respond truthfully to get/set, etc.
(b) instrumentation can be built into processes which in turn
monitor the resources by other means. This is useful
when, for example, one does not have control of the
source code for the resource.
2(b) would IMO be the obvious preferred choice for implementing
this MIB module.
If one uses AgentX as the implementation technology, the protocol
provides the subagent no means of access to other information known
to the master agent. A malicious subagent (one which impersonates
another) is conceivable, but even a malicious subagent doesn't gain
access to existing management information of the subagent it is
impersonating - it only sees subsequent configuration requests
and what it can glean from index values present in get/getnext/bulk
requests.
None of this is specific to management of VMs.
If someone uses some homebrew mechanism in place of AgentX,
all bets are off until there's been an analysis of that
mechanism. Again, however, this is true whether VMs are in
the picture or not.
Randy
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
