Subject: Login interoperability versus efficiency

From: "Cunningham, Howard" <[email-masked]>
Date: Mon, 5 Nov 2001 07:19:29 -0800

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: [email-masked]

---

From: "Julian Satran" <[email-masked]>
Date: Mon, 5 Nov 2001 19:26:34 +0200

Howard,

Comments in text - Julo

"Cunningham, Howard" <[email-masked]>
Sent by: [email-masked]
05-11-01 17:19
Please respond to "Cunningham, Howard"

        To:     [email-masked]
        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

+++

        InitiatorName {no default}, AuthMethod {no default}, SessionType (default 
normal), TargetName {if SessionType=normal, no default}
7. With the more rigid process, the CSG and NSG are not really needed in 
the PDUs. 
        ----- 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

+++