Subject: RE: More on iSCSI boot

From: "Douglas Otis" <[email-masked]>
Date: Thu, 31 May 2001 20:34:26 -0700

Glen,

You are making several assumptions as to what exists on each machine by
assuming a new boot protocol may be available in PROM.  You are also
assuming which arguments this new protocol will need as it becomes developed
and that this protocol can depend on overlaid DHCP settings.  Can DHCP
securely support both an iSCSI and TFTP boot process?  Here you will run
into not only the problem of initially setting shared secrets but also
updating this new boot protocol as it matures.  The angst the shared secret
causes should pale in comparison to maintaining a complex version 1 boot
protocol.  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.  In that case, there is no need to muck with DHCP or
change how the initial boot image is obtained.  Start your scenario at step
two.  Once at step two, I would highly recommend something be used that is
more robust that SLP or DHCP for management.

Doug

> [email-masked] wrote:
> >
> > David Robinson's messages support my inclination to reuse
> > DHCP option 17 (Root Path) by defining iSCSI syntax
> > for it.
>
> The "root path" is still useful if the image
> has been loaded using iSCSI or TFTP.
>
> An alternative would be to request an option for
> "image load protocol" and redefine DHCP's "sname"
> and "file" and options 66 "Server name" and option
> 67 "bootfile name" for interpretation with iSCSI.
>
> Without an allocated option, it might be possible
> to simply redefine the sname/66 and file/67 so
> that sname/66 beginning with "iscsi:" defines
> the iSCSI boot method.
>
>
> GENERAL COMMENTS ON DRAFT-02
>
> I'm not at all keen on the mechanism in draft-*-boot-02.
> The DHCP option should be more generic, as in
>
>   <bootprotocol>:<bootpath>
>
> and defined for iSCSI as
>
>   iscsi:<servername>[:<protocol>[:<port>[:<lun>[:<wwui>]]]]
>
> This would limit future options growth.
>
> Even better would be to define a DHCP option "boot protocol"
> and reuse the sname/66 and file/67 fields.  In the absence
> of the "boot protocol" option TFTP would be assumed.
>
> Other issues with the draft:
>
>  - if <servername> is a domain name then
>      - the "name server" DHCP option SHOULD
>        be provided
>      - <servername> SHOULD be a FQDN unless
>        the "domain name" option DHCP option
>        is provided
>
>  - <protocol> may be better to be textual, as
>    this allows variants on TCP (such as framing).
>    Default value is "tcp" with "tcp-*", "udp" and
>    "sctp" intended for future use.  Syntax is:
>
>       <protocol> ::= <lowerstring>
>                  ::= <null>
>       <lowerstring> ::= <plchar>
>                ::= <string><plchar>
>       <plchar> ::= <punctuation>
>                ::= <lchar>
>       <punctuation> ::= - | .
>       <lchar> ::= a | b | ... | z
>
> The syntax of all textual options should be defined using
> IETF BNF rather than in the text.
>
>  - The "LUN" field is a 16 byte hexadecimal
>    representation of the 8-byte LU number in hex.
>
>    does not allow for SCSI to redefine or expand
>    the LUN.  Although this is unlikely, I'd suggest
>    text like:
>
>    <LUN> is the SCSI logical unit number in hexadecimal.
>    The syntax is:
>
>       <LUN> ::= <hexoctet>
>             ::= <LUN><hexoctet>
>       <hexoctet> ::= <hexdigit><hexdigit0>
>       <hexdigit0> ::= 0 | 1 | ... | 9 | A | B | ... | F | a | b | ... | f
>       <hexdigit> ::= <hexdigit0> | <null>
>
>    If you do want a fixed-length field, then using BNF
>    can replace the somewhat unwieldy text
>
>       <lunoption> ::= :<lun> | <null>
>       <lun> ::= <hex1><hex1><hex1><hex1><hex1><hex1><hex1><hex1>
>       <hex1> ::= <hexdigit><hexdigit>
>       <hexdigit> ::= 0 | 1 | ... | 9 | A | B | ... | F | a | b | ... | f
>
> --
>  Glen Turner                                 Network Engineer
>  (08) 8303 3936      Australian Academic and Research Network
>  [email-masked]          http://www.aarnet.edu.au/
> --
>  The revolution will not be televised, it will be digitised
>

---

From: Glen Turner <[email-masked]>
Date: Fri, 01 Jun 2001 16:18:10 +0930

> 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
> 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

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 1 Jun 2001 10:24:11 -0700

Glen,

Regardless how robust you imagine iSCSI to be or become, it is of several
orders of greater complexity than TFTP or MTFTP, the preferred method of
obtaining a network boot image.  The initial concern being kicked around on
this thread was over the fact that each machine in a large enterprise would
need to be visited to initialize it with a shared secret for a secure boot
if diskless.  Trivial File Transfer Protocol is just that, trivial.  It is
well understood, can work within a slow and clumsy kernel, and can obtain a
secure initial boot image.  Use that boot image to then launch iSCSI.  If
you wish to include any option, use an existing professional management tool
combined with this initial boot image.  I see no reason to alter DHCP and I
would discourage the concept of using iSCSI for the initial boot in an
enterprise environment.

The advantage should be obvious.  Upgrades to this initial boot image is
possible without the need to revisit each machine.  The concern that this
then requires DHCP and TFTP network services for a boot to occur should be
weighed against the expense of updating each machine as iSCSI matures.  In
addition, as there is already a means to network boot, using the existing
standard provides an immediate solution that is stable and understood.  You
would not need to manage multiple methods for obtaining this initial boot
image.  A mode that captures this boot image where it is replayed until it
is rejected may provide better performance and make everyone happy as the
results would look the same.

Moving from direct attached drives should warrant this additional
consideration.  It should always be possible to set various defaults where
no intervention is needed to get the SCSI stack running into a boot device.
This should be possible for consumer items.  In which case even DHCP may not
be available.  That is a different problem all together.  Here you expect to
manage everything locally.  A floppy or CD may be used to create this
self-contained environment.  In this environment, DHCP is not likely
configurable to provide all the fun stuff being imagined.  Here you have a
need to get the code working through manual settings.

There is no justification to modify DHCP that I can see.

Doug