RE: iSCSI: login issue - partial consensus call

["Julian Satran" <Julian_Satran@il.ibm.com>]

The OS name (InitiatorName) is meant for the OS.
If you want to have one OS handle several sessions with a target you need
another element controllable by the host
to distinguish a session from another (i.e. the target should not be the
one to reassign it).  This is needed for the "long lived" things like
reservations that live beyond a session and have to be reassigned to their
rightful owners.

That was the reason we made-up the sessionID from two parts (and not a long
one assigned by one part).

For the CID the assigning entity was chosen arbitrarily (yes it could have
been the target but we needed him to check anyhow for a restart).

As for how to handle the a "bad ISID" I think that this issue has been
discussed far too long and very eloquent (i.e., convincing but not
necessarily right).  I have stated my position several times here and I am
not going to repeat it.

Julo

"Eddy Quicksall" <eddy_quicksall@ivivity.com> on 07-09-2001 00:36:03

Please respond to <eddy_quicksall@ivivity.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI: login issue - partial consensus call



Julian,

There seems to be a lot of helter/scelter discussion in this thread. It
seems like the general problem is the ISID and it seems that the reason for
that is because the InitiiatorName has been assigned to the host.

I would like to propose the following but I think everyone is too engrossed
in solving a hard problem instead of making a hard problem easy. Or, maybe
I
just don't have enough background and I would just clutter the reflector
with stupid ideas.

Can you comment to me on this idea ... you have probably already gone
through it?

- make the InitiatorName be the name of the entity that maintains unique
ISID's. That could be an HBA or a driver controlling several NIC's.

- make a new name called the HostName that can be used for authentication.
The HostName could be optional because some special case HBA's may only be
used on closed connections and will not need authentication.

- to reset a session use the TSID instead of the ISID (because the target
can supply unique TSID's to everyone (may need to expand the TSID to 32
bits)) and use a bit in the login to say you are resetting.

BTW, I don't like the idea of making every run-time target "debug"
someone's
code ... that should be up to the host bashers.

Eddy

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Friday, August 31, 2001 12:24 AM
To: ips@ece.cmu.edu
Subject: iSCSI: login issue - partial consensus call


A review of this long running thread.  We started out with
Mallikarjun's three options:

       A) Should iSCSI let it happen by default as stated above (i.e.
          same ISID, TSID=0 always wipes out the pre-existing session
          on target, since we are mandating it to be used only when
          initiator sees a session failure)?
       B) Should iSCSI mandate making this intended cleanup explicit
          by setting a bit (Say C-bit, for Clear) in the Login Command
          PDU to prevent an accidental session cleanup with a buggy
          initiator code?
       C) Should iSCSI merely state that targets must ascertain
          the connection state(s) whenever a new session creation
          attempt is made with a known ISID and TSID=0?  (sort of
          defeats the intention of the initiator wanting quicker
          session recovery since the Login command PDU would have
          to idle till target ascertains the connection state(s)).

Based on my review of the emails, here's what I think the state
of the discussion is:

(1) I see no support for Option C.  The remaining options are A, B, and
     Julian's version of B in which the X bit is reused as the C bit.

(2) I see strong objections to the reuse of the X bit that Julian
     proposed, and no interest in it from anyone other than Julian.
     The objections are that the X bit is already heavily involved
     in error recovery and adding more semantics to it is an
invitation
     to trouble. Therefore, I believe the rough consensus of the IPS
     WG is that the X bit is not to be reused in this fashion.

(3) I believe the rough consensus is that the situation being analyzed
     here can occur as a consequence of an initiator reboot (i.e.,
     if the reboot is fast with respect to the target's timeout-based
     session cleanup).

The consensus calls in (2) and (3) are over Julian Satran's proposal/
comments/objection.  Anyone else who objects to these should post to
the list.

This leaves options A and B as originally stated.  Most people seem
to be in favor of option A - the two exceptions I noticed were
Julian and Venkat.  Julian's objection can be summarized with a
couple of quotes:

> Option A is prone to "wild closing of sessions"
> Option A is clearly unacceptable as an initiator may do harm.

The wild closing of sessions seems to be based on a different
iSCSI interface with the same Initiator name using the same
ISID.  This is a definite risk as it's an area in which iSCSI
differs from Fibre Channel.  FC identifies sessions via hardware
identities which tend to be static and unique, and set by the
hardware vendor.  The iSCSI ISID is a dynamically managed
entity, and bugs in managing it across multiple interfaces
(which may involve hardware and software from multiple
vendors) will cause this session closing problem, whereas for
it to happen in FC, the hardware identity has to be duplicated.

FWIW, I do know of an FC system that rejects duplicate logins
under some circumstances rather than implicitly destroying
the existing session, although I don't believe that behavior
can be overridden via inband means as is proposed here.

OTOH, a different OS should have different iSCSI Initiator Name,
and denial of service attacks should be foiled by proper use of
authentication.  I also tend to agree with the architectural
point of view that an initiator is in charge of its own sessions.
So, I think Julian has a point here, although some of the things
he's posted are overstated.

This is also Venkat's concern - unintentional reuse of an ISID
by the same Initiator:

> 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,

In contrast to some of the responses to Venkat, I interpret
"client" to mean another iSCSI port on the same Initiator, and
then his concern matches Julian's.  Venkat seems to think that
there's a useful distinction between boot scenarios in which
teardown of existing sessions is needed and boot scenarios
in which it's not needed  - I have no idea how to figure that
out in practice, and suspect that Marj is right when she says
that the C bit will be set all the time.  I agree that the
C bit is always set in a session recovery scenario because
the intent is to blow away the existing session.

So, I'm not ready to call consensus on the A vs. B. issue.
In hopes of making further progress, I would ask the
proponents of B (Venkat, Julian, and anyone else who thinks
this is valuable - I assume Julian prefers B to A, even if
the WG does not like using the X bit for B) to post short
answers to the following questions:

     Under what circumstances would an Initiator not set the
     C bit for option B?  What information would the Initiator use
     to decide not to set the C bit?

I apologize if this was in some of the emails and I missed
it - there were a lot of them.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------