iSCSI boot: Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol
How a computer with no disk of its own finds its iSCSI boot server and collects the information it needs to boot.
Sarkar, P., Missimer, D., and C. Sapuntzakis, "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol", RFC 4173, DOI 10.17487/RFC4173, September 2005, <https://www.rfc-editor.org/info/rfc4173>.
@misc{rfc4173,
series = {Request for Comments},
number = 4173,
howpublished = {RFC 4173},
publisher = {RFC Editor},
doi = {10.17487/RFC4173},
url = {https://www.rfc-editor.org/info/rfc4173},
author = {P. Sarkar and D. Missimer and C. Sapuntzakis},
title = {{Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol}},
pagetotal = 12,
year = 2005,
month = sep,
} RFC text
Contents
Network Working Group P. Sarkar
Request for Comments: 4173 IBM
Category: Standards Track D. Missimer
Hewlett-Packard Company
C. Sapuntzakis
Stanford University
September 2005
Bootstrapping Clients using
the Internet Small Computer System Interface (iSCSI) Protocol
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Internet Small Computer System Interface (iSCSI) is a proposed
transport protocol for Small Computer Systems Interface (SCSI) that
operates on top of TCP. This memo describes a standard mechanism for
enabling clients to bootstrap themselves using the iSCSI protocol.
The goal of this standard is to enable iSCSI boot clients to obtain
the information to open an iSCSI session with the iSCSI boot server.
1. Introduction
The Small Computer Systems Interface (SCSI) is a popular family of
protocols for communicating with I/O devices, especially storage
devices. SCSI can be characterized as a request/response messaging
protocol with a standard architecture and componentized command sets
for different device classes.
iSCSI is a proposed transport protocol for SCSI that operates on top
of TCP. The role of iSCSI is necessitated by the evolution of the
system interconnect from a shared bus to a switched network. IP
networks meet the architectural and performance requirements of
transporting SCSI, paving the way for the iSCSI protocol.
Many diskless clients sometimes bootstrap off remote SCSI devices.
Such diskless entities are lightweight, space efficient, and power-
conserving and are increasingly popular in various environments.
This memo describes a standard mechanism for enabling clients to
bootstrap themselves using the iSCSI protocol. The goal of this
standard is to enable iSCSI boot clients to obtain the information to
open an iSCSI session with the iSCSI boot server. It is possible
that all the information is not available at the very outset, so the
memo describes steps to obtain the information required to bootstrap
clients off an iSCSI boot server.
1.1. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [Bradner97].
2. Requirements
1. There must be no restriction of network topology between the iSCSI
boot client and the boot server other than that in effect for
establishing the iSCSI session. Consequently, it is possible for
an iSCSI boot client to boot from an iSCSI boot server behind
gateways or firewalls as long as it is possible to establish an
iSCSI session between the client and the server.
2. The following represent the minimum information required for an
iSCSI boot client to contact an iSCSI boot server: (a) the
client's IP address (IPv6 or IPv4); (b) the server's iSCSI Target
Name; and (c) mandatory iSCSI initiator capability.
The above assume that the default LUN for the boot process is 0 and
that the default port for the iSCSI boot server is the well-known
iSCSI port [Satran02]. However, both may be overridden at the time
of configuration.
Additional information may be required at each stage of the boot
process.
3. It is possible for the iSCSI boot client to have none of the above
information or capability on starting.
4. The client should be able to complete boot without user
intervention (for boots that occur during an unattended power-up).
However, there should be a mechanism for the user to input values
so as to bypass stages of the boot protocol.
5. Additional protocol software (for example, BOOTP or DHCP) may be
necessary if the minimum information required for an iSCSI session
is not provided.
3. Related Work
The Reverse Address Resolution Protocol (RARP) [Finlayson84] through
the extensions defined in the Dynamic RARP (DRARP) [Brownell96]
explicitly addresses the problem of network address discovery, and
includes an automatic IP address assignment mechanism. The Trivial
File Transfer Protocol (TFTP) [Sollins81] provides for transport of a
boot image from a boot server. BOOTP [Croft85, Reynolds93, Wimer93]
is a transport mechanism for a collection of configuration
information. BOOTP is also extensible, and official extensions have
been defined for several configuration parameters. DHCPv4 [Droms97,
Droms93] and DHCPv6 [Droms02] are standards by which hosts are to be
dynamically configured in an IP network. The Service Location
Protocol (SLP) provides for location of higher-level services
[Guttman99].
4. Software Stage
Some iSCSI boot clients may lack the resources to boot up with the
mandatory iSCSI initiator capability. Such boot clients may choose
to obtain iSCSI initiator software from a boot server. Currently,
many established protocols allow such a service in order to enable
clients to load software images. For example, BOOTP and DHCP servers
have the capability to provide the locations of servers that can
serve software images on requests from boot clients.
Note that this document does not recommend any of the above
protocols, and the final decision of which boot protocol is to be
used to load iSCSI initiator software is left to the discretion of
the implementor.
5. DHCP Stage
In order to use an iSCSI boot server, the following pieces of
information are required for an ISCSI boot client.
- The IP address of the iSCSI boot client (IPv4 or IPv6)
- The IP transport endpoint for the iSCSI Target Port for the iSCSI
boot server. If the transport is TCP, for example, this has to
resolve to an IP address and a TCP port number. TCP is currently
the only transport approved for iSCSI.
- The eight-byte LUN structure identifying the Logical Unit within
the iSCSI boot server.
At boot time, all or none of this information may be stored in the
iSCSI boot client. This section describes techniques for obtaining
the required information via the DHCP stage. Otherwise, if the iSCSI
boot client has all the information, the boot client may proceed
directly to the Boot stage.
An iSCSI boot client that does not know its IP address at power-on
may acquire it via BOOTP or DHCP (v4 or v6), or via IPv6 address
autoconfiguration. Please note that DHCP settings (such as the RA
settings in DHCPv6) may prohibit the use of DHCP in distributing
iSCSI boot information; in this case, the DHCP stage cannot be used.
Unless specified otherwise here, BOOTP or DHCP fields such as the
client ID and gateway information are used in an identical way as
applications other than iSCSI.
A BOOTP or DHCP server (v4 or v6) MAY instruct an iSCSI client how to
reach its boot device. This is done using the variable-length option
named Root Path [Alexander93, Reynolds93]. The use of the option
field is reserved for iSCSI boot use by prefacing the string with
"iscsi:". The Root Path option is not currently defined for DHCPv6;
if the option is defined for DHCPv6 in the future, the use of the
option as defined for iSCSI boot will apply.
The option field consists of an UTF-8 [Yergeau98] string. The string
has the following composition:
"iscsi:"<servername>":"<protocol>":"<port>":"<LUN>":"<targetname>
The fields "servername", "port", "protocol", and "LUN" are OPTIONAL
and should be left blank if there are no corresponding values. The
"targetname" field is not optional and MUST be provided.
The "servername" is the name of iSCSI server and contains either a
valid domain name, a literal IPv4 address, or a literal IPv6 address.
The servername must follow the specifications outlined in Section
3.2.2 of the URI Specification [Lee98] [Hinden99]. The characters
allowed must also conform to Section 2.2 of the same specification.
Servername compression MUST NOT be used in this field.
The "protocol" field is the decimal representation of the IANA-
approved string for the transport protocol to be used for iSCSI. If
the protocol field is left bank, the default value is assumed to be
"6" for TCP. The transport protocol MUST have been approved for use
in iSCSI; currently, the only approved protocol is TCP.
The "port" is the decimal representation of the port on which the
iSCSI boot server is listening. If not specified, the port defaults
to the well-known iSCSI port [Satran02].
The "LUN" field is a hexadecimal representation of the LU number. If
the LUN field is blank, then LUN 0 is assumed. If the LUN field is
not blank, the representation MUST be divided into four groups of
four hexadecimal digits, separated by "-". Digits above 9 may be
either lower or upper case. An example of such a representation
would be 4752-3A4F-6b7e-2F99. For the sake of brevity, at most three
leading zero ("0") digits MAY be omitted in any group of hexadecimal
digits. Thus, the "LUN" representation 6734-9-156f-127 is equivalent
to 6734-0009-156f-0127. Furthermore, trailing groups containing only
the "0" digit MAY be omitted along with the preceding "-". So, the
"LUN" representation 4186-9 is equivalent to 4186-0009-0000-0000.
Other concise representations of the LUN field MUST NOT be used.
Note that SCSI targets are allowed to present different LU numberings
for different SCSI initiators, so to our knowledge nothing precludes
a SCSI target from exporting several different LUs to several
different SCSI initiators as their respective LUN 0s.
The "targetname" field is an iSCSI Name that is defined by the iSCSI
standard [Satran02] to uniquely identify an iSCSI target. The
approved characters in the targetname field are stated in the iSCSI
String Profile document[Bakke04].
If the "servername" field is provided by BOOTP or DHCP, then that
field is used in conjunction with other associated fields to contact
the boot server in the Boot stage (Section 7). However, if the
"servername" field is not provided, then the "targetname" field is
then used in the Discovery Service stage in conjunction with other
associated fields (Section 6).
6. Discovery Service Stage
This stage is required if the BOOTP or DHCP server (v4 or v6) is
unaware of any iSCSI boot servers or if the BOOTP or DHCP server is
unable to provide the minimum information required to connect to the
iSCSI boot server, other than the targetname.
The Discovery Service may be based on the SLP protocol [Guttman99,
Bakke02] and is an instantiation of the SLP Service or Directory
Agent. Alternatively, the Discovery Service may be based on the iSNS
protocol [Tseng03] and is an instantiation of the iSNS Server.
The iSCSI boot client may have obtained the targetname of the iSCSI
boot server in the DHCP stage (Section 5). In that case, the iSCSI
boot client queries the SLP Discovery Service using query string 1 of
the iSCSI Target Concrete Service Type Template, as specified in
Section 6.2 of the iSCSI SLP interaction document [Bakke02], to
resolve the targetname to an IP address and port number.
Alternatively, the iSCSI boot client may query the iSNS Discovery
Service with a Device Attribute Query with the targetname as the
query parameter [Tseng03]. Once this is obtained, the iSCSI boot
client proceeds to the Boot stage (Section 7).
It is possible that the port number obtained from the Discovery
Service 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.
If the iSCSI boot client does not have any targetname information,
the iSCSI boot client may then query the SLP Discovery Service with
query string 4 of the iSCSI Target Concrete Service Type Template, as
specified in Section 6.2 of the iSCSI SLP interaction document
[Bakke02]. In response to this query, the SLP Discovery Service
provides the boot client with a list of iSCSI boot servers the boot
client is allowed to access. Alternatively, the iSCSI boot client
can query the iSNS Discovery Service to verify if the targets in
particular Discovery Domain are bootable [Tseng03].
If the list of iSCSI boot servers is empty, subsequent actions are
left to the discretion of the implementor. Otherwise, the iSCSI boot
client may contact any iSCSI boot server in the list. Moreover, the
order in which iSCSI boot servers are contacted is also left to the
discretion of the implementor.
7. Boot Stage
Once the iSCSI boot client has obtained the minimum information to
open an iSCSI session with the iSCSI boot server, the actual booting
process can start.
The actual sequence of iSCSI commands that are needed to complete the
boot process is left to the implementor. This was done because of
varying requirements from different vendors and equipment, making it
difficult to specify a common subset of the iSCSI standard that would
be acceptable to everybody.
The iSCSI session established for boot may be taken over by the
booted software in the iSCSI boot client.
8. Security Considerations
The security discussion is centered around securing the communication
involved in the iSCSI boot process.
However, the issue of applying credentials to a boot image loaded
through the iSCSI boot mechanism is outside the scope of this
document. One key difference between the iSCSI boot mechanism and
BOOTP-based image loading is the fact that the identity of a boot
image may not be known when the Boot stage starts. The identity of
certain boot images and their locations are known only after the
contents of a boot disk exposed by the iSCSI boot service are
examined. Furthermore, images themselves may recursively load other
images based on both hardware configurations and user input.
Consequently, a practical way to verify loaded boot images is to make
sure that each image loading software verifies the image to be loaded
using a mechanism of their choice.
The considerations involved in designing a security architecture for
the iSCSI boot process include configuration, deployment, and
provisioning issues apart from typical security considerations.
Enabling iSCSI boot creates a critical operational dependence on an
external system with obvious security implications, and thus
administrator awareness of this enablement is extremely important.
Therefore, iSCSI boot SHOULD NOT be enabled or put high in the boot
order without an explicit administrative action.
In all phases of the boot process, a client must ensure that a server
is authorized to send it certain information. This means that the
authenticated identity of a server must have an authorization
indication. A list of authorized servers can be pre-configured into
a client, or the list can be downloaded in an authenticated form from
a prior stage in the boot process.
The software stage SHOULD NOT be involved in a secure iSCSI boot
process, as this would add the additional complexity of trying to
secure the process of loading the software necessary to run the later
stages of iSCSI boot. Authentication and integrity protection of
downloaded boot software has proven to be difficult and complex due
to administrative issues and limitations of the BIOS environment. It
is therefore assumed that all the necessary software is resident on
the iSCSI boot client.
If the DHCP stage is implemented using the DHCP protocol, the iSCSI
boot client SHOULD implement the DHCP authentication ([Droms01],
[Droms02] for IPv6). In this case, an administration interface
SHOULD be provided for the configuration of the DHCP authentication
credentials, both when the network interface is on the motherboard
and when it is removable. Note that DHCP authentication
([Droms01],[Droms02] for IPv6) is focused on intra-domain
authentication, which is assumed to be enough for iSCSI boot
scenarios. In the context of the secure iSCSI boot process, the
reply from the DHCP server in the DHCP stage SHOULD include the
serverName in IPv4 (or IPv6) format to avoid reliance on a DNS server
(for resolving names) or a Discovery Service entity (to look up
targetnames). This reduces the number of entities involved in the
secure iSCSI boot process.
If the Discovery Service stage is implemented using SLP, the iSCSI
boot client SHOULD provide IPsec support (OPTIONAL to use) for the
SLP protocol, as defined in [Bakke02] and [Aboba03]. If the
Discovery Service stage is implemented using iSNS, the iSCSI boot
client SHOULD provide IPsec support (OPTIONAL to use) for the iSNS
protocol, as defined in [Tseng03] and [Aboba03]. When iSNS or SLP
are used to distribute security policy or configuration information,
at a minimum, per-packet data origin authentication, integrity, and
replay protection SHOULD be used to protect the discovery protocol.
For the final communication between the iSCSI boot client and the
iSCSI boot server in the Boot stage, IPsec and in-band authentication
SHOULD be implemented according to the guidelines in the main iSCSI
draft [Satran02] and [Aboba03]. Due to memory constraints, it is
expected that iSCSI boot clients will only support the pre-shared key
authentication in IKE. Where the host IP address is assigned
dynamically, IKE main mode SHOULD NOT be used, as explained in
[Satran02] and [Aboba03]. Regardless of the way parameters in
previous stages (DHCP, SLP, iSNS) were obtained (securely or not),
the iSCSI boot session is vulnerable as any iSCSI session (see
[Satran02] and [Aboba03] for iSCSI security threats). Therefore,
security for this session SHOULD be configured and used according to
[Satran02] and [Aboba03] guidelines.
Note that if a boot image inherits an iSCSI session from a previously
loaded boot image, it also inherits the security properties of the
iSCSI session.
Acknowledgements
We wish to thank John Hufferd for taking the initiative to form the
iSCSI boot team. We also wish to thank Doug Otis, Julian Satran,
Bernard Aboba, David Robinson, Mark Bakke, Ofer Biran, and
Mallikarjun Chadalapaka for helpful suggestions and pointers
regarding the draft document.
Normative References
[Aboba03] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over
IP", RFC 3723, April 2004.
[Alexander93] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
[Bakke02] Bakke, M., Hufferd, J., Voruganti, K., Krueger, M.,
and T. Sperry, "Finding Internet Small Computer
Systems Interface (iSCSI) Targets and Name Servers by
Using Service Location Protocol version 2 (SLPv2)",
RFC 4018, April 2005.
[Bakke04] Bakke, M., "String Profile for Internet Small Computer
Systems Interface (iSCSI) Names", RFC 3722, April
2004.
[Bradner97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Croft85] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC
951, September 1985.
[Droms93] Droms, R., "Interoperation Between DHCP and BOOTP",
RFC 1534, October 1993.
[Droms97] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[Droms01] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[Droms02] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[Guttman99] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June
1999.
[Hinden99] Hinden, R., Carpenter, B., and L. Masinter, "Format
for Literal IPv6 Addresses in URL's", RFC 2732,
December 1999.
[Lee98] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[Reynolds93] Reynolds, J., "BOOTP Vendor Information Extensions",
RFC 1497, August 1993.
[Satran02] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka,
M., and E. Zeidner, "Internet Small Computer Systems
Interface (iSCSI)", RFC 3720, April 2004.
[Tseng03] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C.,
and J. Souza, "Internet Storage Name Service (iSNS)",
RFC 4171, April 2005.
[Yergeau98] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[Wimer93] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993.
Informative References
[Brownell96] Brownell, D., "Dynamic RARP Extensions for Automatic
Network Address Acquisition", RFC 1931, April 1996.
[Finlayson84] Finlayson, R., Mann, T., Mogul, J., and M. Theimer,
"Reverse Address Resolution Protocol", STD 38, RFC
903, June 1984.
[Sollins81] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992.
Authors' Addresses
Prasenjit Sarkar
IBM Almaden Research Center
650 Harry Road
San Jose, CA 95120, USA
Phone: +1 408 927 1417
EMail: psarkar@almaden.ibm.com
Duncan Missimer
Hewlett-Packard Company
10955 Tantau Ave
Cupertino, CA 95014, USA
EMail: duncan.missimer@ieee.org
Constantine Sapuntzakis
Stanford University
353 Serra Hall #407
Stanford, CA 94305, USA
EMail: csapuntz@alum.mit.edu
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1Booting From a Disk on the Network
SCSI, the Small Computer Systems Interface, is a popular family of protocols for communicating with input and output devices, especially storage devices. It works as a request and response protocol, with a standard architecture and componentized command sets for different device classes.
iSCSI, the Internet Small Computer Systems Interface, is a transport protocol for SCSI that operates on top of TCP. Its role comes from the way systems changed: the system interconnect moved from a shared bus to a switched network, and IP networks meet the architectural and performance requirements of transporting SCSI.
Many diskless clients bootstrap off remote SCSI devices. Such diskless entities are lightweight, space efficient and power conserving, and they are increasingly popular in various environments.
This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol. The goal is narrow: let an iSCSI boot client obtain the information it needs to open an iSCSI session with the iSCSI boot server. Some of that information may not be available at the outset, so the memo describes steps to obtain it. The steps are named after where the information comes from: the software stage, the DHCP stage, the discovery service stage and the boot stage.
The memo also surveys the related work it builds on: RARP and its DRARP extensions for network address discovery, TFTP for transporting a boot image, BOOTP for configuration information, DHCPv4 and DHCPv6 for dynamic host configuration, and the Service Location Protocol for locating services.
iSCSI carries SCSI storage commands over TCP, so a computer can reach a disk on the network. This RFC explains how a computer with no disk of its own collects the few facts it needs before it can use one.
§2What a Boot Client Needs
The RFC lists five requirements.
First, there must be no restriction of network topology between the boot client and the boot server beyond the restriction already in effect for establishing the iSCSI session. A client can therefore boot from a server behind gateways or firewalls, as long as an iSCSI session can be established between them.
Second, the minimum information a client needs in order to contact a boot server is its own IP address, either IPv6 or IPv4, the server's iSCSI Target Name, and the mandatory iSCSI initiator capability. These assumptions hold when the default LUN for the boot process is 0 and the default port for the boot server is the well-known iSCSI port, but both may be overridden at the time of configuration. The LUN, the logical unit number, picks which disk inside the server to use.
Third, it is possible for the client to have none of that information or capability when it starts. Fourth, the client should be able to complete a boot without user intervention, for the boots that happen during an unattended power-up, while there should still be a mechanism for the user to enter values so as to bypass stages of the boot protocol. Fifth, additional protocol software, for example BOOTP or DHCP, may be necessary if the minimum information is not provided.
More information may be required at each stage of the boot process, so the rest of the memo describes where that extra information comes from.
To reach a storage server, a client needs three things: its own IP address, the name of the server, and the software that speaks iSCSI. The client may start with none of them, so the RFC also asks that the boot finish without a person answering questions.
§4The Software Stage
Some iSCSI boot clients lack the resources to boot up with the mandatory iSCSI initiator capability. Such clients may choose to obtain iSCSI initiator software from a boot server.
Many established protocols already allow this kind of service, so that clients can load software images. BOOTP and DHCP servers, for example, have the capability to provide the locations of servers that can serve software images when a boot client requests them.
The RFC does not recommend any of those protocols. The final decision about which boot protocol is used to load the iSCSI initiator software is left to the discretion of the implementor.
A very small computer may not have the iSCSI code built in. The RFC allows it to fetch that code from a server first, and leaves the choice of how to fetch it to the maker of the client.
- DHCP requestThe client asks for an address and for information about its boot device.
- DHCP replyThe reply may carry a Root Path string that starts with iscsi:.
- SLP or iSNS queryUsed when the client has the target name but not the address.
- Address and portThe service resolves the target name to an IP address and a port.
- iSCSI sessionThe client opens the session and boots from the server.
§5The DHCP Stage and the Root Path Option
Three pieces of information are needed to use an iSCSI boot server: the IP address of the client, either IPv4 or IPv6; the IP transport endpoint for the iSCSI Target Port of the boot server, which for TCP means an IP address and a TCP port number; and the eight-byte LUN structure identifying the logical unit within the boot server.
At boot time, all or none of this information may be stored in the client. If the client already has all of it, it may proceed directly to the boot stage. A client that does not know its IP address at power-on may acquire one via BOOTP, the Bootstrap Protocol, or DHCP, the Dynamic Host Configuration Protocol, in version 4 or version 6, or via IPv6 address autoconfiguration. DHCP settings, such as the RA settings in DHCPv6, may prohibit the use of DHCP in distributing iSCSI boot information, in which case the DHCP stage cannot be used. Unless the RFC specifies otherwise, BOOTP and DHCP fields such as the client ID and gateway information are used in an identical way as in applications other than iSCSI.
A BOOTP or DHCP server MAY instruct an iSCSI client how to reach its boot device by using the variable-length option named Root Path. The use of the option field is reserved for iSCSI boot use by prefacing the string with iscsi:. The option field consists of a UTF-8 string with the following composition:
"iscsi:"<servername>":"<protocol>":"<port>":"<LUN>":"<targetname>
The servername, protocol, port and LUN fields are optional and should be left blank if there are no corresponding values. The targetname field is not optional and MUST be provided.
servername: a valid domain name, a literal IPv4 address or a literal IPv6 address, following the specifications of the URI Specification. Servername compression MUST NOT be used in this field.protocol: the decimal representation of the IANA-approved string for the transport protocol to be used for iSCSI. If the field is left blank, the default value is assumed to be6for TCP. The transport protocol MUST have been approved for use in iSCSI, and currently the only approved protocol is TCP.port: the decimal representation of the port on which the iSCSI boot server is listening. If it is not specified, the port defaults to the well-known iSCSI port.LUN: the hexadecimal representation of the LU number. If the field is blank, LUN 0 is assumed. If the field is not blank, the representation MUST be divided into four groups of four hexadecimal digits separated by a hyphen, and digits above 9 may be in either case. An example is4752-3A4F-6b7e-2F99. At most three leading zeros may be omitted in any group, so6734-9-156f-127is equivalent to6734-0009-156f-0127. Trailing groups that contain only the digit 0 may be omitted along with the preceding hyphen, so4186-9is equivalent to4186-0009-0000-0000. Other concise representations of the LUN field MUST NOT be used.targetname: an iSCSI Name, as defined by the iSCSI standard, that uniquely identifies an iSCSI target. The approved characters are stated in the iSCSI String Profile document.
SCSI targets are allowed to present different LU numberings to different SCSI initiators, so a target may export several different logical units to several different initiators as their respective LUN 0.
If the servername field is provided by BOOTP or DHCP, that field is used with the other associated fields to contact the boot server in the boot stage. If the servername field is not provided, the targetname field is used in the discovery service stage instead.
In this stage the client learns its own address, the address and port of the storage server, and which disk inside that server it wants. A BOOTP or DHCP server can pass all of that in one text string that starts with iscsi:.
"iscsi:"<servername>":"<protocol>":"<port>":"<LUN>":"<targetname>- servernameOptional. A domain name, a literal IPv4 address or a literal IPv6 address. Name compression must not be used.
- protocolOptional. Decimal transport number, default 6 for TCP, the only transport approved for iSCSI.
- portOptional. Decimal port of the boot server, defaulting to the well-known iSCSI port.
- LUNOptional. Four groups of four hexadecimal digits separated by hyphens. Blank means LUN 0.
- targetnameRequired. The iSCSI Name that uniquely identifies the target.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
GROUP-1 | Group 1 | 2 bytes | First group of four hexadecimal digits. | |
GROUP-2 | Group 2 | 2 bytes | Second group of four hexadecimal digits. | |
GROUP-3 | Group 3 | 2 bytes | Third group of four hexadecimal digits. | |
GROUP-4 | Group 4 | 2 bytes | Fourth group of four hexadecimal digits. |
§6The Discovery Service Stage
This stage is required if the BOOTP or DHCP server is unaware of any iSCSI boot servers, or if it cannot provide the minimum information required to connect to the boot server other than the target name.
The discovery service may be based on the Service Location Protocol, SLP, in which case it is an instantiation of the SLP Service or Directory Agent. Alternatively it may be based on the Internet Storage Name Service, iSNS, in which case it is an instantiation of the iSNS Server.
When the client has obtained the target name in the DHCP stage, it queries the SLP discovery service using query string 1 of the iSCSI Target Concrete Service Type Template, to resolve the target name to an IP address and a port number. Alternatively it may query the iSNS discovery service with a Device Attribute Query that uses the target name as the query parameter. Once that information is obtained, the client proceeds to the boot stage.
The port number from the discovery service may conflict with the one from the DHCP stage. In such a case, the implementor has the option to try both port numbers in the boot stage.
When the client has no target name information at all, it may query the SLP discovery service with query string 4, and the service answers with a list of the iSCSI boot servers that the client is allowed to access. Alternatively it may query the iSNS discovery service to verify whether the targets in a particular Discovery Domain are bootable. If the list is empty, the subsequent actions are left to the discretion of the implementor. Otherwise the client may contact any iSCSI boot server in the list, and the order in which the servers are contacted is also left to the discretion of the implementor.
Sometimes the DHCP or BOOTP server knows only the name of the disk, not where it lives. The client then asks a directory service, either SLP or iSNS, to turn that name into an address and a port. If it does not even have a name, it asks the directory for a list of servers it may use.
§7The Boot Stage
Once the client has obtained the minimum information needed to open an iSCSI session with the boot server, the actual booting process can start.
The actual sequence of iSCSI commands needed to complete the boot process is left to the implementor. The RFC gives the reason: the requirements of different vendors and equipment vary, which makes it difficult to specify a common subset of the iSCSI standard that would be acceptable to everybody.
The iSCSI session established for the boot may be taken over by the booted software in the client.
Once the client knows where the disk is, it opens an iSCSI session and boots. The RFC does not fix the sequence of iSCSI commands for this step, because no common subset of the standard suits every vendor.
§8Security Considerations
The security discussion is centered on securing the communication involved in the iSCSI boot process. Applying credentials to a boot image loaded through the iSCSI boot mechanism is outside the scope of the document.
One key difference between the iSCSI boot mechanism and BOOTP-based image loading is that the identity of a boot image may not be known when the boot stage starts. The identity of certain boot images and their locations are known only after the contents of a boot disk exposed by the iSCSI boot service are examined. Images themselves may recursively load other images, based on both hardware configurations and user input. The practical answer the RFC gives is that each image loading program should verify the image it is about to load, using a mechanism of its own choice.
Enabling iSCSI boot creates a critical operational dependence on an external system, with obvious security implications, so administrator awareness of this enablement is extremely important. iSCSI boot SHOULD NOT be enabled, or put high in the boot order, without an explicit administrative action.
In all phases of the boot process, the client must ensure that a server is authorized to send it certain information. That means the authenticated identity of a server must have an authorization indication. A list of authorized servers can be pre-configured into a client, or the list can be downloaded in an authenticated form from a prior stage in the boot process.
The software stage SHOULD NOT be involved in a secure iSCSI boot process. Securing the loading of that software adds complexity, and the RFC notes that authentication and integrity protection for downloaded boot software has proven to be difficult and complex because of administrative issues and the limitations of the BIOS environment. It is therefore assumed that all the necessary software is resident on the client.
If the DHCP stage is implemented using the DHCP protocol, the client SHOULD implement DHCP authentication, and an administration interface SHOULD be provided for configuring those credentials, both when the network interface is on the motherboard and when it is removable. DHCP authentication is focused on intra-domain authentication, which is assumed to be enough for iSCSI boot scenarios. The reply from the DHCP server SHOULD include the serverName in IPv4 or IPv6 format, so that the boot does not have to rely on a DNS server for resolving names or on a discovery service entity to look up target names. That reduces the number of entities involved in the secure boot.
If the discovery service stage uses SLP, the client SHOULD provide IPsec support, marked as optional to use, for the SLP protocol. If the stage uses iSNS, the client SHOULD provide IPsec support, marked as optional to use, for the iSNS protocol. When SLP or iSNS is used to distribute security policy or configuration information, per-packet data origin authentication, integrity and replay protection SHOULD be used at a minimum.
For the final communication between the client and the boot server in the boot stage, IPsec and in-band authentication SHOULD be implemented according to the guidelines in the main iSCSI specification. Due to memory constraints, boot clients are expected to support only pre-shared key authentication in IKE, and where the host IP address is assigned dynamically, IKE main mode SHOULD NOT be used. Regardless of how the parameters in the earlier stages were obtained, the iSCSI boot session is vulnerable as any iSCSI session, so security for this session SHOULD be configured and used according to the same guidelines. A boot image that inherits an iSCSI session from a previously loaded boot image also inherits the security properties of that session.
Booting from the network means trusting whoever answers. The client should check that a server is allowed to send it information, and an administrator should turn the feature on deliberately. A step where the client fetches its own software should stay out of a secure boot.