Joe,
 
You raise interesting questions. For the first two items, I think I agree that your inclinations are sensible though not necessarily supported in the iSCSI draft. On the third one, I'm not sure. 
 
On 1 - treatment of MaxCmdSN and ExpCmdSN during login, it would make sense to withhold valid values for these fields at least until the security phase of Login has completed and there doesn't seem to be any reason to provide them before the last login. However, I don't find anything in the spec that supports doing this.  Under the description of status class for Login Response, it says 

The numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if Status-Class is 0.

which implies that the fields are valid when Status-Class is 0 including during the security phase.

On 2 - at what point in a connection reinstatement login does the old connection get closed,  5.3.4

The Login request performs the logout function of the old connection if an explicit logout was not performed earlier.

which appears to indicate that it is the reception of the initial Login Request PDU that causes the logout. As you suggest, actually operating this way would leave one vulnerable to denial of service type attacks. It makes more sense to wait until at least security phase has completed to do the logout. It may make sense to wait to do close the old connection until ready to send the final login response as you suggest because this login may not succeed. However for resource constrained implementations the reinstated connection may need resources allocated to the existing connection.

The state machine description might be hoped to provide more detail, but they don't seem to be entirely consistant. The definition in 7.1.2 for T8, (T13 and T18 have similar text)

-target: An internal event of sending a Logout response (success) on another connection for a "close the session" Logout request was received, or an internal event of a successful connection/session reinstatement is received, thus prompting the target to close this connection cleanly.

"Successful connection/session reinstatement" might be read to mean that the login for the new session successfully completed rather than just a login request was received. However note that a failed connection reinstatement causes T15 which moves the session from LOGGED_IN to CLEANUP_WAIT so a failed attempt would still disrupt an active connection. There doesn't seem to be any definition provided for successful and failed connection reinstatement. In the description of connection cleanup state transitions (7.2.2, M4) successful implicit logout appears to be defined as having reached the state LOGGED_IN on the new connection.

 On 3, I think connection reinstatement only applies to a connection that has completed login. The state transitions for the target connection state machine only allow for implicit logout in the LOGGED_IN state and in the states that follow it. The transition from IN_LOGIN to FREE, T4, doesn't make any mention of implicit logout or connection reinstatement. Time out or the transport going away are the things that get you from IN_LOGIN to FREE. One might get a second login attempt if there was a problem on the initial connection such as the network going down but it is probably okay to not accept it until the original attempt has disappeared due to time out or closure of the transport connection. Lack of resources would be a reasonable response. If one does have the resources, I'm not sure it is a necessary response. 

Regards,

Pat

 -----Original Message-----
From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of Pittman, Joseph
Sent: Tuesday, January 06, 2004 1:02 PM
To: ips@ietf.org
Subject: [Ips] iSCSI: When does a connection become part of a session?



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
 <mailto:jpittman@netapp.com> jpittman@netapp.com