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

[Mallikarjun Chadalapaka <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
  Of [e-mail]
  Sent: Friday, September 09, 2011 7:49 AM
  To: [e-mail]; [e-mail]
  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: [e-mail] [mailto:[e-mail]]
  Sent: Friday, September 09, 2011 9:02 AM
  To: Koning, Paul; [e-mail]
  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: [e-mail] [mailto:[e-mail]] On
  Behalf
  > Of [e-mail]
  > Sent: Friday, September 09, 2011 6:50 AM
  > To: [e-mail]; [e-mail]
  > 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: [e-mail] [mailto:[e-mail]] On
  Behalf
  > Of Mallikarjun Chadalapaka
  > Sent: Thursday, September 08, 2011 9:41 PM
  > To: [e-mail]
  > 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
  > [e-mail]
  > https://www.ietf.org/mailman/listinfo/storm
  > _______________________________________________
  > storm mailing list
  > [e-mail]
  > https://www.ietf.org/mailman/listinfo/storm
  
  _______________________________________________
  storm mailing list
  [e-mail]
  https://www.ietf.org/mailman/listinfo/storm