From ips-bounces@ietf.org Mon Sep 15 06:12:29 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28F73A6947; Mon, 15 Sep 2008 06:12:29 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3658B3A6935; Mon, 15 Sep 2008 06:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.52 X-Spam-Level: X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJhaWEI1Niqj; Mon, 15 Sep 2008 06:12:28 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 447E73A69D2; Mon, 15 Sep 2008 06:12:28 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m8FDCXOa010404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2008 09:12:36 -0400 (EDT) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Fri, 15 Aug 2008 09:13:54 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m8FDC9u2004706; Mon, 15 Sep 2008 09:12:19 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Sep 2008 09:12:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Sep 2008 09:12:08 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A8E9565@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom call for candidates thread-index: AckU+UbnvZqqwdnNSQKq9qOu3sb9qwAQmM1Q To: , , X-OriginalArrivalTime: 15 Sep 2008 13:12:10.0499 (UTC) FILETIME=[A96CD530:01C91734] X-RSA-Inspected: yes X-RSA-Classifications: X-RSA-Action: allow Subject: [Ips] FW: Nomcom call for candidates X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org 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@joelhalpern.com nomcom-chair@ietf.org _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Sep 21 18:55:42 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C033A6C5C; Sun, 21 Sep 2008 18:55:42 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6565C3A6C4F for ; Sun, 21 Sep 2008 18:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.951 X-Spam-Level: ** X-Spam-Status: No, score=2.951 tagged_above=-999 required=5 tests=[FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+jq6626uF63 for ; Sun, 21 Sep 2008 18:24:56 -0700 (PDT) Received: from mymail.scalent.com (69-233-57-200.ded.pacbell.net [69.233.57.200]) by core3.amsl.com (Postfix) with ESMTP id ACD293A6C40 for ; Sun, 21 Sep 2008 18:24:56 -0700 (PDT) Received: from exchange.scalent.central ([192.168.151.1]) by mymail.scalent.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Sep 2008 18:24:50 -0700 Received: from [192.168.0.119] ([10.10.100.77]) by exchange.scalent.central with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Sep 2008 18:24:50 -0700 Message-ID: <48D6F3EB.1080400@scalent.com> Date: Sun, 21 Sep 2008 21:24:59 -0400 From: Michael Howard User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ips@ietf.org X-OriginalArrivalTime: 22 Sep 2008 01:24:50.0278 (UTC) FILETIME=[01F94860:01C91C52] Subject: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org 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: iqn.2000-01.org.etherboot: iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot iqn.1986-03.com.ibm.<11:22:33:44:55:66>. 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 =85 but it isn=92t very specific =85 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 =93DHCP option 203=94. = 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@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 >=3D win2k3 * http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=3D15864 * iqn.1987-05.com.intel: Broadcom * iSCSI boot firmware for selected server-class NICs * works in conjunction with MSFT initiator under >=3D 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 >=3D 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 >=3D 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=92s current products. etherboot/gPXE * open source PXE/UNDI/NIC driver implementation * works with MSFT initiator under >=3D win2k3 * http://etherboot.org/wiki/index.php * only (?) supports DHCP assignment of iSCSI boot parameters per RFC 1473. THE END _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 22 04:10:32 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997713A69D7; Mon, 22 Sep 2008 04:10:32 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D9F3A698F for ; Mon, 22 Sep 2008 04:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRpePKsKU6F1 for ; Mon, 22 Sep 2008 04:10:19 -0700 (PDT) Received: from mtagate7.de.ibm.com (mtagate7.de.ibm.com [195.212.29.156]) by core3.amsl.com (Postfix) with ESMTP id 9038A3A69B1 for ; Mon, 22 Sep 2008 04:10:18 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id m8MB7f8c163680 for ; Mon, 22 Sep 2008 11:07:41 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8MB7fLd569490 for ; Mon, 22 Sep 2008 13:07:41 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8MB7cI9008586 for ; Mon, 22 Sep 2008 13:07:38 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8MB7cCP008583; Mon, 22 Sep 2008 13:07:38 +0200 In-Reply-To: <48D6F3EB.1080400@scalent.com> References: <48D6F3EB.1080400@scalent.com> To: Michael Howard MIME-Version: 1.0 X-KeepSent: 51EB8C4B:4A802DE0-852574CC:003C9899; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V85_08052008 August 05, 2008 From: Julian Satran Message-ID: Date: Mon, 22 Sep 2008 07:07:35 -0400 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.1|February 07, 2008) at 22/09/2008 14:07:38, Serialize complete at 22/09/2008 14:07:38 Cc: ips@ietf.org Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1724665744==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1724665744== Content-Type: multipart/alternative; boundary="=_alternative 003D1C63852574CC_=" This is a multipart message in MIME format. --=_alternative 003D1C63852574CC_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Michael - I am not sure what you are looking for? A standard parameter as=20 those described by the iBOOT RFC? In any case the initiator name is not the only way to control what a=20 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=20 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 To: ips@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=20 concern over the apparent lack of IETF or industry standard for having a=20 DHCP server pass an InitiatorName to an iSCSI boot client. This issue may be something that you are already aware of, and may be=20 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=20 the Internet Small Computer System Interface (iSCSI) Protocol) defines=20 the protocol for passing boot target information to an iSCSI boot client=20 via DHCP options. Unfortunately, it does not define a mechanism for=20 passing an InitiatorName to be used by the iSCSI boot initiator. The=20 omission of this has led to differences in the InitiatorName in=20 different iSCSI boot implementations. Many iSCSI target servers depend upon the iSCSI InitiatorName to control=20 visibility to target LUNs. The inability to control InitiatorName=20 through DHCP leads to interoperability issues as one tries to=20 dynamically move between systems with different iSCSI boot=20 implementations. I am not familiar with iSNS (Internet Storage Naming Service=20 http://tools.ietf.org/html/rfc4171) but I assume that the InitiatorName=20 probably plays a key role in identification. I am familiar with several currently available implementations of iSCSI=20 initiators ... hardware, firmware, and software. see listing below. The hardware and firmware implementations of iSCSI boot initiators=20 (QLogic, Intel, Broadcom, IBM) allow one to define static initiator and=20 target login information in EEPROM on the client. In addition, they all=20 support a DHCP assigned iSCSI boot target per RFC 4173. The etherboot/gPXE implementation only supports assignment of iSCSI boot=20 parameters via DHCP. Implementations generally construct the InitiatorName by trying to=20 include the DHCP option 12 hostname. They take a base iSCSI Qualified=20 Name prefix and concatenate the hostname supplied by the DHCP server.=20 You end up with: iqn.1987-05.com.intel: iqn.2000-01.org.etherboot: iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot iqn.1986-03.com.ibm.<11:22:33:44:55:66>. 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=20 applications run on dedicated hardware. Even a mixed environment with=20 different vendors involved is generally not a problem as long as each=20 system is configured individually ... and as long as no system changes=20 are required. However, data centers and data center configurations are not static.=20 They frequently have a need to move from one hardware configuration to=20 another. Common examples are a planned hardware upgrade of an existing=20 system and an emergency hardware replacement for a failed system. A more=20 extreme example would be an offsite disaster-recovery scenario. Machine virtualization tools such as vmWare and Zen facilitate moving=20 images between systems, easing the transition between system hardware. Data center virtualization systems such as Scalent automate assignment=20 of SAN-based applications to available servers in the server pool,=20 effectively enabling a data center to run any application on any=20 available physical or virtual machine. Migrating iSCSI boot images from one system to another is problematic if=20 the iSCSI boot implementations differ between the old hardware and new=20 hardware. On many/most commercial iSCSI target servers the=20 visibility/mapping/zoning configuration would have to change because of=20 the differing iSCSI InitiatorName. This is a problem because it usually=20 requires coordination across organizational units. Take the case where one has an application running on an IBM server=20 using iSCSI boot. iSCSI boot parameters are being assigned via DHCP. One=20 wishes to move this application to an HP server with an Intel NIC that=20 supports iSCSI boot. Both iSCSI initiators support DHCP assignment of=20 the iSCSI target. However, since the full InitiatorName is not specified=20 via DHCP, the SAN administrator must also make a change on the iSCSI SAN=20 storage controller in order to make the appropriate LUN(s) visible to=20 the new/different initiator name. Vendor Extensions Broadcom and IBM seem to have foreseen this oversight in rfc4713. From=20 available documentation it is unclear to me whether or not they have=20 adopted exactly the same mechanism as a workaround for assigning the=20 iSCSI boot initiator name. I am in the process of obtaining hardware so=20 that I can verify behavior. Broadcom documentation indicates that they support a DHCP vendor=20 extension that allows one to fully specify the InitiatorName from the=20 DHCP server. Support for an option such as this would mean that=20 boot-from-iSCSI-SAN images could be moved between systems by only making=20 changes on the DHCP server. See=20 http://ftp.us.dell.com/network/Bcom=5FLAN=5F11.0=5F4.1=5FManual=5FA01.exe Draft IBM documentation at=20 ftp://ftp.software.ibm.com/systems/support/system=5Fx=5Fpdf/39y9159.pdf=20 indicates that the initiator name can be set using DHCP vendor option=20 203 ? but it isn?t very specific ? and I have not been able to verify=20 this. I have also been told that the Microsoft WHQL (Windows Hardware Quality=20 Labs) requirements for iSCSI boot make reference to ?DHCP option 203?. I=20 am trying to obtain these documents. Conclusion There needs to be a standard IETF mechanism, perhaps an extension to=20 rfc4713, that defines what InitiatorName is to be used when iSCSI booting. I am interested in participating in the discussion and am willing to=20 help however I can. Michael Howard Scalent Systems michael.howard@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=5Fproducts=5FiSCSI.aspx * supports DHCP assignment of target parameters Intel * iSCSI boot firmware for selected server-class NICs * works in conjunction with MSFT initiator under >=3D win2k3 * http://downloadcenter.intel.com/Detail=5FDesc.aspx?DwnldID=3D15864 * iqn.1987-05.com.intel: Broadcom * iSCSI boot firmware for selected server-class NICs * works in conjunction with MSFT initiator under >=3D win2k3 *=20 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 >=3D win2k3 * http://www.alphaworks.ibm.com/tech/sancommander * ftp://ftp.software.ibm.com/systems/support/system=5Fx=5Fpdf/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 >=3D win2k3 * http://emboot.com/iscsiboot.htm emBoot uses a proprietary mechanism in their netBoot/i and winBoot/i=20 products to assign login information to their software initiator. emBoot=20 does not support DHCP assignment of iSCSI boot parameters. Therefore,=20 the discussion of DHCP assignment of iSCSI boot parameters is not=20 applicable to emBoot?s current products. etherboot/gPXE * open source PXE/UNDI/NIC driver implementation * works with MSFT initiator under >=3D win2k3 * http://etherboot.org/wiki/index.php * only (?) supports DHCP assignment of iSCSI boot parameters per RFC 1473. THE END =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --=_alternative 003D1C63852574CC_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Michael - I am not sure what you are loo= king 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 Co= mmand 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@sc= alent.com>
To: ips@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.<= br>
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= =5FLAN=5F11.0=5F4.1=5FManual=5FA01.exe
Draft IBM documentation at
ftp://ftp.software.ibm.com/systems/su= pport/system=5Fx=5Fpdf/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 ab= le 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&= #8221;. 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.<= br>
I am interested in participating in the discussion and am willing to
help however I can.


Michael Howard
Scalent Systems
michael.howard@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=5Fproducts=5FiSCSI.as= px
* supports DHCP assignment of target parameters

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

Broadcom
* iSCSI boot firmware for selected server-class NICs
* works in conjunction with MSFT initiator under >=3D win2k3
* http://www.broadcom.com/collate= ral/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 >=3D win2k3
* http://www.alphaworks.ibm.com/tech/sancommander=
* ftp://ftp.software.ibm.com/system= s/support/system=5Fx=5Fpdf/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 >=3D 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 >=3D win2k3
* http://etherboot.org/wiki/index.php=
* only (?) supports DHCP assignment of iSCSI boot parameters per RFC 1473.<= br>

THE END
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www.ietf.org/mailman/listinfo/ips



--=_alternative 003D1C63852574CC_=-- --===============1724665744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============1724665744==-- From ips-bounces@ietf.org Mon Sep 22 06:16:19 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372CB28C0FC; Mon, 22 Sep 2008 06:16:19 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E96A3A6988 for ; Mon, 22 Sep 2008 06:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OthoT6CNRdyr for ; Mon, 22 Sep 2008 06:16:17 -0700 (PDT) Received: from mymail.scalent.com (69-233-57-200.ded.pacbell.net [69.233.57.200]) by core3.amsl.com (Postfix) with ESMTP id 649B328C108 for ; Mon, 22 Sep 2008 06:16:17 -0700 (PDT) Received: from exchange.scalent.central ([192.168.151.1]) by mymail.scalent.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 06:16:12 -0700 Received: from [192.168.0.119] ([10.10.100.77]) by exchange.scalent.central with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 06:16:11 -0700 Message-ID: <48D79AA6.9040104@scalent.com> Date: Mon, 22 Sep 2008 09:16:22 -0400 From: Michael Howard User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Julian Satran References: <48D6F3EB.1080400@scalent.com> In-Reply-To: X-OriginalArrivalTime: 22 Sep 2008 13:16:11.0708 (UTC) FILETIME=[6216A7C0:01C91CB5] Cc: ips@ietf.org Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org 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@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 22 06:29:26 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE023A6AF2; Mon, 22 Sep 2008 06:29:26 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4D763A68BA for ; Mon, 22 Sep 2008 06:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTUX-e1434Hq for ; Mon, 22 Sep 2008 06:29:20 -0700 (PDT) Received: from mtagate3.de.ibm.com (mtagate3.de.ibm.com [195.212.29.152]) by core3.amsl.com (Postfix) with ESMTP id 408C328C0CF for ; Mon, 22 Sep 2008 06:29:19 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id m8MDT4IO278110 for ; Mon, 22 Sep 2008 13:29:04 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8MDT3PX2936854 for ; Mon, 22 Sep 2008 15:29:03 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8MDT0xf016670 for ; Mon, 22 Sep 2008 15:29:00 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8MDT0t0016667; Mon, 22 Sep 2008 15:29:00 +0200 In-Reply-To: <48D79AA6.9040104@scalent.com> References: <48D6F3EB.1080400@scalent.com> <48D79AA6.9040104@scalent.com> To: Michael Howard MIME-Version: 1.0 X-KeepSent: 2B1DCFAA:18C9A07A-852574CC:004985AD; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V85_08052008 August 05, 2008 From: Julian Satran Message-ID: Date: Mon, 22 Sep 2008 09:28:59 -0400 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.1|February 07, 2008) at 22/09/2008 16:29:00, Serialize complete at 22/09/2008 16:29:00 Cc: Sivan Tal , ips@ietf.org Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1775872133==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org 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 To: Julian Satran/Haifa/IBM@IBMIL Cc: ips@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 --=_alternative 004A0FA6852574CC_= Content-Type: text/html; 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 <michael.howard@scalent.com>
To: Julian Satran/Haifa/IBM@IBMIL
Cc: ips@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



