Re: no DHCP-assigned InitiatorName

This is a multipart message in MIME format.
--===============1775872133==
Content-Type: multipart/alternative; boundary="=_alternative 004A0FA6852574CC_="

This is a multipart message in MIME format.
--=_alternative 004A0FA6852574CC_=
Content-Type: text/plain; charset="US-ASCII"

Michael,

I think that some of the OSs have the initiator name wired into the image 
and boot providers will have to set this name.
I am not sure how what exactly is required for each version.
The boot RFC defines where the image comes from but very little else.

Sivan may give you a pointer to CbCS.

Regards,
Julo





From:
Michael Howard <[email protected]>
To:
Julian Satran/Haifa/IBM@IBMIL
Cc:
[email protected]
Date:
09/22/2008 09:19
Subject:
Re: [Ips] no DHCP-assigned InitiatorName





Julian Satran wrote:
> Michael - I am not sure what you are looking for? A standard parameter 
> as those described by the iBOOT RFC?

Yes, I am looking for a specific DHCP parameter that defines what 
InitiatorName is to be used by the iSCSI boot client.

It seems to me that the purpose of RFC4173 was/is to allow stateless 
clients to boot. The target parameters that are specified in RFC4173 are 
necessary, but not sufficient. On many commercial iSCSI target servers 
you must have the InitiatorName in order to be able to log in to the 
target. This is the case for NetApp and SANRAD, and I strongly for many 
others.

> In any case the initiator name is not the only way to control what a 
> server will access.
> 
> CbCS (stands for Credential Based Command Security) available for any 
> SCSI device at the SCSI layer (see the T10 site) is probably 
> safer/better and does not depend on things that can be so easy faked by 
> an initiator as the initiator name and may be easier to deploy.

This is not something that I am familiar with ...

*** 10 minutes later ***

I could find no reference to CbCS or Command Based Command Security at 
the NetApp support site now.netapp.com

A quick search at www.t10.org didn't turn anything up either ... I'll 
keep looking.


There may (and should) be other/better security mechanisms working their 
way through the standardization and implementation processes.

As a practical measure, I believe that a DHCP-supplied InitiatorName is 
needed because InitiatorName is required by many commercial iSCSI target 
servers.


Michael




--=_alternative 004A0FA6852574CC_=
Content-Type: text/html; charset="US-ASCII"

<font size=2 face="sans-serif">Michael,</font>
<br>
<br><font size=2 face="sans-serif">I think that some of the OSs have the
initiator name wired into the image and boot providers will have to set
this name.</font>
<br><font size=2 face="sans-serif">I am not sure how what exactly is required
for each version.</font>
<br><font size=2 face="sans-serif">The boot RFC defines where the image
comes from but very little else.</font>
<br>
<br><font size=2 face="sans-serif">Sivan may give you a pointer to CbCS.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Julo</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Michael Howard &lt;[email protected]&gt;</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">Julian Satran/Haifa/IBM@IBMIL</font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">[email protected]</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">09/22/2008 09:19</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [Ips] no DHCP-assigned InitiatorName</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2><br>
<br>
Julian Satran wrote:<br>
&gt; Michael - I am not sure what you are looking for? A standard parameter
<br>
&gt; as those described by the iBOOT RFC?<br>
<br>
Yes, I am looking for a specific DHCP parameter that defines what <br>
InitiatorName is to be used by the iSCSI boot client.<br>
<br>
It seems to me that the purpose of RFC4173 was/is to allow stateless <br>
clients to boot. The target parameters that are specified in RFC4173 are
<br>
necessary, but not sufficient. On many commercial iSCSI target servers
<br>
you must have the InitiatorName in order to be able to log in to the <br>
target. This is the case for NetApp and SANRAD, and I strongly for many
<br>
others.<br>
<br>
&gt; In any case the initiator name is not the only way to control what
a <br>
&gt; server will access.<br>
&gt; <br>
&gt; CbCS (stands for Credential Based Command Security) available for
any <br>
&gt; SCSI device at the SCSI layer (see the T10 site) is probably <br>
&gt; safer/better and does not depend on things that can be so easy faked
by <br>
&gt; an initiator as the initiator name and may be easier to deploy.<br>
<br>
This is not something that I am familiar with ...<br>
<br>
*** 10 minutes later ***<br>
<br>
I could find no reference to CbCS or Command Based Command Security at
<br>
the NetApp support site now.netapp.com<br>
<br>
A quick search at </font></tt><a href=www.t10.org><tt><font size=2>www.t10.org</font></tt></a><tt><font size=2>
didn't turn anything up either ... I'll <br>
keep looking.<br>
<br>
<br>
There may (and should) be other/better security mechanisms working their
<br>
way through the standardization and implementation processes.<br>
<br>
As a practical measure, I believe that a DHCP-supplied InitiatorName is
<br>
needed because InitiatorName is required by many commercial iSCSI target
<br>
servers.<br>
<br>
<br>
Michael<br>
</font></tt><br>
<br>
<br>
--=_alternative 004A0FA6852574CC_=--

--===============1775872133==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ips

--===============1775872133==--