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

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Thu, 8 Sep 2011 18:40:40 -0700

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)

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 05:50:05 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Mallikarjun Chadalapaka
Sent: Thursday, September 08, 2011 9:41 PM
To: [email-masked]
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.

_______________________________________________
storm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/storm

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 09:01:34 -0400

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

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, September 09, 2011 6:50 AM
> To: [email-masked]; [email-masked]
> 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).
> 
> 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
> 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.
>

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 09:48:39 -0500

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: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 09, 2011 9:02 AM
To: Koning, Paul; [email-masked]
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

Thanks,
--David

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

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Fri, 9 Sep 2011 10:20:45 -0700

Paul, thanks for the feedback.  From the new requirement text, I will also
add a cross-reference to the section 9.2.1 text that David cited, to make
this clear.

Mallikarjun

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]] On Behalf
  Of [email-masked]
  Sent: Friday, September 09, 2011 7:49 AM
  To: [email-masked]; [email-masked]
  Subject: 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: [email-masked] [mailto:[email-masked]]
  Sent: Friday, September 09, 2011 9:02 AM
  To: Koning, Paul; [email-masked]
  Subject: RE: [storm] iSCSI Node Name for SCSI (composite) Device
  
  > same secret is used for both directions, which violates an explicit
  prohibition in the existing spec (because it enables reflection attacks).
  > 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
  
  Thanks,
  --David
  
  > From: [email-masked] [mailto:[email-masked]] On
  Behalf
  > Of [email-masked]
  > same secret is used for both directions, which violates an explicit
  prohibition in the existing spec (because it enables reflection attacks).
  > From: [email-masked] [mailto:[email-masked]] On
  Behalf
  > Of Mallikarjun Chadalapaka
  > even if the SCSI Device is a composite device containing a SCSI
Initiator
  Device
  > as an attribute of iSCSI Initiator Node, and models iSCSI Target Name as
  that for iSCSI Target Node.
  > same as the iSCSI Target Name for the contained Nodes such that there is
  only one iSCSI Node Name for the iSCSI Node overall.
  > any related text updates in both drafts - into the next revisions at the
end
  of the Last Call.