RE: iSCSI : target session login behavior

["CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com>]

Seems like there may be a small security hole in the direction suggested
below.  Before performing the implicit logout, shouldn't you authenticate
the initiator first?  If not, it would be possible for anyone to cause a
session to get dropped simply by knowing their WWUI and ISID.

Paul

+--------------------------+----------------------------+
+ Paul Congdon             + Email: paul_congdon@hp.com +
+ Hewlett Packard Company  + Mail Stop:  5662           +
+ HP ProCurve Networking   + Phone:  (916) 785-5753     +
+ 8000 Foothills Blvd      + Fax:    (916) 785-5949     +
+ Roseville, CA   95747    + Mobile: (916) 765-4056     +
+--------------------------+----------------------------+

> -----Original Message-----
> From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
> Sent: Thursday, April 26, 2001 6:18 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI : target session login behaviour 
> 
> 
> Santosh,
> 
> > How should a target respond when it receives a session 
> login  [on a new
> > TCP connection] with the same (ISID, Initiator Name) as a session
> > already active at the target.
> 
> Originally, I thought rejecting the login was the correct behavior,
> and that's what I specified in the error handling pseudocode.  I
> construed this as a consistency (logic) error in the target.  However,
> on further thought, I've changed my mind.  I believe the correct
> behavior is to perform an implicit logout (of all outstanding
> connections in the session).  The target and initiator may have
> different ideas about whether the connections are still live, and like
> in FCP, performing an implicit logout solves this problem.  It also
> provides a mechanisms for rapid, proactive recovery of session
> resources when possible, which is the right thing.
> 
> > iSCSI session login semantics should explicitly state that the above
> > scenario will result in case (1) above.
> 
> I agree.  This and all other possible cases.  
> 
> > As a side note, the iSCSI draft Status Class/Codes could do 
> with a misc
> > error category along the lines of the FC "No additional Explantion"
> > reason explantion. This would help deal with error 
> conditions that don't
> > come under the listed category.
> 
> Personally, I think we should add categories for reasons we obviously
> see now, AND have a no additional reason.
> 
> One peculiarity with what you're talking about above is that it should
> be a login response status code which expresses this rejection.  The
> login response set does not seem to have an `invalid parameter'
> response for cases when the request is somehow inconsistent.
> 
> Steph
>