Subject: Re: iSCSI: reusing ISID for recovery

From: "Julian Satran" <[email-masked]>
Date: Thu, 30 Aug 2001 23:37:18 +0300

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

Julo

Santosh Rao <[email-masked]>@ece.cmu.edu on 30-08-2001 23:18:01

Please respond to Santosh Rao <[email-masked]>

Sent by:  [email-masked]

To:   [email-masked]
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.

Regards,
Santosh

 - santoshr.vcf

---

From: "Somesh Gupta" <[email-masked]>
Date: Thu, 30 Aug 2001 14:52:01 -0700

Julian,

I final comment on this issue from me. I think the point
is that the code is either broke or not, and there is no
way to help code that has bugs.

On the other hand, the more complexity, the higher
the probability of bugs. For this, one does not
have to look at the incremental effort for one
feature or another (because that always ends up in a
debate of whether I can program another 100 lines
of code correctly or not), but rather in gross terms.
And to use another hyperbole, the forest is finally
made up of trees.

Somesh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Julian Satran
> Sent: Thursday, August 30, 2001 1:37 PM
> To: [email-masked]

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Santosh Rao <[email-masked]>
Date: Thu, 30 Aug 2001 14:42:15 -0700

> 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