Re: iSCSI: reusing ISID for recovery

[Santosh Rao <santoshr@cup.hp.com>]

Julian Satran wrote:

> My major objection is that we make it to easy to err.  Even
> not-malicious/just mistaken code can blow up a session.

Code that is not written to manage session resources correctly across multiple
iscsi clients [if someone would  try to do that !!] is'nt going to go too far
anyway ! The session would blow up sooner rather than later and that system
is'nt going to have too much forward progress with its iscsi sessions.

I don't think complexity should be introduced into the draft to protect
against simple coding errors.  I have'nt yet seen a valid scenario, other than
a coding error, which would result in a session being blown away. There are
other precedents to the mechanism being asked for here [ex :FC] and it has
been well used without any complaints in those cases.

- Santosh


> Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 30-08-2001 23:18:01
>
> Please respond to Santosh Rao <santoshr@cup.hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  Re: iSCSI: reusing ISID for recovery
>
> Venkat Rangan wrote:
>
> >  One aspect from the
> > other thread that may not have been mentioned is the fact that you could
> > have a situation where a rogue software on the initiator running in user
> > mode which simply issues ISID=existing, TSID=0 to the target. (This may
> be
> > what was meant by "wild closing of connections" in this thread.) Choosing
> > option A) would destroy an otherwise well protected ISID managed in the
> > kernel space. This could also occur when you accidentally start another
> > application that does not coordinate its ISID selection.
>
> Another parallel iscsi application running in user space should use a
> different
> iscsi initiator name than the iscsi kernel driver. If it does use the same
> iscsi initiator name, it must co-ordinate its usage of ISID, cmdsn,
> exp_statsn,
> initiator task tag with the kernel iscsi driver.
>
> Failure to do either can and should result in the pre-existing session
> being
> logged out, since this is a coding error in the initiator application.
> However,
> prior to taking any such action, the login request must first be
> authenticated
> to protect against malicious logouts from spurious initiators.
>
> > The earlier thread was leaning towards "Reject the second login attempt
> with
> > In-Use error code" but the issue of targets cleaning up inactive and
> failed
> > sessions still lingers on.
> >
> > Some observations:
> >
> > 1. There is no way to protect against rogue software at the intiator;
> even
> > the best IPSec policies and key management can not prevent such software
> > from disturbing other well-behaved components. So trying to design
> > mechanisms to prevent this at the target would be fruitless.
>
> Agreed. That is the philosophy of option (A).
>
> >
> > 2. There is some value in protecting an accidental use of an existing
> ISID
> > by a second client (ISID=<existing>, TSID=0). This can be done with a
> Reject
> > of the login attempt, even without verification of login credentials -
> (less
> > of a DOS attack). You also do not need to analyze connection states in
> this
> > case.
>
> A second client should create its own iscsi initiator name or partition the
> (ISID, cmdsn, init task tag) resources into pools that can be shared b/n
> the 2
> clients. Even then, there exist issues in sending exp_statsn values. The
> easiest partition is to use different names for different clients.
>
> If multiple clients on a host do not follow the above precautions, they are
> faulty in their iscsi session resource management and there is little sense
> in
> designing targets to protect against such behaviour.
>
> >
> > 3. From the perspective of the Target, case 2) above is no different from
> an
> > initiator rebooting and accidentally choosing an existing ISID with
> TSID=0.
> > To distinguish 2) from 3), we can make use of the Clear bit (or the
> C-bit)
> > and avoid many unnecessary trips at reboot time, trying to probe for an
> > unused ISID. The usage is that if C-bit is present, any previous sessions
> > are also closed by the target. I think this was Option B) in the original
> > email.
>
> There is nothing to prevent multiple concurrent clients from logging in
> with
> "C" bit set, and use the same ISID + 0 TSID.
>
> The simplest approach is for the targets to authenticate the initiators and
> once authentication has passed, to trust the initiator's requests. The
> target
> should not be in the business of second-guessing the initiator's intentions
> by
> testing connections, etc.
>
> The "C" bit is of little or no use, since the initiator does not know
> reliably
> in which cases its usage is required. [It may have lost prior state and has
> no
> knowledge that it had a pre-existing session].  It would end up using this
> bit
> in all logins.
>
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard