Subject: iSCSI boot

From: [email-masked]
Date: Thu, 24 May 2001 20:35:10 -0400

Somewhere buried in my "to-do" list is to provide some
guidance to the iSCSI boot draft authors about what
to do next.  What follows are more of suggestions than
instructions and comments are welcome.

- The draft will need to be split into two pieces,
	an informational draft describing the overall
	boot process and a standards-track document
	that standardizes the DHCP option.  The
	informational draft might benefit from being
	merged into the corresponding portion of the
	naming and discovery draft, since much of what
	it covers is how to discover the boot device.

- The DHCP option draft would need to be coordinated
	with the DHC WG.  This need for a new DHCP option
	may be a problem, as there aren't may option codes left:
	(http://www.iana.org/assignments/bootp-dhcp-parameters).
	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), but I wonder
	if there's a way to [ab]use existing DHCP option 17
	(Root Path) for this purpose.
	
In any case, the use of DHCP will need to be pursued
with the DHCP WG via a document that describes only the
DHCP option to be standardized.  This probably shouldn't
be undertaken until the iSCSI naming and discovery draft
is relatively stable so that we're certain about naming
formats and mechanisms (e.g., is "Send Targets" involved
in boot? - this has implications for the information passed
through DHCP).

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: "Douglas Otis" <[email-masked]>
Date: Fri, 25 May 2001 12:26:31 -0700

David,

If there already is a means of discovering either LDAP or SLP in conjunction
with DCHP together will some security features defined within the PXE
specification, then adding iSCSI specific information is not really
required.  If you assume there is security present within LDAP and there is
a defined schema, the ability to retrieve information related to things like
ISID, Initiator Name, Target Name, mount point, etc can be made available
through those standard services with security providing the initial filter.
LDAP can store state as it is commonly used to keep password counts and the
like. It is not a direct property of LDAP, but a well structured schema
should make this task easier.  I know that I will hear, "Send in the Draft"
but until there is consensus as to what is needed and how it is to be used,
it would be a likely futile venture.

Doug

---

From: David Robinson <[email-masked]>
Date: Fri, 25 May 2001 12:54:29 -0700

> it would be a likely futile venture.

I think you are over complicating things Doug. We already have a well
defined
standard for Network Adapters to discover their identity and their
"root"
storage device using DHCP.  All that is really needed by the IPS WG is
to define
the syntax and semantics of the string that indicates where the iSCSI
target is.

While LDAP provides a lot of features and can easily be used as the
directory
service behind a DHCP server (and in fact is often is), it is highly
unlikely
that vendors will embed LDAP into the PROMs of their adapters to
retrieve
a simple string that can just as easily be served using their existing
DHCP/PXE
PROMs.

Security is actively being worked on the the DHCP community so that
is something that iSCSI can leverage.
(draft-ietf-dhc-authentication-16.txt)

So I won't say "Send in a Draft" but instead "The IESG won't let us
reinvent existing protocols".

	-David

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 25 May 2001 14:31:23 -0700

David,

I think you misunderstand where this code would exist.  It would not be
within the DHCP/PXE PROM code.

Use the existing environment and previously defined parameters in
conjunction with existing servers and existing protocols.

Doug

---

From: David Robinson <[email-masked]>
Date: Fri, 25 May 2001 23:25:34 -0700

> conjunction with existing servers and existing protocols.

I clearly don't understand your point.  The purpose of the iSCSI boot
draft is to define a mechanism to determine where the "root" disk is
using standard protocols, most notable DHCP. Once the root disk is
accessed and the operating system is loaded, everything is done
using the naming and discovery mechanisms that will be defined.

Using sophisticated protocols like LDAP may be appropriate once a
kernel is loaded and should be defined as part of the naming and
discovery design, but it is not a boot issue. The richness of LDAP
is complete overkill for the initial boot environment.

As a practical example, NFS clients today can boot using either
bootparams or DHCP to load the initial root partition, once the
kernel is loaded it is common to "remount" the root partition
using the full NFS mount mechanisms. An iSCSI initiator could
do the same thing to "relogin" and use the full set of options
that may not be present in the boot environment.

	-David

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 26 May 2001 09:05:41 -0700

David,

Rather than attempting to replicate a micro NFS client level of complexity
in a boot NAS, A DUA to obtain parameters should allow immediate use of a
SAN.  As far as the level of complexity, the means of obtaining the required
access together with code exists today.  It is simply a matter of defining
the structures.  Yes, it is different from starting with a NAS.  DHCP passes
a limited number of parameters and will be overwhelmed by the demands for
starting an iSCSI session.  LDAP can easily accommodate these demands
without one bit of the protocol modified or new DHCP parameters defined.
There could simply be a table defined in the boot image for that matter if
LDAP seems to difficult but that seems difficult to manage.

Doug

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 May 2001 09:22:47 -0700 (PDT)

> (draft-ietf-dhc-authentication-16.txt)

Unfortunately, it's not clear to me that
draft-ietf-dhc-authentication-16.txt is viable for use in securing the
boot process without some additional work. As written, the draft assumes
that the adapter has been seeded with a DHCP authentication key
tied to the DHCP client identifier (e.g. htype/MAC address), computed
from the master key. As I understand it, PXE/BIS also assumes the ability
to store a public key validating the boot image. Neither spec really
provides much insight on how one might obtain proper keying/authentication
material to secure the iSCSI boot process. 

While it might be reasonable to assume that a manufacturer could supply a
set of machines programmed with the correct public key to validate the
boot image, it seems somewhat of a stretch that the adapters could be
programmed on a large scale according to the technique described in
-16. 

Also, in both cases, it would appear that revocation/key change is a huge
headache. Note that the master secret described in -16 is not be provided
to the individual stations; this is held in confidence by the DHCP server.

The upshot is that I would not necessarily assume that we in the
IETF really have a good handle on secure boot at this point.