Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 22 Jun 2015 04:57:54 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-opsawg-vmm-mib-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I found the SecDir review to be interesting, raising a point of
clarification specific to this draft and not the agreed boilerplate text.
 Since there was confusion by the reader as to the access possibilities
and where this mib is used, I think it's worth adding a sentence with the
clarifying point from the discussion.  How about:

This MIB module is typically implemented on the hypervisor not inside a
virtual machine.  Virtual machines, possibly under other administrative
domains, would not have access to this mib as the SNMP service would
typically operate in a separate management network.

https://www.ietf.org/mail-archive/web/secdir/current/msg05705.html 
https://www.ietf.org/mail-archive/web/secdir/current/msg05706.html

The suggested text, or something similar might fit into the introduction
to limit the scope or after paragraph 2 in Section 3.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 22 Jun 2015 19:19:41 +0000

Anything more specific regarding what the potential issues are? ‎Besides "adding an ‎interface adds an attack surface"?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Michael MacFaden‎
Sent: Monday, June 22, 2015 15:09
To: Kathleen Moriarty; The IESG; Randy Presuhn
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)

Agree there should be some warning here. But if this text is intended for those who implement it
(like me) then I'd prefer to make it clear as mud what the issue is:

Any implementation of this MIB module in an agent where the Virtual Machines being monitored 
have access to this very agent or this MIB module creates an attack vector on the system or on
any other VM hosted by this system. 

Mike MacFaden

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 22 Jun 2015 14:00:58 -0700 (GMT-07:00)

Hi -

>From: Kathleen Moriarty
>Sent: Jun 22, 2015 1:23 PM
>To: Randy Presuhn
>Cc: The IESG , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
>On Mon, Jun 22, 2015 at 4:18 PM, Randy Presuhn >> wrote:
>
>> Hi -
>>
>> >From: Kathleen Moriarty
>> >Sent: Jun 22, 2015 12:49 PM
>> >To: Randy Presuhn
>> >Cc: The IESG , "
>> [email-masked]" <
>> [email-masked]>, "
>> [email-masked]" ,
>> "[email-masked]" , "[email-masked]" <
>> [email-masked]>, "[email-masked]" <
>> [email-masked]>
>> >Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on
>> draft-ietf-opsawg-vmm-mib-03: (with COMMENT)
>> >
>> >Hi,
>> >
>> >Sent from my iPhone
>> >
>> >> On Jun 22, 2015, at 6:58 PM, Randy Presuhn <
>> [email-masked]> wrote:
>> >>
>> >> Hi -
>> >>
>> >>> From: Kathleen Moriarty
>> >>> Sent: Jun 22, 2015 4:57 AM
>> >>> To: The IESG
>> >>> Cc: [email-masked],
>> [email-masked], [email-masked],
>> [email-masked], [email-masked]
>> >>> Subject: [OPSAWG] Kathleen Moriarty's No Objection on
>> draft-ietf-opsawg-vmm-mib-03: (with COMMENT)
>> >> ...
>> >> If I understand the concern correctly, I'd suggest this text as
>> >> an alternative.
>> >>
>> >> Instrumentation for this MIB module is typically implemented
>> >> within the hypervisor for two reasons. First, that is where
>> >> the necessary information is most readily available. Second,
>> >> because individual virtual machines can be under other
>> >> administrative domains and are thus not necessarily trusted
>> >> by the hypervisor, there is no assurance that a given virtual
>> >> machine will even contain supporting instrumentation,
>> >> much less make it available in a trustworthy manner.
>> >>
>> >This text is close to what I was looking for, thanks. It doesn't
>> >explicitly say that the managed virtual machines would not have
>> >access to the SNMP management interface clearly it just says they
>> >aren't trusted. Some recommendation would be helpful.
>>
>> I guess what I'm missing here is that I don't see how a managed
>> virtual machine is different from any other managed resource.
>> Whether a given managed virtual machine has been granted access
>> (via VACM) and has the necessary network connectivity to reach
>> the SNMP engine is a question of what that virtual machine is
>> supposed to do and of security/administrative policy. For example,
>> if that VM is hosting implementations of some of the distributed
>> management MIB modules, it would be perfectly reasonable for
>> an entity running on it to be an authorized user granted access
>> by VACM to this MIB module. If, on the other hand, that VM hosts
>> malware for observation purposes, one would probably not allow it to
>> monitor or configure the hypervisor, and might choose to severely
>> limit its connectivity. I don't see how this is substantially
>> different from any other managed application.
>>
> There would be a management connection to the virtual machine. Apparently
>(from a response to the SecDir review previously provided), the management
>channel is separate for SNMP to the hypervisor. That wasn't readily
>apparent to the SecDir reviewer or me. You shouldn't be able to use the
>management channel back from the virtual machine to the hypervisor to
>exploit the access possible via this mib. Some text to explain this is
>helpful.

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 certainly level of trust that the subagent will
respond truthfully to get/set, etc.
(b) instrumentation can be built into processes 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 that 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 learns 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