Re: iSCSI : Login Phase Problems

[julian_satran@il.ibm.com]

Santosh,

That is already in in 04 as I was refining the security negotiation.

Regards,
Julo

Santosh Rao <santoshr@cup.hp.com> on 24/01/2001 09:18:30

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   ips@ece.cmu.edu (ips)
cc:   santoshr@hpcuhe.cup.hp.com (Santosh Rao)
Subject:  iSCSI : Login Phase Problems




Julian & All,

Problem :
=========
The login phase is intended to be driven by the initiator and it is the
one to decide if only a Login PDU is sufficient or it needs a Login + Text
PDU. The initiator needs a mechanism to indicate to the target that a Text
command will [or will not] follow the login command.

However, by placing the "F" bit in the login response and NOT the login
command, the iSCSI login phase opens up a number of questions :

 Reference
 ========
 Section 4, 4.1 of rev 03 iSCSI draft.

 The login phase is negotiated as follows :
 ===========================================
 Initiator                Target
 ===========================================
 1) Login    ----------->
                   <---------- 1) Login response of "accept login"
                                                 with F=0
 2) Text    ------------>
               <-----------  2) Text Response
             :
             :
            <------------  3) Login Response of "accept login"
                                                with F=1

 Issues :
 ========
 1) Without a communication from the initiator on whether it intends to
 follow the login command with a text command, the target may send back a
 login accept with the "final" (F) bit set, when the initiator was still
 interested in negotiating more keys.

 2) The target may send back an interim login accept ("F" bit is not set),
 expecting the initiator to continue negotiation with a text command. The
 initiator may have no further keys to negotiate and so, does nothing.
 When is the login phase then deemed to be complete ? (i.e. what causes
 the tgt to do a final login accept (F bit set)).

 3) If multiple Text commands are to be allowed in the login phase, how
 does a target know that the initiator is done with all its key
 negotiations and has sent all its text commands ?
 If multiple Text commands are NOT allowed in the login
 phase, then, the draft MUST state this explicitly.

 It is the initiator that drives the Login/Text negotiations and
 hence, it is the initiator that must decide whether a login
 is sufficient or a login will be followed by a text phase.

 Therefore, the "F" bit currently in the login response should actually
 be in login command. The initiator is the master of the login phase and
 it should drive the login + text phases.

 Solution :
 ==========
 Case I (only login command used )
 ---------------------------------

 Initiator               Target
 ======================================
 Login(F bit set) ------>
            <-----  Login Accept (F bit set)


Case (II) (login + text commands used in login phase)
-----------------------------------------------------
 Initiator               Target
 ======================================
 Login(F bit NOT set) ------>
                <----- Login Accept (F bit NOT set)
Text (F bit NOT set)  ------>
                <----- Text Response
                :
                :
Text (F bit set)      ----->
                <---- Text Response
                <---- Login Response (F bit set)


Comments ?

Regards,
Santosh


--
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
#################################