--=_alternative 004A0FA6852574CC_=-- --===============1775872133== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============1775872133==-- From ips-bounces@ietf.org Mon Sep 22 08:41:39 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4B23A68C9; Mon, 22 Sep 2008 08:41:39 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BAF73A686A for ; Mon, 22 Sep 2008 08:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.071 X-Spam-Level: * X-Spam-Status: No, score=1.071 tagged_above=-999 required=5 tests=[AWL=0.719, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul0yiIq923Qt for ; Mon, 22 Sep 2008 08:41:32 -0700 (PDT) Received: from mymail.scalent.com (69-233-57-200.ded.pacbell.net [69.233.57.200]) by core3.amsl.com (Postfix) with ESMTP id 6FFB628C1C8 for ; Mon, 22 Sep 2008 08:41:12 -0700 (PDT) Received: from exchange.scalent.central ([192.168.151.1]) by mymail.scalent.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 08:41:06 -0700 Received: from [192.168.0.119] ([10.10.100.77]) by exchange.scalent.central with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 08:41:05 -0700 Message-ID: <48D7BC9D.7060306@scalent.com> Date: Mon, 22 Sep 2008 11:41:17 -0400 From: Michael Howard User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Julian Satran References: <48D6F3EB.1080400@scalent.com> <48D79AA6.9040104@scalent.com> In-Reply-To: X-OriginalArrivalTime: 22 Sep 2008 15:41:05.0892 (UTC) FILETIME=[A039DA40:01C91CC9] Cc: Sivan Tal , ips@ietf.org Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org 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@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 22 08:41:46 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC05728C13F; Mon, 22 Sep 2008 08:41:46 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7723A69C6 for ; Mon, 22 Sep 2008 08:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZyxf+z7+-Mo for ; Mon, 22 Sep 2008 08:41:39 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 76D6F3A6935 for ; Mon, 22 Sep 2008 08:41:39 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m8MFfbN3026038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Sep 2008 11:41:37 -0400 (EDT) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor) for ; Mon, 22 Sep 2008 11:38:44 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m8MFfIog010523 for ; Mon, 22 Sep 2008 11:41:25 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Sep 2008 11:41:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Sep 2008 11:41:12 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A8A5EC3@CORPUSMX80A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] no DHCP-assigned InitiatorName thread-index: Ackct2b7OXnIhY0QSU+6tGn40Il3QAAEeU2w References: <48D6F3EB.1080400@scalent.com><48D79AA6.9040104@scalent.com> To: X-OriginalArrivalTime: 22 Sep 2008 15:41:11.0801 (UTC) FILETIME=[A3BF7E90:01C91CC9] X-RSA-Inspected: yes X-RSA-Classifications: X-RSA-Action: allow Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0493778013==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0493778013== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C91CC9.A3E41668" This is a multi-part message in MIME format. ------_=_NextPart_001_01C91CC9.A3E41668 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran Sent: Monday, September 22, 2008 9:29 AM To: Michael Howard Cc: Sivan Tal; ips@ietf.org Subject: Re: [Ips] no DHCP-assigned InitiatorName =09 =09 Michael,=20 =09 I think that some of the OSs have the initiator name wired into the image and boot providers will have to set this name.=20 I am not sure how what exactly is required for each version.=20 The boot RFC defines where the image comes from but very little else.=20 =09 Sivan may give you a pointer to CbCS.=20 =09 Regards,=20 Julo=20 =09 =09 =09 =09 =09 From: Michael Howard =20 To: Julian Satran/Haifa/IBM@IBMIL=20 Cc: ips@ietf.org=20 Date: 09/22/2008 09:19=20 Subject: Re: [Ips] no DHCP-assigned InitiatorName ________________________________ =09 =09 Julian Satran wrote: > Michael - I am not sure what you are looking for? A standard parameter=20 > as those described by the iBOOT RFC? =09 Yes, I am looking for a specific DHCP parameter that defines what=20 InitiatorName is to be used by the iSCSI boot client. =09 It seems to me that the purpose of RFC4173 was/is to allow stateless=20 clients to boot. The target parameters that are specified in RFC4173 are=20 necessary, but not sufficient. On many commercial iSCSI target servers=20 you must have the InitiatorName in order to be able to log in to the=20 target. This is the case for NetApp and SANRAD, and I strongly for many=20 others. =09 > In any case the initiator name is not the only way to control what a=20 > server will access. >=20 > CbCS (stands for Credential Based Command Security) available for any=20 > SCSI device at the SCSI layer (see the T10 site) is probably=20 > safer/better and does not depend on things that can be so easy faked by=20 > an initiator as the initiator name and may be easier to deploy. =09 This is not something that I am familiar with ... =09 *** 10 minutes later *** =09 I could find no reference to CbCS or Command Based Command Security at=20 the NetApp support site now.netapp.com =09 A quick search at www.t10.org didn't turn anything up either ... I'll=20 keep looking. =09 =09 There may (and should) be other/better security mechanisms working their=20 way through the standardization and implementation processes. =09 As a practical measure, I believe that a DHCP-supplied InitiatorName is=20 needed because InitiatorName is required by many commercial iSCSI target=20 servers. =09 =09 Michael =09 =09 =09 =09 ------_=_NextPart_001_01C91CC9.A3E41668 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
CbCS is a=20 technology for which there is little to no current = product
support.  As a security technology, it does not = strike me as a=20 good
solution to=20 the issue that Michael raises, which is=20 basically an
automatic=20 configuration issue.

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

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

Michael, =

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

Sivan may give you a pointer to = CbCS.=20

Regards,
Julo




From:=20 Michael Howard=20 <michael.howard@scalent.com>=20
To:=20 Julian = Satran/Haifa/IBM@IBMIL=20
Cc:=20 ips@ietf.org=20
Date:=20 09/22/2008 09:19=20
Subject:=20 Re: [Ips] no DHCP-assigned=20 InitiatorName






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

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

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

> In any case the initiator name is not the = only=20 way to control what a
> server will access.
>
> = CbCS=20 (stands for Credential Based Command Security) available for any =
> SCSI=20 device at the SCSI layer (see the T10 site) is probably
> = safer/better=20 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=20 not something that I am familiar with ...

*** 10 minutes later=20 ***

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

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


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

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


Michael



<= /BODY> ------_=_NextPart_001_01C91CC9.A3E41668-- --===============0493778013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============0493778013==-- From ips-bounces@ietf.org Mon Sep 22 09:05:20 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B023A6B8C; Mon, 22 Sep 2008 09:05:20 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5746B3A6AA6 for ; Mon, 22 Sep 2008 09:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTG7szQaNdYO for ; Mon, 22 Sep 2008 09:05:18 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 2DE183A6B8C for ; Mon, 22 Sep 2008 09:05:17 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m8MG4lSW028268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 12:04:48 -0400 (EDT) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Mon, 22 Sep 2008 12:01:52 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m8MG4UGS028937; Mon, 22 Sep 2008 12:04:34 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Sep 2008 12:04:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Sep 2008 12:04:32 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A8A5EC6@CORPUSMX80A.corp.emc.com> In-Reply-To: <48D6F3EB.1080400@scalent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: no DHCP-assigned InitiatorName: Procedural notes thread-index: AckcVliDYT5YMyWxSbe1WCbaPwxZfQAddVrw References: <48D6F3EB.1080400@scalent.com> To: , X-OriginalArrivalTime: 22 Sep 2008 16:04:33.0516 (UTC) FILETIME=[E73C3AC0:01C91CCC] X-RSA-Inspected: yes X-RSA-Classifications: X-RSA-Action: allow Subject: [Ips] no DHCP-assigned InitiatorName: Procedural notes X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org 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@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 22 10:12:57 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583D928C1D2; Mon, 22 Sep 2008 10:12:57 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC46128C160 for ; Mon, 22 Sep 2008 10:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.891 X-Spam-Level: X-Spam-Status: No, score=0.891 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK51+yVbwy-Z for ; Mon, 22 Sep 2008 10:12:55 -0700 (PDT) Received: from mymail.scalent.com (69-233-57-200.ded.pacbell.net [69.233.57.200]) by core3.amsl.com (Postfix) with ESMTP id 31B663A67A1 for ; Mon, 22 Sep 2008 10:12:44 -0700 (PDT) Received: from exchange.scalent.central ([192.168.151.1]) by mymail.scalent.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 10:12:10 -0700 Received: from [192.168.0.119] ([10.10.100.77]) by exchange.scalent.central with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 10:12:09 -0700 Message-ID: <48D7D1F5.6050301@scalent.com> Date: Mon, 22 Sep 2008 13:12:21 -0400 From: Michael Howard User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Black_David@emc.com References: <48D6F3EB.1080400@scalent.com> <9FA859626025B64FBC2AF149D97C944A8A5EC6@CORPUSMX80A.corp.emc.com> In-Reply-To: <9FA859626025B64FBC2AF149D97C944A8A5EC6@CORPUSMX80A.corp.emc.com> X-OriginalArrivalTime: 22 Sep 2008 17:12:10.0033 (UTC) FILETIME=[591B9A10:01C91CD6] Cc: ips@ietf.org Subject: Re: [Ips] no DHCP-assigned InitiatorName: Procedural notes X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Black_David@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@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 22 10:22:24 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087933A6C3F; Mon, 22 Sep 2008 10:22:24 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A1C3A6C3F for ; Mon, 22 Sep 2008 10:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB1I7TLpYp-f for ; Mon, 22 Sep 2008 10:22:21 -0700 (PDT) Received: from mtagate5.de.ibm.com (mtagate5.de.ibm.com [195.212.29.154]) by core3.amsl.com (Postfix) with ESMTP id 903F93A6C24 for ; Mon, 22 Sep 2008 10:22:21 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id m8MHK0CB342126 for ; Mon, 22 Sep 2008 17:20:00 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8MHJxlb4018252 for ; Mon, 22 Sep 2008 19:19:59 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8MHJxYo030743 for ; Mon, 22 Sep 2008 19:19:59 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8MHJxMn030737; Mon, 22 Sep 2008 19:19:59 +0200 In-Reply-To: <48D7BC9D.7060306@scalent.com> References: <48D6F3EB.1080400@scalent.com> <48D79AA6.9040104@scalent.com> <48D7BC9D.7060306@scalent.com> To: Michael Howard MIME-Version: 1.0 X-KeepSent: BBCF89D4:CCDF2FC8-852574CC:005E8F41; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V85_08052008 August 05, 2008 From: Julian Satran Message-ID: Date: Mon, 22 Sep 2008 13:19:58 -0400 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.1|February 07, 2008) at 22/09/2008 20:19:59, Serialize complete at 22/09/2008 20:19:59 Cc: Sivan Tal , Prasenjit Sarkar , ips@ietf.org Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1277100288==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1277100288== Content-Type: multipart/alternative; boundary="=_alternative 005F3552852574CC_=" This is a multipart message in MIME format. --=_alternative 005F3552852574CC_= Content-Type: text/plain; charset="US-ASCII" 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 To: Julian Satran/Haifa/IBM@IBMIL Cc: ips@ietf.org, Sivan Tal/Haifa/IBM@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 --=_alternative 005F3552852574CC_= Content-Type: text/html; charset="US-ASCII" 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@scalent.com>
To: Julian Satran/Haifa/IBM@IBMIL
Cc: ips@ietf.org, Sivan Tal/Haifa/IBM@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



