Re: More on iSCSI boot

[Glen Turner <glen.turner@aarnet.edu.au>]

> You are making several assumptions as to what exists on each machine by
> assuming a new boot protocol may be available in PROM.

Naturally.  It's a new protocol, so sysadms may choose to
upgrade flash BIOSes or purchase new PROMS.  Or they may
choose not to.  <shrug>

> Can DHCP securely support both an iSCSI and TFTP boot process?

DHCP can't even securely support a TFTP boot as it stands today.
That's not IPS's problem.  IPS's responsibility is to ensure than
when a secure DHCP is developed, any IPS protocol used in the boot
process then allows an end-to-end secure boot.

> Here you will run into not only the problem of initially setting
> shared secrets

Not a protocol problem, a vendor problem.  For example, there is
nothing to prevent vendors from reading the secret from the
network, or a floppy disk  or a PC Card keyloader when asked
to do so from the BIOS configuration.

Again, not IPS's problem.

> Two ways to do the same thing should suggest this optional iSCSI
> approach is not a good one.  If just one is to be used, it can not be an
> initial iSCSI boot.

I can't agree.  TFTP and iSCSI appeal to differing market segments.
Enterprises will have significant robust iSCSI storage, engineered
for serious uptime.  That in turn makes it cheap to use iSCSI
boot to obtain a boot image rather than implement a set of TFTP
servers that won't offer the same availability.

Similarly, high threat environments like universities are attracted
to iSCSI boot because the boot image can be held on a iSCSI CD drive,
requiring physical access or hacked routers for students to subvert
the network boot process.

The large group in the middle will probably be happy to continue
to boot from attached disk with its higher per-unit sysadm costs,
with small workgroups using TFTP becuase of its ubiquity.

If you want to criticise the iSCSI boot proposal, then how about
pointing out that iSCSI boot doesn't exploit the expected
availability of an iSCSI network by defining further boot
devices should the first device be unavailable.  Now doing
that using DHCP gets problematic...

Regards,
Glen