Staging plans to remove network IPMI support?

[Vernon Mauery]

On 18-Sep-2019 04:34 PM, Joseph Reynolds wrote:
> Re-sending to fix up formatting error:
> 
> The OpenBMC security working group discussed a desire to remove out-of-band
> network IPMI support from the OpenBMC firmware stack, here:
> https://lists.ozlabs.org/pipermail/openbmc/2019-September/018319.html
> 
> This would affect out-of-band (network IPMI) only, in repository
> https://github.com/openbmc/phosphor-net-ipmid. The host IPMI support is
> a separate topic.
> 
> The *main idea* is a staging plan to remove network IPMI support over a
> period of years, like in this progression:

This may be a year 3030 topic; I would not worry too much about it for 
now. By the time RMCP+ is gone, BMCs may not even be a thing anymore :)

But in all seriousness, telnet and rlogin stayed on for YEARS beyond 
their welcome. It will be a difficult task to wean users off RMCP+. It 
is so easy to use and we are all used to it. Redfish is so complicated 
and we don't have the tooling to make it work as smoothly as RMCP+.

Basically what I am saying is that we need buy-in from the end users. So 
far, for all its wonder and glory, Redfish really has been a hard sell. 
For all the warts and flaws of RMCP+ over IPMI, people *need* it. People 
are not rational and do not make security decisions based on logic.

> 1. Tell everyone the plans at each stage below. For example: emails to the
> group, mention in the release notes, update
> https://github.com/openbmc/phosphor-net-ipmid/blob/master/README.md and the
> ipmitool repo.

We can certainly add something to the README, but we do need to set some 
expectations on how much people actually read documentation. Adding 
something there will not have nearly as much effect as putting a big red 
banner on the bmcweb console that says "IPMI over RMCP+ is enabled and 
is insecure. You might consider disabling it and using the Redfish 
protocol instead"

OpenBMC does not own the ipmitool project (or any of the other 
opensource utilities that speak RMCP+), so we will need to reach out. It 
turns out that the ipmitool maintainer is a member of the OpenBMC 
community, so we can hopefully leverage that relationship.

> 2. Implement the Redfish ManagerNetworkProtocol - defined in the DMTF
> Redfish Resource and Schema Guide DSP2046 https://www.dmtf.org/dsp/DSP2046. 
> This gives the BMC admin an interface to disable out-of-band network
> IPMI.That means stopping the IPMI network service and closing its port.

I keep hearing stories about redfish not being united and common enough 
to be useful. Does the spec need to grow or do we just need to make sure 
that it is always implemented according to the spec?

> 3. Change the IPMI ManagerNetworkProtocol setting to be disabled by
> default.  After this, BMC admins have to take an explicit action to enable
> IPMI access.

I would hope that long before we disable netipmid by default, Redfish 
would be the main mechanism for accessing the BMC. 

> By this point it should be possible to learn how to migrate from
> IPMI to Redfish APIs.

No, people should be learning how to migrate from IPMI to Redfish right 
now, long before we attempt to disable RMCP+/IPMI by default.

> 4. Remove IPMI from the default OpenBMC configuration. This means network
> IPMI is not built into the BMC firmware image. After this, project who want
> to use network IPMI will have to explicitly add it to their image. This will
> hopefully be a wake-up call to anyone who is still using network IPMI.

I think this step could be moved up. Not every OEM user of OpenBMC wants 
to include netipmid in their builds today. Adding a package to an image 
is just as easy as removing it. We could make it NOT part of the image 
by default and require all OEMs that want it to add it to their image.

> 5. Remove all references to network IPMI from OpenBMC.

I am not sure this is ever necessary. This is not a nanny state. If 
someone wants openBMC to have insecure packages on their builds, that is 
up to them. We can disable the package by default, but I think that is 
as far as we need to go.

--Vernon