Black_David | 15 Sep 15:12 2008

FW: Nomcom call for candidates

I'm passing along this request from the Nominating Committee:

The 2008-9 IETF Nominating Committee needs your help.
We have started getting candidates.
If we are going to do our job in time, we have only 3 more weeks to get
enough candidates to have a reasonable pool for all the jobs.
At the moment, we do not have a reasonable pool for any jobs.

If you are willing to serve, please nominate yourself.
If there is someone you think would do a good job, please nominate them.

The web site at:
    http://wiki.tools.ietf.org/group/nomcom/08
Has the list of positions we are seeking people for, as well as tools
for
providing both nominations and feedback.

Alternatively, you can submit nominations by sending email to me.

Please help us.

Thank you,
Joel M. Halpern
jmh <at> joelhalpern.com
nomcom-chair <at> ietf.org

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
(Continue reading)

Michael Howard | 22 Sep 03:24 2008

no DHCP-assigned InitiatorName

I am writing this memo to the IETF IP Storage Working Group to voice my 
concern over the apparent lack of IETF or industry standard for having a 
DHCP server pass an InitiatorName to an iSCSI boot client.

This issue may be something that you are already aware of, and may be 
something that you are already working to address.

(I am going to ignore the related issues of CHAP username and secret)

rfc4173 [http://tools.ietf.org/html/rfc4173 Bootstrapping Clients using 
the Internet Small Computer System Interface (iSCSI) Protocol) defines 
the protocol for passing boot target information to an iSCSI boot client 
via DHCP options. Unfortunately, it does not define a mechanism for 
passing an InitiatorName to be used by the iSCSI boot initiator. The 
omission of this has led to differences in the InitiatorName in 
different iSCSI boot implementations.

Many iSCSI target servers depend upon the iSCSI InitiatorName to control 
visibility to target LUNs. The inability to control InitiatorName 
through DHCP leads to interoperability issues as one tries to 
dynamically move between systems with different iSCSI boot implementations.

