Redfish - IPMI Alternative Coming Soon

    In September 2014, a group of leading server hardware companies announced plans to replace the hardware management protocol, known among IT professionals as the Intelligent Platform Management Interface (IPMI). The new protocol was given the name Redfish.



    According to the developers of Redfish, the protocol used now is already outdated and does not allow to reveal the full potential of managing modern IT equipment. IPMI was first introduced in 1998 with the support of Intel, Dell, NEC and Hewlett-Packard. At that time, the servers were still controlled by 8-bit microcontrollers, which significantly limited the protocol at the development stage. In 2004, the protocol was updated to version 2.0. The main improvements introduced in IPMI 2.0 include new authentication and encryption algorithms, the new Serial Over LAN feature (which supports remote interaction with applications, BIOS, and the operating system), a built-in firewall, and new configuration and user registration options. IPMI for attackers is a great opportunity to obtain tools for low-level access to the server, not requiring operating system tools. The security problem is compounded by the fact that many IPMI configurations are available without a password or use the default password.

    In addition, experts noted that passwords are stored in clear form, there is no encryption of individual varieties of IPMI traffic, and the leak of a single password means full access to all the servers in the group.

    These reasons are the main ones for creating a new protocol that meets modern requirements both in systems management and in terms of security.

    Redfish developers face many different challenges in developing an architecture, protocol, and data representation model. It is anticipated that this architecture will support a wide range of systems in use today - from standalone machines to equipment racks used in the cloud. Simplicity to the best of your ability is another goal of Redfish. Compliance with programming environments that are widely accepted today is also one of the key principles.

    Among other principles laid down in the design of Redfish:

    1) RESTful interface using the JSON data model;
    2) the protocol and the data model are separated, which allows updating them separately from each other;
    3) special rules for specifying versions for the protocol and scheme;
    4) elimination of weaknesses in the standards of Internet protocols, in those places where they are faced with architectural requirements, such as JSON, HTTP and RFCs;
    5) the protocol is focused on scalable environments, but is able to manage current server environments;
    6) focus on out-of-band - feasible in BMC and firmware products;
    7) the functionality should be accessible / understandable for the average user;
    8) the implementation of the architecture should be as discreet as possible for security purposes.



    Key reasons to use RESTful:

    1) makes it easy to implement in cases where saving is important (less data transfer than SOAP, fewer protocol layers than WS-Man);
    2) aims to become the most common access method in industry;
    3) easy to learn, access to documentation;
    4) there are a number of off-the-shelf tools and development environments that can be used for REST;
    5) the consumption of RAM and CPU is less than that of other interfaces;
    6) it supports data model semantics and simple mapping of common CRUD operations;
    7) complies with the development principle: ease of use;
    8) it can equally be used both in embedded environments and in the application space, which makes it possible to bring together the component code within the control ecosystem;
    9) it is not initially tied to a circuit, so it adapts well to any modeling language;
    10) thanks to him, Redfish can be used to safely start mechanisms in the industry.

    Separation of protocol from data model

    The protocol version changes extremely rarely, while the versions of the data model can be modified as necessary. Thus, innovations in the data model, and not in the protocol, are expected in the first place. This will allow you to change the data model as needed without touching the version of the API or protocol.

    Json

    All resources can be expressed in JSON format. JSON Schema will be used and extended to define classes. Both JSON and JSON Schema are widely used and have a large number of tools for different programming languages ​​that accelerate development.



    Support for synchronous and asynchronous operations

    While most operations in this architecture can be executed synchronously, some operations may take too long to complete, more than the client agrees to wait. For this reason, some operations may be asynchronous at the discretion of the service. An asynchronous operation request is no different from a synchronous request.
    Using HTTP Response codes will allow the client to determine whether the operation was completed: synchronously or asynchronously.

    Actions

    Operations can be divided into two types: internal and external. The protocol has the ability to support external operations - those operations that are not displayed freely on CRUD. Examples are a software update or a system reset. Software update is considered as three possible operations: transferring the image for updating to the system, downloading the image by the system and its subsequent activation. It is possible to combine these operations into one single action or one function call.

    In Redfish, these external operations are called actions. There are certain actions defined in the Redfish schema that describe each resource. For these standard actions, the Redfish schema is provided with a regulatory language. OEM extensions are also allowed by the schema and are assigned to actions.

    Device support (console, KVM-IP, command shell, virtual media)

    This architecture supports a wide variety of devices and services. A very important component is the support mechanisms for the console, (KVM-IP), the command shell (for example, the Linux command line) and remote virtual media. Their support is implemented in this standard and expressed in a diagram at the level of the data model representation, however, the protocols themselves are beyond the scope of this standard.

    The security problem in the remote interface, which is programmable, is to provide not only protection of the transmitted data, but also protection of the interface itself, which is used to interact with Redfish. This implies the development of appropriate security control mechanisms at the interface level and the protection of data exchange channels.

    Security



    Implementations must support TLS v1.1 or higher and use only compatible TLS connections to transport sensitive data.

    Implementations must support AES-256 based on TLS. Redfish should consider supporting ciphers that include authentication and identification without the use of trusted certificates: TLS_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, TLS_RSA_PSK_WITH_AES_256_GCM.

    AES-GCM is not only efficient and safe, its hardware implementations can achieve high speeds at low cost and latency.

    Implementations should support the replacement of the default certificate, if provided, with a certificate that has at least 4096 bit RSA key and RSA-SHA512 signature.

    Features of Redfish

    1) privilege model for monitoring and management;
    2) system settings;
    3) BIOS configuration;
    4) power management system;
    5) information sensors (power / thermal / viability);
    6) network settings;
    7) memory settings;
    8) journaling;
    9) Redfish configuration service;
    10) account management;
    11) firmware versions;
    12) authentication within the infrastructure;
    13) compatibility with CURL;
    14) Automation of customers;
    15) built-in service processes.

    According to the developers, Redfish will have the ability to manage not only one system but also entire shelving systems. Also, Redfish is a kind of reincarnation of IPMI, and this means that when switching to a new system, the user will not lose any of the functions for which IPMI is so fond of. Management through an additional channel makes it possible to perform maintenance regardless of the operating capacity of the OS. It can be used to monitor or change BIOS / UEFI settings, as well as control statistics at the system level: temperature, voltage, fans and power supplies. According to the latest statements by the creators, the standard is under development and will soon be submitted for analysis by industry standards.

    Also popular now: