Subject: [Ips] iSCSI: When does a connection become part of a session?

From: "Pittman, Joseph" <[email-masked]>
Date: Tue, 6 Jan 2004 16:01:48 -0500

I'm working on adding support for multi-connection sessions to an
iSCSI target implementation, and I have some questions about when
a new connection is considered to be part of a session.
 
Consider this set of login request/response exchanges.  Assume
that there already exists a session with ISID=1/TSIH=2 on the
target, so the initiator is trying to add a connection to an
existing session.  The session is operating at ErrorRecoveryLevel=2,
and there already exists a connection with CID=3 within that
session, so connection reinstatement is required.
 
                  Initiator sends                   Target responds
                  -------------------------
--------------------------
Exchange 0        LOGIN_REQ                         LOGIN_RESP
                  ISID=1, TSIH=2, CID=3             ISID=1, TSIH=2,
CID=3
                  CSG=0, T=0                        CSG=0, T=0
                  AuthMethod=CHAP                   AuthMethod=CHAP
 
  ** Connection now in SecurityNegotiation phase
 
Exchange 1        LOGIN_REQ                         LOGIN_RESP
                  ISID=1, TSIH=2, CID=3             ISID=1, TSIH=2,
CID=3
                  CSG=0, T=0                        CSG=0, T=0
                  CHAP_A=5                          CHAP_A=5
                                                    CHAP_I=x
                                                    CHAP_C=x
 
Exchange 2        LOGIN_REQ                         LOGIN_RESP
                  ISID=1, TSIH=2, CID=3             ISID=1, TSIH=2,
CID=3
                  CSG=0, T=1, NSG=1                 CSG=0, T=1, NSG=1
                  CHAP_R=x
                  CHAP_N=x
 
  ** Connection now in LoginOperationalNegotiation phase

Exchange 3        LOGIN_REQ
                  ISID=1, TSIH=2, CID=3             ISID=1, TSIH=2,
CID=3
                  CSG=1, T=1, NSG=3                 CSG=1, T=1, NSG=3
                  MaxRecvDSegLen=xxx                MaxRecvDSegLen=xxx
 
  ** Connection now in FullFeaturePhase phase
  ** Connection has been added to the session ISID=1/TSIH=2
  ** Previous connection ISID=1/TSIH=2/CID=3 has been logged out for
     recovery

Given this example, here are a few questions:
 
1) When is the target supposed to consider the connection as part of
   the session, for the purposes of the response ExpCmdSN and MaxCmdSN
   fields?
 
   In general, the ExpCmdSN and MaxCmdSN fields contain information
   about the current command window for a session.  But when does the
   target consider the connection to be part the session:
 
   - Before security negotiation is complete?  If true, then this
     tells a spoofing initiator (who will eventually fail
authentication)
     about the presence of a connection by the initiator being spoofed
 
   - After security negotiation is complete?
 
   - Only in the last login response/transition to FFP?
 
   My inclination is to only consider the connection to be part of the
   connection when it has successfully completed the entire login
   sequence, and thus to return the joined session's ExpCmdSN and
   MaxCmdSN only in the last login response.

2) When is the target supposed to perform the connection reinstatement
   algorithm, including the implicit logout for recovery of the
   existing ISID=1/TSIH=2/CID=3 connection?
 
   - Before security negotiation is complete?  Surely not, because
     this allows a denial of service attack.
 
   - After security negotiation is complete?
 
   - Just before sending the last login response/transition to FFP?
 
   My inclination is to only consider the connection to be part of the
   connection when it has successfully completed the entire login
   sequence, and thus do connection reinstatement just prior to sending
   the last login response.
 
3) Here's a more esoteric question: if the login sequence for one
   connection ISID=1/TSIH=2/CID=3 is still in LoginOpNegotiation stage,
   and the initiator starts another connection with the same
   ISID/TSIH/CID, what is the target supposed to do?  Does 'connection
   reinstatement' apply also to a connection which is not yet in FFP?
 
   My inclination is for the target to consider the second login
   request as spurious, and to return NotEnoughResources (since I
   am unwilling to dedicate two 'new connection' slots to the same
   ISID/TSIH/CID combination).

I cannot find any text in the iSCSI spec that unambiguously addresses
these issues.  Am I missing anything?  If not, would any of the
authors care to give guidance?
 
Thanks in advance for any help.
--
Joe Pittman
[email-masked] <mailto:[email-masked]>