Re: [storm] iSCSI Node Name for SCSI (composite) Device

<david.black@emc.com> Fri, 09 September 2011 12:59 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD3821F86C7 for <storm@ietfa.amsl.com>; Fri, 9 Sep 2011 05:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.541
X-Spam-Level:
X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rUSSG6H1Vv5 for <storm@ietfa.amsl.com>; Fri, 9 Sep 2011 05:59:47 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEDA21F867E for <storm@ietf.org>; Fri, 9 Sep 2011 05:59:47 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p89D1e6D029865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2011 09:01:40 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 9 Sep 2011 09:01:36 -0400
Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p89D1Z7s005372; Fri, 9 Sep 2011 09:01:36 -0400
Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Fri, 9 Sep 2011 09:01:35 -0400
From: <david.black@emc.com>
To: <Paul_Koning@Dell.com>, <storm@ietf.org>
Date: Fri, 9 Sep 2011 09:01:34 -0400
Thread-Topic: [storm] iSCSI Node Name for SCSI (composite) Device
Thread-Index: Acxuj2l2QYR5jDLeQ/6sfbz+l/piAQATnEyQAAQmjtA=
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058B27F43A@MX14A.corp.emc.com>
References: <SNT131-ds428634E0048BE2FF6E211A0010@phx.gbl> <09787EF419216C41A903FD14EE5506DD0153553162@AUSX7MCPC103.AMER.DELL.COM>
In-Reply-To: <09787EF419216C41A903FD14EE5506DD0153553162@AUSX7MCPC103.AMER.DELL.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [storm] iSCSI Node Name for SCSI (composite) Device
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Sep 2011 12:59:48 -0000

> I'm wondering if this creates an issue with CHAP based authentication.  Assuming the node name is the
> CHAP username, you'd have a CHAP secret associated with that name.  Since there are two roles, it
> means the same secret is used for both directions, which violates an explicit prohibition in the
> existing spec (because it enables reflection attacks).
> 
> Is that not an issue here, or is it one that can be avoided by additional constraints?  If so it would
> be worth spelling out how.

That's definitely a valid concern, but one that has already been taken care of - the following
sentence is from Section 8.2.1 of RFC 3720, and has been carried over to Section 9.2.1 of the
consolidated draft:

   Also, if an iSCSI
   implementation can function as both initiator and target, different
   CHAP secrets and identities MUST be configured for these two roles.

Thanks,
--David

> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Paul_Koning@Dell.com
> Sent: Friday, September 09, 2011 6:50 AM
> To: cbm@chadalapaka.com; storm@ietf.org
> Subject: Re: [storm] iSCSI Node Name for SCSI (composite) Device
> 
> I'm wondering if this creates an issue with CHAP based authentication.  Assuming the node name is the
> CHAP username, you'd have a CHAP secret associated with that name.  Since there are two roles, it
> means the same secret is used for both directions, which violates an explicit prohibition in the
> existing spec (because it enables reflection attacks).
> 
> Is that not an issue here, or is it one that can be avoided by additional constraints?  If so it would
> be worth spelling out how.
> 
> 	paul
> 
> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Mallikarjun Chadalapaka
> Sent: Thursday, September 08, 2011 9:41 PM
> To: storm@ietf.org
> Subject: [storm] iSCSI Node Name for SCSI (composite) Device
> 
> In reviewing some editorial feedback received offline, we have identified a potential misalignment
> between SAM-5 and iSCSI.  And it turns out we can address it with a simple requirement, which the
> drafts' authors wanted to surface to the list.
> 
> SAM-5 models SCSI Device Name as an attribute of a SCSI Device class, even if the SCSI Device is a
> composite device containing a SCSI Initiator Device
> and a SCSI Target Device.   iSCSI in contrast models an iSCSI Initiator Name
> as an attribute of iSCSI Initiator Node, and models iSCSI Target Name as that for iSCSI Target Node.
> As the new consolidated draft now explicitly allows iSCSI Nodes to be SCSI composite Devices, we just
> need to make sure that a SCSI (composite) Device in iSCSI transport domain would only have one SCSI
> Device Name.
> 
> This can be accomplished by adding the following requirement to the consolidated draft: whenever an
> iSCSI Node contains an iSCSI Initiator Node and an iSCSI Target Node, the iSCSI Initiator Name MUST be
> the same as the iSCSI Target Name for the contained Nodes such that there is only one iSCSI Node Name
> for the iSCSI Node overall.
> 
> Please let the list know if you have concerns, or questions about this approach.  Assuming WG
> consensus on this, we plan to get this - and any related text updates in both drafts - into the next
> revisions at the end of the Last Call.
> 
> Thanks.
> 
> Mallikarjun (for all the authors)
> 
> 
> 
> 
> 
> 
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm