Subject: RE: iSCSI: reusing ISID for recovery

From: Venkat Rangan <[email-masked]>
Date: Wed, 29 Aug 2001 22:25:27 -0700

Steph,

This is a long thread, almost as long as the thread "iSCSI: response to
second login (with same ISID)" we had a few months ago. 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.

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.

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.

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.

4. If initiators always set the C-bit, then they can't benefit from the
duplicate session identification capability of 2). It is a bad initiator in
that it doesn't respect the presence of other sessions at the initiator
system, but the protocol can't bloat handling these cases of bad initiators.

5. If an initiator only implements mandatory session recovery, it can help a
target recover faster by explicitly logging out the previous session and use
same or different ISID with TSID=0 and an C-bit to really ensure that it can
recover on a new session. This is a fast operation because we are not
waiting for lengthy round trips or timeouts, and the presence of the C-bit
makes the intent clear to the target that it must wipe off the existing
session. The perceived delay noted in Option C) does not arise.

6. If a target determines that all connections in a session are dead (TCP
keepalives can help here), and there is no activity on a session, it can
simply close the session and release the ISID and the TSID and recover
target side resources. This is not driven be explicit protocol action from
initiator, but simply target timer based, and is designed for initiators
that disappear without cleanup of sessions and don't reappear (no reboot for
a long time).

With this limited understanding, my preference would be Option B). One could
argue that B) offers protection only against an accidental use of the same
ISID, but if (as was pointed out earlier and in the other thread by Nick),
there are multiple ways in which iSCSI applications are packaged, so that
there is no shared visibility into ISID space, the protection offered by B)
can be useful.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

-----Original Message-----
From: Stephen Bailey [mailto:[email-masked]]
Sent: Wednesday, August 29, 2001 1:53 PM
To: Santosh Rao
Cc: [email-masked]
Subject: Re: iSCSI: reusing ISID for recovery 

> The same was earlier proposed by myself in a previous thread on this
> issue a few months ago.

You're not the only one.  I'm also in favor of (A).  I have also
carefully laid out the chain that Marjorie's following on at least one
(and probably several) past occasions.  It seems sound to me.  An
initiator that has lost its mind (this might be an OS reboot, or
`simply' a fat adapter crash & restart) is going to want to stomp out
any existing sessions in its name.  It's not going to want to pick up
old context unless it's aware that there IS old context, in which case
it hasn't completely lost its mind.

I've been keeping my mouth shut in hopes that it would actually pass,
but I guess I don't have to articulate a position so much as just hold
it to ensure it gets killed.  Given my track record, I'm now for sale
to the highest bidder.

Steph

---

From: Santosh Rao <[email-masked]>
Date: Thu, 30 Aug 2001 13:18:01 -0700

Venkat Rangan wrote:

>  One aspect from the

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.

> mechanisms to prevent this at the target would be fruitless.

Agreed. That is the philosophy of option (A).

> of a DOS attack). You also do not need to analyze connection states in this

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.

> are also closed by the target. I think this was Option B) in the original

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