I am not familiar with iSNS (Internet Storage Naming Service 
http://tools.ietf.org/html/rfc4171) but I assume that the InitiatorName 
probably plays a key role in identification.

I am familiar with several currently available implementations of iSCSI 
initiators ... hardware, firmware, and software. see listing below.

The hardware and firmware implementations of iSCSI boot initiators 
(Continue reading)

Julian Satran | 22 Sep 13:07 2008
Picon

Re: no DHCP-assigned InitiatorName

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

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.

Regards,
Julo




From: Michael Howard <michael.howard <at> scalent.com>
To: ips <at> ietf.org
Date: 09/21/2008 21:56
Subject: [Ips] no DHCP-assigned InitiatorName




I am writing this memo to the IETF IP Storage Working Group to voice my
concern over the apparent lack of IETF or industry standard for having a
DHCP server pass an InitiatorName to an iSCSI boot client.

This issue may be something that you are already aware of, and may be
something that you are already working to address.

(I am going to ignore the related issues of CHAP username and secret)

rfc4173 [http://tools.ietf.org/html/rfc4173 Bootstrapping Clients using
the Internet Small Computer System Interface (iSCSI) Protocol) defines
the protocol for passing boot target information to an iSCSI boot client
via DHCP options. Unfortunately, it does not define a mechanism for
passing an InitiatorName to be used by the iSCSI boot initiator. The
omission of this has led to differences in the InitiatorName in
different iSCSI boot implementations.

Many iSCSI target servers depend upon the iSCSI InitiatorName to control
visibility to target LUNs. The inability to control InitiatorName
through DHCP leads to interoperability issues as one tries to
dynamically move between systems with different iSCSI boot implementations.

I am not familiar with iSNS (Internet Storage Naming Service
http://tools.ietf.org/html/rfc4171) but I assume that the InitiatorName
probably plays a key role in identification.

I am familiar with several currently available implementations of iSCSI
initiators ... hardware, firmware, and software. see listing below.

The hardware and firmware implementations of iSCSI boot initiators
(QLogic, Intel, Broadcom, IBM) allow one to define static initiator and
target login information in EEPROM on the client. In addition, they all
support a DHCP assigned iSCSI boot target per RFC 4173.

The etherboot/gPXE implementation only supports assignment of iSCSI boot
parameters via DHCP.

Implementations generally construct the InitiatorName by trying to
include the DHCP option 12 hostname. They take a base iSCSI Qualified
Name prefix and concatenate the hostname supplied by the DHCP server.
You end up with:

 iqn.1987-05.com.intel:<hostname>
 iqn.2000-01.org.etherboot:<hostname>
 iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot
 iqn.1986-03.com.ibm.<11:22:33:44:55:66>.<hostname>

<hostname> represents the hostname provided in DHCP option 12.
<11.22.33.44.55.66> represents the MAC address of the initiator NIC.

This might work fine in a static data-center environment where dedicated
applications run on dedicated hardware. Even a mixed environment with
different vendors involved is generally not a problem as long as each
system is configured individually ... and as long as no system changes
are required.

However, data centers and data center configurations are not static.
They frequently have a need to move from one hardware configuration to
another. Common examples are a planned hardware upgrade of an existing
system and an emergency hardware replacement for a failed system. A more
extreme example would be an offsite disaster-recovery scenario.

Machine virtualization tools such as vmWare and Zen facilitate moving
images between systems, easing the transition between system hardware.

Data center virtualization systems such as Scalent automate assignment
of SAN-based applications to available servers in the server pool,
effectively enabling a data center to run any application on any
available physical or virtual machine.

Migrating iSCSI boot images from one system to another is problematic if
the iSCSI boot implementations differ between the old hardware and new
hardware. On many/most commercial iSCSI target servers the
visibility/mapping/zoning configuration would have to change because of
the differing iSCSI InitiatorName. This is a problem because it usually
requires coordination across organizational units.

Take the case where one has an application running on an IBM server
using iSCSI boot. iSCSI boot parameters are being assigned via DHCP. One
wishes to move this application to an HP server with an Intel NIC that
supports iSCSI boot. Both iSCSI initiators support DHCP assignment of
the iSCSI target. However, since the full InitiatorName is not specified
via DHCP, the SAN administrator must also make a change on the iSCSI SAN
storage controller in order to make the appropriate LUN(s) visible to
the new/different initiator name.

Vendor Extensions

Broadcom and IBM seem to have foreseen this oversight in rfc4713. From
available documentation it is unclear to me whether or not they have
adopted exactly the same mechanism as a workaround for assigning the
iSCSI boot initiator name. I am in the process of obtaining hardware so
that I can verify behavior.

Broadcom documentation indicates that they support a DHCP vendor
extension that allows one to fully specify the InitiatorName from the
DHCP server. Support for an option such as this would mean that
boot-from-iSCSI-SAN images could be moved between systems by only making
changes on the DHCP server. See
http://ftp.us.dell.com/network/Bcom_LAN_11.0_4.1_Manual_A01.exe

Draft IBM documentation at
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/39y9159.pdf
indicates that the initiator name can be set using DHCP vendor option
203 … but it isn’t very specific … and I have not been able to verify this.

I have also been told that the Microsoft WHQL (Windows Hardware Quality
Labs) requirements for iSCSI boot make reference to “DHCP option 203”. I
am trying to obtain these documents.


Conclusion

There needs to be a standard IETF mechanism, perhaps an extension to
rfc4713, that defines what InitiatorName is to be used when iSCSI booting.

I am interested in participating in the discussion and am willing to
help however I can.


Michael Howard
Scalent Systems
michael.howard <at> scalent.com

----

Internet Small Computer Systems Interface (iSCSI)
http://tools.ietf.org/html/rfc3720

Internet Small Computer Systems Interface (iSCSI)
Naming and Discovery
http://tools.ietf.org/html/rfc3721

String Profile for Internet Small Computer
Systems Interface (iSCSI) Names
http://tools.ietf.org/html/rfc3722

Internet Storage Naming Service (iSNS)
http://tools.ietf.org/html/rfc4171

Bootstrapping Clients using the Internet
Small Computer System Interface (iSCSI) Protocol
http://tools.ietf.org/html/rfc4173

----

QLogic
* hardware iSCSI HBAs
* proprietary drivers for Win + Linux
* http://qlogic.com/Products/SAN_products_iSCSI.aspx
* supports DHCP assignment of target parameters

Intel
* iSCSI boot firmware for selected server-class NICs
* works in conjunction with MSFT initiator under >= win2k3
* http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=15864
* iqn.1987-05.com.intel:<hostname>

Broadcom
* iSCSI boot firmware for selected server-class NICs
* works in conjunction with MSFT initiator under >= win2k3
* http://www.broadcom.com/collateral/wp/FSC-BRCM-iSCSI-BOOT-White-Paper.pdf
* iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot
* Vendor extension DHCP option 43 suboption 203

IBM
* iSCSI NIC firmware in selected blades/servers
* works in conjunction with MSFT initiator under >= win2k3
* http://www.alphaworks.ibm.com/tech/sancommander
* ftp://ftp.software.ibm.com/systems/support/system_x_pdf/39y9159.pdf
* vendor extension option 203

emBoot
* software PXE/UNDI implementation
* proprietary windows initiator under XP & win2k with netBoot/i
* works with MSFT initiator under >= win2k3
* http://emboot.com/iscsiboot.htm

emBoot uses a proprietary mechanism in their netBoot/i and winBoot/i
products to assign login information to their software initiator. emBoot
does not support DHCP assignment of iSCSI boot parameters. Therefore,
the discussion of DHCP assignment of iSCSI boot parameters is not
applicable to emBoot’s current products.

etherboot/gPXE
* open source PXE/UNDI/NIC driver implementation
* works with MSFT initiator under >= win2k3
* http://etherboot.org/wiki/index.php
* only (?) supports DHCP assignment of iSCSI boot parameters per RFC 1473.


THE END
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips



_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Michael Howard | 22 Sep 15:16 2008

Re: 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
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips

Julian Satran | 22 Sep 15:28 2008
Picon

Re: no DHCP-assigned InitiatorName

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 <michael.howard <at> scalent.com>
To: Julian Satran/Haifa/IBM <at> IBMIL
Cc: ips <at> ietf.org
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



_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Michael Howard | 22 Sep 17:41 2008

Re: no DHCP-assigned InitiatorName


Julian Satran wrote:
> 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 do not understand what you are trying to say.

On x86 architectures the iBFT (iSCSI Boot Firmware Table) is used to 
pass iSCSI boot parameters to the OS. The iSCSI boot parameters include 
target information and InitiatorName ... so that a new session 
(attaching to the same LUN) can be established by the OS driver.

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

I am arguing that "very little else" is actually too little ;)

> Sivan may give you a pointer to CbCS.

OK

Michael
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips

Black_David | 22 Sep 17:41 2008

Re: no DHCP-assigned InitiatorName

CbCS is a technology for which there is little to no current product
support.  As a security technology, it does not strike me as a good
solution to the issue that Michael raises, which is basically an
automatic configuration issue.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

From: ips-bounces <at> ietf.org [mailto:ips-bounces <at> ietf.org] On Behalf Of Julian Satran
Sent: Monday, September 22, 2008 9:29 AM
To: Michael Howard
Cc: Sivan Tal; ips <at> ietf.org
Subject: Re: [Ips] no DHCP-assigned InitiatorName

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 <michael.howard <at> scalent.com>
To: Julian Satran/Haifa/IBM <at> IBMIL
Cc: ips <at> ietf.org
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



_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips
Black_David | 22 Sep 18:04 2008

no DHCP-assigned InitiatorName: Procedural notes

A couple of procedural notes:

> I am writing this memo to the IETF IP Storage Working Group to voice
> my concern over the apparent lack of IETF or industry standard for
> having a DHCP server pass an InitiatorName to an iSCSI boot client.

The IP Storage WG has been closed, BUT this list is still a fine place
to discuss this sort of topic, and it can be addressed via an individual
Internet-Draft (a WG is not required to do work).

> This issue may be something that you are already aware of, and may be 
> something that you are already working to address.
> 
> (I am going to ignore the related issues of CHAP username and secret)

Considering that DHCP has no real security, one cannot pass the CHAP
secret in the clear via DHCP.  The CHAP username should not cause a
problem.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips

Michael Howard | 22 Sep 19:12 2008

Re: no DHCP-assigned InitiatorName: Procedural notes

Black_David <at> emc.com wrote:
> A couple of procedural notes:
> 
>> I am writing this memo to the IETF IP Storage Working Group to voice
>> my concern over the apparent lack of IETF or industry standard for
>> having a DHCP server pass an InitiatorName to an iSCSI boot client.
> 
> The IP Storage WG has been closed, BUT this list is still a fine place
> to discuss this sort of topic, and it can be addressed via an individual
> Internet-Draft (a WG is not required to do work).

Understood.

>> This issue may be something that you are already aware of, and may be 
>> something that you are already working to address.
>>
>> (I am going to ignore the related issues of CHAP username and secret)
> 
> Considering that DHCP has no real security, one cannot pass the CHAP
> secret in the clear via DHCP.  The CHAP username should not cause a
> problem.

I agree.

Michael
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips

Julian Satran | 22 Sep 19:19 2008
Picon

Re: no DHCP-assigned InitiatorName

Michael,

I will have to defer to boot RFC authors. My 2 cents is that DHCP "practice" has already several mechanisms to name the initiator (most based on what the DHCP agents present to the DHCP server - like the real of "fake" (for VMs) MAC address. And I don't know how the iBFT interacts (or is supposed to) with a DHCP server.

Regards,
Julo


From: Michael Howard <michael.howard <at> scalent.com>
To: Julian Satran/Haifa/IBM <at> IBMIL
Cc: ips <at> ietf.org, Sivan Tal/Haifa/IBM <at> IBMIL
Date: 09/22/2008 11:42
Subject: Re: [Ips] no DHCP-assigned InitiatorName






Julian Satran wrote:
> 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 do not understand what you are trying to say.

On x86 architectures the iBFT (iSCSI Boot Firmware Table) is used to
pass iSCSI boot parameters to the OS. The iSCSI boot parameters include
target information and InitiatorName ... so that a new session
(attaching to the same LUN) can be established by the OS driver.

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

I am arguing that "very little else" is actually too little ;)

> Sivan may give you a pointer to CbCS.

OK


Michael



_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www.ietf.org/mailman/listinfo/ips

Gmane