--=_alternative 005F3552852574CC_=-- --===============1277100288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============1277100288==-- From ips-bounces@ietf.org Mon Sep 22 11:10:31 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 836253A6B6F; Mon, 22 Sep 2008 11:10:31 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66293A6BEB for ; Mon, 22 Sep 2008 11:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.783 X-Spam-Level: X-Spam-Status: No, score=0.783 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZJo-Di-nSlC for ; Mon, 22 Sep 2008 11:10:27 -0700 (PDT) Received: from mymail.scalent.com (69-233-57-200.ded.pacbell.net [69.233.57.200]) by core3.amsl.com (Postfix) with ESMTP id 99ED83A6AFF for ; Mon, 22 Sep 2008 11:10:27 -0700 (PDT) Received: from exchange.scalent.central ([192.168.151.1]) by mymail.scalent.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 11:10:16 -0700 Received: from [192.168.0.119] ([10.10.100.77]) by exchange.scalent.central with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 11:10:15 -0700 Message-ID: <48D7DF92.9030605@scalent.com> Date: Mon, 22 Sep 2008 14:10:26 -0400 From: Michael Howard User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Julian Satran References: <48D6F3EB.1080400@scalent.com> <48D79AA6.9040104@scalent.com> <48D7BC9D.7060306@scalent.com> In-Reply-To: X-OriginalArrivalTime: 22 Sep 2008 18:10:16.0069 (UTC) FILETIME=[76F27B50:01C91CDE] Cc: Sivan Tal , Prasenjit Sarkar , ips@ietf.org Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Julian Satran wrote: > 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. I agree that there are several different mechanisms that are used to construct the initiator name. In practice, what we have ended up with is: iqn.1987-05.com.intel: iqn.2000-01.org.etherboot: iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot iqn.1986-03.com.ibm.<11:22:33:44:55:66>. This is a problem because almost every commercially available iSCSI target uses the initiator name as an identification mechanism to control visibility to target LUNs. As a result, trying to move from one iSCSI boot initiator to another requires changes on the SAN storage controller (or iSCSI head) to reconfigure for the new initiator name. This is unnecessarily complicated and, in many commercial environments, forces coordination across different organizational units. > And I don't know how the iBFT interacts > (or is supposed to) with a DHCP server. There is no *direct* interaction between the DHCP server and the iBFT. Rather, the values get passed through the iSCSI boot initiator. The boot iSCSI initiator is responsible for populating the iBFT with the iSCSI parameters that are required to continue to boot the OS once it switches to its protected-mode drivers. The relevant fields in the iBFT are: * portal hostname/ip addr * portal port * target name * target lun * initiator name * CHAP stuff The iSCSI boot initiator fills in these fields regardless of whether the parameters come from EEPROM config or from a DHCP server. The values that are filled in are the same values used by the boot initiator for its iSCSI login. Michael _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 22 11:13:48 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3B628C104; Mon, 22 Sep 2008 11:13:48 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C74928C104 for ; Mon, 22 Sep 2008 11:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5rjK9fivyMc for ; Mon, 22 Sep 2008 11:13:46 -0700 (PDT) Received: from mymail.scalent.com (69-233-57-200.ded.pacbell.net [69.233.57.200]) by core3.amsl.com (Postfix) with ESMTP id 4218828C127 for ; Mon, 22 Sep 2008 11:13:46 -0700 (PDT) Received: from exchange.scalent.central ([192.168.151.1]) by mymail.scalent.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 11:13:40 -0700 Received: from [192.168.0.119] ([10.10.100.77]) by exchange.scalent.central with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 11:13:39 -0700 Message-ID: <48D7E05D.3010507@scalent.com> Date: Mon, 22 Sep 2008 14:13:49 -0400 From: Michael Howard User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Sivan Tal References: <48D6F3EB.1080400@scalent.com> <48D79AA6.9040104@scalent.com> In-Reply-To: X-OriginalArrivalTime: 22 Sep 2008 18:13:39.0314 (UTC) FILETIME=[F0173520:01C91CDE] Cc: ips@ietf.org, Julian Satran Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Thank you for the reference and explanation. This looks like it may be useful down the road as the standard becomes adopted and commercial implementations become available. Michael Sivan Tal wrote: > Michael, > > CbCS (Capability-based Command Security) is part of the SPC-4 (SCSI Primary > Commands) standard draft. > The current version is in > http://www.t10.org/ftp/t10/drafts/spc4/spc4r16.pdf > Clause 5.14.6 described Command Security, and sub-clause 5.14.6.8 describes > CbCS, which is currently the only SCSI command security technique. > > Using CbCS, the initiator provides credential to the target that authorizes > it to access the target logical unit. The credential does not contain an > initiator identity and it is obtained from a trusted third party (security > manager) and "signed" with HMAC (based on a symmetric key shared between > the security manager and the target). The credential (the Capability > descriptor) contains a DISCRIMINATOR field that can be set in a "vendor > specific" manner. One can use that field for initiator identifier. However, > it should be noted that when using CbCS you don't need this for > authorization. The access decision point is in the security manager and the > access enforcement point is in the target device, based on the credential. > The initiator authenticates only to the security manager, thus keeping the > device simple. This is especially valuable in virtualized environments. > > Sivan Tal > IBM. > > > > |------------> > | From: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |Julian Satran/Haifa/IBM | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | To: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |Michael Howard | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Cc: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |ips@ietf.org, Sivan Tal/Haifa/IBM@IBMIL | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Date: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |09/22/2008 09:29 AM | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | 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 | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | To: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |Julian Satran/Haifa/IBM@IBMIL | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Cc: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |ips@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@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 22 12:02:50 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F0728C18B; Mon, 22 Sep 2008 12:02:50 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1300228C18B for ; Mon, 22 Sep 2008 12:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5op5+v-6DANz for ; Mon, 22 Sep 2008 12:02:48 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by core3.amsl.com (Postfix) with ESMTP id A0AE93A6900 for ; Mon, 22 Sep 2008 12:02:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Sep 2008 00:32:22 +0530 Message-ID: <46A00B48CC54E4468EF6911F877AC4CA019D6922@blrx3m10.blr.amer.dell.com> In-Reply-To: <48D7DF92.9030605@scalent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] no DHCP-assigned InitiatorName Thread-Index: Ackc3qqMVrmRnBqKSTGRqJIZQNuhJQAAx8bQ References: <48D6F3EB.1080400@scalent.com><48D79AA6.9040104@scalent.com><48D7BC9D.7060306@scalent.com> <48D7DF92.9030605@scalent.com> From: To: , X-OriginalArrivalTime: 22 Sep 2008 19:02:23.0604 (UTC) FILETIME=[BF1A7340:01C91CE5] Cc: SIVANT@il.ibm.com, Prasenjit_Sarkar%IBMIL@il.ibm.com, ips@ietf.org Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org My 2cents on the issue. Please correct me if I am wrong. Shouldn't it be possible to configure the isns server with a set of possibly regex rules for the control path. If this not possible today, then it could possibly be the root to take towards standardizing. This can solve the problem of provisioning for dynamic boot environments with minimum changes to legacy iqn implementations, many of which would need to relearn to the new iqn mechanism that might end up as a result of this discussion. Instead of changing numerous configurations we could simply change the isns server control mechanism. Comments? -Shyam Iyer -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Michael Howard Sent: Monday, September 22, 2008 11:40 PM To: Julian Satran Cc: Sivan Tal; Prasenjit Sarkar; ips@ietf.org Subject: Re: [Ips] no DHCP-assigned InitiatorName Julian Satran wrote: > 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. I agree that there are several different mechanisms that are used to construct the initiator name. In practice, what we have ended up with is: iqn.1987-05.com.intel: iqn.2000-01.org.etherboot: iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot iqn.1986-03.com.ibm.<11:22:33:44:55:66>. This is a problem because almost every commercially available iSCSI target uses the initiator name as an identification mechanism to control visibility to target LUNs. As a result, trying to move from one iSCSI boot initiator to another requires changes on the SAN storage controller (or iSCSI head) to reconfigure for the new initiator name. This is unnecessarily complicated and, in many commercial environments, forces coordination across different organizational units. > And I don't know how the iBFT interacts (or is supposed to) with a > DHCP server. There is no *direct* interaction between the DHCP server and the iBFT. Rather, the values get passed through the iSCSI boot initiator. The boot iSCSI initiator is responsible for populating the iBFT with the iSCSI parameters that are required to continue to boot the OS once it switches to its protected-mode drivers. The relevant fields in the iBFT are: * portal hostname/ip addr * portal port * target name * target lun * initiator name * CHAP stuff The iSCSI boot initiator fills in these fields regardless of whether the parameters come from EEPROM config or from a DHCP server. The values that are filled in are the same values used by the boot initiator for its iSCSI login. Michael _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 22 12:28:42 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBEA3A6A38; Mon, 22 Sep 2008 12:28:42 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DB03A6A2B for ; Mon, 22 Sep 2008 12:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.66 X-Spam-Level: X-Spam-Status: No, score=0.66 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVriwLtQ6E6o for ; Mon, 22 Sep 2008 12:28:41 -0700 (PDT) Received: from mymail.scalent.com (69-233-57-200.ded.pacbell.net [69.233.57.200]) by core3.amsl.com (Postfix) with ESMTP id D31D83A6A5B for ; Mon, 22 Sep 2008 12:28:41 -0700 (PDT) Received: from exchange.scalent.central ([192.168.151.1]) by mymail.scalent.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 12:28:20 -0700 Received: from [192.168.0.119] ([10.10.100.77]) by exchange.scalent.central with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 12:28:19 -0700 Message-ID: <48D7F1DE.5060000@scalent.com> Date: Mon, 22 Sep 2008 15:28:30 -0400 From: Michael Howard User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Shyam_Iyer@Dell.com References: <48D6F3EB.1080400@scalent.com><48D79AA6.9040104@scalent.com><48D7BC9D.7060306@scalent.com> <48D7DF92.9030605@scalent.com> <46A00B48CC54E4468EF6911F877AC4CA019D6922@blrx3m10.blr.amer.dell.com> In-Reply-To: <46A00B48CC54E4468EF6911F877AC4CA019D6922@blrx3m10.blr.amer.dell.com> X-OriginalArrivalTime: 22 Sep 2008 19:28:19.0764 (UTC) FILETIME=[5EA59F40:01C91CE9] Cc: SIVANT@il.ibm.com, psarkar@almaden.ibm.com, ips@ietf.org, Julian_Satran@il.ibm.com Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Shyam_Iyer@Dell.com wrote: > My 2cents on the issue. Please correct me if I am wrong. Thank you for participating in this discussion. > Shouldn't it be possible to configure the isns server with a set of > possibly regex rules for the control path. If this not possible today, > then it could possibly be the root to take towards standardizing. I am not familiar enough with iSNS to comment. I have been exposed to about about a dozen commercial environments with some level of iSCSI use/experimentation. I am not aware that any of them were running iSNS servers. > This can solve the problem of provisioning for dynamic boot environments > with minimum changes to legacy iqn implementations, many of which would > need to relearn to the new iqn mechanism that might end up as a result > of this discussion. Frankly, my concern is that Broadcom/IBM already have a non-standard DHCP Vendor Option work-around for this problem. Adding a new/standardized InitiatorName DHCP option would not break existing initiator implementations. Vendors would integrate support for this new InitiatorName option into their code/firmware releases over time. > Instead of changing numerous configurations we could > simply change the isns server control mechanism. I need to do some homework regarding iSNS. > Comments? iSCSI is still a very small part of the market. I advocate addressing this deficiency sooner rather than later. Michael _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 22 12:44:25 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E85928C167; Mon, 22 Sep 2008 12:44:25 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B9D28C167 for ; Mon, 22 Sep 2008 12:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ax0+PlF0HP7 for ; Mon, 22 Sep 2008 12:44:23 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) by core3.amsl.com (Postfix) with ESMTP id A2EC83A6B40 for ; Mon, 22 Sep 2008 12:44:23 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-MimeOLE:Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:thread-index:References:From:To:Cc: Return-Path:X-OriginalArrivalTime; b=hxG0il6HrdU+EryIQxkx8reTEFJuUKHyT3VorJZaMwtKVEtfQKugKY+R qn5qpNJIb9bpGxieXBnT6PAfJ+QaFHru4yT9bR6GMKDFyMv61JfVa+v42 zr5Py6aMfaD+fHW; X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Sep 2008 14:46:01 -0500 Message-ID: <42D8A6CDC96A5A4D8D91DE26991A51AA02016F63@ausx3mpc108.aus.amer.dell.com> In-Reply-To: <48D7F1DE.5060000@scalent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] no DHCP-assigned InitiatorName thread-index: Ackc6XVrlRzKxSf0TEy+wtYv9BwVHAAAXBXQ References: <48D6F3EB.1080400@scalent.com><48D79AA6.9040104@scalent.com><48D7BC9D.7060306@scalent.com><48D7DF92.9030605@scalent.com><46A00B48CC54E4468EF6911F877AC4CA019D6922@blrx3m10.blr.amer.dell.com> <48D7F1DE.5060000@scalent.com> From: To: , X-OriginalArrivalTime: 22 Sep 2008 19:44:18.0985 (UTC) FILETIME=[9A632190:01C91CEB] Cc: SIVANT@il.ibm.com, psarkar@almaden.ibm.com, ips@ietf.org, G_Chawla@Dell.com, Julian_Satran@il.ibm.com Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org My 2 cents based on my understanding of iSNS. - iSNS clients (initiators and targets) need to have an IQN address before they register with the iSNS server. - Most pre-OS iSCSI initiators available today are not iSNS clients i.e. they don't register with and/or query iSNS server. Given this, it seems better to have a DHCP based standardized mechanism for acquiring the initiator IQN. Based on initial email from Michael, most pre-OS iSCSI Initiators available today have the capability to be a DHCP client. Thanks, Gaurav Chawla Technology Strategist, Network Storage Architecture | Office of the CTO, Dell, Inc. Phone: 512.724.4064 (work) -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Michael Howard Sent: Monday, September 22, 2008 2:29 PM To: Iyer, Shyam Cc: SIVANT@il.ibm.com; psarkar@almaden.ibm.com; ips@ietf.org; Julian_Satran@il.ibm.com Subject: Re: [Ips] no DHCP-assigned InitiatorName Shyam_Iyer@Dell.com wrote: > My 2cents on the issue. Please correct me if I am wrong. Thank you for participating in this discussion. > Shouldn't it be possible to configure the isns server with a set of > possibly regex rules for the control path. If this not possible today, > then it could possibly be the root to take towards standardizing. I am not familiar enough with iSNS to comment. I have been exposed to about about a dozen commercial environments with some level of iSCSI use/experimentation. I am not aware that any of them were running iSNS servers. > This can solve the problem of provisioning for dynamic boot environments > with minimum changes to legacy iqn implementations, many of which would > need to relearn to the new iqn mechanism that might end up as a result > of this discussion. Frankly, my concern is that Broadcom/IBM already have a non-standard DHCP Vendor Option work-around for this problem. Adding a new/standardized InitiatorName DHCP option would not break existing initiator implementations. Vendors would integrate support for this new InitiatorName option into their code/firmware releases over time. > Instead of changing numerous configurations we could > simply change the isns server control mechanism. I need to do some homework regarding iSNS. > Comments? iSCSI is still a very small part of the market. I advocate addressing this deficiency sooner rather than later. Michael _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 22 13:08:33 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012D528C17D; Mon, 22 Sep 2008 13:08:33 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA8128C179 for ; Mon, 22 Sep 2008 13:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rbjfAxk5Iyn for ; Mon, 22 Sep 2008 13:08:31 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) by core3.amsl.com (Postfix) with ESMTP id 978303A6B05 for ; Mon, 22 Sep 2008 13:08:31 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-MimeOLE:Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Cc: Return-Path:X-OriginalArrivalTime; b=iTnsdqnSzY1GApkr1Vg6RRItSU4lUDQlDMBvzVlzu5AMKWWkQpy3EU/3 jRVkZjxlOsB2q8D63kSzirokrg/l1qXkcsMUADefHoB5UhhZnehdikB5I pDnk94cGTmCidQ/; X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Sep 2008 01:37:22 +0530 Message-ID: <46A00B48CC54E4468EF6911F877AC4CA019D6963@blrx3m10.blr.amer.dell.com> In-Reply-To: <42D8A6CDC96A5A4D8D91DE26991A51AA02016F63@ausx3mpc108.aus.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] no DHCP-assigned InitiatorName Thread-Index: Ackc6XVrlRzKxSf0TEy+wtYv9BwVHAAAXBXQAABNyzA= References: <48D6F3EB.1080400@scalent.com><48D79AA6.9040104@scalent.com><48D7BC9D.7060306@scalent.com><48D7DF92.9030605@scalent.com><46A00B48CC54E4468EF6911F877AC4CA019D6922@blrx3m10.blr.amer.dell.com> <48D7F1DE.5060000@scalent.com> <42D8A6CDC96A5A4D8D91DE26991A51AA02016F63@ausx3mpc108.aus.amer.dell.com> From: To: , X-OriginalArrivalTime: 22 Sep 2008 20:07:23.0089 (UTC) FILETIME=[D360A410:01C91CEE] Cc: SIVANT@il.ibm.com, psarkar@almaden.ibm.com, ips@ietf.org, Julian_Satran@il.ibm.com Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Thanks Gaurav. You are right. The fact that most of the pre-OS iSCSI initiators don't have iSNS clients, takes us away from the iSNS scenario atleast for the boot environment. On the other hand the scenario where in there are iSNS clients(or a more enterprise ready environment) we could probably think more on the lines of security since parameters with DHCP(clear text) is going to be less secure. Thanks, Shyam Iyer -----Original Message----- From: Chawla, G Sent: Tuesday, September 23, 2008 1:16 AM To: Michael Howard; Iyer, Shyam Cc: SIVANT@il.ibm.com; psarkar@almaden.ibm.com; ips@ietf.org; Julian_Satran@il.ibm.com; Chawla, G Subject: RE: [Ips] no DHCP-assigned InitiatorName My 2 cents based on my understanding of iSNS. - iSNS clients (initiators and targets) need to have an IQN address before they register with the iSNS server. - Most pre-OS iSCSI initiators available today are not iSNS clients i.e. they don't register with and/or query iSNS server. Given this, it seems better to have a DHCP based standardized mechanism for acquiring the initiator IQN. Based on initial email from Michael, most pre-OS iSCSI Initiators available today have the capability to be a DHCP client. Thanks, Gaurav Chawla Technology Strategist, Network Storage Architecture | Office of the CTO, Dell, Inc. Phone: 512.724.4064 (work) -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Michael Howard Sent: Monday, September 22, 2008 2:29 PM To: Iyer, Shyam Cc: SIVANT@il.ibm.com; psarkar@almaden.ibm.com; ips@ietf.org; Julian_Satran@il.ibm.com Subject: Re: [Ips] no DHCP-assigned InitiatorName Shyam_Iyer@Dell.com wrote: > My 2cents on the issue. Please correct me if I am wrong. Thank you for participating in this discussion. > Shouldn't it be possible to configure the isns server with a set of > possibly regex rules for the control path. If this not possible today, > then it could possibly be the root to take towards standardizing. I am not familiar enough with iSNS to comment. I have been exposed to about about a dozen commercial environments with some level of iSCSI use/experimentation. I am not aware that any of them were running iSNS servers. > This can solve the problem of provisioning for dynamic boot > environments with minimum changes to legacy iqn implementations, many > of which would need to relearn to the new iqn mechanism that might end > up as a result of this discussion. Frankly, my concern is that Broadcom/IBM already have a non-standard DHCP Vendor Option work-around for this problem. Adding a new/standardized InitiatorName DHCP option would not break existing initiator implementations. Vendors would integrate support for this new InitiatorName option into their code/firmware releases over time. > Instead of changing numerous configurations we could simply change the > isns server control mechanism. I need to do some homework regarding iSNS. > Comments? iSCSI is still a very small part of the market. I advocate addressing this deficiency sooner rather than later. Michael _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 22 14:17:32 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CD43A6B7B; Mon, 22 Sep 2008 14:17:32 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D0D3A67AE for ; Mon, 22 Sep 2008 14:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lJfxKj7Jmnj for ; Mon, 22 Sep 2008 14:17:25 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by core3.amsl.com (Postfix) with ESMTP id 1A1153A6B7B for ; Mon, 22 Sep 2008 14:17:24 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Sep 2008 16:18:40 -0500 Message-ID: <42D8A6CDC96A5A4D8D91DE26991A51AA02016FCC@ausx3mpc108.aus.amer.dell.com> In-Reply-To: <46A00B48CC54E4468EF6911F877AC4CA019D6963@blrx3m10.blr.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] no DHCP-assigned InitiatorName thread-index: Ackc6XVrlRzKxSf0TEy+wtYv9BwVHAAAXBXQAABNyzAAAxb08A== References: <48D6F3EB.1080400@scalent.com><48D79AA6.9040104@scalent.com><48D7BC9D.7060306@scalent.com><48D7DF92.9030605@scalent.com><46A00B48CC54E4468EF6911F877AC4CA019D6922@blrx3m10.blr.amer.dell.com> <48D7F1DE.5060000@scalent.com> <42D8A6CDC96A5A4D8D91DE26991A51AA02016F63@ausx3mpc108.aus.amer.dell.com> <46A00B48CC54E4468EF6911F877AC4CA019D6963@blrx3m10.blr.amer.dell.com> From: To: , X-OriginalArrivalTime: 22 Sep 2008 21:16:57.0533 (UTC) FILETIME=[8B8A3ED0:01C91CF8] Cc: SIVANT@il.ibm.com, psarkar@almaden.ibm.com, ips@ietf.org, Julian_Satran@il.ibm.com Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org We should be able to leverage CHAP based security (already defined for iSCSI) to provide the necessary security (authentication) between the initiators and targets. Thanks, Gaurav Chawla Technology Strategist, Network Storage Architecture | Office of the CTO, Dell, Inc. Phone: 512.724.4064 (work) -----Original Message----- From: Iyer, Shyam Sent: Monday, September 22, 2008 3:07 PM To: Chawla, G; 'Michael Howard' Cc: 'SIVANT@il.ibm.com'; 'psarkar@almaden.ibm.com'; 'ips@ietf.org'; 'Julian_Satran@il.ibm.com' Subject: RE: [Ips] no DHCP-assigned InitiatorName Thanks Gaurav. You are right. The fact that most of the pre-OS iSCSI initiators don't have iSNS clients, takes us away from the iSNS scenario atleast for the boot environment. On the other hand the scenario where in there are iSNS clients(or a more enterprise ready environment) we could probably think more on the lines of security since parameters with DHCP(clear text) is going to be less secure. Thanks, Shyam Iyer -----Original Message----- From: Chawla, G Sent: Tuesday, September 23, 2008 1:16 AM To: Michael Howard; Iyer, Shyam Cc: SIVANT@il.ibm.com; psarkar@almaden.ibm.com; ips@ietf.org; Julian_Satran@il.ibm.com; Chawla, G Subject: RE: [Ips] no DHCP-assigned InitiatorName My 2 cents based on my understanding of iSNS. - iSNS clients (initiators and targets) need to have an IQN address before they register with the iSNS server. - Most pre-OS iSCSI initiators available today are not iSNS clients i.e. they don't register with and/or query iSNS server. Given this, it seems better to have a DHCP based standardized mechanism for acquiring the initiator IQN. Based on initial email from Michael, most pre-OS iSCSI Initiators available today have the capability to be a DHCP client. Thanks, Gaurav Chawla Technology Strategist, Network Storage Architecture | Office of the CTO, Dell, Inc. Phone: 512.724.4064 (work) -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Michael Howard Sent: Monday, September 22, 2008 2:29 PM To: Iyer, Shyam Cc: SIVANT@il.ibm.com; psarkar@almaden.ibm.com; ips@ietf.org; Julian_Satran@il.ibm.com Subject: Re: [Ips] no DHCP-assigned InitiatorName Shyam_Iyer@Dell.com wrote: > My 2cents on the issue. Please correct me if I am wrong. Thank you for participating in this discussion. > Shouldn't it be possible to configure the isns server with a set of > possibly regex rules for the control path. If this not possible today, > then it could possibly be the root to take towards standardizing. I am not familiar enough with iSNS to comment. I have been exposed to about about a dozen commercial environments with some level of iSCSI use/experimentation. I am not aware that any of them were running iSNS servers. > This can solve the problem of provisioning for dynamic boot > environments with minimum changes to legacy iqn implementations, many > of which would need to relearn to the new iqn mechanism that might end > up as a result of this discussion. Frankly, my concern is that Broadcom/IBM already have a non-standard DHCP Vendor Option work-around for this problem. Adding a new/standardized InitiatorName DHCP option would not break existing initiator implementations. Vendors would integrate support for this new InitiatorName option into their code/firmware releases over time. > Instead of changing numerous configurations we could simply change the > isns server control mechanism. I need to do some homework regarding iSNS. > Comments? iSCSI is still a very small part of the market. I advocate addressing this deficiency sooner rather than later. Michael _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 23 09:46:03 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E594C3A68E0; Tue, 23 Sep 2008 09:46:03 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE233A6AA6 for ; Mon, 22 Sep 2008 08:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QKLHCIYooY1 for ; Mon, 22 Sep 2008 08:51:14 -0700 (PDT) Received: from mtagate3.de.ibm.com (mtagate3.de.ibm.com [195.212.29.152]) by core3.amsl.com (Postfix) with ESMTP id 410DC3A67AA for ; Mon, 22 Sep 2008 08:51:14 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id m8MFocBs197458 for ; Mon, 22 Sep 2008 15:50:38 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8MFob9d1720574 for ; Mon, 22 Sep 2008 17:50:37 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8MFobut030154 for ; Mon, 22 Sep 2008 17:50:37 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8MFobFo030151; Mon, 22 Sep 2008 17:50:37 +0200 In-Reply-To: References: <48D6F3EB.1080400@scalent.com> <48D79AA6.9040104@scalent.com> X-KeepSent: 0A82A218:3518FC7A-852574CC:005411EC; type=4; name=$KeepSent To: Julian Satran X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 Message-ID: From: Sivan Tal Date: Mon, 22 Sep 2008 11:50:36 -0400 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 8.0.1|February 07, 2008) at 22/09/2008 18:50:36 MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 23 Sep 2008 09:46:01 -0700 Cc: ips@ietf.org Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Michael, CbCS (Capability-based Command Security) is part of the SPC-4 (SCSI Primary Commands) standard draft. The current version is in http://www.t10.org/ftp/t10/drafts/spc4/spc4r16.pdf Clause 5.14.6 described Command Security, and sub-clause 5.14.6.8 describes CbCS, which is currently the only SCSI command security technique. Using CbCS, the initiator provides credential to the target that authorizes it to access the target logical unit. The credential does not contain an initiator identity and it is obtained from a trusted third party (security manager) and "signed" with HMAC (based on a symmetric key shared between the security manager and the target). The credential (the Capability descriptor) contains a DISCRIMINATOR field that can be set in a "vendor specific" manner. One can use that field for initiator identifier. However, it should be noted that when using CbCS you don't need this for authorization. The access decision point is in the security manager and the access enforcement point is in the target device, based on the credential. The initiator authenticates only to the security manager, thus keeping the device simple. This is especially valuable in virtualized environments. Sivan Tal IBM. |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Julian Satran/Haifa/IBM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Michael Howard | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |ips@ietf.org, Sivan Tal/Haifa/IBM@IBMIL | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |09/22/2008 09:29 AM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | 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 | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Julian Satran/Haifa/IBM@IBMIL | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |ips@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@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 24 14:59:34 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271C53A6B74; Wed, 24 Sep 2008 14:59:34 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17BBD3A690E for ; Wed, 24 Sep 2008 14:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZhvvFz1QIhr for ; Wed, 24 Sep 2008 14:59:30 -0700 (PDT) Received: from mymail.scalent.com (69-233-57-200.ded.pacbell.net [69.233.57.200]) by core3.amsl.com (Postfix) with ESMTP id BDB993A6B20 for ; Wed, 24 Sep 2008 14:59:30 -0700 (PDT) Received: from [192.168.15.15] ([74.65.146.114]) by mymail.scalent.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Sep 2008 14:59:16 -0700 Message-ID: <48DAB828.4010609@scalent.com> Date: Wed, 24 Sep 2008 14:59:04 -0700 From: Michael Howard User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: G_Chawla@Dell.com References: <48D6F3EB.1080400@scalent.com><48D79AA6.9040104@scalent.com><48D7BC9D.7060306@scalent.com><48D7DF92.9030605@scalent.com><46A00B48CC54E4468EF6911F877AC4CA019D6922@blrx3m10.blr.amer.dell.com> <48D7F1DE.5060000@scalent.com> <42D8A6CDC96A5A4D8D91DE26991A51AA02016F63@ausx3mpc108.aus.amer.dell.com> In-Reply-To: <42D8A6CDC96A5A4D8D91DE26991A51AA02016F63@ausx3mpc108.aus.amer.dell.com> X-OriginalArrivalTime: 24 Sep 2008 21:59:16.0487 (UTC) FILETIME=[C9B36170:01C91E90] Cc: ips@ietf.org, Shyam_Iyer@Dell.com Subject: Re: [Ips] no DHCP-assigned InitiatorName X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Gaurav and Shyam, Q: Do you have contacts with the EqualLogic team who may be interested in working on a resolution for this iSCSI/DHCP issue? Q: Do you have any contacts at Broadcom? Thanks, Michael G_Chawla@Dell.com wrote: > My 2 cents based on my understanding of iSNS. > > - iSNS clients (initiators and targets) need to have an IQN address > before they register with the iSNS server. > - Most pre-OS iSCSI initiators available today are not iSNS clients i.e. > they don't register with and/or query iSNS server. > > Given this, it seems better to have a DHCP based standardized mechanism > for acquiring the initiator IQN. Based on initial email from Michael, > most pre-OS iSCSI Initiators available today have the capability to be a > DHCP client. > > Thanks, > Gaurav Chawla > Technology Strategist, Network Storage Architecture | Office of the CTO, > Dell, Inc. > Phone: 512.724.4064 (work) > > > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of > Michael Howard > Sent: Monday, September 22, 2008 2:29 PM > To: Iyer, Shyam > Cc: SIVANT@il.ibm.com; psarkar@almaden.ibm.com; ips@ietf.org; > Julian_Satran@il.ibm.com > Subject: Re: [Ips] no DHCP-assigned InitiatorName > > Shyam_Iyer@Dell.com wrote: >> My 2cents on the issue. Please correct me if I am wrong. > > Thank you for participating in this discussion. > >> Shouldn't it be possible to configure the isns server with a set of >> possibly regex rules for the control path. If this not possible today, >> then it could possibly be the root to take towards standardizing. > > I am not familiar enough with iSNS to comment. > > I have been exposed to about about a dozen commercial environments with > some level of iSCSI use/experimentation. I am not aware that any of them > > were running iSNS servers. > >> This can solve the problem of provisioning for dynamic boot > environments >> with minimum changes to legacy iqn implementations, many of which > would >> need to relearn to the new iqn mechanism that might end up as a result >> of this discussion. > > Frankly, my concern is that Broadcom/IBM already have a non-standard > DHCP Vendor Option work-around for this problem. > > Adding a new/standardized InitiatorName DHCP option would not break > existing initiator implementations. Vendors would integrate support for > this new InitiatorName option into their code/firmware releases over > time. > >> Instead of changing numerous configurations we could >> simply change the isns server control mechanism. > > I need to do some homework regarding iSNS. > >> Comments? > > iSCSI is still a very small part of the market. > > I advocate addressing this deficiency sooner rather than later. > > > Michael > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From newsadwords@google.com Mon Sep 29 23:42:05 2008 Return-Path: X-Original-To: ietfarch-ips-archive@core3.amsl.com Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB5A3A6839 for ; Mon, 29 Sep 2008 23:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.438 X-Spam-Level: X-Spam-Status: No, score=-44.438 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBcEg+R95c9A for ; Mon, 29 Sep 2008 23:42:04 -0700 (PDT) Received: from dslb-084-056-231-166.pools.arcor-ip.net (dslb-084-056-231-166.pools.arcor-ip.net [84.56.231.166]) by core3.amsl.com (Postfix) with ESMTP id A1D903A6820 for ; Mon, 29 Sep 2008 23:42:03 -0700 (PDT) Date: Tue, 30 Sep 2008 04:55:02 +0000 Message-ID: <34964.fred@jaik> From: "Google Adwords Center" To: Subject: Google Adwords Security and Identity Protection Newsletter MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_F2SWtvZctze5O0" This is a multi-part message in MIME format. --=_F2SWtvZctze5O0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Attention GOOGLE ADWORDS Customers!=20 For certain services, such as our advertising programs, we request = 128-bit SSL security information which we maintain in encrypted form on = secure servers.=20 We take appropriate security measures to protect against unauthorized = access to our unauthorized alteration, disclosure or destruction of = data. Please download latest SSL protection certificate Read more>> Unprotected browsers will not be able to Log in after September 30, 2008 Sincerely, Jaime Moon. 2008 Google Adwords, Developing new services. --=_F2SWtvZctze5O0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Attention GOOGLE ADWORDS Customers!

For certain services, such as our advertising programs, we request = 128-bit SSL security information which we maintain in encrypted form on = secure servers.
We take appropriate security measures to protect against unauthorized = access to our unauthorized alteration, disclosure or destruction of = data.
Please download latest SSL protection certificate

Read= more>>

Unprotected browsers will not be able to Log in after September 30, = 2008
Sincerely, Jaime Moon.

2008 Google Adwords, Developing new services.
--=_F2SWtvZctze5O0--