RE: iSCSI: response to second login (with same ISID)

["Martin, Nick" <Nick.Martin@compaq.com>]

Stephen, Santosh, and All,

I am a bit weak in my understanding of authentication.  (Is the initiator
being authenticated, or the driver on the initiator, or the application on
the initiator, or the user of the application on the initiator, etc.)  My
impression is that authentication means that something within the initiator
can somehow prove its identity to the target (and vise versa).  The
initiator is not proving its intentions.

I know from personal experience how easy it is for an authorized user to
unintentionally start a second copy of a backup program, while the tape
drive is still in use.  This should be a harmless mistake.  What kind of
traffic cop would prevent this request from making it to the iSCSI target
and terminating the session already in progress?  (Rhetorical question,
please do not describe for me such a mechanism ;)

I do not dispute the need to be able to clean up stale sessions.  I would
prefer that this be handled by timeout and/or explicit request rather than
presuming that *every* "authenticated" request to establish a session with
the same ISID is an *intentional* attempt to logout any other active session
with that ISID.

When I attempt a duplicate login for the same ISID, I would like to be able
to get an error response code for "session already logged in".  Then I would
have a choice of whether I will quit, try again later, try again immediately
with a "login unconditionally" flag, or try again with a different ISID.

In some situations, such as kernel drivers, "login unconditionally" could be
used on every attempt to save time.  The ISID's for kernel drivers may need
to be reserved (and pre-configured) so that a kernel reboot after an
ungraceful shutdown will automatically recover all the kernel's sessions.
However if two copies of an application attempt to open sessions to the same
iSCSI URL from the same host at the same time, the second should not disrupt
the first.  I'm not sure what will force them to have different ISID's, or
how they would even try to each pick a unique one.

I would like to somehow leave the [programmer of the] iSCSI initiator a
choice.

Whatever mechanism is chosen to globally assign and/or reserve ISID's within
an initiator is not specified by iSCSI and so will be a local convention.
Software not adhering to the local convention (perhaps unaware of the
correct local convention) could at least operate non-disruptively by probing
for an available ISID, but only if automatic logout of pre-existing sessions
is never done, or is selectable rather than always unconditional.

So I guess what I am suggesting is a bit in the Login PDU to select behavior
1) or behavior 2).

"1) REJECT the login with some error code (that the iSCSI initiator can
understand or infer to mean "ISID in use") and leave the pre-existing
session alone
2) CLOSE the pre-existing session (and abort all it's tasks) and then
process the new login fresh."

I now believe both are needed.

Thanks,
Nick
> -----Original Message-----
> From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
> Sent: Tuesday, May 22, 2001 9:09 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: response to second login (with same ISID) 
> 
> 
> Nick,
> 
> > If I read Steph Bailey's comments on this right (from the 
> ERT work), the
> > target would have to authenticate the 2nd login on the same 
> ISID [as it
> > does with any other login] and only take action when 
> authentication is
> > successful.
> 
> What he said.
> 
> Steph
>