Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol
updated by
- rfc-7146 — Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3
Extracted elements (25)
Applying credentials to a boot image loaded through iSCSI is outside the scope of this document because the identity of a boot image may not be known when the Boot Stage starts, and images may recursively load other images based on hardware configuration and user input. Each image-loading component is expected to verify images independently.
The specific sequence of iSCSI commands needed to complete the boot process is left to the implementor, because varying requirements from different vendors and equipment make it difficult to specify a common subset of the iSCSI standard acceptable to all.
There must be no restriction of network topology between the iSCSI boot client and boot server beyond what is required for the iSCSI session itself, explicitly allowing booting from servers behind gateways or firewalls.
DHCP settings such as RA settings in DHCPv6 may prohibit the use of DHCP in distributing iSCSI boot information, in which case the DHCP Stage cannot be used. BOOTP or DHCP fields such as client ID and gateway information are used identically to non-iSCSI applications unless otherwise specified.
The port number obtained from the Discovery Service Stage may conflict with the one obtained from the DHCP Stage. In such a case, the implementor has the option to try both port numbers in the Boot Stage.
A BOOTP or DHCP server (v4 or v6) MAY instruct an iSCSI client how to reach its boot device using the Root Path option, prefaced with 'iscsi:'. The Root Path option is not currently defined for DHCPv6; if defined in the future, iSCSI boot use will apply.
Servername compression MUST NOT be used in the servername field of the Root Path option. The servername must follow URI specification Section 3.2.2 and contain either a valid domain name, a literal IPv4 address, or a literal IPv6 address.
The minimum information required for an iSCSI boot client to contact an iSCSI boot server is: (a) the client's IP address (IPv4 or IPv6), (b) the server's iSCSI Target Name, and (c) mandatory iSCSI initiator capability. The default LUN is 0 and the default port is the well-known iSCSI port.
The 'targetname' field in the Root Path option is not optional and MUST be provided. It is an iSCSI Name that uniquely identifies an iSCSI target as defined by the iSCSI standard.
The transport protocol specified in the 'protocol' field MUST have been approved for use in iSCSI; currently the only approved protocol is TCP (decimal '6'). If the protocol field is left blank, TCP is assumed.
If the iSCSI boot client has no targetname information, it may query SLP with query string 4 of the iSCSI Target Concrete Service Type Template to obtain a list of accessible iSCSI boot servers, or query iSNS to find bootable targets in a Discovery Domain.
If the 'servername' field is provided by BOOTP or DHCP, the client proceeds directly to the Boot Stage. If 'servername' is absent, the 'targetname' field is used in the Discovery Service Stage to resolve the server's address via SLP or iSNS.
The Discovery Service Stage is required when DHCP cannot provide the boot server address beyond the targetname. It may use SLP (querying iSCSI Target Concrete Service Type Template) or iSNS (Device Attribute Query) to resolve the targetname to an IP address and port.
The iSCSI boot process is divided into four sequential stages: Software Stage (optional, loads iSCSI initiator software), DHCP Stage (obtains IP address and boot server info), Discovery Service Stage (resolves targetname to IP/port if server address unknown), and Boot Stage (opens iSCSI session and boots).
The iSCSI session established during the Boot Stage may be taken over by the booted software in the iSCSI boot client, inheriting all session properties including security parameters.
For the Boot Stage communication, IPsec and in-band authentication SHOULD be implemented per RFC 3720 and RFC 3723 guidelines. iSCSI boot clients are expected to support only pre-shared key authentication in IKE due to memory constraints.
If the DHCP stage is implemented using DHCP, the iSCSI boot client SHOULD implement DHCP authentication (RFC 3118 for IPv4, RFC 3315 for IPv6), and an administration interface SHOULD be provided for configuring DHCP authentication credentials.
If the Discovery Service stage uses SLP or iSNS, the iSCSI boot client SHOULD provide IPsec support (OPTIONAL to use). When SLP or iSNS distribute security policy or configuration, at minimum per-packet data origin authentication, integrity, and replay protection SHOULD be used.
In a secure iSCSI boot process, the DHCP reply SHOULD include the serverName in IPv4/IPv6 format to avoid reliance on DNS or a Discovery Service entity, reducing the number of entities involved in the boot process.
In all phases of the boot process, a client must ensure that a server is authorized to send it information. The authenticated identity of a server must carry an authorization indication; authorized server lists may be pre-configured or downloaded in authenticated form from a prior boot stage.
iSCSI boot SHOULD NOT be enabled or placed high in the boot order without an explicit administrative action, because enabling iSCSI boot creates a critical operational dependence on an external system with obvious security implications.
The Software Stage SHOULD NOT be involved in a secure iSCSI boot process, as securing the loading of software required for later boot stages is difficult and complex due to administrative issues and BIOS environment limitations. All necessary software is assumed to be resident on the boot client.
Where the host IP address is assigned dynamically, IKE main mode SHOULD NOT be used, as explained in RFC 3720 and RFC 3723. The iSCSI boot session is vulnerable as any iSCSI session regardless of how prior stage parameters were obtained.
The LUN field in the Root Path option is a hexadecimal representation divided into four groups of four hex digits separated by '-' (e.g., '4752-3A4F-6b7e-2F99'). At most three leading zero digits MAY be omitted per group; trailing all-zero groups MAY be omitted with the preceding '-'. Other concise representations MUST NOT be used.
The Root Path option for iSCSI boot is a UTF-8 string with the format: 'iscsi:<servername>:<protocol>:<port>:<LUN>:<targetname>'. The fields servername, port, protocol, and LUN are OPTIONAL and may be left blank; targetname is mandatory.