BMC & DMTF Redfish Standards
From IPMI Legacy to RESTful Resource Modeling
The Challenge: Legacy Protocol Limitations
The Baseboard Management Controller (BMC) functions as the primary out-of-band management interface for server hardware. For decades, the Intelligent Platform Management Interface (IPMI) has been the de facto standard for BMC communication. However, IPMI's fundamental architecture creates significant challenges for modern hyperscale operations.
Observation: Buffer overflow in legacy IPMI stack implementations across multiple vendor BMC firmware versions.
Recommendation: Immediate transition to SPDM-based hardware attestation and disabling of unencrypted IPMI 2.0 channels. Deploy Redfish-only management interfaces where supported.
IPMI Security Issues
- No encryption by default (IPMI 1.5/2.0)
- Weak authentication mechanisms
- Known cipher-zero vulnerability
- Cleartext password transmission
- No certificate-based authentication
Redfish Advantages
- RESTful API with JSON payloads
- TLS/HTTPS encryption by default
- OAuth2/OpenID Connect support
- Standardized schema definitions
- SSE/gRPC for real-time telemetry
Neocloud Pain Points
Redfish Implementation Variance
While Redfish provides a standard schema, vendor implementations diverge significantly. Dell iDRAC implements Redfish 1.17, HPE iLO uses 1.10, and Supermicro BMC supports 1.12. These differences in API behavior, supported resources, and extension OEMs force operators to maintain vendor-specific adapters despite using a "standard" API.
TLS 1.3 Resource Overhead
Legacy BMC processors (25MHz-512MB RAM class) struggle with modern TLS 1.3 cryptographic overhead. This creates a tradeoff between security compliance and telemetry performance, particularly for sub-second monitoring requirements of GPU thermal management.
Firmware SBOM Verification
Software Bill of Materials (SBOM) verification at the silicon level remains a critical gap. Without automated SBOM validation, operators cannot verify firmware integrity across their fleet, creating supply chain security risks that are particularly acute for AI infrastructure handling sensitive workloads.
Event Subscription Scalability
Redfish SSE (Server-Sent Events) subscriptions do not scale well beyond a few hundred connections. For operators managing 10,000+ node clusters, this requires architectural workarounds including polling hierarchies or custom aggregation layers.
Relevant OCP Workstreams
The following OCP projects and sub-projects are actively working on specifications and contributions that address the challenges outlined in this research.
Hardware Management
Developing standardized BMC interfaces and management protocols that build on Redfish while addressing hyperscale requirements.
Security (S.A.F.E. Program)
Establishing security requirements for hardware attestation, including SPDM integration, secure boot chains, and firmware verification.
Standards Compliance Matrix
| Standard | Version | Scope | OCP Alignment |
|---|---|---|---|
| Redfish v1.x | 1.18+ | RESTful resource management | Required |
| PLDM/MCTP | 1.0 | Transport-independent messaging | Required |
| SPDM | 1.3 | Security Protocol & Data Model | Required |
| NC-SI | 1.2 | Network Controller Sideband Interface | Recommended |
| IPMI | 2.0 | Legacy compatibility only | Deprecated |
OCP Contributions
The following contributions are available through the OCP Contributions portal. These include reference implementations, specifications, and design documents.
OCP RAS API v0.9 Final
Standardized Redfish-based API for reliability, availability, and serviceability operations.
Caliptra Root of Trust 2.0
Open-source silicon root of trust specification for secure boot and attestation.
Secure Boot 2.0
Security baseline requirements for firmware boot chain verification and secure update mechanisms.
View all contributions at opencompute.org/contributions