Subject: More on iSCSI boot

From: [email-masked]
Date: Wed, 30 May 2001 22:49:57 -0400

Let's start with a simple boot from a disk - the system
BIOS reads the boot sector(s) off of the disk drive,
loads and runs it/them.  That primary bootloader then
handles whatever else is necessary based on the ability
to do disk reads (a secondary bootloader and/or other
things may be involved).  On Intel systems, it's generally
a combination of the system BIOS and card BIOS that
make the disk reads work.  Simplifying assumptions
are common (e.g., boot from LUN 0 on the first SCSI
target found).  The goal of the iSCSI boot draft is
to explain how to make this "simple boot from a disk"
mechanism work when the boot disk is attached via iSCSI.

An iSCSI adapter has some things to do in order to make
this work, e.g., it has to log into the target before disk
reads can be issued.  I tend to believe that "Don't do this
(i.e., try to boot over iSCSI)" is not an acceptable answer.

In the message that started this whole boot discussion, I
suggested that

	Using DHCP to find SLP to find the boot device seems
	both clumsy and an invitation to problems (one more
	thing that can break and prevent booting), 

I think that's doubly true if LDAP is used instead of SLP.
David Robinson's messages support my inclination to reuse
DHCP option 17 (Root Path) by defining iSCSI syntax
for it.  Between that, any TCP parameters that one wants to
set through DHCP, and iSCSI parameters that can be defaulted,
it should be possible to get the first disk reads done
through iSCSI.

As has been pointed out, booting is often poorly secured in
general.  While it'd be nice to change this, iSCSI will face
the same pressures that other boot mechanisms face - keep
it simple, get the boot image loaded, and let it do something
fancier.  Any signature/validation of the boot image will be
above the level of iSCSI.  Somehow, I don't expect to find
implementations of ESP in card BIOSes anytime soon.

If implementers want to use DHCP and TFTP to boot, I don't
see any point in stopping them, but I don't think either should
be mandated.  DHCP has centralized administration advantages,
and TFTP is a simple way to download code, but both are "one
more thing that can break and prevent booting" and hence may
not be used all the time.

Comments?
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: [email-masked]
Date: Thu, 31 May 2001 06:08:12 +0300

David,

The trouble with our boot is two-fold:

-the SCSI boot - unlike the network boot is unbounded (there is no such
thing as an image).
-even if we would like to standardize a "primary" or "minimal" boot we have
no good understanding (experience)
of how this will interact with the iSCSI security mechanisms.

Julo

[email-masked] on 31-05-2001 05:49:57

Please respond to [email-masked]

To:   [email-masked]
cc:
Subject:  More on iSCSI boot

Comments?
--David

---

From: [email-masked]
Date: Thu, 31 May 2001 13:17:29 +0300

David,

I don't think I am confused by terminology (although I might be!).
In PXE as in all network boots the boot image is a file and you can do with
it
all sorts of authentication (that is what I call a bounded process).

In a SCSI boot  the target has no way of distinguishing a read for boot
from a read for a fully operational
initiator (the boot is unbounded).  Authenticating this type of "unbounded
image" is hard.
You can imagine various schemes but all of them are hard and many of them
require heavy administration and cooperating third parties (DHCP and
others).

An authentic DHCP is but a small item in the foolproofing boot.

Considering what an "infected" boot can do to an organization standardizing
a 2 phase process might
be the way to go (very little external support is required) but we lack the
required experience to attempt even this now.

We some patience we might get a secure boot even over an unsecured DHCP (as
we get secure communication over unsecured channels).

Regards,
Julo

David Robinson <[email-masked]> on 31-05-2001 07:00:00

Please respond to David Robinson <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: More on iSCSI boot

Julian,
I think you are simply confused on terminology.  I think
when David says "boot image" he is using in generally to
mean transfering enough data to provide a self supporting
operating system. In the case of SCSI the "image" is set
of sectors necessary to start the kernel, similarily in NFS
it is typically the "vmunix" file(s). It is not the full LUN
representing the root filesystem.

As Bernard has shown, a flexible and scaleable mechanism to
bootstrap a security system without a disk is just very hard.
We need to do a reality check on the environment that iSCSI
boot will use. I don't think there will be a large market
for booting over the Internet, but boot disks will be
physically co-located in constrained environments where DHCP
will be "good enough".  While the IESG may not like the
weak security, I would be surprised if it insisted that
the ips WG take on the task of building a better DHCP.

     -David

---

From: [email-masked]
Date: Thu, 31 May 2001 13:17:29 +0300

David,

Regards,
Julo

To:   [email-masked]
cc:

Julian,

     -David

---

From: [email-masked]
Date: Thu, 31 May 2001 13:17:29 +0300

David,

Regards,
Julo

To:   [email-masked]
cc:

Julian,

     -David