Login interoperability versus efficiency

["Cunningham, Howard" <Howard.Cunningham@spirentcom.com>]

Title: Login interoperability versus efficiency

I know that this is probably too late but I am concerned that some of iSCSI source code that I have seen indicates some development centers may not be considering all of the possible complexities of the session and connection establishment.

Since I am a test equipment vendor, I have been silently waiting as the login process has settled and hoping it would converge on a solution with assured interoperability.  It seems that efficiency (minimize the number of PDU exchanges) has been preferred to simplicity. Let me ask a question to higlight my concern:

Assume I am an Initiator who would like to get to full-feature phase as quickly as possible but I am willing authenticate. So I issue:

I-> Login (CSG=0, NSG=3,T=1)
        InitiatorName=iqn.1999-07.com.os.hostif.77
        TargetName=iqn.1999-07.com.acme.diskarray.sn.88
        AuthMethod=SRP,none
        SessionType=normal
        FMarker=send,no
        ImmediateData=yes,no
        InitiatR2T=yes,no
As I read the draft I believe this is a valid PDU. It is not clear to me:
1. Can the operational parameters be negotiated by the target along with the AuthMethod=SRP?
T->Login (CSG=0, NSG=1,T=0)
        AuthMethd=SRP
        FMarker=receive
        ImmediateData=no
        InitialR2T=no
2. Does the target 'defer' the operational parameters until after authentication (so that they are not 'revealed' to an unauthenticated party?

3. Does the target ignore or reject the initiator operational parameters?
4. Is this implementation dependent?

Just as authentication messages are rigid in nature (e.g., Intiator MUST send TargetAuth=yes along with SRP-U and not later with SRP_M - why not make two kinds of SRP - unidirectional, bidirectional?), why not make the entire login process more structured? At one time there were four possible values to CSG and NSG (I believe) and I would support a return to them with a more structured process. What I propose is:

1. Stage
        0 =Identication stage - Intiator and target identify each other, decide type of session and what kind of authentication

        1=Authentication stage - Initiator and target authenticate each other (optional)
        2=Operational stage - Initiator and target explicitly agree on operational parameters
        3=FullFeature stage
2. The first login request PDU (CSG=0) for any connection (new session or add-on) from the Initiator can only contain ONLY:

        InitiatorName {no default}, AuthMethod {no default}, SessionType (default normal), TargetName {if SessionType=normal, no default}

Arguably not sending a TargetName could imply a discovery session. These keys can ONLY be in this first PDU.
3. The first login response PDU from the target can only contain:
        AuthMethod=... with NSG=1 OR "login accepted" with NSG=2 OR "login rejected"
4. After the Initiator and Target have agreed to the authentication method if any, they exchange stage 1 authentication PDUs as appropriate and then transition to stage 2.

5. In Stage 2, the Initiator and Target negotiate operational parameters using ONLY TextOut PDUs and then transition to stage 3. I could live with using Login PDUs here instead of TextOut since the CSG has changed.

6. TextOut PDUs in stage 3 could be used ONLY to query operational parameters (which I think could be eliminated entirely).

7. With the more rigid process, the CSG and NSG are not really needed in the PDUs.

So for the 'simple' no authentication Discovery session, there would be
        1 login PDU exchange
        the Initiator TextOut PDU (MaxRcvPDULength=..., SendTargets=...)
        the Target TextOut replies
        1 logout PDU exchange

For the 'simple' no authentication Normal session, there would be
        1 login PDU exchange
        the Initiator TextOut PDU with negotiated operational parameters
        the Target TextOut reply negotiation results
        ----- full feature -------------
        1 logout PDU exchange
In this case, there is a mandatory, 'possibly extra' TextOut exchange to get to full-feature phase. I would argue that this is not significant for performance. Structure can be used to make things simpler and ease interoperability.

Regards...
 
Howard Cunningham, Senior MTS
Spirent Communications
900 Main Campus Drive, Suite 201
Raleigh, NC 27606
Voice: +1 (919) 829-6332
Fax: +1 (919) 829-6400
Email: howard.cunningham@spirentcom.com