Re: Login interoperability versus efficiency

["Julian Satran" <Julian_Satran@il.ibm.com>]

Howard,

Comments in text - Julo






"Cunningham, Howard" <Howard.Cunningham@spirentcom.com>
Sent by: owner-ips@ece.cmu.edu
05-11-01 17:19
Please respond to "Cunningham, Howard"

 
        To:     ips@ece.cmu.edu
        cc: 
        Subject:        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? 

++++

Operational parameters can't be negotiated together with authentication
This sequence will result in the session being dropped.
+++
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? 
+++ 

It was the group's will that parameters be segregated in stages.

++++

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 
+++

There are 3 distinct stages - and consesus on them was reached

+++


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... 
++++

I suggest you reread section 5

+++  
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