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

Ok, so that means that, in this case at least, it must be possible for the CHAP name to be different from the iSCSI name.  That's certainly always a possibility but it also seems likely that people would take the shortcut of making them match -- here you can't do that.  The text you quoted should be sufficient to alert implementers to that consideration.

	paul

-----Original Message-----
From: david.black@emc.com [mailto:david.black@emc.com] 
Sent: Friday, September 09, 2011 9:02 AM
To: Koning, Paul; 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.

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