Mallikarjun,

For case #1, that seems like a good idea but I don't think the spec says
this.

If an initiator is using MaxCmdSN and ExpCmdSN to update internal registers,
then suddenly forcing them to 0 may cause problems in current
implementations.

Eddy

----- Original Message ----- 
From: "Mallikarjun C." <cbm@rose.hp.com>
To: <pat_thaler@agilent.com>
Cc: <Joseph.Pittman@netapp.com>; <ips@ietf.org>
Sent: Tuesday, January 06, 2004 9:06 PM
Subject: Re: [Ips] iSCSI: When does a connection become part of a session?


> Let me attempt to answer Joe's questions and clarify
> a couple of Pat's points.
>
> On Joe's #1, I agree with Pat's comments - there is no
> need to return valid values of sequence numbers before
> the final successful login reponse.
>
> On Joe's #2, Joe said:
>    "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."
>
> This is indeed the intent.  Connection reinstatement
> should be performed only when the target is ready to
> signal the final approval for the login attempt on the
> connection in question.  A target cannot perform the
> reinstatement for an old CID instance unless it arrived
> at a new FFP connection with the same CID (clearly, I
> think, stated in 5.3.4), i.e. unless login process is
> successfully complete for the new instance.
>
> On Joe's #3, the general approach should be to allow
> new login attempts to proceed as long as the total
> number of connections is < MaxConnections.  At the
> time the target moves a connection to FFP, it should
> consider any earlier instance of the same CID to have
> been reinstated and drop the old instance (10.12.7).
> I thus would not recommend the approach you're leaning
> towards.  Note however that the 10.12.7 text assumes
> that the initiator is well-behaved - if the initiator
> is in fact launching multiple login requests at the
> same time for the same CID, then it's violating the MUST
> requirement in 10.12.7 - "The initiator connection
> state MUST be CLEANUP_WAIT (section 7.1.3) when the
> initiator attempts a connection reinstatement."
>
> On Pat's points -
>
>  > "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.
>
> Yes, as clarified above.
>
>  >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.
>
> True, that was intended.  However, there are two state
> machines here (CSM-C and CSM-I, borrowing 7.2 terminology),
> and note that Pat's clarification applies to CSM-C (i.e.
> the state machine representing the old instance).  The CSM-I,
> the new state machine the login is happening on, OTOH,
> takes the T7 transition from IN_LOGIN to FREE.
>
> A "failed connection reinstatement", however, should have
> been defined in the spec (as Pat says).  For a connection
> reinstatement effort to be considered "failed" and thus
> cause a state change to CSM-C on the target end, the effort
> should have progressed (and failed) beyond the SecurityNegotiation
> stage.  Ditto for session reinstatement.
>
> Hope that helps.
> -- 
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm [at] rose.hp.com
>
>
>
>
>
> pat_thaler@agilent.com wrote:
>
> > 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
> >     jpittman@netapp.com <mailto:jpittman@netapp.com>
> >
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips